AWS KMS (Key Management Service)

AWS KMS (Key Management Service) – Complete Guide for AWS Security Specialty

Why AWS KMS Is Important

AWS Key Management Service (KMS) is the cornerstone of data protection across virtually every AWS service. It provides centralized control over the cryptographic keys used to protect your data, making it one of the most heavily tested topics on the AWS Security Specialty exam. Understanding KMS is essential because:

• It integrates with over 100 AWS services for seamless encryption
• It enforces the principle of least privilege through key policies and IAM policies
• It helps organizations meet regulatory and compliance requirements (PCI DSS, HIPAA, FedRAMP, etc.)
• It provides an audit trail via AWS CloudTrail for all key usage
• It is the default encryption mechanism for most AWS managed services

What Is AWS KMS?

AWS KMS is a fully managed service that enables you to create, manage, and control cryptographic keys used to encrypt and decrypt your data. It uses Hardware Security Modules (HSMs) that are validated under FIPS 140-2 (Level 2, and Level 3 in some cases) to protect the security of your keys.

Key Concepts:

1. KMS Keys (formerly Customer Master Keys / CMKs)
These are the primary resources in KMS. There are several types:
• AWS managed keys – Created and managed by AWS on your behalf (e.g., aws/s3, aws/ebs). You cannot manage their rotation, deletion, or key policies directly.
• Customer managed keys (CMKs) – Created and managed by you. You have full control over key policies, rotation, enabling/disabling, and deletion.
• AWS owned keys – Keys owned and managed by AWS for use across multiple accounts. You do not see or manage these.

2. Data Encryption Keys (DEKs)
KMS uses a concept called envelope encryption. A KMS key is used to generate, encrypt, and decrypt data keys (DEKs). The DEK is then used to encrypt the actual data. This means the KMS key itself never leaves KMS; only the DEKs travel outside the service.

3. Key Policies
Every KMS key has a key policy – a resource-based policy that defines who can use and manage the key. Unlike most AWS services, KMS key policies are the primary mechanism for access control. Without the appropriate key policy, even IAM policies and root access may not grant permissions to the key.

4. Grants
Grants provide temporary, granular permissions to use KMS keys. They are often used by AWS services on your behalf (e.g., when EBS encrypts a volume, it creates a grant).

How AWS KMS Works

Envelope Encryption (Critical Concept)

1. You call GenerateDataKey API on a KMS key.
2. KMS returns a plaintext data key and an encrypted (ciphertext) copy of that data key.
3. You use the plaintext data key to encrypt your data locally.
4. You store the encrypted data key alongside the encrypted data.
5. You discard the plaintext data key from memory.
6. To decrypt: You send the encrypted data key to KMS via the Decrypt API. KMS returns the plaintext data key, which you then use to decrypt the data.

This approach means KMS never needs to handle large amounts of data directly, and the master key material never leaves the HSM boundary.

Symmetric vs. Asymmetric Keys

• Symmetric (AES-256) – Default and most common. The same key is used for encryption and decryption. The plaintext key material never leaves KMS unencrypted.
• Asymmetric (RSA, ECC, SM2) – Public/private key pairs. The public key can be downloaded and used outside AWS. Useful for sign/verify operations or encryption by parties who cannot call KMS.

Key Rotation

• AWS managed keys: Automatically rotated every year (you cannot change this).
• Customer managed keys: You can enable automatic rotation, which rotates key material every year (configurable to 90-2560 days as of recent updates). Old key material is retained so previously encrypted data can still be decrypted.
• Manual rotation: Create a new key and use aliases to point to the new key. This is necessary for asymmetric keys and imported key material.
• During automatic rotation, the key ID and ARN remain the same; only the backing key material changes. KMS keeps all previous versions of key material.

Imported Key Material

• You can import your own key material into a KMS key (BYOK – Bring Your Own Key).
• Imported keys do NOT support automatic rotation.
• You can set an expiration date on imported key material.
• If deleted, you can re-import the same key material; you cannot do this with KMS-generated material.
• The key material must be wrapped using a public key provided by KMS during the import process.

Multi-Region Keys

• KMS supports multi-Region keys that are replicated across AWS Regions.
• They share the same key ID and key material but are independent resources in each Region.
• Useful for cross-Region encryption scenarios (e.g., DynamoDB global tables, cross-Region S3 replication with encryption).
• They are NOT global; they are replicas managed independently with their own key policies.

Key Deletion

• You can schedule deletion of customer managed keys with a waiting period of 7 to 30 days (default 30).
• During the waiting period, the key is in Pending Deletion state and cannot be used.
• You can cancel deletion during the waiting period.
• Once deleted, all data encrypted under that key is permanently unrecoverable.
• Use CloudWatch alarms and CloudTrail to detect usage of keys pending deletion.

Cross-Account Access

To share a KMS key across accounts:
1. The key policy in the owning account must allow the external account (or specific principals) access.
2. The external account must have IAM policies granting its users/roles permission to use the key.
3. Both the key policy AND IAM policy must allow the action.

KMS and AWS Services Integration

• S3: SSE-KMS encryption; uses the GenerateDataKey and Decrypt APIs. Be aware of KMS request rate limits for high-throughput buckets.
• EBS: Encrypted volumes use KMS. Snapshots of encrypted volumes are also encrypted. You can copy snapshots and re-encrypt with a different key (useful for cross-account/cross-Region sharing).
• RDS: Encryption at rest via KMS. Cannot change encryption after creation. To encrypt an unencrypted database, create an encrypted snapshot copy and restore from it.
• Lambda: Environment variables can be encrypted with KMS.
• Secrets Manager: Secrets are encrypted using KMS keys.
• CloudTrail: All KMS API calls are logged, providing a full audit trail of key usage.

KMS Request Quotas (Throttling)

• KMS has per-second request quotas (vary by Region and key type, typically 5,500 to 30,000 requests/second for symmetric operations).
• If you exceed these limits, you get a ThrottlingException.
• Solutions: Use DEK caching (via the AWS Encryption SDK), request a quota increase, or use S3 bucket keys to reduce KMS calls.
• S3 Bucket Keys: A special feature that reduces KMS API calls by generating a bucket-level key that is used for a time-limited period to derive per-object keys.

KMS vs. CloudHSM

• KMS is multi-tenant (shared infrastructure), while CloudHSM gives you dedicated, single-tenant HSMs.
• KMS keys are managed by AWS; CloudHSM keys are managed entirely by you.
• CloudHSM is FIPS 140-2 Level 3; KMS is Level 2 (with Level 3 for the HSMs themselves).
• Use CloudHSM when you need full control over HSMs, contractual/regulatory requirements demand single tenancy, or you need custom key stores.
• KMS can use a Custom Key Store backed by a CloudHSM cluster, giving you KMS convenience with CloudHSM-level control.

KMS Condition Keys for Fine-Grained Access Control

• kms:ViaService – Restrict key use to specific AWS services.
• kms:CallerAccount – Restrict access to specific AWS accounts.
• kms:EncryptionContext – Require specific encryption context key-value pairs.
• kms:GrantIsForAWSResource – Allow grants only when created by AWS services.
• kms:KeyOrigin – Filter based on whether key material is AWS_KMS, EXTERNAL, or AWS_CLOUDHSM.

Encryption Context

• An optional set of key-value pairs that provide additional authenticated data (AAD) during encryption.
• The same encryption context must be provided during decryption.
• Encryption context is logged in CloudTrail, providing auditing capability without exposing sensitive data.
• It is NOT encrypted – it is plaintext metadata.

---

Exam Tips: Answering Questions on AWS KMS

1. Understand the Key Policy + IAM Policy Model
KMS uses a combined authorization model. The key policy is the primary gatekeeper. If the key policy does not grant access (either directly or by enabling IAM policies), then IAM policies alone will NOT work. When you see questions about access denied to KMS, check the key policy first.

2. Know Envelope Encryption Inside Out
If a question mentions encrypting large data (over 4 KB), the answer involves envelope encryption with GenerateDataKey. KMS can only directly encrypt up to 4 KB of data via the Encrypt API.

3. Cross-Account and Cross-Region Scenarios
For cross-account access: key policy + IAM policy. For cross-Region encrypted resource sharing (e.g., EBS snapshot copy), you need to re-encrypt with a key in the destination Region (or use multi-Region keys).

4. Key Rotation Questions
Remember: automatic rotation keeps the same key ID/ARN, rotates backing material only, and retains old material. Imported key material cannot be auto-rotated. Manual rotation requires aliases for seamless transition.

5. Deletion and Recovery
If a question asks about recovering deleted keys – once past the waiting period, it is gone. Best practice: disable the key first, monitor with CloudTrail, then schedule deletion. For imported key material, you can re-import.

6. Throttling and Performance
When you see high-volume encryption scenarios (e.g., millions of S3 PUTs with SSE-KMS), think about DEK caching (Encryption SDK), S3 Bucket Keys, or requesting quota increases.

7. Custom Key Stores
If a question requires FIPS 140-2 Level 3 and single-tenant HSMs while still using KMS APIs, the answer is KMS with a Custom Key Store backed by CloudHSM.

8. When to Choose KMS vs. CloudHSM vs. SSE-S3
• SSE-S3: Simplest, no key management, AWS handles everything. No audit trail of individual key usage.
• SSE-KMS: Key usage logged in CloudTrail, granular access control via key policies, supports rotation and cross-account sharing.
• CloudHSM: Regulatory requirement for dedicated HSMs, need for custom cryptographic operations not supported by KMS.

9. Encryption Context Is a Favorite Exam Topic
If a question mentions additional authentication or conditional decryption, encryption context is likely the answer. Remember it is logged in CloudTrail and is NOT secret.

10. Pay Attention to Key Origins
• AWS_KMS – generated by KMS (default)
• EXTERNAL – imported key material (BYOK)
• AWS_CLOUDHSM – Custom Key Store
Each has different capabilities regarding rotation, deletion, and availability.

11. Common Exam Traps
• AWS managed keys cannot have their key policy modified – if the question requires custom access control, the answer is a customer managed key.
• Disabling a key is immediate; deleting a key has a mandatory waiting period.
• You cannot export KMS key material (symmetric). If a question requires using key material outside AWS, consider asymmetric keys (public key download) or CloudHSM.
• KMS is Regional. A key in us-east-1 cannot directly encrypt/decrypt in eu-west-1 (unless using multi-Region keys).

12. Integration with Other Security Services
• AWS Config rules can check for KMS encryption compliance.
• AWS Organizations SCPs can enforce KMS usage across accounts.
• CloudTrail + CloudWatch can alert on suspicious key usage or keys pending deletion being accessed.
• AWS Secrets Manager and Parameter Store (SecureString) both rely on KMS.

By mastering these concepts, you will be well-prepared to handle the significant number of KMS-related questions on the AWS Security Specialty exam.