SkarpChapter 7 of 26
Data Protection at Rest with AWS KMS, S3, RDS, and EBS
Encryption questions frequently hinge on subtle differences between key types and where encryption is applied. This module dissects data-at-rest protection patterns using AWS KMS and service-integrated encryption options.
Big Picture: Data at Rest Encryption on AWS
From Network Security to Data Security
You already saw how VPCs and security groups protect traffic. This module shifts focus to data at rest: how AWS encrypts stored data using KMS and service-integrated options.
Four Core Building Blocks
We will connect four services: AWS KMS (keys and policies), S3 (server-side encryption options), RDS (instance and snapshot encryption), and EBS (volume and snapshot encryption).
Well-Architected Context
Encryption at rest is part of the Security pillar, which "describes how to take advantage of cloud technologies to protect data, systems, and assets in a way that can improve your security posture."
Exam Focus
Many exam questions hinge on subtle differences: which key type, which encryption mode, and what happens to snapshots, copies, or cross-Region resources. That is exactly what we will unpack.
AWS KMS Fundamentals: Keys, Policies, and Grants
What Is a KMS Key?
A KMS key (historically CMK) is a logical key with metadata and policy, whose cryptographic material is stored and protected by AWS KMS. It is the root of trust for many AWS encryptions.
AWS Managed vs Customer Managed
AWS managed keys like `aws/s3` or `aws/ebs` are created and maintained by AWS. Customer managed keys are created by you and give you control over policy, rotation, and aliases.
Key Policies and IAM
The key policy defines who can use or manage the key. IAM policies and grants work only if the key policy allows them. A common pattern is to let IAM policies govern access.
Grants and Envelope Encryption
Services like S3 or RDS use grants to access keys on your behalf. KMS usually performs envelope encryption: it encrypts data keys, while the service uses those data keys to encrypt your data.
S3 Encryption Options: SSE-S3, SSE-KMS, SSE-C, and Client-Side
SSE-S3 Basics
SSE-S3 uses S3-managed keys. You enable it at bucket or object level, get encryption at rest with no KMS calls, and pay no KMS cost. You do not see or manage the keys.
SSE-KMS Basics
SSE-KMS uses KMS keys (AWS or customer managed). Every encrypt/decrypt uses KMS APIs, giving fine-grained control and audit logs, but also adding cost and potential throttling.
SSE-C and Client-Side
SSE-C lets you send your own key on each request; S3 never stores it. Client-side encryption encrypts data before upload so S3 only sees ciphertext.
Default Encryption Context
S3 now encrypts new objects by default, but the exam still cares which mode (SSE-S3 vs SSE-KMS vs SSE-C) you choose based on control, compliance, and cost.
Choosing S3 Encryption in Real Scenarios
Scenario 1: Analytics Data Lake
Millions of log objects per hour, basic encryption at rest, no key control requirement. SSE-S3 is ideal: simple, scalable, and cheaper than SSE-KMS.
Scenario 2: Regulated PII
Storing PII with needs for key disablement and key-usage logs. Choose SSE-KMS with a customer managed key for policy control and CloudTrail auditing.
Scenario 3: Partner-Owned Keys
Partner demands AWS never store their key. SSE-C if S3 must encrypt; client-side encryption if you can encrypt before upload so AWS never sees plaintext.
Exam Patterns
Look for cues: "audit key usage" → SSE-KMS; "no KMS cost" or "very high throughput" → SSE-S3; "must not store keys in AWS" → SSE-C or client-side encryption.
RDS Encryption: Instances, Snapshots, and Cross-Region Copies
When Can You Encrypt RDS?
You enable encryption when you create the RDS instance. You cannot toggle an existing unencrypted instance to encrypted directly; you must go through snapshots.
Encrypting an Existing DB
To encrypt later: snapshot the unencrypted DB, copy the snapshot with encryption enabled, then restore a new encrypted instance from that encrypted snapshot.
Snapshots, Replicas, and Regions
Encrypted instances produce encrypted backups, snapshots, and read replicas. Cross-Region snapshot copies require choosing a KMS key in the target Region.
Key Deletion Risk
If you delete or schedule deletion of the KMS key used by RDS, you may permanently lose access to that DB and its backups. This is a common exam pitfall.
EBS Volume Encryption: Behavior, Snapshots, and Performance
Enabling EBS Encryption
You can encrypt each EBS volume individually or enable account-level defaults so all new volumes in a Region are encrypted with a chosen KMS key.
Snapshots and Copies
Encrypted volumes produce encrypted snapshots. Volumes created from encrypted snapshots remain encrypted. Cross-Region snapshot copies need a KMS key in the target Region.
Changing Encryption State
To encrypt an existing unencrypted volume, snapshot it, copy that snapshot with encryption enabled, then create a new encrypted volume from the encrypted snapshot.
Performance and Sharing
On modern Nitro instances, EBS encryption overhead is minimal. To share encrypted snapshots, other accounts must be allowed to use the underlying KMS key.
Key Management and Rotation Strategies
AWS vs Customer Managed Keys
AWS managed keys are simple and automatic. Customer managed keys offer custom policies, cross-account sharing, and rotation, which matter for compliance-heavy workloads.
Automatic Rotation
Enable annual rotation on customer managed keys. KMS creates new backing keys while old data stays decryptable; you do not need to re-encrypt S3, EBS, or RDS data.
Separation and Access Control
Use separate keys per environment or sensitivity. Combine key policies with IAM conditions and remember under the shared responsibility model you configure KMS securely.
Deletion vs Disabling
Deleting a KMS key can permanently lock your data. Prefer disabling a key to test the impact, and use scheduled deletion only when you are sure.
Design Exercise: End-to-End Encrypted Web App
Work through this thought exercise to solidify how KMS, S3, RDS, and EBS fit together.
Scenario
You are designing a simple three-tier web application:
- Front-end static assets in S3, served via CloudFront.
- Application servers in a private subnet using EC2.
- A relational database on Amazon RDS.
- EBS volumes for the application servers.
Requirements
- All data at rest must be encrypted.
- Security team needs audit logs for key usage for PII data.
- You want minimal operational overhead for logs and static assets.
- You need to comply with a policy that separates dev and prod keys.
Your task
Without worrying about exact console steps, decide:
- Which S3 encryption mode to use for:
- Static assets (public website files).
- PII exports stored as CSV in a separate bucket.
- Which type of KMS key to use for:
- RDS database encryption.
- EBS volumes attached to prod EC2 instances.
- How to separate dev and prod keys.
Think, then compare with this reference design:
- Static assets: SSE-S3 (AWS managed key) for simplicity and cost.
- PII exports: SSE-KMS with a customer managed key to get key usage logs.
- RDS: Encrypted with a customer managed key dedicated to prod databases.
- EBS: Encrypted-by-default using a customer managed key for prod compute.
- Dev vs prod: Use separate KMS keys (for example, `cmk-dev-app`, `cmk-prod-app`, `cmk-prod-rds`) and restrict prod keys to a smaller admin group.
Check your design against this one. Where did you choose differently? Could your choices still meet the requirements?
Quiz 1: S3 and KMS Basics
Test your understanding of S3 encryption modes and KMS behavior.
A company stores sensitive PII in S3 and must be able to (1) audit which IAM principals used the encryption key and (2) immediately revoke decryption ability if a role is compromised, without moving data. Which S3 encryption option best meets these needs?
- SSE-S3 using the default S3-managed key
- SSE-KMS using a customer managed KMS key
- SSE-C with customer-provided keys
- Client-side encryption using a library outside AWS
Show Answer
Answer: B) SSE-KMS using a customer managed KMS key
SSE-KMS with a customer managed KMS key is correct because KMS logs key usage to CloudTrail and you can change key policies or disable the key to revoke decryption without moving data. SSE-S3 lacks key-level audit and control. SSE-C and client-side encryption shift key control off AWS but do not provide KMS-based audit or revocation.
Quiz 2: RDS and EBS Encryption Scenarios
Apply what you know about RDS and EBS encryption behavior.
You have an unencrypted RDS database in production. Compliance now requires encryption at rest with a customer managed KMS key. What is the MOST appropriate sequence of actions?
- Enable encryption on the existing RDS instance and choose the customer managed key
- Create a read replica with encryption enabled, then promote it to primary
- Take a snapshot, copy the snapshot with encryption enabled using the customer managed key, and restore a new encrypted instance from the copied snapshot
- Change the storage type to encrypted and reboot the instance
Show Answer
Answer: C) Take a snapshot, copy the snapshot with encryption enabled using the customer managed key, and restore a new encrypted instance from the copied snapshot
You cannot enable encryption directly on an existing unencrypted RDS instance, nor simply change storage type. The correct process is: snapshot the unencrypted DB, copy the snapshot with encryption enabled and the desired KMS key, then restore a new encrypted instance from that snapshot. Creating a read replica does not bypass the initial unencrypted state.
Key Terms Review
Flip these cards to reinforce terminology and behaviors that often appear in exam questions.
- SSE-S3
- Server-side encryption where Amazon S3 manages the keys. Provides encryption at rest with no KMS API calls or key management by the customer; good for simple, high-throughput use cases.
- SSE-KMS
- Server-side encryption using AWS KMS keys (AWS or customer managed). Supports fine-grained key policies, CloudTrail logging of key usage, and key disablement or rotation.
- SSE-C
- Server-side encryption with customer-provided keys. You send the key on each request; S3 encrypts data but never stores the key, only a hash. You handle key storage and rotation.
- Customer managed KMS key
- A KMS key you create and control, including key policy, grants, aliases, and optional automatic rotation. Used when you need custom access control and compliance alignment.
- AWS managed KMS key
- A KMS key created and managed by AWS for a specific service (such as aws/s3 or aws/ebs). Simplifies encryption but offers less granular control and configuration.
- Envelope encryption
- Pattern where KMS encrypts data keys, and those data keys are used by services like S3, EBS, or RDS to encrypt the actual data locally, improving scalability and performance.
- RDS encryption enablement
- RDS encryption must be chosen at instance creation. To encrypt an existing unencrypted DB, snapshot it, copy the snapshot with encryption, and restore a new encrypted instance.
- EBS encryption-by-default
- An account-level setting to ensure all new EBS volumes in a Region are created encrypted with a selected KMS key, enforcing consistent encryption at rest.
- KMS key rotation
- For customer managed keys, an optional annual automatic rotation that creates new backing key material while keeping older versions to decrypt existing data without re-encryption.
- KMS key deletion risk
- Deleting a KMS key after its waiting period makes all data encrypted with that key effectively unrecoverable. Disabling a key is safer for temporary access revocation.
Key Terms
- Grant
- A KMS mechanism that allows AWS principals or services to use a KMS key with specific permissions, often used for service integrations.
- SSE-C
- Server-side encryption in S3 using customer-provided keys on each request; S3 does not store the keys, only a hash.
- SSE-S3
- Server-side encryption in S3 using S3-managed keys. Provides encryption at rest with no customer-managed key configuration.
- AWS KMS
- AWS Key Management Service, a managed service that makes it easy to create and control cryptographic keys used to encrypt data across many AWS services.
- SSE-KMS
- Server-side encryption in S3 using KMS keys stored in AWS KMS, enabling fine-grained access control and audit logging.
- Key policy
- A resource-based policy attached directly to a KMS key that defines who can use or manage that key.
- KMS key (CMK)
- A logical key in AWS KMS with associated metadata, key policy, and key material. Historically called a Customer Master Key (CMK).
- EBS encryption
- Encryption at rest for Amazon EBS volumes and their snapshots using AWS KMS keys, often enabled by default at the account level.
- RDS encryption
- Encryption at rest for Amazon RDS instances using AWS KMS keys, affecting the instance, its backups, snapshots, and read replicas.
- KMS key rotation
- Automatic or manual process of changing the cryptographic material of a KMS key while maintaining the ability to decrypt existing data.
- Encrypted snapshot
- A backup of an encrypted RDS or EBS resource that remains encrypted and cannot be converted to unencrypted form.
- Encryption at rest
- Protection of stored data by encrypting it on disk, so that data is unreadable without access to the appropriate decryption keys.
- Envelope encryption
- A pattern where a master key encrypts data keys, and those data keys encrypt the actual data, improving scalability and security.
- Client-side encryption
- An approach where data is encrypted by the client before sending it to AWS, so AWS services store only ciphertext.