Encryption at Rest

Encryption at Rest protects data stored on disk (S3 objects, EBS volumes, RDS databases, DynamoDB tables) by encrypting it with a cryptographic key. Even if someone gains physical access to the storage hardware, the data is unreadable without the key. It is a foundational control and a compliance staple, but it is worth being precise about the threat it addresses: stolen or decommissioned storage media and out-of-band access to raw disks, not an attacker holding valid credentials to your account.

AWS Encryption Options

• SSE-S3: AWS manages both the key and encryption process (default for S3 since Jan 2023)
• SSE-KMS: AWS KMS manages the key; you control key policies, rotation, and audit via CloudTrail
• SSE-C: you provide your own key; AWS encrypts/decrypts but never stores the key
• Client-side encryption: you encrypt data before sending it to AWS

Services with Default Encryption

S3 (SSE-S3 default since January 2023), EBS (AES-256, opt-in per region), RDS (optional, must be enabled at creation), DynamoDB (AWS owned key by default), and most newer services encrypt by default.

What Encryption at Rest Actually Protects Against

Every server-side option decrypts transparently for any caller that IAM authorizes. If an attacker steals an access key with s3:GetObject permission, the bucket's encryption does not slow them down for one second: S3 decrypts the object and hands it over, exactly as it does for your application. This is the most misunderstood point in cloud data protection. Where encryption at rest earns real security value beyond the physical-media scenario is with SSE-KMS and customer managed keys: the caller then needs permission on both the object and the key, key policies give you an independent control plane (including a kill switch, since disabling a key blocks all decryption under it), and every decrypt lands in CloudTrail as auditable KMS usage. Under the hood these services use envelope encryption: each object or volume is encrypted with a unique data key, and the KMS key encrypts those data keys rather than the data itself.

How It Goes Wrong in Practice

The recurring pattern is checkbox encryption: a team confirms every bucket shows "encryption enabled" (which, since January 2023, all S3 buckets do by default), reports the data protection item closed, and stops thinking. Meanwhile the actual exposure paths remain wide open: a bucket policy or misconfigured access grants read access too broadly, credentials with blanket s3:* circulate in CI systems, and nothing about SSE-S3 stops any of it, because authorization, not cryptography, is the gate. The breaches that make headlines out of "encrypted" buckets are almost never cryptographic failures; they are IAM and policy failures that encryption at rest was never designed to catch. A second practical trap is RDS: encryption there can only be chosen at instance creation. Discovering during an audit that a three-year-old production database is unencrypted means a migration project, snapshot, encrypted copy, restore, cutover, not a checkbox.

A Practical Check: What Is This Bucket Actually Using?

To see a bucket's server-side encryption configuration:

aws s3api get-bucket-encryption --bucket my-data-bucket

The response shows the default encryption rule, with SSEAlgorithm values of AES256 (SSE-S3), aws:kms, or aws:kms:dsse, plus the KMS key ID where applicable and whether S3 Bucket Keys are enabled to reduce KMS request costs. For RDS, the equivalent check is aws rds describe-db-instances and reading the StorageEncrypted field per instance.

Frequently Asked Questions

Does encryption at rest protect me if my credentials are stolen?

No. Server-side encryption decrypts transparently for any authorized caller, so an attacker using stolen credentials reads data as easily as your application does. Stolen-credential risk is addressed by least privilege, MFA, short-lived credentials, and, with SSE-KMS, the additional requirement that the caller also holds permission on the key.

When should I use SSE-KMS instead of the default SSE-S3?

When you need control and evidence: a key policy you own, the ability to revoke or disable the key, CloudTrail records of every decrypt, and cross-account access governed at the key level. SSE-S3 satisfies "data is encrypted on disk"; SSE-KMS turns encryption into an access control and audit mechanism.

Can I enable encryption on an existing RDS instance?

Not in place. RDS encryption is only set at creation. The documented path for existing data is: snapshot the unencrypted instance, copy the snapshot with encryption enabled, then restore a new instance from the encrypted copy and switch your application over.