Deep Dive on AWS Key Management Service

AWS Key Management Service (AWS KMS) is the centralized key management layer for the AWS cloud, controlling the encryption keys that protect data across more than 100 AWS services and customer applications. It matters because the security of every encrypted S3 object, EBS volume, RDS database, and Lambda secret depends on who controls the KMS keys protecting them and how those keys are governed. The recommended starting point is creating customer-managed KMS keys with an explicit key policy, enabling automatic rotation, and configuring CloudTrail to capture every encrypt and decrypt event tied to an authenticated identity.

Quick Answer: Which AWS KMS Key Type Should You Use?

For regulated workloads: always use customer-managed KMS keys. They are the only type that gives you an independent per-operation audit trail in CloudTrail, a key policy you control, the ability to disable or delete the key independently, and support for BYOK (imported key material). For general workloads where compliance does not require customer key control: AWS-managed keys are acceptable and require zero operational overhead. AWS-owned keys provide no audit trail and no customer visibility; avoid them for any sensitive data. For the highest key protection requirement (FIPS 140-2 Level 3 with dedicated hardware): use a custom key store backed by AWS CloudHSM.

Key Takeaways

• KMS key material never leaves the HSM in plaintext: All KMS keys are generated and used inside FIPS 140-2 validated HSMs. Standard KMS uses Level 2; custom key stores backed by CloudHSM use Level 3.
• AWS KMS uses envelope encryption for all data protection: KMS generates and protects data encryption keys (DEKs). The KMS key encrypts the DEK; the DEK encrypts the data. The KMS key itself never encrypts data directly.
• Customer-managed keys are required for compliance audit trails: Only customer-managed keys generate per-operation CloudTrail events (GenerateDataKey, Decrypt) tied to specific IAM identities.
• Key policy and IAM policy must both allow an action: AWS KMS access control requires both the key resource policy and the calling principal’s IAM identity policy to permit the operation. Neither alone is sufficient in most configurations.
• Automatic rotation does not require re-encrypting existing data: When a KMS key rotates, KMS retains previous key versions to decrypt data encrypted before the rotation. The key ARN stays the same; applications do not need updating.

What Is AWS Key Management Service?

AWS Key Management Service (AWS KMS) is a managed cryptographic key management service that creates, stores, and controls access to the encryption keys that protect AWS workloads. When you enable encryption on an S3 bucket, an EBS volume, an RDS instance, or a Secrets Manager secret, AWS KMS generates and protects the keys that make that encryption meaningful.

AWS KMS stores all key material inside hardware security modules (HSMs) validated to FIPS 140-2 Level 2 for standard KMS keys. Key material generated in AWS KMS never leaves the HSM boundary in plaintext. When an AWS service or application needs to encrypt or decrypt data, it calls the KMS API, KMS performs the key operation inside the HSM, and returns only the result. AWS KMS integrates natively with over 100 AWS services including Amazon S3, Amazon EBS, Amazon RDS, Amazon DynamoDB, AWS Lambda, AWS Secrets Manager, Amazon Redshift, Amazon EFS, and AWS Systems Manager Parameter Store.

How AWS KMS Uses Envelope Encryption

AWS KMS does not encrypt your data directly. It uses envelope encryption: a master key (the KMS key) protects a data encryption key (DEK), and the DEK encrypts the actual data. Envelope encryption keeps data encryption local while protecting the key in hardware, because KMS keys never leave the HSM and large data payloads cannot be sent to KMS for direct encryption.

Write operation: the application calls kms:GenerateDataKey. KMS generates a new DEK inside the HSM and returns a plaintext DEK and an encrypted DEK. The application encrypts the data with the plaintext DEK, discards the plaintext DEK immediately, and stores the encrypted DEK alongside the ciphertext. The encrypted DEK can only be unwrapped by KMS using the original KMS key.

Read operation: the application sends the encrypted DEK to KMS via kms:Decrypt. KMS unwraps it inside the HSM and returns the plaintext DEK. The application decrypts the data and immediately discards the plaintext DEK. The KMS key never leaves the HSM; only the DEK moves between KMS and the application.

AWS KMS Key Types: AWS-Managed, Customer-Managed, and AWS-Owned

AWS KMS organizes keys into three types with significantly different control, visibility, and compliance properties. The naming changed in 2021 from CMK (Customer Master Key) to KMS key, but the underlying types remain the same.

Customer-Managed KMS Keys

Customer-managed keys are created by you in your AWS account. You define the key policy, control who can use and manage the key, enable or disable the key, schedule deletion, and configure automatic rotation. Every GenerateDataKey and Decrypt call generates a CloudTrail event with the key ARN, the requesting IAM principal, the source IP, and a timestamp. This per-operation audit trail is the core compliance capability that customer-managed keys provide and other key types do not. Customer-managed keys cost $1 per key per month plus $0.03 per 10,000 API calls. They support three key material origins: AWS-generated, BYOK (imported), and custom key store (CloudHSM-backed).

AWS-Managed KMS Keys

AWS-managed keys are created automatically by AWS services the first time you enable encryption without specifying a customer-managed key. The alias follows the pattern aws/service-name (for example, aws/s3, aws/ebs, aws/rds). You can view key metadata but cannot change the key policy, disable the key, schedule deletion, or control rotation. AWS automatically rotates AWS-managed keys every three years. No additional charge beyond standard API call fees.

AWS-Owned KMS Keys

AWS-owned keys are owned and managed entirely by AWS and shared across multiple customer accounts. They are not visible in your KMS console, you have no control over them, and they generate no CloudTrail events in your account. Appropriate for non-sensitive data where zero management overhead is the priority, but unsuitable for any regulated workload requiring an audit trail or customer key control.

Property	Customer-Managed Key	AWS-Managed Key	AWS-Owned Key
Created by	Customer	AWS service	AWS
Visible in your account	Yes	Yes	No
Key policy control	Full customer control	None	None
Disable/delete capability	Yes	No	No
Per-operation CloudTrail events	Yes (every GenerateDataKey and Decrypt)	Limited	No
Automatic rotation	Optional (90 days to 7 years)	Yes (every 3 years)	Varies
BYOK support	Yes	No	No
Cost	$1/key/month + $0.03/10k API calls	$0.03/10k API calls only	No charge
Best for	Regulated workloads, compliance, audit requirements	General workloads, low overhead	Non-sensitive, zero-management scenarios

Symmetric, Asymmetric, and HMAC KMS Keys

Symmetric KMS keys use a single 256-bit AES-GCM key for both encryption and decryption. The key material never leaves AWS KMS in plaintext. Symmetric keys are correct for most data protection use cases: encrypting S3 objects, EBS volumes, RDS databases, and Secrets Manager secrets. Most AWS services that integrate with KMS support only symmetric keys.

Asymmetric KMS keys hold a public/private key pair. The private key never leaves KMS in plaintext. The public key can be downloaded and used outside KMS. Asymmetric KMS keys support RSA (for encryption/decryption or signing/verification) and ECDSA (for signing/verification only). Use asymmetric keys when you need a public key to distribute to external parties while the private key remains protected in KMS. AWS services that encrypt data at rest use symmetric keys exclusively.

HMAC KMS keys generate and verify Hash-Based Message Authentication Codes for token validation, API request signing, and data integrity verification. They use symmetric key material but serve authentication rather than encryption purposes.

IAM Model: How Access Control Works in AWS KMS

AWS KMS access control is the most commonly misconfigured aspect of KMS deployments. The two-layer policy model requires both the key resource policy and the calling principal’s IAM identity policy to permit an operation.

Key policy (resource-based policy): Every customer-managed KMS key has a mandatory key policy that is the primary access control mechanism. If the key policy does not explicitly grant an IAM principal permission to use the key, that principal cannot use the key regardless of its IAM identity policy. If the key policy includes the statement granting the root account key management permissions, IAM policies in that account can grant key management permissions to principals in the account. This is the default policy created by the KMS console.

IAM identity policy: An IAM identity policy can grant KMS permissions, but only if the key policy also permits the principal. For data-plane operations (Encrypt, Decrypt, GenerateDataKey, Sign), apply least privilege in both the key policy and the IAM identity policy.

Separation of key management from key use: Separate the key administrator role (who can manage key policies, rotation, deletion, and disable/enable) from the key user role (who can call Encrypt, Decrypt, GenerateDataKey). Application service accounts should have only the specific cryptographic operation permissions they need on specific keys, never key management permissions.

Service control policies (SCPs): In an AWS Organization, SCPs provide a guardrail layer above IAM policies. Use an SCP to deny deletion of production KMS keys, require encryption on specific services, or prevent disabling KMS logging through CloudTrail. SCPs operate as a maximum permission boundary; they cannot grant permissions, only restrict them.

BYOK in AWS KMS: Bring Your Own Key Material

BYOK (Bring Your Own Key) in AWS KMS means importing key material generated outside AWS into a KMS key. BYOK is used when regulations or internal policy require that encryption key material be generated in customer-controlled infrastructure and that the customer retain the original key material independently of AWS.

The BYOK import process: create a KMS key with no key material (Origin: EXTERNAL); download the wrapping public key and import token from KMS; generate 256-bit AES key material in your own HSM; encrypt your key material using the wrapping public key (RSA_OAEP_SHA_256); upload the encrypted key material and import token to KMS. KMS decrypts the key material inside the HSM and stores it as the KMS key’s key material.

BYOK constraints: you can set an expiration date on imported key material, after which KMS automatically deletes it. You can manually delete imported key material without deleting the key, immediately making all data encrypted with it inaccessible until re-imported. Automatic rotation is not available for BYOK keys; you must generate new material externally and re-import it.

HYOK: Hold Your Own Key

HYOK (Hold Your Own Key) goes further than BYOK: the encryption key never enters AWS KMS at all. Your application encrypts data client-side before uploading to any AWS service, using a key generated and stored in your own infrastructure. AWS stores only ciphertext and cannot decrypt your data under any circumstance, including a legal demand directed at AWS.

HYOK is appropriate for classified data, sovereignty requirements where AWS infrastructure is outside your trust boundary, or workloads where your threat model includes AWS itself. Every read and write requires a round-trip to your external key management system, which must be highly available. Encryption Consulting’s HSM as a Service provides the external FIPS 140-2 Level 3 key management infrastructure needed to implement HYOK for AWS workloads.

Dimension	Native KMS (AWS-generated key)	BYOK (Imported key material)	HYOK (Client-side, key outside AWS)
Key generated by	AWS KMS HSM	Customer (imported into KMS)	Customer (never enters AWS)
AWS access to key during use	Yes	Yes (operational)	No
CloudTrail audit trail	Yes (per operation)	Yes (per operation)	No (external KMS logs only)
Independent revocation	Disable/delete key via API	Delete imported material (immediate)	Revoke at external KMS
Automatic rotation	Yes (90 days to 7 years)	No (manual re-import required)	Fully customer-managed
Operational complexity	Low	Medium	High
Best for	Most AWS workloads	Regulated: customer key provenance required	Classified, zero-trust, sovereignty-mandated

KMS Custom Key Store: FIPS 140-2 Level 3 with CloudHSM

A KMS custom key store associates AWS KMS with an AWS CloudHSM cluster you own and manage. KMS key material is generated and stored in your CloudHSM cluster at FIPS 140-2 Level 3, rather than the standard KMS Level 2 infrastructure. Keys in a custom key store are 256-bit AES-GCM, non-exportable, and never leave the CloudHSM HSMs in plaintext. All cryptographic operations are performed inside your CloudHSM cluster.

Custom key stores require at least two active HSMs in different Availability Zones. If the cluster becomes unavailable, KMS cannot perform operations on those keys, meaning your application availability depends on your CloudHSM cluster. Custom key stores are appropriate for FedRAMP High workloads requiring FIPS 140-2 Level 3, eIDAS qualified signature operations, or organizations with existing CloudHSM infrastructure wanting Level 3 validation within the KMS API experience.

Key Rotation in AWS KMS

AWS KMS key rotation generates new cryptographic material for a KMS key and marks it as the active version for new encrypt operations, while retaining all previous key versions for decrypting data encrypted before the rotation. The key ARN, key ID, and all aliases remain unchanged. Applications continue to function after rotation without any configuration changes.

For customer-managed keys with AWS-generated material, automatic rotation is configurable between 90 days and 7 years. When rotation occurs, KMS generates new key material inside the HSM, marks it as active, and logs a RotateKey CloudTrail event. Previous material versions are retained indefinitely.

For BYOK keys with imported material, automatic rotation is not available. You must manage rotation manually: generate new 256-bit AES key material outside AWS, import it as a new key version, and designate it as the primary material. On-demand rotation for customer-managed keys with AWS-generated material is available anytime via the RotateKeyOnDemand API, useful after a suspected key exposure event.

CloudTrail Logging for AWS KMS

Every AWS KMS API call generates a CloudTrail management event by default. Every encrypt, decrypt, key creation, key deletion, and policy change is logged with the requesting identity, key ARN, timestamp, and source IP. Key events to monitor and alert on:

• GenerateDataKey: Logged when a service or application creates a new data encryption key. Alert on unexpected principals generating data keys.
• Decrypt: Logged when a service or application decrypts a data encryption key. Alert on any Decrypt call from a principal not in the approved role list. High-volume Decrypt calls may indicate data exfiltration.
• ScheduleKeyDeletion: Alert immediately on any production key being scheduled for deletion. KMS enforces a minimum 7-day waiting period.
• DisableKey: Alert immediately. A disabled key stops all encrypt and decrypt operations, causing immediate outages.
• PutKeyPolicy: Alert on any key policy change for production keys. Policy changes can expand or restrict key access.
• RotateKey / RotateKeyOnDemand: Log for compliance evidence. Unexpected rotation events should be investigated.

Route CloudTrail logs to a separate, write-protected S3 bucket in a dedicated security account. Enable CloudTrail log file integrity validation. Enable S3 data events separately as object-level operations are not captured in management event logs by default.

AWS KMS Cost: Pricing and Optimization

Customer-managed keys cost $1 per key per month. AWS-managed and AWS-owned keys have no key storage charge. All KMS API calls cost $0.03 per 10,000 requests. For high-volume S3 workloads, KMS API costs accumulate because every S3 PutObject generates a GenerateDataKey call and every GetObject generates a Decrypt call. An S3 workload with 10 million PUT and GET operations per month generates approximately $60 per month in KMS API fees.

The S3 Bucket Key feature reduces this cost by up to 99%. When enabled, S3 generates a short-lived bucket-level data key from your KMS key and uses it to generate individual object DEKs locally within S3, rather than calling KMS for every object. Security properties are unchanged; objects remain encrypted with AES-256-GCM under a key hierarchy tracing back to your KMS key. For custom key store keys backed by CloudHSM, the cluster costs approximately $1.45 per hour per HSM instance, approximately $2,100 per month for a two-instance HA cluster, in addition to standard KMS fees.

AWS KMS in Multi-Cloud and Hybrid Architectures

AWS KMS is AWS-native and does not extend natively to Azure, GCP, or on-premises systems. Three patterns address AWS KMS in a multi-cloud context:

• Per-cloud native KMS with unified governance: Use AWS KMS for AWS, Azure Key Vault for Azure, and GCP Cloud KMS for GCP, but deploy a centralized key lifecycle management platform aggregating key inventory, rotation status, and audit logs across all three. This preserves native cloud performance while providing cross-cloud compliance visibility.
• Centralized BYOK from an external HSM: Generate all key material from a single external HSM. Import derived keys into AWS KMS as BYOK keys, into Azure Key Vault, and into GCP Cloud KMS. All encryption traces back to a single authoritative key source. Encryption Consulting’s HSM as a Service provides the external FIPS 140-2 Level 3 HSM infrastructure for this model.
• Client-side encryption with a shared key (HYOK): Encrypt all data before it enters any cloud provider. AWS KMS is not involved; the cloud stores only ciphertext. Strongest multi-cloud sovereignty model but requires applications to handle cryptographic operations client-side and your external KMS to be highly available.

How Encryption Consulting Can Help

Encryption Consulting is an applied cryptography firm with ISO/IEC 27001:2022 and SOC 2 certifications. We help organizations design, implement, and audit AWS KMS configurations from initial key architecture through ongoing compliance evidence generation.

• Cloud Data Protection Advisory: We assess your AWS KMS configuration, identify gaps (AWS-owned keys where customer-managed keys are required, missing key policies, absent CloudTrail data events, S3 buckets without Bucket Key optimization, over-permissive key policies), and design the target key hierarchy, IAM model, rotation schedule, and audit configuration. See our cloud advisory services.
• HSM as a Service: For BYOK and HYOK architectures requiring FIPS 140-2 Level 3 key generation outside AWS, Encryption Consulting’s HSM as a Service provides dedicated HSM infrastructure integrating with AWS KMS key import workflows, suitable as the BYOK source across AWS, Azure, and GCP simultaneously.
• CBOM Secure: Encryption Consulting’s CBOM Secure discovers and inventories all KMS key configurations, access policies, and rotation statuses across AWS accounts, generating a Cryptographic Bill of Materials in CycloneDX format supporting PCI DSS v4.0.1 Requirement 12.3.3 compliance documentation.
• PKI as a Service: For AWS workloads using mutual TLS between services or deploying AWS Private CA for internal certificate issuance, Encryption Consulting’s PKI as a Service provides a managed private CA with ACME-automated certificate lifecycle management and KMS-backed CA key storage. See also our guide on AWS S3 client and server-side encryption.
• PQC Readiness: NIST finalized post-quantum cryptography standards FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. NIST IR 8547 points toward deprecating RSA and ECC for new uses around 2030. AWS KMS RSA and ECC asymmetric keys will need migration. Encryption Consulting’s PQC Readiness service maps your AWS KMS key estate against the post-quantum migration timeline.
• Compliance Advisory: We map your AWS KMS configuration to PCI DSS v4.0.1, FedRAMP, HIPAA, DORA, NIST CSF 2.0, and NIST SP 800-53 Rev. 5 requirements, identify gaps, build the remediation roadmap, and produce the audit evidence package. See our Compliance Advisory Services.

To discuss your AWS KMS architecture or compliance requirements, contact Encryption Consulting.

Conclusion

AWS KMS is the key management foundation for the AWS cloud. The choice between AWS-managed, customer-managed, and BYOK keys is a compliance and sovereignty decision that determines whether your organization has an independent audit trail, independent revocation capability, and independent key provenance.

The most common KMS misconfigurations are using AWS-managed or AWS-owned keys where compliance requires customer-managed keys, over-permissive key policies granting broad KMS access to application roles, absent or misconfigured CloudTrail data events leaving gaps in the audit trail, and missing S3 Bucket Key configuration unnecessarily multiplying KMS API costs. Getting these right from the start is significantly easier than remediating them across a large AWS estate after a compliance audit surfaces them.

Frequently Asked Questions

What is AWS Key Management Service (AWS KMS)?

AWS Key Management Service (AWS KMS) is a managed service that creates and controls encryption keys used to protect data across AWS services and applications. AWS KMS stores key material in FIPS 140-2 validated HSMs (Level 2 for standard keys, Level 3 for custom key store keys). Key material never leaves the HSM in plaintext. AWS KMS integrates natively with over 100 AWS services including S3, EBS, RDS, Lambda, and Secrets Manager.

What is the difference between AWS-managed keys, customer-managed keys, and AWS-owned keys?

AWS-managed keys are created automatically by AWS services; you can view them but cannot change their policy, disable them, or control rotation. Customer-managed keys are created by you with full key policy control, per-operation CloudTrail audit trail, and the ability to disable or delete; they cost $1 per key per month. AWS-owned keys are invisible to you, shared across accounts, and generate no CloudTrail events. For regulated workloads, customer-managed keys are required.

How does envelope encryption work in AWS KMS?

AWS KMS generates a data encryption key (DEK) when called by a service or application, returning a plaintext DEK and an encrypted copy. The application encrypts data with the plaintext DEK, discards it, and stores only the encrypted DEK alongside the ciphertext. To decrypt, the application sends the encrypted DEK to KMS, which decrypts it inside the HSM and returns the plaintext DEK. The KMS key never leaves the HSM; only the DEK moves between KMS and the application.

What is BYOK in AWS KMS and how does it work?

BYOK means generating key material in your own HSM and importing it into an AWS KMS key with Origin set to EXTERNAL. You download a wrapping key from KMS, encrypt your key material with it, and upload the encrypted material. AWS KMS uses your material for cryptographic operations but you retain the original outside AWS. You can delete the imported material from KMS to immediately revoke usability. Automatic rotation is not available for BYOK keys.

How does key rotation work in AWS KMS?

Automatic rotation generates new key material inside the KMS HSM on a schedule you configure (90 days to 7 years for customer-managed keys). Previous material versions are retained for decrypting data encrypted before the rotation. The key ARN and key ID remain unchanged. For BYOK keys, automatic rotation is unavailable; you generate new material externally and re-import it manually. On-demand rotation is available anytime via the RotateKeyOnDemand API.

What AWS KMS events appear in CloudTrail and how should you monitor them?

Every KMS API call generates a CloudTrail event. Alert immediately on ScheduleKeyDeletion and DisableKey for any production key, on Decrypt calls from principals not in the approved role list, and on high-volume Decrypt events suggesting exfiltration. Alert on PutKeyPolicy changes for production keys. Route CloudTrail logs to a write-protected S3 bucket in a dedicated security account. Enable S3 data events separately as object-level operations are not captured in management event logs by default.