Domain 5 of 6 · Chapter 2 of 3

Data at Rest

Choosing the key service: KMS vs CloudHSM

A common exam stem reads "a regulator requires keys in a single-tenant, dedicated HSM under the customer's sole control" and dangles AWS KMS as the cheap answer. The deciding question is custody and tenancy, not the FIPS number. AWS KMS[1] is a managed, multi-tenant key service: AWS operates the hardware security modules (HSMs), and those HSMs are validated at FIPS 140-3 Security Level 3[2] in every Region where KMS runs. AWS CloudHSM[3] gives you a dedicated, single-tenant HSM cluster that only you can access; AWS manages the appliance but never holds your keys.

When each one wins

Reach for KMS by default. It integrates natively with S3, EBS, RDS, DynamoDB, and dozens of other services through one-line encryption settings, costs $1 per customer-managed key per month plus $0.03 per 10,000 requests, and handles availability and durability for you. Because KMS already meets FIPS 140-3 Level 3, a bare "we need FIPS 140-3 Level 3" requirement no longer differentiates the two services. The CloudHSM triggers are specific: single-tenancy, dedicated hardware you exclusively control, full key custody where AWS must have no path to the key, or a contractual mandate to run your own HSM. CloudHSM is billed hourly per HSM (see the AWS pricing calculator) and you own cluster sizing, high availability, and backups.

Bridging the two with a custom key store

The two services are not mutually exclusive. A KMS custom key store[4] backs KMS keys with an AWS CloudHSM cluster (or an external HSM via an external key store). You then call KMS APIs and get native service integration, but the key material lives in your dedicated HSM. This is the pattern for "we need CloudHSM custody but also need S3/EBS to encrypt using KMS": the requirement is not KMS or CloudHSM, it is KMS fronting CloudHSM.

AWS KMSMulti-tenant, AWS-operatedFIPS 140-3 Level 3 HSMsAWS CloudHSMSingle-tenant, dedicatedSole customer key custodyKMS custom key storeKMS API, keys in your HSMCustody required?
KMS is the multi-tenant default; CloudHSM gives sole custody; a KMS custom key store fronts CloudHSM with the KMS API.

S3 server-side encryption and Bucket Keys

Picture a 50-million-object data lake encrypted with SSE-KMS: every read and write calls KMS once, and the KMS request bill dwarfs the storage cost. That scenario is what S3 Bucket Keys exist to fix, but first the four S3 encryption modes need pinning down because exam options mix them deliberately.

The four modes

Server-side encryption with S3-managed keys (SSE-S3)[5] encrypts each object with an AES-256 key S3 manages for you; it is the default for every new bucket since January 5, 2023[6], so objects are already encrypted with no action. Server-side encryption with KMS keys (SSE-KMS)[7] uses a KMS key, so every use is logged in CloudTrail and gated by the key policy, giving you auditability and per-key access control. Dual-layer SSE-KMS (DSSE-KMS)[8] applies two independent AES-256 layers; only the first layer is KMS-backed and the second uses a separate S3-managed key, so it is not two KMS layers. Use DSSE-KMS only when a requirement explicitly names dual-layer at-rest encryption. Server-side encryption with customer-provided keys (SSE-C)[9] has you send the key on every request; S3 uses it to encrypt or decrypt and then discards it, so AWS never stores your key. Note the vendor term is "customer-provided keys," not "customer-supplied." Beyond all of these, client-side encryption encrypts bytes before they leave your application, so AWS only ever sees ciphertext.

How Bucket Keys cut cost

Without a Bucket Key, S3 makes an individual GenerateDataKey/Decrypt call to KMS for every object operation. An S3 Bucket Key[10] is a short-lived, bucket-level key S3 derives from your KMS key and caches briefly; S3 uses it to generate the per-object data keys, so it stops calling KMS for each object. AWS states this reduces KMS request costs by up to 99 percent. It changes only cost and the CloudTrail encryption context, which becomes the bucket ARN instead of the object ARN, so any key policy that scoped access using the object ARN as encryption context must be rewritten to the bucket ARN. Two limits matter for the exam: Bucket Keys are not supported for DSSE-KMS, and enabling a Bucket Key affects only new objects, so existing objects need a CopyObject to adopt it.

aws s3api put-bucket-encryption --bucket my-data-lake \
  --server-side-encryption-configuration '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"aws:kms","KMSMasterKeyID":"<key-arn>"},"BucketKeyEnabled":true}]}'
Without Bucket KeyObject 1Object 2Object NKMSOne KMS call per objectWith Bucket KeyObject 1..NBucket-level key(cached in S3)KMSFew KMS calls totalup to 99% fewer requests
Bucket Keys derive one cached bucket-level key to wrap many objects, replacing per-object KMS calls and cutting request cost up to 99%.

Integrity and immutability: Object Lock, Glacier Vault Lock, signing

Encryption keeps data secret but an attacker who gains write access can still delete or overwrite it, which is exactly how ransomware destroys recoverability. The control for that is write-once-read-many (WORM) immutability, and the recurring exam distinction is governance mode versus compliance mode.

S3 Object Lock

S3 Object Lock[11] enforces WORM on object versions and works only on a bucket with S3 Versioning enabled. It offers two retention modes plus an independent legal hold. In governance mode, a protected version cannot be deleted or have its lock shortened unless the caller holds s3:BypassGovernanceRetention and sends the bypass header, so designated operators retain an escape hatch. In compliance mode, no one can overwrite, delete, or shorten the retention of a protected version, not even the AWS account root user; the documentation states the only way to remove the object before its retain-until date is to close the AWS account. A legal hold uses s3:PutObjectLegalHold, has no expiry, and holds the version until someone explicitly removes it, independent of any retention period. Use governance mode when trusted admins may need to correct mistakes, compliance mode when a regulator demands true immutability, and a legal hold when you cannot predict the duration, such as during litigation.

S3 Glacier Vault Lock and signing

For archive vaults, S3 Glacier Vault Lock[12] enforces a vault-level policy, such as "deny deletes for five years," through a two-step lock: you initiate the lock and have 24 hours to test and then complete it, after which the policy is immutable. This is a different feature from S3 Object Lock and from AWS Backup Vault Lock, a distinction the exam tests directly. Integrity at the bits level is separate from immutability: S3 validates object integrity with checksums on upload and download, and for code artifacts AWS Signer produces digital signatures so consumers (for example Lambda code signing) can reject any tampered package.

Retention period known?(versioning required)Legal holdno expiry, removableNoTrusted admin override allowed?YesGovernance modeBypassGovernanceRetentionCompliance modeimmutable even to rootYesNo
S3 Object Lock: governance mode allows a permissioned override, compliance mode is immutable even to root, legal hold has no expiry.

Lifecycle, backup, and ransomware resilience

The last piece of data-at-rest design is keeping copies that survive both cost pressure and a malicious admin. Two questions drive the answers: where should aging data go, and how do backups stay recoverable when an attacker holds your credentials?

Lifecycle and retention

S3 Lifecycle[13] rules transition objects to cheaper classes or expire them on a schedule. A frequently-tested limit: you cannot transition to S3 Standard-IA or One Zone-IA until objects are at least 30 days old, while transitions to Glacier classes can fire from day 0 (their own minimum-duration billing still applies: 90 days for Glacier Instant/Flexible Retrieval, 180 days for Deep Archive). Amazon EFS lifecycle management[14] moves files to Infrequent Access or Archive storage classes after a configured idle period, and FSx file systems carry their own backup-retention policies. Object Lock retention can double as a retention solution where records must persist for a fixed legal period.

Backup and ransomware resilience

AWS Backup[15] centralizes scheduled backups across services into backup vaults. The ransomware control is AWS Backup Vault Lock[16], which enforces WORM on recovery points in the same two-mode model: governance mode can be removed by a sufficiently-permissioned IAM principal, while compliance mode becomes fully immutable once its cooling-off "grace time" of at least 3 days (72 hours) expires, after which neither the root user nor AWS can delete recovery points or the vault until their lifecycle completes. Combine a compliance-mode locked vault with cross-account copies into a separate, locked-down account to create a logically air-gapped backup that a single compromised account cannot erase, and use cross-Region copies for regional resilience. Amazon Data Lifecycle Manager (DLM)[17] automates EBS snapshot and AMI schedules, retention, and cross-account/cross-Region copy specifically for EBS.

DataSync versus AWS Backup

The two are easy to confuse. AWS DataSync[18] is a data-transfer service for moving large datasets between on-premises storage, other clouds, and AWS storage (or between AWS storage services), with in-transit encryption and integrity verification. AWS Backup is for policy-driven, point-in-time backups with retention and immutability. If the stem says "migrate or replicate file data," think DataSync; if it says "scheduled, retained, immutable recovery points," think AWS Backup with Vault Lock.

Source accountAWS Backup planCompliance-locked vaultgrace time >= 3 daysimmutable to root and AWSIsolated backup accountair-gapped, locked vaultCross-Region copyregional resiliencebackupcross-account copycopy
Ransomware-resilient backup: a compliance-locked vault plus cross-account copy to an isolated account and cross-Region copy.

S3 server-side encryption options compared

PropertySSE-S3SSE-KMSDSSE-KMSSSE-C
Key owner / locationS3-managedYour KMS keyYour KMS key (one layer)You supply per request
Encryption layersSingle (AES-256)Single (AES-256)Dual independent layersSingle (AES-256)
Per-use audit in CloudTrailNoYes (KMS events)Yes (KMS events)No (AWS never sees key)
Access control via key policyNoYesYesNo
S3 Bucket Key cost cutN/AYes (up to 99%)Not supportedN/A
Default on new bucketsYes (since Jan 2023)NoNoNo

Decision tree

Plaintext may reach AWS?Client-side encryptionAWS sees only ciphertextNoYou hold the key per request?YesSSE-Csupply key each callYesSole custody / single-tenant?(not just FIPS 140-3 L3)NoCloudHSMor KMS custom key storeYesDual-layer mandated?NoDSSE-KMStwo AES-256 layersYesSSE-KMS + S3 Bucket Keyauditable, up to 99% less KMS costNoAlways-on baseline: SSE-S3 default since Jan 2023
Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

SSE-S3 is the default encryption on every new bucket since January 2023

Server-side encryption with S3-managed keys (SSE-S3) applies AES-256 automatically to all new buckets created on or after January 5, 2023, with no per-bucket action required. An exam answer claiming objects are unencrypted by default, or that you must turn encryption on, is outdated. SSE-S3 gives no per-use CloudTrail audit and no key-policy access control, which is why you upgrade to SSE-KMS when those are required.

Use SSE-KMS when you need per-use audit and key-policy access control

SSE-KMS encrypts S3 objects with a KMS key, so every encrypt and decrypt is recorded in CloudTrail and gated by the key policy, giving auditability and fine-grained access control that SSE-S3 cannot. The cost is a KMS request per object operation unless you enable an S3 Bucket Key. Reach for SSE-KMS when a requirement names auditable key usage, key rotation control, or restricting decryption to specific principals.

1 question tests this
DSSE-KMS is two AES-256 layers, only one of which is KMS-backed

Dual-layer server-side encryption (DSSE-KMS) applies two independent AES-256 layers to an object: the first uses a KMS data key, the second uses a separate S3-managed key, so it is not two KMS layers. Use it only when a requirement explicitly names dual-layer at-rest encryption, such as certain government mandates; ordinary key-managed encryption is fully served by SSE-KMS.

Trap Reading DSSE-KMS as applying two KMS keys; only the first layer is KMS-backed, the second uses an independent S3-managed key.

SSE-C keeps the key out of AWS by making you send it on every request

With server-side encryption using customer-provided keys (SSE-C), you pass the encryption key in each PUT and GET; S3 encrypts or decrypts and then discards the key, so AWS never stores it. The vendor term is customer-provided keys, not customer-supplied. Choose SSE-C when the key must stay outside AWS-managed storage but you still want S3 to do the encryption work; choose client-side encryption when even the ciphertext-to-plaintext step must happen before data reaches AWS.

Trap Calling SSE-C 'customer-supplied keys'; the AWS term is customer-provided keys, and a wrong-name distractor relies on that slip.

Only client-side encryption keeps plaintext from ever reaching AWS

Client-side encryption encrypts data inside your application before upload, so AWS only ever handles ciphertext and cannot read the plaintext even in memory. All four server-side modes, including SSE-C, let S3 see plaintext momentarily during the operation. When a requirement says AWS must never be able to access the data in clear, the answer is client-side encryption, with you owning all key management.

Trap Assuming SSE-C hides plaintext from AWS; with SSE-C, S3 still decrypts server-side, so plaintext exists on the service momentarily.

Enable an S3 Bucket Key to cut SSE-KMS request cost up to 99 percent

Without a Bucket Key, S3 calls KMS once per object operation, so large SSE-KMS buckets rack up per-request KMS charges. An S3 Bucket Key is a short-lived bucket-level key S3 derives from your KMS key and reuses to wrap many objects, cutting KMS request traffic by up to 99 percent. It changes only cost and the CloudTrail encryption context, not which key protects your data, and the savings grow with object count and shared requesters.

1 question tests this
S3 Bucket Keys do not work with DSSE-KMS and only apply to new objects

Two limits define when a Bucket Key helps: it is not supported for DSSE-KMS at all, and enabling it affects only objects written afterward, so existing objects must be re-copied (CopyObject) to adopt it. Enabling a Bucket Key also switches the KMS encryption context from the object ARN to the bucket ARN, so any key policy that scoped access by object-ARN encryption context must be rewritten to the bucket ARN or access breaks.

Trap Expecting a newly-enabled Bucket Key to cover objects already in the bucket; it applies only to new writes until you re-copy the old ones.

4 questions test this
S3 Object Lock requires versioning and enforces write-once-read-many

S3 Object Lock makes object versions immutable for a retention period or under a legal hold, and it works only on a bucket with S3 Versioning enabled because the lock attaches to a specific version. It protects against accidental or malicious deletion and overwrite, which encryption alone does not. Object Lock can also serve as a fixed-period retention solution where records must persist for a legal duration.

Trap Assuming you can enable Object Lock on a non-versioned bucket; versioning is a prerequisite because the lock binds to an object version.

Object Lock compliance mode is immutable even to the account root user

In compliance mode, no principal can overwrite, delete, or shorten the retention of a protected object version, including the AWS account root user; the only way to remove the object before its retain-until date is to close the AWS account. Governance mode, by contrast, lets a caller with s3:BypassGovernanceRetention and the bypass header override the lock. Choose compliance mode when a regulator demands true immutability with no escape hatch.

Trap Believing the root user can delete a compliance-mode object early; root cannot, which is exactly the property regulators rely on.

3 questions test this
Governance mode allows a permissioned override via s3:BypassGovernanceRetention

Governance mode protects objects from deletion by most users but lets an operator holding s3:BypassGovernanceRetention delete or shorten the lock when they also send x-amz-bypass-governance-retention:true. Use it when trusted admins must be able to correct mistakes, or to test retention settings before committing to compliance mode. The escape hatch is the whole difference from compliance mode.

A legal hold places WORM protection on an object version with no expiry, independent of any retention period, and is set or cleared with s3:PutObjectLegalHold. Even after a retention period expires, an active legal hold keeps the version immutable until someone removes the hold. Use it when you cannot predict how long the data must stay frozen, such as during litigation or an audit.

S3 Glacier Vault Lock locks an archive policy immutably after a 24-hour test window

S3 Glacier Vault Lock enforces a vault-level policy such as 'deny deletes for five years' through a two-step process: you initiate the lock, then have 24 hours to validate it before completing the lock, after which the policy becomes immutable. It is a distinct feature from S3 Object Lock (object versions) and AWS Backup Vault Lock (recovery points), a separation the exam tests directly.

Trap Confusing S3 Glacier Vault Lock with S3 Object Lock or AWS Backup Vault Lock; they immutably protect different resources and are configured separately.

Use AWS Signer code signing to reject tampered code artifacts

Integrity for executable artifacts comes from digital signatures, not WORM storage: AWS Signer produces a signature over a code package, and consumers like Lambda code signing verify it and refuse to deploy a package whose signature does not match. This protects the supply chain so an altered artifact is rejected at deploy time rather than running silently.

S3 Lifecycle cannot move objects to Standard-IA or One Zone-IA before 30 days

A lifecycle rule cannot transition objects to S3 Standard-IA or One Zone-IA until they are at least 30 days old, and the same 30-day floor applies to noncurrent versions. Transitions straight to Glacier classes can fire from day 0, though each Glacier class still bills its own minimum duration in full: 90 days for Glacier Instant and Flexible Retrieval, 180 days for Deep Archive. A claim of 'IA transition after 0 days' is wrong.

Trap Configuring a 0-day transition to Standard-IA; the IA classes require a 30-day minimum, unlike the Glacier classes which allow day-0 transitions.

EFS and FSx have their own lifecycle and retention policies

Amazon EFS lifecycle management moves files to Infrequent Access or Archive storage classes after a configured idle period to cut cost on cold data, and FSx file systems carry their own backup-retention policies. These are the file-system analogs of S3 Lifecycle; the design pattern of tiering cold data to cheaper storage applies across object and file storage, not just S3.

AWS Backup Vault Lock compliance mode becomes immutable after a grace time of at least 3 days

AWS Backup Vault Lock enforces WORM on recovery points. In compliance mode you set a cooling-off grace time of at least 3 days (72 hours); during grace time you can still remove or change the lock, but once it expires neither the root user nor AWS can delete recovery points or the vault until their lifecycle completes. Governance mode, by contrast, can be removed any time by a principal with sufficient IAM permissions.

Trap Assuming a freshly-created compliance lock is immediately immutable; it stays changeable during the >= 3-day grace time before locking in.

4 questions test this
Build ransomware-resilient backups with a locked vault plus cross-account copies

Encryption does nothing against an admin who deletes backups, so resilience comes from immutability plus isolation. Combine an AWS Backup compliance-mode locked vault with cross-account copies into a separate, locked-down account to create a logically air-gapped backup that a single compromised account cannot erase, and add cross-Region copies for regional failure. The locked vault stops deletion; the separate account stops a credential-holder from reaching it.

DataSync moves data; AWS Backup creates retained, immutable recovery points

AWS DataSync is a transfer service for migrating or replicating large datasets between on-premises, other clouds, and AWS storage, with in-transit encryption and integrity checks. AWS Backup is for scheduled, point-in-time backups with retention and Vault Lock immutability. If a stem says 'migrate or replicate file data,' choose DataSync; if it says 'scheduled, retained, immutable recovery points,' choose AWS Backup.

Trap Reaching for DataSync to satisfy a backup-retention or immutability requirement; DataSync transfers data and does not manage retained recovery points.

Use Amazon Data Lifecycle Manager to automate EBS snapshot and AMI policies

Amazon Data Lifecycle Manager (DLM) automates the creation, retention, and cross-account or cross-Region copy of EBS snapshots and EBS-backed AMIs on a schedule. It is the EBS-specific automation layer; for cross-service centralized backups with Vault Lock you use AWS Backup instead. Reach for DLM when the requirement is specifically scheduled EBS snapshot or AMI lifecycle management.

3 questions test this
Retain N newest noncurrent versions with NoncurrentVersionExpiration + NewerNoncurrentVersions

On a versioned bucket, the NoncurrentVersionExpiration lifecycle action deletes noncurrent versions after NoncurrentDays, and adding NewerNoncurrentVersions keeps that many of the most recent noncurrent versions before expiration applies. A Filter element is required when NewerNoncurrentVersions is set. Pair it with AbortIncompleteMultipartUpload to clean up stalled uploads.

Trap Using only NoncurrentDays (or current-version Expiration) when the requirement is to keep the N newest noncurrent versions regardless of age.

3 questions test this
EBS encryption by default is a per-Region setting that can pin a customer managed key

Enabling EBS encryption by default makes every new EBS volume in that Region encrypted even when no encryption parameters are supplied, and you can set a specific customer managed key as the default encryption key instead of aws/ebs. The setting is Region-scoped, so it must be enabled separately in each Region; volumes in Regions where it is not enabled stay unencrypted.

Trap Assuming enabling encryption-by-default in one Region applies account-wide across all Regions.

3 questions test this
A cross-Region encrypted RDS/Aurora read replica needs a KMS key in the destination Region

KMS keys are Regional and cannot be used outside their Region, so creating an encrypted cross-Region read replica requires you to specify a customer managed key that exists in the destination Region (via --kms-key-id). The replica is then encrypted with that destination-Region key; you can enable automatic rotation on it independently.

Trap Trying to reuse the source Region's KMS key for the replica instead of creating and specifying a key in the destination Region.

3 questions test this
Encrypt an existing unencrypted RDS/Aurora DB by copying a snapshot with a KMS key

You cannot turn on encryption in place for an existing unencrypted RDS or Aurora instance, nor change the KMS key of an already-encrypted one. Snapshot the database, copy the snapshot specifying the customer managed key (which encrypts the copy), and restore a new encrypted instance/cluster; once encrypted, its storage, automated backups, read replicas, and snapshots are all encrypted. Logical replication minimizes cutover downtime.

Trap Looking for a 'modify instance to enable encryption' option instead of the snapshot-copy-with-key-then-restore path.

3 questions test this
DynamoDB CMK encryption: audit/rotation/disable-to-revoke, and Global Tables need v2019

Encrypting a DynamoDB table with a customer managed key gives CloudTrail audit of key use, automatic rotation, and immediate revocation by disabling the key. Customer managed keys require Global Table Version 2019 (not 2017), and each replica uses a CMK in its own Region. If a replica's CMK becomes inaccessible (disabled or pending deletion), DynamoDB removes that replica from the replication group about 20 hours later without deleting the replica table.

Trap Expecting CMK encryption on a Global Table Version 2017, or assuming an existing on-demand backup re-encrypts when you rotate to a new key (it stays on the key used at backup time).

4 questions test this
A disabled or pending-deletion CMK locks out encrypted EFS and RDS

Encrypted EFS needs the CMK enabled with kms:Decrypt and kms:GenerateDataKeyWithoutPlaintext (plus kms:CreateGrant for the caller creating the file system, often scoped with kms:ViaService). If the key is disabled or scheduled for deletion, EFS mounts fail and an encrypted RDS instance enters an inaccessible state; re-enable the key (or cancel deletion) and, for RDS, restart the instance to recover.

Trap Scheduling a CMK for deletion or removing its EFS/RDS permissions while data encrypted under it is still in use, which silently locks out the storage.

4 questions test this

Also tested in

References

  1. AWS KMS Developer Guide — What is AWS Key Management Service?
  2. AWS Key Management Service FAQs — FIPS 140-3 validation FAQ
  3. AWS CloudHSM User Guide — What is AWS CloudHSM?
  4. AWS KMS Developer Guide — Custom key stores
  5. Amazon S3 User Guide — Using server-side encryption with Amazon S3 managed keys (SSE-S3)
  6. Amazon S3 User Guide — Configuring default encryption (SSE-S3 default since Jan 5, 2023)
  7. Amazon S3 User Guide — Using server-side encryption with AWS KMS keys (SSE-KMS)
  8. Amazon S3 User Guide — Protecting data with server-side encryption (DSSE-KMS)
  9. Amazon S3 User Guide — Using server-side encryption with customer-provided keys (SSE-C)
  10. Amazon S3 User Guide — Reducing the cost of SSE-KMS with Amazon S3 Bucket Keys
  11. Amazon S3 User Guide — Locking objects with Object Lock
  12. Amazon Glacier Developer Guide — Amazon Glacier Vault Lock
  13. Amazon S3 User Guide — Managing the lifecycle of objects
  14. Amazon EFS User Guide — Managing storage with lifecycle management
  15. AWS Backup Developer Guide — What is AWS Backup?
  16. AWS Backup Developer Guide — AWS Backup Vault Lock
  17. Amazon EBS User Guide — Automate snapshot and AMI lifecycles with Amazon Data Lifecycle Manager
  18. AWS DataSync User Guide — What is AWS DataSync?