Study guide
Technical reference and lesson notes
Purpose of This Lesson
Amazon RDS encryption must be selected when the DB instance is created. If an existing DB instance is unencrypted, you cannot enable encryption in place. The supported migration pattern is to create an unencrypted snapshot, copy it as an encrypted snapshot, and restore the encrypted copy as a new DB instance.
This process creates a separate database with a new DB instance identity and endpoint. Applications must therefore be reconfigured or redirected to the new database.
Key Concepts
RDS encryption is a creation-time setting
For an RDS DB instance, storage encryption cannot be enabled or disabled after the instance has been created. The same restriction applies to the encryption state of a DB snapshot:
- An unencrypted snapshot can be copied to create an encrypted snapshot.
- An encrypted snapshot cannot be copied into an unencrypted snapshot.
- Restoring an encrypted snapshot creates an encrypted DB instance.
Encryption migration workflow
The standard workflow is:
- Create a manual snapshot of the existing unencrypted RDS DB instance.
- Copy the snapshot.
- Enable encryption during the copy operation.
- Select an AWS KMS key, using the default key or a customer managed key as appropriate.
- Restore the encrypted snapshot as a new RDS DB instance.
- Update applications, connection strings, DNS records, or other dependencies to use the new endpoint.
- Validate the new database before decommissioning the original instance.
The snapshot copy can be created in the same AWS Region or, where supported, copied to another Region. Cross-Region copies are useful for regional migration and disaster recovery, but the destination Region must have an appropriate KMS key available.
The restored database is a new resource
Restoring a snapshot does not alter the source DB instance. The new instance has its own:
- DB instance identifier
- Endpoint and connection details
- Storage and compute configuration
- Security group and subnet group associations, as configured during restoration
- Backup and maintenance settings, which should be reviewed independently
Applications do not automatically move to the new database. A planned cutover is required.
KMS key considerations
RDS uses AWS KMS to protect encrypted database storage and snapshots. During snapshot copy, choose the KMS key that should protect the encrypted snapshot. For production workloads, a customer managed KMS key may be preferable when the organization needs explicit control over key policies, grants, rotation configuration, or key lifecycle.
The principals performing the copy and restore need permission to use the relevant KMS key. For cross-account or cross-Region operations, key policies and IAM permissions must be configured for the destination environment.
Architecture Decision Guide
| Requirement | Recommended approach | Important consideration |
|---|---|---|
| Enable encryption for an existing unencrypted RDS DB instance | Snapshot, copy with encryption enabled, then restore | Creates a new DB instance and endpoint |
| Preserve the original unencrypted database during migration | Keep the source instance running while validating the restored instance | Additional storage and instance cost applies |
| Move encrypted snapshot data to another Region | Copy the snapshot to the destination Region and select a destination KMS key | Configure KMS permissions and account for transfer time and cost |
| Prevent future applications from depending on a fixed RDS endpoint | Place a stable DNS name or configuration abstraction in front of the database endpoint | DNS or configuration cutover still requires operational planning |
| Require customer-controlled encryption keys | Use a customer managed KMS key during snapshot copy or database creation | Protect the key policy and avoid disabling or deleting an in-use key |
| Remove encryption from an encrypted RDS snapshot | Not supported through snapshot copy | Export or migrate data through another mechanism if unencrypted data is explicitly required |
Exam-Relevant Takeaways
- You cannot enable storage encryption directly on an existing unencrypted RDS DB instance.
- The exam-friendly migration sequence is snapshot → encrypted snapshot copy → restore as a new DB instance.
- Restoring the encrypted snapshot does not convert the original database; it creates a separate database.
- The new database has a different endpoint, so application connectivity must be updated.
- Encryption can be added when copying an unencrypted snapshot.
- Encryption cannot be removed by copying an encrypted snapshot.
- AWS KMS key selection is part of the encrypted snapshot-copy process.
- Treat the change as a migration and cutover, not as an in-place configuration update.
Common Exam Traps
Choosing an in-place modification
Changing the DB instance class, storage configuration, or some other modifiable setting does not mean encryption can be enabled after creation. Encryption status is a special creation-time property.
Assuming the snapshot is automatically encrypted
An unencrypted RDS instance produces an unencrypted snapshot. Encryption must be explicitly enabled when the snapshot is copied.
Expecting the original endpoint to remain valid
The restored instance is a new database. An answer that ignores endpoint changes is incomplete unless an abstraction such as controlled DNS or application configuration already handles the cutover.
Trying to decrypt an encrypted snapshot
RDS does not provide a snapshot-copy operation that removes encryption. Encryption is one-way within this workflow.
Deleting the source too early
The original database should remain available until the encrypted replacement has been restored, tested, and adopted by all dependent applications.
Forgetting KMS permissions
A user may have RDS permissions but still lack permission to use the selected KMS key. IAM policies and KMS key policies must both permit the required operations.
Real-World Engineer Notes
A production migration should include more than the snapshot operation:
- Confirm the acceptable recovery point objective because the snapshot represents data at a particular point in time.
- Schedule the snapshot and cutover to minimize application disruption.
- Validate database engine version, parameter groups, option groups, subnet groups, security groups, monitoring, backups, and maintenance settings on the replacement instance.
- Test application connectivity, credentials, TLS requirements, performance, and read/write behavior before cutover.
- Plan how to handle writes that occur on the source after the snapshot is created. For workloads requiring minimal data loss, use an appropriate replication or migration strategy rather than relying on a stale snapshot alone.
- Use a controlled endpoint abstraction, such as a DNS record or centralized configuration, to reduce the number of application changes during cutover.
- Retain the original instance or snapshot until rollback and compliance requirements have been satisfied.
- Review KMS key ownership, rotation, access logging, and deletion safeguards before using a customer managed key.
Quick Reference Summary
Existing unencrypted RDS instance
|
v
Create manual unencrypted snapshot
|
v
Copy snapshot with encryption enabled and select KMS key
|
v
Restore encrypted snapshot as a new RDS DB instance
|
v
Test, cut over applications, and retire the original when safe
The key rule is: RDS encryption cannot be enabled in place; use an encrypted snapshot copy and restore it as a new DB instance.
Flashcards
- Q: Can encryption be enabled directly on an existing unencrypted RDS DB instance?
A: No. Encryption must be enabled at creation time, so the database must be migrated through an encrypted snapshot copy.
- Q: What is the first step when migrating an unencrypted RDS database to encryption?
A: Create a snapshot of the existing DB instance.
- Q: How is encryption added to an unencrypted RDS snapshot?
A: Copy the snapshot and enable encryption during the copy operation.
- Q: What does restoring an encrypted RDS snapshot create?
A: A new encrypted DB instance.
- Q: Does the restored database retain the original RDS endpoint?
A: No. It receives a new endpoint, requiring an application cutover or configuration update.
- Q: Can an encrypted RDS snapshot be copied as an unencrypted snapshot?
A: No. Snapshot copying cannot remove encryption.
- Q: What AWS service manages the keys used for RDS encryption?
A: AWS Key Management Service, or AWS KMS.
- Q: Why should the original database generally remain available during migration?
A: It provides a rollback option and allows validation of the replacement before production cutover.
- Q: What must be checked in addition to the encryption setting after restoring the snapshot?
A: Connectivity, security groups, subnet group, parameter and option groups, backups, monitoring, maintenance settings, and application behavior.
- Q: What permissions are required when using a customer managed KMS key?
A: The operator and relevant RDS workflows need IAM and KMS key-policy permissions to use the key.
Practice Questions
Question 1
A company has an unencrypted Amazon RDS DB instance containing production data. Security policy now requires storage encryption. The company wants to preserve the data while minimizing application changes. What is the correct approach?
A. Modify the existing DB instance and enable encryption.
B. Create a snapshot, copy it with encryption enabled, and restore it as a new DB instance.
C. Enable encryption on the existing automated backups and wait for the instance to inherit it.
D. Copy the database snapshot without encryption and enable encryption after restoration.
Correct answer: B
Explanation: RDS encryption cannot be enabled in place. An encrypted snapshot copy must be created and restored as a new DB instance. The application must still be directed to the new endpoint.
Question 2
An architect copies an encrypted RDS snapshot and wants the resulting snapshot to be unencrypted for use in a development account. Which statement is correct?
A. The encryption option can be disabled during the copy.
B. Encryption can be removed if the default KMS key was used.
C. RDS snapshot copy cannot remove encryption.
D. Encryption is removed automatically when the snapshot crosses accounts.
Correct answer: C
Explanation: RDS supports creating an encrypted copy from an unencrypted snapshot, but it does not support removing encryption through snapshot copy.
Question 3
A team restores an encrypted RDS snapshot and discovers that applications still connect to the original unencrypted database. What is the most likely reason?
A. The restored database cannot accept application connections.
B. Snapshot restoration changes storage encryption but not the endpoint used by applications.
C. RDS automatically retains the original endpoint for 24 hours.
D. The KMS key prevents application connectivity.
Correct answer: B
Explanation: Snapshot restoration creates a separate DB instance with a new endpoint. Applications must be updated or redirected as part of the cutover.
Question 4
An organization copies an unencrypted RDS snapshot to another Region and enables encryption. The copy fails because the destination account cannot use the selected key. What should the architect investigate first?
A. Whether the source DB instance is Multi-AZ.
B. Whether the destination Region has a usable KMS key and the required IAM and key-policy permissions.
C. Whether the original DB instance has a public IP address.
D. Whether the source snapshot was created manually.
Correct answer: B
Explanation: Encrypted cross-Region snapshot copies require an appropriate KMS key in the destination context and permissions for the principals and RDS workflow to use it.
Question 5
A company must encrypt an existing RDS database but cannot tolerate losing writes made after a snapshot is created. Which design concern is most important?
A. A snapshot alone may not provide the required recovery point for the final cutover.
B. Encryption requires converting the database to an EC2 instance first.
C. RDS cannot restore encrypted snapshots.
D. The database must be made publicly accessible during migration.
Correct answer: A
Explanation: A snapshot captures data at a point in time. If the workload requires minimal data loss, the team needs an appropriate replication or migration method and a carefully planned cutover rather than relying solely on a static snapshot.