Storage encryption
Encryption at rest for EBS, snapshots and AMIs, RDS and Aurora, DynamoDB and the AWS Database Encryption SDK, EFS and FSx, and what happens to each when its KMS key is disabled or deleted.
Exam tasks: 5.2.1 (choose KMS options and client- vs server-side encryption), 5.2.3 (lifecycle of data at rest)
The decision: can encryption be turned on in place or only at creation, which key does each copy (snapshot, replica, backup) use, and what breaks, and when, if that key becomes unusable?
Can you encrypt what already exists?
| Service | Encrypt an existing unencrypted resource in place? | How to get there |
|---|---|---|
| EBS volume | No | Snapshot, then create an encrypted volume from it (or copy the snapshot with encryption) |
| RDS / Aurora | No | Snapshot, copy the snapshot with a KMS key, restore a new encrypted instance or cluster |
| DynamoDB | Always encrypted | Switch between AWS owned, AWS managed and customer managed keys at any time |
| EFS | No | Create a new encrypted file system and copy data (DataSync or AWS Backup restore) |
| FSx (all types) | Always encrypted | Choose the KMS key at creation |
| S3 | New writes only | Change default encryption; rewrite old objects with Batch Operations |
| SQS, SNS | Yes | Turn on SSE-SQS or SSE-KMS; applies to new messages |
Amazon EBS
- Encryption by default is a per-account, per-Region setting. Once on, every new volume and snapshot copy
is encrypted with the default key (
aws/ebsunless you choose a customer managed key). Turn it on in every Region you use, detect gaps with the Config ruleec2-ebs-encryption-by-default, and back it with an SCP that deniesec2:CreateVolumewhenec2:Encryptedis false. - Encryption covers data at rest, data moving between the instance and the volume, snapshots and volumes created from them. It happens in Nitro hardware with no performance cost.
- A volume created from an encrypted snapshot is always encrypted. You can change the key when you copy a snapshot or create a volume from it.
Sharing snapshots and AMIs
| Snapshot encrypted with | Can share with another account? |
|---|---|
| Unencrypted | Yes, or even publicly (risky) |
aws/ebs (AWS managed key) | No, because you can't give another account access to that key |
| Customer managed key | Yes: share the snapshot and allow the other account in the key policy |
- The receiving account should copy the shared snapshot with its own key, so it no longer depends on your key.
- Encrypted snapshots can never be made public. Turn on block public access for EBS snapshots and for AMIs at account level to stop accidental public sharing of unencrypted ones.
Re-sharing with the default key
Copying a snapshot "to share it" while leaving the default aws/ebs key selected produces a snapshot that still
can't be shared. The copy must use a customer managed key whose policy includes the target account.
Amazon RDS and Aurora
- Encryption is chosen at creation and covers storage, automated backups, snapshots, read replicas and logs. You can't encrypt an existing unencrypted instance or change its key in place; use the snapshot-copy path.
- Read replicas in the same Region use the same key. A cross-Region replica or snapshot copy needs a KMS key in the destination Region.
- Sharing an encrypted snapshot works only with a customer managed key, exactly as for EBS.
- TDE for Oracle and SQL Server is an extra, engine-level option. RDS TDE uses the RDS-managed wallet; to keep a TDE master key in your own HSM, run the database on EC2 with CloudHSM (see Key material and HSMs).
Amazon DynamoDB
- Every table is encrypted at rest: tables, indexes, streams, backups and global table replicas.
- Choose between AWS owned (default, no charge), AWS managed (
aws/dynamodb) and customer managed. You can switch keys on an existing table without downtime. - Server-side encryption means anyone allowed
dynamodb:GetItemsees plaintext. When specific attributes must stay unreadable even to people with table access, encrypt them on the client.
AWS Database Encryption SDK
- Client-side library that encrypts and signs individual attributes before they reach DynamoDB. You choose per attribute: encrypt and sign, sign only, or leave alone.
- Searchable encryption (beacons) lets you query encrypted attributes without decrypting the table.
- Keys come from KMS through keyrings, including the hierarchical keyring that caches branch keys to reduce KMS calls. Use a multi-Region key when the table is a global table.
Legacy: use the AWS Database Encryption SDK instead
The DynamoDB Encryption Client is the predecessor. It is still supported for existing data, but new designs should use the Database Encryption SDK, which adds searchable encryption and signed item structure.
EFS and FSx
- EFS: encryption at rest is set when you create the file system. Encryption in transit uses TLS through
the EFS mount helper (
-o tls). Enforce it with a file system policy that deniesaws:SecureTransportfalse. - EFS lifecycle management moves files that aren't accessed to Infrequent Access and Archive, and back to Standard on first access. It changes cost, not encryption.
- FSx (Windows File Server, Lustre, ONTAP, OpenZFS) always encrypts at rest with KMS. In transit: SMB 3 encryption for Windows and ONTAP SMB, Kerberos or TLS options for NFS, and Nitro-based encryption for Lustre clients on supported instances.
- FSx for Lustre backups work only on persistent file systems that aren't linked to an S3 data repository. Scratch file systems can't be backed up.
When the key becomes unusable
KMS keys become unusable when disabled, scheduled for deletion, when imported material expires or is deleted, or when a custom key store disconnects. Services feel it at different times:
| Service | Immediate effect | Later effect | Recovery |
|---|---|---|---|
| EBS | None: the data key is already in the Nitro hardware of the attached instance | Detach, stop or reattach fails | Make the key usable again, then attach |
| S3 SSE-KMS | New GETs and PUTs fail with AccessDenied / KMS errors | Same | Re-enable the key |
| RDS / Aurora | Instance moves to inaccessible-encryption-credentials-recoverable after about 2 hours | After 7 days it becomes terminal; only a restore from backup helps | Re-enable the key and start the instance within 7 days |
| DynamoDB (customer managed key) | Table status becomes INACCESSIBLE_ENCRYPTION_CREDENTIALS | After 7 days, DynamoDB archives the table and takes an on-demand backup; global table replicas drop out after about 20 hours | Restore key access within 7 days, or re-enable the key and restore from the archival backup |
| Deleted key (any service) | Permanent | Permanent | None. Ciphertext is gone |
Exam signal
"The KMS key was accidentally disabled" is recoverable: re-enable it. "The key was scheduled for deletion" is recoverable within the waiting period: cancel deletion, then re-enable. "The imported key material was deleted" is recoverable by importing the same material. "The key was deleted" is not recoverable.
Scenarios
RDS can't encrypt an existing instance in place, and a read replica of an unencrypted instance can't be encrypted. The supported path is snapshot, encrypted copy, restore, cut over. EBS encryption by default doesn't apply to RDS storage, and rebooting changes nothing.
The AWS managed key's policy can't be edited, so the snapshots must be re-encrypted under a customer managed key that the auditor's account may use. Encrypted snapshots can't be made public at all, and turning on encryption by default in the auditor's account doesn't grant access to the source key.
An attached EBS volume keeps working because the plaintext data key is already in the Nitro hardware. It will fail when the volume is detached or the instance stops. S3 calls KMS for each object and fails immediately. EBS uses the key you choose, KMS doesn't cache disabled keys, and permissions don't matter when the key itself is disabled.
Further reading
S3 data protection
S3 encryption options and how to enforce a specific key, Bucket Keys, SSE-KMS permissions for multipart uploads, public access and ownership controls, VPC endpoint policies, versioning, MFA delete, Object Lock, Glacier Vault Lock and lifecycle retention.
Backup and ransomware protection
AWS Backup plans and org backup policies, Vault Lock modes, logically air-gapped vaults, cross-account and cross-Region copies, Data Lifecycle Manager, secure transfer with DataSync, integrity checks and restore testing.