Encryption at Rest

What is encryption at rest?

Encryption at rest protects data where it’s stored — disks, databases, object stores, backups, snapshots — so physical theft, a mislaid drive, or an exposed backup yields ciphertext instead of secrets. In the cloud it’s largely a solved, checkbox-level concern: EBS volumes, S3 buckets, and RDS instances encrypt transparently via KMS, performance overhead is negligible on modern hardware (AES-NI), and many providers now default it on.

The threat model it actually addresses

Be precise about what at-rest encryption stops: it defeats offline access to storage media — the lost laptop, the decommissioned drive that skipped wiping, the S3 snapshot accidentally shared, the compliance auditor’s checkbox. It does not defend against an attacker with valid application credentials, because your app decrypts data as it reads — to a live application (or a stolen app role), encrypted-at-rest data reads in plaintext. This is the near-universal misconception: encryption at rest is not access control, and a breach through the application layer walks right past it. That’s why it’s necessary-but-insufficient, always paired with IAM, least privilege, and encryption in transit.

Where the real decisions live

The interesting choice isn’t whether but whose keys. Provider-managed keys (free, automatic) satisfy most needs; customer-managed KMS keys add rotation control, key policies, and crypto-shredding — delete the key and every copy of the data becomes permanently unreadable, which is how you “delete” data from immutable backups and satisfy right-to-erasure at scale. Field-level or envelope encryption above the storage layer adds protection against the application-credential threat that disk encryption ignores.

What people get wrong

• Believing it protects against breaches — the application decrypts; a compromised app sees plaintext.
• Encrypting the database but not the backups/snapshots/logs — data leaks from the copies you forgot.
• Key sprawl without rotation or policy, turning “encrypted” into a checkbox with no governance behind it.

Primary source: AWS — encryption at rest documentation

Envelope Encryption

Most cloud encryption-at-rest implementations use envelope encryption rather than encrypting data directly with a single master key: a unique data key is generated for each object or volume, used to encrypt the actual data, and that data key is itself encrypted (or “wrapped”) using a separate master key managed by a service like AWS KMS. This layered approach means the master key itself is rarely, if ever, directly exposed to the encryption operation on bulk data, and it allows efficient key rotation — the master key can be rotated without needing to re-encrypt every piece of data protected by it, since only the much smaller wrapped data keys need to be re-wrapped with the new master key version.