AWS KMS: Key Types, Encryption Workflows, Rotation, and Key Policies

Purpose of This Lesson

AWS Key Management Service (KMS) creates and manages encryption keys used by AWS services and applications. For the AWS Certified CloudOps Engineer Associate (SOA-C03), the important decisions involve selecting the correct key type, understanding who controls the key, choosing an appropriate encryption workflow, interpreting rotation behavior, and configuring key policies or grants.

Key Concepts

KMS keys

A KMS key contains the key material used for encryption and decryption. KMS keys were previously called customer master keys (CMKs), so that older terminology may still appear in technical material or assessment questions.

KMS can create symmetric and asymmetric KMS keys. By default, KMS generates the key material, although key material can also be imported for supported use cases. KMS keys are protected by hardware security modules (HSMs).

A KMS key can directly encrypt only up to 4 KB of data. It is therefore not normally used to encrypt large files or large data volumes directly.

Data encryption keys

For larger amounts of data, use envelope-encryption behavior:

1. KMS generates, encrypts, or decrypts a data encryption key (DEK).
2. The application uses the plaintext DEK to encrypt the data.
3. The application must manage the DEK and perform the data-encryption operations outside KMS.

KMS does not store, manage, track, or perform the bulk-data cryptographic operations with the DEK. Application code is responsible for using and managing the data key appropriately.

KMS key ownership and control

Key type	Who creates and manages it?	Learner control
Customer managed KMS key	The customer or developer	Can view and manage the key; automatic rotation is optional and can occur every 365 days for supported keys
AWS managed KMS key	AWS, for an integrated AWS service	Can use the key through the service, but cannot manage the key, change its key policy, or configure its rotation; rotation is required and occurs every 365 days
AWS owned key	AWS	Cannot view or manage it; it is used generally by AWS and is outside the account’s control

AWS managed keys are associated with integrated services such as Amazon SQS, AWS Certificate Manager (ACM), Amazon EBS, and Amazon FSx. When an AWS service uses an AWS managed KMS key, the service performs the cryptographic operations rather than application code directly calling the key for those operations.

External and custom key stores

An external key store (XKS) allows key material to remain in an external key manager outside AWS. This may support regulatory or control requirements. With XKS, key material does not leave the external HSM.

A custom key store uses an AWS CloudHSM cluster that the customer owns and manages. Keys are generated and stored in that CloudHSM cluster, and cryptographic operations are performed solely there. Custom key stores are not available for asymmetric KMS keys.

KMS Key Rotation and Policy Operations

Automatic rotation

Automatic rotation changes the key material while preserving the KMS key’s identity. The following properties remain unchanged:

• Key ID
• ARN
• Region
• Policies and permissions
• Aliases that refer to the key

Because the key ID and ARN remain stable, applications generally do not need to be changed after automatic rotation is enabled. For the supported key types described in this lesson, AWS rotates the key material every 365 days.

Automatic rotation is supported only for symmetric encryption keys with key material generated by KMS, where the origin is AWS_KMS. It is not supported for:

• Asymmetric KMS keys
• HMAC KMS keys
• Keys in custom key stores using CloudHSM
• KMS keys with imported key material

Manual rotation

Manual rotation is required when automatic rotation is unavailable or when the operator chooses to replace the key. The process is:

1. Create a new KMS key.
2. Receive a different key ID.
3. Update applications or configurations that reference the old key ID.
4. Optionally repoint an alias to the new key.

Using an alias can reduce application changes because the application continues to reference the alias while the alias is associated with the replacement key.

Key policies and grants

KMS key policies control both management and usage permissions. Separate policy statements can distinguish administrative actions from cryptographic operations.

Administrative permissions include actions such as describing, creating, updating, and managing a KMS key. Usage permissions include cryptographic actions such as encrypting, decrypting, and re-encrypting data.

Grants delegate key usage permissions, including to AWS services. They are useful for temporary permissions because they can be created or revoked without modifying the key policy or an IAM policy. Relevant grant actions include CreateGrant, ListGrants, and RevokeGrant.

A kms:ViaService condition can restrict use of a key to specified AWS services. For example, a policy can limit usage to EC2 and RDS rather than allowing unrestricted use by other callers.

Cross-account encrypted snapshot sharing

When sharing an encrypted snapshot with another account, the receiving workflow requires permissions to decrypt the data and create a grant. The relevant permissions from the lesson are decrypt and create grant.

Cryptographic erasure

If imported key material may have been exposed, deleting that imported key material prevents the associated encrypted data from being decrypted again. This is called cryptographic erasure. The operation is destructive and should only be used when the consequences are understood.

Parameter Store diagnostic clue

An InvalidKeyIdException from Systems Manager Parameter Store can indicate that the configured KMS key is not enabled. The error should prompt an operator to check the key’s enabled state and related configuration.

Exam- or Assessment-Relevant Takeaways

• A KMS key directly encrypts no more than 4 KB; use a data encryption key for large data volumes.
• KMS protects key material with HSMs.
• Customer managed keys provide customer control; AWS managed keys are service-managed and AWS owned keys are outside the account’s control.
• AWS managed KMS keys cannot be rotated or have their key policies changed by the customer.
• Automatic rotation changes key material but does not change the key ID, ARN, policies, permissions, or aliases.
• Automatic rotation applies only to supported symmetric keys with KMS-generated key material.
• Imported key material, asymmetric keys, HMAC keys, and custom key-store keys require manual rotation if rotation is needed.
• Manual rotation creates a new key ID. An alias can shield application code from that key replacement.
• Grants provide a way to delegate or revoke temporary key permissions without modifying IAM or key policies.
• kms:ViaService narrows key usage to named AWS services.
• Deleting imported key material is a cryptographic-erasure technique and can make existing encrypted data permanently unrecoverable.

Tool / Feature Decision Guide

Requirement or scenario	Appropriate choice	Reason
Encrypt a small value of 4 KB or less directly	KMS key	Direct KMS encryption is limited to 4 KB
Encrypt a large file or large data volume	Data encryption key with KMS	The application performs bulk encryption while KMS protects or generates the DEK
Need customer control over key management and policy	Customer managed KMS key	The customer can view and manage the key and configure supported rotation
Let an integrated AWS service handle encryption with minimal customer management	AWS managed KMS key	AWS creates and manages the key for the service
Keep key material outside AWS for external control or regulatory reasons	External key store	Key material remains in the external key manager or HSM
Use dedicated AWS-owned CloudHSM infrastructure	Custom key store	Keys and cryptographic operations remain in the customer’s CloudHSM cluster
Replace a key without changing application references	Manual rotation plus an alias	Repoint the alias to the replacement key
Delegate temporary access without editing policies	Grant	Grants can be created, listed, and revoked independently
Restrict a key to specific AWS services	kms:ViaService condition	Limits usage through named services such as EC2 or RDS

Common Traps / Misconceptions

• Assuming KMS encrypts arbitrarily large data directly: Direct KMS encryption is limited to 4 KB. Large data requires a DEK and application-side bulk encryption.
• Confusing customer managed, AWS managed, and AWS owned keys: These categories differ primarily in who can view, manage, rotate, and control the key.
• Assuming automatic rotation creates a new key ID: Automatic rotation changes key material but preserves the key ID and ARN.
• Assuming every KMS key supports automatic rotation: Asymmetric, HMAC, imported-material, and custom key-store keys do not support the automatic rotation described here.
• Treating AWS managed keys like customer managed keys: Customers cannot change their policies, rotate them, or use them directly for cryptographic operations outside the integrated service.
• Assuming a DEK is managed by KMS after generation: KMS helps generate, encrypt, and decrypt the DEK, but the application must use and manage it.
• Confusing an external key store with a custom key store: XKS uses an external key manager outside AWS; a custom key store uses a customer-owned AWS CloudHSM cluster.
• Deleting imported key material as a routine rotation method: Deletion can permanently prevent decryption and should be treated as a destructive cryptographic-erasure action.
• Ignoring the key state behind Parameter Store errors: InvalidKeyIdException can indicate that the referenced KMS key is disabled.

Real-World Engineer / Analyst Notes

• Choose customer managed keys when operational control, policy customization, or deliberate lifecycle management is important. Choose AWS managed keys when service-integrated encryption is sufficient and direct key administration is not required.
• Document whether an application references a key ID, ARN, or alias. Aliases are especially useful when planning manual key replacement because they reduce code changes.
• Treat data encryption keys as sensitive application-managed material. The security of the envelope-encryption design depends on how the application handles, stores, and disposes of the DEK.
• Before deleting imported key material, identify every dataset and service that depends on it. Cryptographic erasure is irreversible from the perspective of the affected encrypted data.
• When troubleshooting a KMS-integrated service, check key type, key state, permissions, policy conditions, grants, and whether the service is authorized through kms:ViaService.

Quick Reference Summary

• KMS purpose: Create and manage encryption keys.
• Direct encryption limit: 4 KB per KMS key operation.
• Large-data pattern: KMS protects a data encryption key; application code encrypts the data.
• Customer managed key: Customer can manage it; automatic rotation is optional for supported keys.
• AWS managed key: AWS manages it for an integrated service; customer cannot alter its policy or rotation.
• AWS owned key: Completely outside the customer’s visibility and control.
• Automatic rotation: Changes key material while preserving key ID, ARN, policies, permissions, and aliases.
• Manual rotation: Creates a new key ID; an alias can reduce application changes.
• External key store: Key material remains in an external key manager.
• Custom key store: Key material and cryptographic operations reside in a customer-managed CloudHSM cluster.
• Grants: Useful for temporary delegated permissions.
• kms:ViaService: Restricts key use to specified AWS services.
• Cryptographic erasure: Delete imported key material to remove the ability to decrypt associated data.

Flashcards

Q: An application must encrypt several gigabytes of data. Should it call a KMS key for every block of plaintext?

A: No. The application should use KMS to generate, encrypt, or decrypt a data encryption key, then use that DEK for bulk encryption outside KMS.

Q: What is the maximum amount of data that a KMS key can directly encrypt according to this lesson?

A: A KMS key can directly encrypt up to 4 KB of data.

Q: A team needs to control the key policy and choose whether to enable supported automatic rotation. Which KMS key type fits?

A: A customer managed KMS key, because the customer can view and manage it and configure supported rotation.

Q: When would an AWS managed KMS key be preferable to a customer managed key?

A: Use an AWS managed key when an integrated AWS service should handle the encryption and AWS-managed lifecycle is sufficient. The customer gives up direct key-policy and rotation control.

Q: How does automatic rotation differ from manual rotation?

A: Automatic rotation changes the key material while preserving the key ID and ARN. Manual rotation creates a new KMS key with a different key ID and may require configuration changes unless an alias is used.

Q: Which KMS key properties remain stable during automatic rotation?

A: The key ID, ARN, Region, policies, permissions, and aliases remain unchanged while the underlying key material changes.

Q: An asymmetric KMS key uses imported key material. Can it use the automatic rotation described in the lesson?

A: No. Automatic rotation is not supported for asymmetric keys or imported key material; replacement requires manual rotation if needed.

Q: Why use an alias during manual KMS key rotation?

A: The application can continue referring to the alias while the alias is repointed to the new key, avoiding direct code changes to the key ID.

Q: When would an organization choose an external key store?

A: When key material must remain in an external key manager or HSM, such as for regulatory or external-control requirements. The key material does not leave that external HSM.

Q: What distinguishes a custom key store from an external key store?

A: A custom key store uses a customer-owned AWS CloudHSM cluster, where keys and cryptographic operations reside. An external key store uses an external key manager outside AWS.

Q: What is the purpose of a KMS grant?

A: A grant delegates key permissions, often temporarily, and can be created or revoked without modifying the KMS key policy or IAM policy.

Q: A key policy must allow use only through EC2 and RDS. Which condition concept should be considered?

A: Use the kms:ViaService condition to restrict key usage to the named AWS services.

Q: What permissions are important when sharing an encrypted snapshot with another account?

A: The recipient workflow needs decrypt and create-grant permissions so the snapshot can be used across accounts.

Q: What is the operational consequence of deleting imported key material?

A: It performs cryptographic erasure: data encrypted with that material can no longer be decrypted. The action should be treated as destructive.

Q: What can an InvalidKeyIdException from Systems Manager Parameter Store indicate?

A: It can indicate that the referenced KMS key is not enabled, so the key state should be checked during troubleshooting.

Practice Questions

Question 1

A service encrypts large objects. The architect wants KMS protection but does not want the application to send the entire object directly to KMS. What should the engineer recommend?

A. Encrypt the object directly with the KMS key in one operation
B. Use a data encryption key for the object and use KMS to protect the DEK
C. Use an AWS owned key and store the plaintext object in the application
D. Create an asymmetric KMS key for each object

Correct answer: B

Explanation: KMS direct encryption is limited to 4 KB. A DEK is used for large data, while KMS generates, encrypts, or decrypts the DEK.

Question 2

An application references a customer managed KMS key by its key ID. The security team enables automatic rotation. What should the engineer expect?

A. The key ID and ARN change every 365 days
B. The application must be updated after each rotation
C. The key material changes while the key ID and ARN remain the same
D. The key policy and permissions are deleted during rotation

Correct answer: C

Explanation: Automatic rotation changes the underlying key material but preserves the key identity and associated policies, permissions, and aliases.

Question 3

A company must retain key material in a key manager outside AWS to satisfy a regulatory requirement. Which option best matches this requirement?

A. AWS owned key
B. AWS managed KMS key
C. External key store
D. Customer managed KMS key with automatic rotation

Correct answer: C

Explanation: An external key store keeps key material in an external key manager, and the material does not leave the external HSM.

Question 4

An administrator wants to grant an AWS service temporary access to use a KMS key without editing the key policy or IAM policy. Which feature should be used?

A. KMS grant
B. AWS owned key
C. Manual key rotation
D. Imported key material

Correct answer: A

Explanation: Grants provide delegated permissions that can be created or revoked independently of the key and IAM policies.

Question 5

An application receives InvalidKeyIdException from Systems Manager Parameter Store when retrieving an encrypted value. Which initial check is most consistent with the lesson?

A. Whether the KMS key is enabled
B. Whether the KMS key is asymmetric
C. Whether the data exceeds 4 KB
D. Whether the alias has been deleted after automatic rotation

Correct answer: A

Explanation: The lesson identifies a disabled KMS key as a possible cause of this exception from Parameter Store.

WordPress Metadata

Suggested Slug:
aws-kms-key-types-rotation-policies-soa-c03

Meta Description:
Study AWS KMS key types, data encryption keys, external and custom key stores, rotation behavior, key policies, grants, and common CloudOps assessment traps.

Tags:
AWS KMS, AWS security, encryption, key management, data encryption keys, AWS CloudHSM, key rotation, KMS key policies, AWS Certified CloudOps Engineer, SOA-C03