Encryption at rest and key management: KMS and CloudHSM
8 min read · about 1 h 25 min with practice3 quick checks≈4% of the testStretch: Stretch: harder material that separates the top grades
Reading is free. Sign in to tick off lessons, keep your place and track your mastery.
Encryption at rest is the largest single topic in task statement 1.3, and Domain 1 carries 30% of the exam. Expect three to five questions on which key type gives enough control, why a KMS call is denied, how to encrypt a resource that was created unencrypted, or how to move encrypted data between accounts and Regions.
By the end you’ll be able to
Choose AWS owned, AWS managed or customer managed KMS keys, or CloudHSM/external key stores, based on control and compliance needs
Write key policies and grants for cross-account use and explain why both the key policy and IAM must allow access
Select S3 encryption: SSE-S3, SSE-KMS (with S3 Bucket Keys), DSSE-KMS, SSE-C or client-side, and enforce it with bucket policies and default encryption
Encrypt an existing unencrypted EBS volume or RDS instance via encrypted snapshot copy and restore; enable EBS encryption by default
Configure automatic key rotation and multi-Region keys for cross-Region workloads
What the exam asks
SAA-C03 does not test cryptography. It tests who controls the key, who can use it, and what AWS cannot change once a resource exists. The stems repeat a few patterns:
“Control the key policy”, “audit every use”, “disable the key immediately” or “share with another account” → a customer managed KMS key.
“KMS throttling or a high KMS bill with SSE-KMS” → S3 Bucket Keys.
“Decrypt the same ciphertext in two Regions” → multi-Region keys.
Core ideas
Key types and who controls them
Key
Edit key policy
Rotation
Cross-account
AWS owned
No (not visible in your account)
Handled by the service
No
AWS managed (aws/s3, aws/ebs, aws/rds)
No
Automatic, yearly
No
Customer managed
Yes
Optional automatic (365 days by default, configurable) or on demand
Yes
Customer managed, imported material
Yes
No automatic rotation
Yes
Custom key store (CloudHSM or external)
Yes
Manual only
Yes
AWS managed keys need no management, but you cannot share them, disable them or change their policy. Any need for control points to a customer managed key.
Key policies, IAM and grants
Every key has exactly one , and it is the primary control. IAM policies take effect . The default key policy does this with a statement for the account’s root principal. Without that statement, only the principals named in the key policy can use the key, whatever IAM says.
vii.Check your understanding
3 questions on encryption at rest and key management: KMS and CloudHSM. Every option is explained once you answer.
Sign in to try the quick check
Answers are checked on our side, every option is explained, and your result feeds your mastery for this topic. It’s free.
The first 3 of 12 cards for this topic. Sign in and finish the lesson to review them with spaced repetition.
PromptCard 1 of 3
AWS owned vs AWS managed vs customer managed KMS key: which one lets you edit the key policy, disable the key and share it across accounts?
key policy
only if the key policy allows the account
Cross-account use needs both sides to allow it. The key policy in the owning account must name the other account or role, and an IAM policy in the calling account must allow the action on the key ARN. An alias can point only to a key in its own account and Region. Grants give temporary, narrowly scoped permissions, and services such as EBS use them on your behalf. SCPs never grant access. They only set limits.
Envelope encryption
The Encrypt API accepts at most 4 KB of plaintext. For larger data, call GenerateDataKey and encrypt the data locally with the plaintext data key, then discard that key. Store the encrypted data key next to the data and send it back to KMS to decrypt. S3, EBS and RDS use this method internally. For client-side encryption, the AWS Encryption SDK does it for you.
Rotation and deletion
Automatic rotation creates new key material and keeps the same key ID and ARN. The old material is kept, so older data still decrypts, and nothing is re-encrypted.
Asymmetric keys, HMAC keys, keys in custom key stores and keys with imported material never rotate automatically. To rotate one manually, create a new key and repoint the alias.
Deletion requires a 7–30 day waiting period, and after that the data is lost for good. If you are not sure a key is unused, disable it first.
Imported key material is generated by you. You can give it an expiry date or delete it immediately, which makes the data unreadable until you import the same material again.
Multi-Region keys
A multi-Region key is a set of related keys in different Regions that share the same key ID and key material. Data encrypted in one Region can be decrypted in another without calling across Regions. Use them for client-side encryption of data that is replicated between Regions. S3 Cross-Region Replication and cross-Region snapshot copies do not need them, because those services re-encrypt the data with a key in the destination Region. An existing single-Region key cannot be converted into a multi-Region key.
CloudHSM and custom key stores
AWS CloudHSM gives you a cluster of single-tenant HSMs in your VPC. You manage the HSM users and keys, and AWS runs the hardware but has no access to your keys. Applications use standard interfaces (PKCS#11, JCE, Microsoft CNG), which suits Oracle TDE, TLS offload and private certificate authorities. Deploy at least two HSMs in different AZs. KMS HSMs are also FIPS 140-3 Level 3 validated, so choose CloudHSM for tenancy and control, not for its FIPS level.
A custom key store keeps KMS keys in your CloudHSM cluster. AWS services still integrate through KMS, but the key material stays in HSMs that only you control. An external key store keeps the key material in a key manager outside AWS. It gives the most control and carries the most risk: if that key manager is unreachable, every KMS request fails.
Encrypting each service
Service
What to know
S3
SSE-S3 by default. SSE-KMS adds control and auditing, and Bucket Keys reduce KMS cost and throttling. DSSE-KMS adds a second layer for strict compliance. SSE-C (you send the key with every request) is blocked on new buckets by default since April 2026. Client-side encryption protects data before upload.
EBS
Turn on encryption by default per account and per Region. You cannot encrypt a volume in place: snapshot it, then create an encrypted copy or an encrypted volume.
RDS and Aurora
Encryption is chosen at creation. For an existing database: snapshot, encrypted copy, restore. Read replicas have the same encryption state as their source.
DynamoDB
Always encrypted. Choose the AWS owned key (the default), the AWS managed key or a customer managed key.
EFS
Encryption is chosen at creation. For an existing file system, create a new encrypted one and copy the data with DataSync.
KMS keys are Regional. A cross-Region snapshot copy must name a key in the destination Region.
Worked examples
Exam technique
Find the control verb: “edit, disable, share or audit” (customer managed key), “exclusive HSM control” (CloudHSM), “remove the key material now” (imported material).
Eliminate every option that enables encryption on an existing RDS instance, EBS volume or EFS file system.
If a call returns AccessDenied although IAM allows it, fix the key policy.
SSE-KMS plus throttling or cost means Bucket Keys, not a quota increase.
For LEAST operational overhead, KMS beats CloudHSM unless the stem requires single tenancy.
Common mistakes
Quick recap
Customer managed keys give you control: key policy, disabling, rotation and cross-account sharing.
IAM works only when the key policy allows the account, and cross-account access needs both sides.
Data larger than 4 KB needs envelope encryption with GenerateDataKey.
Existing RDS and EBS resources are encrypted by snapshot, copy and restore. EFS needs a new file system and DataSync.
Turn on EBS encryption by default in every Region you use.
Use Bucket Keys for SSE-KMS cost and throttling, and DSSE-KMS for two layers of encryption.
Multi-Region keys decrypt client-side ciphertext in other Regions. All other keys are Regional.
CloudHSM gives single tenancy, a custom key store adds native integration, and imported material can be removed immediately.