SkarpChapter 8 of 26
Data Protection at Rest: S3, EBS, RDS, and AWS KMS
Encryption questions often hinge on small details; compare how S3, EBS, and RDS use AWS KMS so you can choose the right key strategy without second-guessing.
Big Picture: Encryption at Rest and AWS KMS
Why This Module Matters
You will connect secure networking to how AWS protects data at rest. We focus on Amazon S3, EBS, and RDS, and how they integrate with AWS Key Management Service (AWS KMS).
What Is Encryption at Rest?
Encryption at rest means data is stored on disk as unreadable ciphertext and only decrypted when accessed by an authorized principal or service. On AWS, this typically uses AWS KMS.
Role of AWS KMS
AWS KMS is a regional service for creating and managing cryptographic keys and controlling their use across AWS, including S3, EBS, and RDS encryption features.
Exam-Relevant Skills
You must know when encryption is automatic, when to choose AWS vs customer managed keys, how IAM and key policies interact, and how S3, EBS, and RDS each call KMS.
Link to Well-Architected
This topic lives in the security pillar: "The security pillar describes how to take advantage of cloud technologies to protect data, systems, and assets in a way that can improve your security posture."
AWS KMS Fundamentals: Keys, CMKs, and Grants
KMS Key Basics
A KMS key is the logical key resource in KMS (older term: CMK). Its plaintext material never leaves KMS. S3, EBS, and RDS use these for encryption at rest.
Symmetric and Envelope Encryption
S3, EBS, and RDS use symmetric KMS keys (AES-256). KMS performs envelope encryption: it uses the KMS key to generate and protect data keys, which actually encrypt your data.
Key Policy vs IAM Policy
A key policy is attached to the KMS key and defines who can administer or use it. IAM policies are attached to identities and must also allow KMS actions.
Grants
Grants are lightweight permissions objects on a KMS key, often created automatically so AWS services like EBS or RDS can keep using the key for encryption.
Combined Authorization
KMS evaluates key policy and IAM policy together. If either denies access, the KMS operation fails, even if the other policy allows it.
AWS Managed Keys vs Customer Managed Keys
AWS Managed Keys
AWS managed keys like `aws/s3` and `aws/ebs` are created and run by AWS. They are simple to use, rotate automatically, and have limited configuration options.
Customer Managed Keys
Customer managed keys are created by you. You control policies, aliases, tags, rotation (annually), and deletion schedules, and can meet stricter compliance needs.
When to Use Which
AWS managed keys: fast, low overhead, basic compliance. Customer managed keys: when you need fine-grained access control, auditability, and explicit regulatory control.
Cost Considerations
Both key types incur per-request charges. Customer managed keys also add a monthly fee per active key, which can matter in high-scale designs.
Exam Signal
If a scenario mentions regulatory requirements, customer-controlled rotation, or separation of duties, it usually signals using customer managed keys.
Designing a Compliance-Friendly Key Strategy
Scenario Overview
A company stores financial statements in S3, runs analytics on EC2 with EBS, and uses RDS PostgreSQL. Compliance requires customer-controlled keys and detailed logging.
Separate Keys Per Layer
Create three customer managed KMS keys: one for S3, one for EBS, one for RDS. Use clear aliases like `alias/prod-finance-s3` and `alias/prod-finance-rds`.
Key Policy Design
Give a Security Admin role key administration rights but no decrypt rights. Give app roles permission to use the keys for cryptographic operations but not to manage them.
Auditing and Rotation
Use CloudTrail to log KMS API calls for audit. Enable annual automatic rotation on the customer managed keys; apps keep working without changes.
Exam Takeaway
When you see strong compliance and audit requirements, the likely answer is S3, EBS, and RDS encrypted with customer managed KMS keys plus restrictive key policies.
S3 Encryption at Rest and KMS Integration
S3 Encryption Options
S3 offers SSE-S3 (S3-managed keys), SSE-KMS (KMS keys), SSE-C (customer-provided keys), and client-side encryption. Focus on SSE-KMS for this module.
SSE-S3 vs SSE-KMS
SSE-S3 uses S3-managed AES-256 keys and does not call KMS. SSE-KMS uses a KMS key (AWS or customer managed) and makes KMS API calls for data keys.
Access Control for SSE-KMS
You need S3 permissions for `s3:PutObject`/`s3:GetObject` and KMS permissions on the chosen key. Both must allow the operation.
Cost and Scale Considerations
Each SSE-KMS object operation triggers KMS calls, adding cost and potential rate limits. For massive, high-traffic buckets, SSE-S3 can be cheaper if allowed by compliance.
Enforcing SSE-KMS
Use a bucket policy with a condition on `s3:x-amz-server-side-encryption` = `aws:kms`, optionally locking to a specific KMS key ARN to enforce SSE-KMS.
EBS Encryption at Rest and KMS Integration
What EBS Encryption Covers
EBS encryption protects data at rest on volumes and snapshots, and data in transit between an EC2 instance and its encrypted volume.
Choosing the KMS Key
You can use the AWS managed `aws/ebs` key or a customer managed KMS key. You can also enable default EBS encryption per Region.
How KMS Is Used
When a volume is created, EBS gets a data key from KMS and uses it to encrypt the volume. Normal I/O does not call KMS on every read/write.
Access Control and Grants
The IAM role creating the volume needs permission to use the KMS key. EBS creates grants so it can keep using the key for that volume.
Key Change Gotcha
You cannot switch the KMS key of an existing volume directly. To change keys, snapshot the volume, then create a new volume encrypted with the new KMS key.
RDS Encryption at Rest and KMS Integration
RDS Encryption Scope
RDS encryption is configured at the DB instance (or Aurora cluster) level. It encrypts storage volumes, automated backups, and snapshots.
Choosing a KMS Key
When creating the DB instance, choose the AWS managed `aws/rds` key or a customer managed KMS key for encryption at rest.
Cannot Encrypt In-Place
You cannot turn on encryption on an existing unencrypted RDS instance. You must snapshot, copy with encryption, and restore a new encrypted instance.
Backups and Snapshots
Backups and snapshots of an encrypted instance are encrypted with the same KMS key by default. You can re-encrypt when copying a snapshot.
Exam Scenario Pattern
If a question asks how to encrypt an existing RDS instance or change keys, the answer is usually: snapshot → copy with new key → restore a new encrypted instance.
Thought Exercise: Picking Keys for S3, EBS, and RDS
Work through this scenario mentally and, if you like, jot down your design.
Scenario
You are designing an architecture for a healthcare startup. Requirements:
- All patient data must be encrypted at rest.
- Auditors want to see which team accessed which type of data.
- Data types:
- Raw medical images stored in S3.
- Application servers running on EC2 with EBS volumes.
- A production RDS MySQL database.
- The team has limited ops capacity and wants to keep the design as simple as possible while meeting compliance.
Your task
- Decide how many KMS keys you would create and what each is used for.
- For each key, decide whether it is AWS managed or customer managed, and briefly justify.
- Sketch who can administer each key and who can use each key (for example, Security team vs App roles).
- Identify one trade-off you are making (cost, complexity, or flexibility).
Hint
- Think about whether you need separate keys per data type for auditing and least privilege.
- Remember that AWS managed keys are simpler but less flexible for detailed access control.
After you have an answer, compare it to this reference design:
- 3 customer managed keys (one each for S3, EBS, RDS), Security Admin role for management, app roles for use, CloudTrail for auditing. This balances compliance with manageable complexity.
Quiz: KMS Key Types and S3/EBS/RDS Basics
Check your understanding of core KMS and storage encryption concepts.
A company stores highly sensitive data in S3, on EBS volumes, and in RDS. Compliance requires customer-controlled key rotation and the ability to restrict which applications can use which keys. Which option best meets these requirements with the least operational effort?
- Use the AWS managed keys aws/s3, aws/ebs, and aws/rds for all resources.
- Create a single customer managed KMS key and use it for S3, EBS, and RDS across the account.
- Create separate customer managed KMS keys for S3, EBS, and RDS, and use key policies plus IAM roles to control which applications can use each key.
- Use SSE-S3 for S3, unencrypted EBS volumes, and RDS without encryption, since AWS already secures the infrastructure.
Show Answer
Answer: C) Create separate customer managed KMS keys for S3, EBS, and RDS, and use key policies plus IAM roles to control which applications can use each key.
Option 3 is correct: separate customer managed keys per service allow customer-controlled rotation and fine-grained access control via key policies and IAM. Option 1 uses AWS managed keys, which do not provide the same policy flexibility. Option 2 centralizes to one key, reducing isolation between data types. Option 4 ignores the requirement for encryption and customer-controlled keys.
Quiz: Service-Specific Encryption Behavior
Test your understanding of how S3, EBS, and RDS behave when you change encryption settings.
You need to start using a new customer managed KMS key for an existing encrypted workload. Which statement is MOST accurate for S3, EBS, and RDS?
- For S3, EBS, and RDS you can change the KMS key in-place on existing data without any data movement.
- For S3 you can re-encrypt existing objects with a new KMS key; for EBS and RDS you must create new volumes/instances from snapshots encrypted with the new key.
- For EBS you can change the KMS key of a volume in-place; for S3 and RDS you must recreate the resources.
- None of these services support changing the KMS key; you must always create a new AWS account.
Show Answer
Answer: B) For S3 you can re-encrypt existing objects with a new KMS key; for EBS and RDS you must create new volumes/instances from snapshots encrypted with the new key.
Option 2 is correct. S3 lets you rewrite or copy objects to change their KMS key. EBS and RDS do not support changing the KMS key in-place; you must snapshot and create new volumes/instances encrypted with the new key. Option 1 and 3 incorrectly state in-place key changes. Option 4 is clearly incorrect.
Key Term Review: KMS and Encryption at Rest
Flip these cards to reinforce key terminology and behaviors.
- AWS KMS key (formerly CMK)
- A logical key resource in AWS KMS whose plaintext key material never leaves KMS. Used for cryptographic operations like generating and protecting data keys for S3, EBS, and RDS encryption.
- AWS managed key (for example, aws/s3)
- A KMS key created and fully managed by AWS for a specific service. Limited customization, automatic rotation, and no detailed key policy control by the customer.
- Customer managed key
- A KMS key that you create and manage. You control key policies, aliases, tags, rotation (annual), and deletion. Preferred when you need fine-grained access control and compliance.
- Envelope encryption
- A pattern where KMS keys protect data keys, and the data keys encrypt the actual data. The encrypted data key is stored with the data, while the KMS key stays inside KMS.
- SSE-S3 vs SSE-KMS
- SSE-S3 uses S3-managed keys without KMS calls. SSE-KMS uses KMS keys (AWS or customer managed), incurs KMS API charges, and allows key-level access control and auditing.
- EBS encryption behavior
- EBS volumes use a data key from KMS to encrypt data at rest. You cannot change the KMS key of an existing volume directly; you must snapshot and restore with a new key.
- RDS encryption behavior
- RDS encryption is chosen at DB creation. You cannot enable encryption in-place on an unencrypted instance; instead, snapshot, copy with encryption, and restore a new encrypted instance.
- KMS key policy
- A resource-based policy attached to a KMS key that defines who can administer or use the key. Evaluated together with IAM policies for authorization.
- Grants (KMS)
- Lightweight permissions objects on a KMS key, often created by AWS services so they can continue to use a key for operations on resources like EBS volumes or RDS instances.
- Default EBS encryption
- A per-Region account setting that causes all newly created EBS volumes to be encrypted automatically with a specified KMS key (AWS managed or customer managed).
Key Terms
- SSE-S3
- Server-side encryption for S3 using S3-managed keys, with no direct use of AWS KMS.
- SSE-KMS
- Server-side encryption for S3 that uses AWS KMS keys, enabling fine-grained access control and auditability.
- AWS KMS key
- A logical key resource in AWS KMS (formerly called a CMK) whose plaintext key material never leaves KMS and is used to perform cryptographic operations.
- Grant (KMS)
- A permissions object associated with a KMS key that allows AWS services or principals to use the key for specific operations.
- EBS encryption
- Encryption at rest for Amazon EBS volumes and snapshots using data keys protected by a KMS key.
- KMS key policy
- A resource-based policy attached to a KMS key that controls who can administer and use that key.
- RDS encryption
- Encryption at rest for Amazon RDS instances, backups, and snapshots using a KMS key chosen at DB creation time.
- AWS managed key
- A KMS key created and managed by AWS for a specific service, such as aws/s3 or aws/ebs, with limited customer configuration options.
- Envelope encryption
- An encryption pattern where a master key (KMS key) protects data keys, and the data keys encrypt the actual data.
- Customer managed key
- A KMS key that a customer creates and manages, allowing full control over key policies, rotation, tags, and deletion.