Cargando...
Cargando...
Centralized, managed encryption key lifecycle control for every AWS service and beyond
AWS Key Management Service (KMS) is a fully managed service that enables you to create, control, and rotate cryptographic keys used to encrypt your data across AWS services and custom applications. KMS integrates natively with over 100 AWS services, providing envelope encryption, key policies, and granular access controls backed by FIPS 140-2 validated hardware security modules (HSMs). Every key operation is logged to AWS CloudTrail, giving you a complete, auditable record of who used which key, when, and from where.
Centralize cryptographic key management, enforce data-at-rest and data-in-transit encryption policies, and maintain a tamper-evident audit trail across all AWS workloads without managing HSM infrastructure yourself.
Use When
Avoid When
Symmetric encryption keys (AES-256-GCM)
Default key type. Used for envelope encryption with GenerateDataKey. Cannot be exported.
Asymmetric key pairs (RSA, ECC, SM2)
Public key can be downloaded; private key never leaves KMS. Used for signing/verification and public key encryption.
HMAC keys
Used for GenerateMac and VerifyMac operations. Useful for token validation and message authentication.
Automatic key rotation
Symmetric customer managed keys only. Configurable 90–2560 days. Asymmetric and HMAC keys do NOT support automatic rotation.
Manual key rotation (key aliasing pattern)
For asymmetric keys or when you need rotation on your own schedule — create a new key, update the alias to point to it.
Bring Your Own Key (BYOK) / Key Import
Import your own key material into a KMS key. You are responsible for key material durability outside KMS. Key material can be deleted (key becomes unusable) and re-imported.
Custom Key Store (CloudHSM-backed)
Store key material in your own CloudHSM cluster. Satisfies FIPS 140-2 Level 3 and requirements for dedicated HSM control. Higher latency than standard KMS.
Custom Key Store (External / XKS)
External Key Store (XKS) allows key material to reside in an on-premises HSM or third-party key manager. KMS proxies cryptographic requests to your external key manager.
Multi-Region Keys
Replicate key material across Regions. Key IDs start with mrk-. Enables cross-Region decryption without re-encryption — critical for DR and global applications.
Key Policies (resource-based policy)
Every KMS key has exactly one key policy. IAM policies alone are NOT sufficient — the key policy must explicitly allow the principal or grant access to the root account.
Grants
Programmatic, delegatable permissions for specific cryptographic operations. AWS services use grants to access KMS keys on behalf of users (e.g., EBS, SSM, Secrets Manager).
VPC Endpoint (PrivateLink) for KMS
Keep KMS API traffic within the AWS network. Required for workloads in private subnets that cannot route to the public internet.
CloudTrail integration (automatic)
Every KMS API call is automatically logged to CloudTrail — who called what operation, on which key, from which IP, at what time. Cannot be disabled for KMS.
Cross-account key access
Key policy in Account A grants access to a principal in Account B. Account B's IAM policy must also allow KMS actions. Both conditions must be true.
Envelope Encryption
Generate a data key (plaintext + encrypted copy), use plaintext key to encrypt data locally, discard plaintext key, store encrypted data key with ciphertext. KMS never sees your actual data.
GenerateDataKeyWithoutPlaintext
Returns only the encrypted data key (no plaintext). Use when you want to pre-generate encrypted keys for future use without immediately encrypting data.
KMS key tagging
Tags support cost allocation, access control via tag-based IAM conditions, and organizational governance.
AWS managed keys (aws/service-name)
Created and managed by AWS on your behalf for specific services (e.g., aws/s3, aws/ebs). You cannot manage key policies, rotation schedule, or delete them. Free of charge.
S3 Server-Side Encryption with KMS (SSE-KMS)
high freqS3 calls KMS GenerateDataKey for each object (or uses a cached key). The encrypted data key is stored as object metadata. On download, S3 calls KMS Decrypt. Use S3 Bucket Keys to reduce KMS API calls by up to 99% by caching the data key at the bucket level — critical for cost and throttling management at scale.
Secrets encryption at rest
high freqSecrets Manager automatically encrypts every secret using a KMS key (default: aws/secretsmanager, or a CMK you specify). When rotating secrets, Secrets Manager uses a grant to call KMS on your behalf. Cross-account secret sharing requires the KMS key policy to grant access to the consuming account.
KMS audit trail and CloudTrail log encryption
high freqEvery KMS API call is automatically logged in CloudTrail — this cannot be disabled. Additionally, CloudTrail log files themselves can be encrypted with a KMS CMK, providing encryption of the audit trail. Use CloudTrail + CloudWatch Logs + metric filters to alert on unauthorized KMS key usage or key deletion attempts.
Lambda environment variable encryption and application-level encryption
high freqLambda encrypts environment variables at rest using an AWS managed key (aws/lambda) by default. You can specify a CMK for additional control. Inside Lambda code, use the AWS SDK to call KMS GenerateDataKey for application-level envelope encryption. Use data key caching in the Lambda execution environment to avoid KMS calls on every invocation.
Dual-layer access control (key policy + IAM policy)
high freqKMS access requires BOTH the key policy to allow the principal AND the IAM policy to allow the KMS action (unless the key policy explicitly delegates all access to IAM). This dual-layer model is a frequent exam topic. The key policy is the ultimate authority — even an account root cannot use a KMS key if the key policy doesn't permit it.
EBS volume encryption
high freqWhen you create an encrypted EBS volume, EC2 calls KMS to generate a data key. The encrypted data key is stored with the volume metadata. EC2 decrypts the data key in memory (never on disk) and uses it for AES-256 encryption of all I/O. Snapshots of encrypted volumes are automatically encrypted with the same key. Copying a snapshot allows re-encryption with a different key.
RDS database encryption at rest
high freqRDS encryption must be enabled at creation time — you cannot encrypt an existing unencrypted RDS instance directly. Workaround: create a snapshot, copy the snapshot with encryption enabled, restore from the encrypted snapshot. Read replicas inherit the encryption status of the primary. Cross-region read replicas require a CMK in the destination Region.
Private CA and certificate private key protection
medium freqAWS Private CA (ACM PCA) uses KMS to protect the private keys of your private certificate authority. You specify a CMK when creating the private CA. This allows you to control, audit, and revoke access to CA private key operations via KMS key policy.
Custom Key Store (CloudHSM-backed KMS)
medium freqFor workloads requiring FIPS 140-2 Level 3 validation or dedicated HSM tenancy, create a KMS Custom Key Store backed by your CloudHSM cluster. KMS operations are proxied to CloudHSM. You get KMS API compatibility plus dedicated hardware. Higher cost and latency than standard KMS.
DynamoDB table encryption at rest
medium freqDynamoDB supports three encryption options: AWS owned key (free, default), AWS managed key (aws/dynamodb — free, CloudTrail visibility), or CMK (full control, $1/month). CMK option enables key policy control and cross-account scenarios. DynamoDB Streams and Global Tables also support encryption.
The key policy is the ONLY mandatory access control for KMS keys. Even the AWS account root user cannot use a KMS key if the key policy doesn't grant access. IAM policies are a secondary layer — they work only when the key policy delegates authority to IAM (which the default key policy does for the root account). If you lock yourself out of a key, AWS Support cannot recover it for you.
AWS managed keys (e.g., aws/s3, aws/ebs, aws/rds) CANNOT be shared across accounts, cannot have their key policy modified, cannot be rotated on your schedule, and cannot be deleted by you. They are account-scoped and service-specific. Any exam question suggesting cross-account use of AWS managed keys is describing an impossible scenario.
Envelope encryption is the answer whenever the question involves encrypting data larger than 4 KB or asks about performance-efficient encryption. The pattern: GenerateDataKey → encrypt data locally with plaintext key → store encrypted data key with ciphertext → discard plaintext key. KMS never sees your actual data payload.
Key rotation does NOT re-encrypt existing ciphertext. KMS retains all previous key versions (backing keys) indefinitely to decrypt data encrypted with older key versions. Only new encryption operations use the new key material. This is why you can enable rotation without breaking existing encrypted data.
For cross-account KMS key usage: (1) The key policy in the key-owner account must explicitly grant access to the external account or principal. (2) The IAM policy in the consuming account must also allow the KMS actions. BOTH conditions are required. Missing either one means access is denied.
AWS managed keys (aws/s3, aws/ebs, etc.) are NEVER shareable across accounts. Cross-account encryption ALWAYS requires a customer managed key (CMK) with an explicit cross-account key policy grant.
KMS key policy is the primary access control — it must explicitly allow access OR delegate to IAM. IAM policies alone are insufficient if the key policy doesn't grant the account root or delegate to IAM. Lock yourself out = permanent loss of key access.
Envelope encryption solves the 4 KB limit and performance problem: GenerateDataKey → encrypt data locally → store encrypted data key with ciphertext → discard plaintext key. KMS never processes your actual data.
Multi-Region Keys (mrk- prefix) solve the problem of cross-Region decryption without re-encryption. Use case: encrypt in us-east-1, replicate encrypted data to eu-west-1, decrypt in eu-west-1 using the replica key. Without Multi-Region Keys, you would need to decrypt in the source Region and re-encrypt in the destination — expensive and complex.
RDS encryption must be set at creation. To encrypt an existing unencrypted RDS instance: take a snapshot → copy snapshot with encryption enabled → restore from the encrypted snapshot. This is a frequently tested operational scenario.
S3 Bucket Keys dramatically reduce KMS API calls and costs for SSE-KMS. When enabled, S3 generates a short-lived bucket-level data key from KMS and uses it to encrypt individual object keys locally — reducing KMS API calls by up to 99%. This also reduces the risk of hitting KMS request rate quotas.
KMS key deletion has a mandatory waiting period of 7–30 days (default 30 days, minimum 7 days). During this period, the key is disabled. Use CloudTrail + CloudWatch alarms to detect if any application is still calling the key during the waiting period — if so, cancel deletion. You cannot immediately delete a KMS key.
KMS vs CloudHSM decision framework: KMS = managed, multi-tenant, FIPS 140-2 Level 2, integrated with AWS services, lower cost. CloudHSM = dedicated single-tenant hardware, FIPS 140-2 Level 3, you manage the HSM, required for some strict compliance mandates. KMS Custom Key Store bridges both — KMS API with CloudHSM backing.
Asymmetric KMS keys do NOT support automatic key rotation. If you need to rotate asymmetric keys, you must do it manually: create a new asymmetric key pair, update your alias to point to the new key, and update any systems that cache the public key.
ThrottlingException from KMS is solved by: (1) implementing exponential backoff and retry in your application, (2) using data key caching (AWS Encryption SDK), (3) enabling S3 Bucket Keys for S3 workloads, (4) requesting a quota increase via AWS Service Quotas. Never solve KMS throttling by switching to client-side encryption without KMS — that defeats the audit trail.
Common Mistake
AWS managed keys (like aws/s3, aws/ebs) can be shared across AWS accounts to enable cross-account encryption scenarios.
Correct
AWS managed keys are strictly account-scoped and service-scoped. They cannot be shared with other accounts, their key policies cannot be modified, and they cannot be used in cross-account scenarios. For cross-account encryption, you MUST use a customer managed key (CMK) with a key policy that explicitly grants access to the external account.
This is the #1 KMS misconception on certification exams. Candidates assume that because AWS manages the key, it is somehow more shareable. The opposite is true — AWS managed keys are the MOST restricted. Remember: AWS manages them FOR you, not FOR others.
Common Mistake
Enabling key rotation in KMS will re-encrypt all existing data with the new key material, potentially breaking applications.
Correct
Key rotation ONLY affects new encryption operations. KMS retains all previous key versions (called 'backing keys') indefinitely. Existing ciphertext can still be decrypted because KMS knows which backing key version was used (encoded in the ciphertext metadata). Applications never need to be updated when rotation occurs.
This misconception causes candidates to fear enabling key rotation or to think they need to re-encrypt data after rotation. Understanding that KMS maintains all backing keys is critical — rotation is transparent to applications.
Common Mistake
AWS KMS can replace AWS CloudHSM in all use cases, including those requiring FIPS 140-2 Level 3 validation and dedicated hardware tenancy.
Correct
Standard KMS is validated to FIPS 140-2 Level 2. CloudHSM provides FIPS 140-2 Level 3 with dedicated, single-tenant hardware under your control. Some compliance frameworks (certain government, financial, and defense requirements) explicitly mandate Level 3 or dedicated HSM hardware — KMS alone cannot satisfy these. KMS Custom Key Store (CloudHSM-backed) bridges the gap but at significantly higher cost and complexity.
Exam questions test whether you know the compliance boundary. When you see 'FIPS 140-2 Level 3' or 'dedicated HSM' in a question, the answer involves CloudHSM or KMS Custom Key Store — not standard KMS.
Common Mistake
You can encrypt an existing unencrypted RDS database by simply enabling encryption in the RDS console settings.
Correct
RDS encryption can only be enabled at database creation time. To encrypt an existing unencrypted RDS instance, you must: (1) create a snapshot of the unencrypted database, (2) copy the snapshot and enable encryption during the copy, (3) restore a new database instance from the encrypted snapshot, (4) update your application connection strings. This is a multi-step operational process.
This is a classic operational scenario on SAA-C03 and DOP-C02. The trap is assuming you can flip a switch on a running database. The snapshot copy + restore pattern is the only supported path.
Common Mistake
KMS key policies work just like S3 bucket policies — if the IAM policy allows KMS actions, the principal can use the key even without an explicit key policy entry.
Correct
KMS key policies are the primary and mandatory access control mechanism. Unlike S3 (where IAM policies alone can grant access), KMS requires the key policy to explicitly allow access OR to delegate authority to IAM. The default key policy grants the AWS account root full access and allows IAM policies to control access for other principals — but if you create a custom key policy that omits this delegation, IAM policies alone will NOT grant access.
Understanding the key policy as the 'root of trust' for KMS access is critical. The most dangerous mistake is creating a key policy that locks out all principals, including the account root — this makes the key permanently inaccessible and requires AWS Support intervention (which may not be able to help).
Common Mistake
Using a dedicated on-premises HSM or hybrid HSM architecture is more cost-effective than using AWS KMS for cloud-native workloads.
Correct
For cloud-native workloads, AWS KMS is almost always more cost-effective: no hardware procurement, no HSM maintenance staff, no physical security costs, built-in HA/redundancy, and pay-per-use pricing at $0.03 per 10,000 API calls. On-premises or hybrid HSM architectures carry significant capital and operational expenses that dwarf KMS costs at any reasonable scale. Only very specific compliance requirements justify the premium of dedicated HSM hardware.
Exam questions sometimes present hybrid HSM architectures as a cost optimization strategy — this is a trap. The correct answer for cost optimization in cloud-native encryption is KMS (or KMS with S3 Bucket Keys/data key caching to reduce API costs further).
KMS Access = KEY POLICY first, IAM second. Remember 'KP-IAM': Key Policy is the King, IAM is the Assistant. The King must say yes before the Assistant's opinion matters.
Envelope Encryption = 'Lock the box, then lock the key': Encrypt data with a data key (lock the box), then encrypt the data key with KMS (lock the key to the box), throw away the original key, keep only the locked version.
AWS managed vs Customer managed keys: 'AWS manages THEIR keys, you manage YOUR keys.' AWS managed = THEIR rules (no sharing, no custom policy, no deletion). Customer managed = YOUR rules (cross-account, custom policy, configurable rotation).
RDS Encryption timing: 'You can't put a lock on a house after it's built — only during construction.' Encryption must be set at RDS creation. Snapshot → Copy with encryption → Restore = the renovation path.
KMS vs CloudHSM: 'KMS = Hotel safe (managed, shared building, convenient). CloudHSM = Your own vault (dedicated, you hold the only key, expensive but maximum control).'
CertAI Tutor · DOP-C02, DVA-C02, SAA-C03, SAP-C02, DEA-C01, SCS-C02, AIF-C01, CLF-C02 · 2026-02-21
In the Same Category
Comparisons
Guides & Patterns