Volumes, file systems, and databases

Lesson 4 of 4 in Protecting Data at Rest.

Block storage, file systems and databases share a pattern that S3 does not: encryption is decided when the resource is created, and changing your mind means making a copy. Knowing which conversions are impossible is most of what this topic tests.

EBS encryption is KMS-backed and transparent — data on the volume, data in transit between the instance and the volume, snapshots, and volumes created from those snapshots are all encrypted, with no measurable performance impact. The rules that generate questions: you cannot encrypt an existing unencrypted volume in place, and you cannot remove encryption from an encrypted one. The conversion is a copy — snapshot the volume, copy the snapshot specifying a KMS key, create a new volume from the encrypted copy, and swap it in. Inheritance runs one way and is absolute: a snapshot of an encrypted volume is encrypted, and any volume created from an encrypted snapshot is encrypted, so you cannot accidentally produce plaintext from an encrypted lineage. And encryption by default is an account setting per Region — turn it on in every Region you use, and every new volume and snapshot is encrypted whether or not the caller asked, which is the control to cite for “ensure no unencrypted volumes can be created”.

EFS encrypts at rest with a KMS key chosen at file-system creation — again not changeable afterwards; migration means a new file system and a copy, typically with DataSync. Encryption in transit is separate and is enabled per mount, by the EFS mount helper using TLS (-o tls). You can require it: an EFS file system policy with a condition on elasticfilesystem:AccessedViaMountTarget and aws:SecureTransport refuses unencrypted mounts, which is the EFS analogue of the bucket-policy deny.

FSx for Lustre is always encrypted at rest, with an AWS managed key by default or your own customer managed key; in-transit encryption is provided automatically between supported instance types and the file system. Its backup policy — automatic daily backups with a retention period, plus on-demand backups — is examinable alongside EFS lifecycle policies, so know that backups are themselves encrypted with the file system's key.

Storage encryption: when it is decided, and what it takes to change
ResourceAt-rest encryptionIn-transit encryptionCan you convert an existing resourceAccount-wide enforcement

Amazon EBS

KMS key chosen at volume creation

Automatic between a Nitro instance and its volumes

No — snapshot, copy with a key, create a new volume, swap

Encryption by default, set per Region

Amazon EFS

KMS key chosen at file-system creation

Per mount, via the mount helper with TLS

No — create a new file system and copy, e.g. with DataSync

A file system policy denying unencrypted access; AWS Config rules to detect

FSx for Lustre

Always on — AWS managed key or your own

Automatic between supported instance types and the file system

Key choice is at creation; encryption itself is never off

Nothing to enforce for at-rest — it cannot be disabled

RDS / Aurora

Enabled at instance or cluster creation with a KMS key; covers storage, automated backups, snapshots, read replicas

TLS to the endpoint; can be required per engine (for example a parameter group setting)

No — snapshot, copy the snapshot with encryption, restore to a new instance, cut over

AWS Config rules; SCPs or RCPs denying creation without encryption

Amazon S3

Per object; SSE-S3 by default since January 2023

TLS, deniable with aws:SecureTransport

Yes — copy objects with new encryption headers (Batch Operations at scale)

Bucket policy conditions on the encryption headers

Database encryption adds one distinction and one notorious set of rules.

The distinction is storage-level encryption versus transparent data encryption. RDS encryption at rest encrypts the underlying storage, snapshots, automated backups and read replicas with a KMS key — it protects against someone obtaining the media or a snapshot, and it is invisible to SQL. TDE is an engine feature, available for Oracle and SQL Server through option and parameter groups, which encrypts data inside the database engine itself. A requirement that names TDE, or that says the encryption must be managed within the database by the DBA team, means the engine feature; a requirement that says “the database and its backups must be encrypted at rest” means the RDS setting. They can coexist, and layering them costs performance for limited additional benefit, so AWS advises choosing deliberately rather than enabling both reflexively.

The notorious rules concern sharing encrypted snapshots, which the exam returns to again and again:

  • A snapshot encrypted with an AWS managed key (such as aws/rds or aws/ebs) cannot be shared at all — not with another account, and not publicly. The policy of an AWS managed key cannot be modified to permit it. The fix is to copy the snapshot, specifying a customer managed key, and share the copy.
  • A snapshot encrypted with a customer managed key can be shared with specific accounts, and the sharing takes two steps: share the snapshot, and grant the target account access to the KMS key through the key policy. Miss the second and the target account can see the snapshot and cannot restore it.
  • To then use it, the receiving account typically copies the snapshot into a key of its own — otherwise its restored resources remain dependent on a key in your account that you could disable at any time.
  • An encrypted snapshot can never be shared publicly. Only unencrypted snapshots can be public, which is a good reminder that “public snapshot” has been a real breach vector.

Sharing an encrypted snapshot with another account

  1. Which key encrypts the snapshot?

    Check first, because it determines whether sharing is possible at all. An aws/service alias means an AWS managed key and the answer is no.

  2. AWS managed key — sharing is impossible

    The key policy of an AWS managed key cannot be edited, so no external principal can ever be authorized to decrypt. This is the single most tested snapshot fact.

  3. Copy the snapshot, re-encrypting with a customer managed key

    CopySnapshot or CopyDBSnapshot with a KmsKeyId produces a new snapshot under a key whose policy you control. This is the mandatory first step out of the AWS-managed-key dead end — and the same operation re-encrypts into a different Region if the copy must travel.

  4. Customer managed key — two grants of authority

    Sharing a snapshot and authorizing the key are separate actions. The usual failure is doing only the first: the target account sees the snapshot and cannot restore it, with an error that points at KMS rather than at the snapshot.

  5. Share the snapshot with the target account id

    ModifySnapshotAttribute / ModifyDBSnapshotAttribute adds the account to the restore list. Encrypted snapshots can be shared with named accounts only — never publicly.

  6. Grant the target account use of the KMS key

    Add the external account to the key policy for kms:Decrypt, kms:DescribeKey, kms:CreateGrant and the re-encryption actions the restore needs. Scope it with a condition if you can — the organization id, or kms:ViaService.

  7. Target account copies it onto its own key

    Best practice, and often required: the receiving account copies the shared snapshot using a key it owns, removing its dependence on your key. Until it does, disabling your key breaks their restored database.

Key terms: EBS encryption by default, RDS encryption at rest, Transparent data encryption (TDE), Encrypted snapshot sharing, EFS lifecycle policy

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.