EBS and RDS Encryption: A Comprehensive Guide for AWS Security Specialty
Why EBS and RDS Encryption Matters
Data protection is one of the core pillars of the AWS Security Specialty exam and a critical component of any cloud security strategy. Amazon Elastic Block Store (EBS) and Amazon Relational Database Service (RDS) are two of the most commonly used AWS services for storing persistent data. Because these services often hold sensitive information — such as customer records, financial data, application secrets, and intellectual property — encrypting data at rest is essential for meeting compliance requirements (HIPAA, PCI-DSS, SOC 2, GDPR) and following security best practices.
Without encryption, anyone who gains unauthorized access to the underlying storage medium could potentially read your data. Encryption ensures that even if physical media is compromised or snapshots are shared inappropriately, the data remains unintelligible without the proper decryption keys.
What Is EBS Encryption?
EBS encryption is a feature that provides seamless, transparent encryption for EBS volumes and their associated snapshots. When you enable encryption on an EBS volume, AWS encrypts the following:
• Data at rest stored on the volume
• All data moving between the volume and the EC2 instance (data in transit between EBS and EC2)
• All snapshots created from the volume
• All volumes created from encrypted snapshots
EBS encryption uses AWS Key Management Service (KMS) keys to perform encryption. You can use either the AWS managed key (alias: aws/ebs) or a customer managed key (CMK) that you create and manage yourself.
Key Characteristics of EBS Encryption:
• Encryption is handled transparently by the EC2 host — there is no performance penalty that is noticeable for most workloads.
• EBS encryption uses AES-256 encryption algorithm.
• Encryption is applied at the volume level, not at the file level.
• You cannot remove encryption from an encrypted volume or snapshot. Once encrypted, always encrypted.
• You can enable encryption by default at the account level per region, meaning all new EBS volumes and snapshots will be automatically encrypted.
• Unencrypted volumes can be encrypted by creating a snapshot, copying the snapshot with encryption enabled, and then creating a new volume from the encrypted snapshot.
How EBS Encryption Works Under the Hood
1. When you create an encrypted EBS volume, EBS requests a data encryption key (DEK) from AWS KMS.
2. KMS generates a DEK and returns both a plaintext version and an encrypted (ciphertext) version of the key.
3. The plaintext DEK is used by the EC2 hypervisor to encrypt and decrypt I/O operations on the volume. It is stored in memory on the EC2 host only while the volume is attached.
4. The encrypted DEK is stored alongside the volume metadata.
5. When the volume is detached or the instance is stopped, the plaintext DEK is discarded from memory.
6. When the volume is reattached, EBS sends the encrypted DEK to KMS for decryption, and the plaintext DEK is loaded back into memory on the EC2 host.
This is known as envelope encryption — the data key encrypts the data, and the KMS key (CMK) encrypts the data key.
What Is RDS Encryption?
Amazon RDS encryption provides encryption at rest for RDS database instances, automated backups, read replicas, and snapshots. Similar to EBS, RDS encryption uses AWS KMS for key management and employs AES-256 encryption.
Key Characteristics of RDS Encryption:
• Encryption must be enabled at the time of database creation. You cannot encrypt an existing unencrypted RDS instance directly.
• To encrypt an existing unencrypted database: take a snapshot → copy the snapshot with encryption → restore a new DB instance from the encrypted snapshot.
• All read replicas of an encrypted database must also be encrypted, using the same or a different KMS key.
• For cross-region read replicas, you must use a KMS key in the destination region.
• Automated backups and snapshots of an encrypted RDS instance are also encrypted.
• You cannot create an unencrypted snapshot of an encrypted RDS instance.
• You cannot create an unencrypted read replica of an encrypted DB instance.
• RDS encryption encrypts the underlying storage, automated backups, snapshots, and read replicas — it covers data at rest.
• For data in transit, RDS supports SSL/TLS connections. This is separate from encryption at rest and must be configured independently.
RDS Encryption for Different Database Engines:
• MySQL, PostgreSQL, MariaDB, Oracle, SQL Server — all support RDS encryption using KMS.
• Oracle and SQL Server also support Transparent Data Encryption (TDE) as an additional layer. Oracle TDE can use AWS CloudHSM for key management via the Oracle TDE integration.
• Amazon Aurora — supports encryption at rest using KMS. Aurora encrypted clusters encrypt all DB instances, storage, backups, snapshots, and replicas.
Comparing EBS and RDS Encryption
While both EBS and RDS encryption use KMS and AES-256, there are important differences:
• EBS encryption can be enabled on existing volumes (through the snapshot-copy-restore process), and you can enable encryption by default for new volumes at the account level.
• RDS encryption must be set at instance creation time and cannot be toggled on an existing instance without the snapshot-copy-restore workflow.
• RDS manages the underlying EBS volumes, so you do not directly interact with EBS encryption settings when using RDS — RDS handles it for you.
• Both services support customer managed KMS keys, giving you control over key rotation, key policies, and access grants.
Key Management Considerations
• AWS Managed Keys vs. Customer Managed Keys (CMKs): AWS managed keys are simpler but offer less control. CMKs allow you to define key policies, enable automatic key rotation (every year), and use grants for fine-grained access control.
• Key Policies: You must ensure that the appropriate IAM principals (EC2 service, RDS service, or specific IAM roles) have permissions to use the KMS key for encryption and decryption operations (kms:Encrypt, kms:Decrypt, kms:GenerateDataKey, kms:ReEncrypt, kms:CreateGrant, kms:DescribeKey).
• Cross-Account Sharing: If you share an encrypted EBS snapshot or RDS snapshot with another account, you must also grant that account access to the KMS key used for encryption. AWS managed keys cannot be shared cross-account — you must use a CMK.
• Cross-Region Copying: When copying encrypted snapshots to another region, you must specify a KMS key in the destination region. The snapshot is re-encrypted with the destination key during the copy process.
Encrypting Unencrypted Resources — Step-by-Step
For EBS Volumes:
1. Create a snapshot of the unencrypted volume.
2. Copy the snapshot and enable encryption during the copy (select a KMS key).
3. Create a new volume from the encrypted snapshot.
4. Detach the old unencrypted volume and attach the new encrypted volume.
5. (Optional) Delete the old unencrypted volume and snapshot.
For RDS Instances:
1. Create a snapshot of the unencrypted RDS instance.
2. Copy the snapshot and enable encryption during the copy.
3. Restore a new RDS instance from the encrypted snapshot.
4. Update your application to point to the new encrypted RDS endpoint.
5. (Optional) Delete the old unencrypted instance after verification.
Important Limitations to Remember
• You cannot disable encryption on an encrypted EBS volume or RDS instance.
• You cannot create an unencrypted snapshot from an encrypted volume/instance.
• You cannot directly encrypt an existing unencrypted RDS instance — you must go through the snapshot-copy-restore process.
• You cannot share encrypted snapshots publicly.
• You cannot use AWS managed KMS keys for cross-account snapshot sharing — use a CMK instead.
• Encrypted EBS volumes can only be attached to supported instance types (virtually all current-generation instances support it).
• If the KMS key used for encryption is deleted or disabled, the encrypted data becomes permanently inaccessible.
Exam Tips: Answering Questions on EBS and RDS Encryption
Here are targeted strategies for tackling EBS and RDS encryption questions on the AWS Security Specialty exam:
1. Encryption by Default: Remember that you can enable EBS encryption by default at the account and region level. When this is enabled, all newly created EBS volumes and snapshot copies are automatically encrypted. This is a common answer for questions about enforcing encryption across an organization.
2. Snapshot-Copy-Restore Pattern: Whenever a question asks how to encrypt an existing unencrypted EBS volume or RDS instance, the answer almost always involves: snapshot → copy with encryption → restore from encrypted snapshot. Memorize this workflow.
3. Cross-Account Sharing: Questions about sharing encrypted snapshots across accounts will test whether you know that you must use a customer managed CMK (not the AWS managed key) and must grant the target account permissions on the CMK via key policy.
4. Cross-Region Considerations: KMS keys are regional. When copying encrypted snapshots across regions, you need a KMS key in the destination region. The snapshot is re-encrypted during the copy. For RDS cross-region read replicas, a KMS key in the target region is required.
5. Once Encrypted, Always Encrypted: If a question presents a scenario where someone wants to remove encryption, the answer is that this is not possible. You cannot un-encrypt an encrypted EBS volume or RDS instance.
6. SSL/TLS vs. Encryption at Rest: Don't confuse data in transit encryption (SSL/TLS) with encryption at rest (KMS-based). RDS questions may test both. For data in transit, the answer involves enabling SSL/TLS on the database connection, possibly using the rds.force_ssl parameter. For data at rest, the answer involves KMS encryption.
7. Key Deletion = Data Loss: If a question mentions deleting or scheduling deletion of a KMS key, understand that once the key is deleted, all data encrypted with it becomes permanently inaccessible. AWS has a mandatory waiting period (7-30 days) for key deletion to prevent accidental loss.
8. Oracle TDE and CloudHSM: If a question specifically mentions Oracle TDE or regulatory requirements for single-tenant key management, the answer may involve AWS CloudHSM rather than standard KMS.
9. Enforcement with SCPs and IAM Policies: Questions about preventing the creation of unencrypted resources may reference Service Control Policies (SCPs) or IAM policies with conditions like ec2:Encrypted or kms:ViaService. You can use condition keys to ensure that only encrypted volumes or databases are created.
10. Performance: EBS encryption has minimal to no noticeable performance impact because encryption is handled by the EC2 host hardware. If a question implies that encryption causes significant performance degradation, that answer is likely incorrect.
11. Read the Question Carefully for Scope: Determine whether the question is asking about data at rest, data in transit, or both. EBS/RDS encryption covers data at rest. Data in transit between EC2 and EBS is also encrypted when EBS encryption is enabled, but data in transit to RDS requires SSL/TLS configuration.
12. Watch for "Least Effort" or "Most Operationally Efficient" Questions: Enabling encryption by default at the account level is often the simplest solution. Using AWS managed keys requires less operational overhead than CMKs, but CMKs offer more control. Choose based on the scenario requirements.
13. Automatic Key Rotation: Customer managed KMS keys support automatic annual rotation. AWS managed keys are automatically rotated every three years (or every year depending on the service). If a question asks about key rotation for compliance, enabling automatic rotation on a CMK is the correct approach.
14. Grants and Key Policies: For EBS and RDS to use a CMK, the service must have appropriate permissions. This is typically handled through key policies and grants. RDS and EBS create grants on the CMK automatically when you select a CMK during resource creation. Understand how kms:CreateGrant and kms:ViaService conditions work.
15. Multi-AZ and Encryption: Both EBS and RDS support encryption in Multi-AZ configurations. Encryption does not affect the ability to use Multi-AZ deployments, failover mechanisms, or backup processes. If a question implies a conflict between encryption and high availability, that is incorrect.
Summary
EBS and RDS encryption are foundational data protection mechanisms in AWS. They both leverage AWS KMS, use AES-256 encryption, and follow the envelope encryption model. The key exam concepts revolve around understanding the snapshot-copy-restore workflow for encrypting existing resources, cross-account and cross-region encryption requirements, the distinction between AWS managed and customer managed keys, and the relationship between encryption at rest and encryption in transit. Mastering these topics will help you confidently answer a significant portion of the data protection questions on the AWS Security Specialty exam.
