Amazon RDS Security: Encryption, KMS, TLS, and Access Control – SAP-C02 Study Guide | AWS Systems Architect Professional

Study guide

Technical reference and lesson notes

Purpose of This Lesson

Amazon RDS security involves controlling network access, protecting connections in transit, encrypting database storage, and understanding how encryption affects snapshots and read replicas. These details frequently appear in AWS certification scenarios because RDS encryption status is largely determined when the database is created.

Key Concepts

Network access and security groups

An Amazon RDS database runs inside a VPC and has a network endpoint and IP address. It can be configured as publicly accessible, but public accessibility should be used only when required and must be tightly controlled.

A common security-group design is:

Assign a dedicated security group to the RDS database.
Assign a separate security group to the application servers, such as EC2 instances.
Add an inbound rule to the database security group that references the application security group as the source.
Permit only the required database port.

For example, MySQL commonly uses TCP port 3306. Referencing the application security group is preferable to allowing a broad CIDR range because access follows the identity of the application instances rather than their changing private IP addresses.

Encryption in transit with TLS/SSL

RDS can use SSL/TLS to encrypt connections between an application and the database. This protects data while it travels across the network, including credentials and query results.

Network encryption and storage encryption solve different problems:

TLS/SSL: Protects data in transit between the client and database.
RDS encryption at rest: Protects database storage and related persisted data.

Enabling one does not automatically provide the other.

Encryption at rest with AWS KMS

RDS encryption at rest uses AWS Key Management Service (AWS KMS) to manage the encryption keys. The underlying encryption uses AES-256 and is designed to have minimal performance impact for RDS workloads.

RDS encryption at rest covers important database-related data, including:

Database storage volumes
Automated backups
Read replicas
DB snapshots

For Oracle and SQL Server, transparent data encryption (TDE) is also supported. TDE is a database-engine encryption capability and may have a performance impact, so it should not be treated as identical to standard RDS storage encryption.

Encryption status is established at creation

RDS encryption at rest must be enabled when the DB instance is created. You cannot directly enable encryption on an existing unencrypted DB instance, and you cannot directly disable encryption on an encrypted one.

This restriction also affects operations involving snapshots and replicas. RDS does not provide a direct operation that changes the encryption state of the same existing database instance.

Read replica encryption rules

A read replica must have the same encryption status as its source DB instance:

An encrypted primary cannot have an unencrypted read replica.
An unencrypted primary cannot have an encrypted read replica created directly from it.
A read replica of an encrypted primary is encrypted.
For a replica in the same AWS Region, the same KMS key is used.
For a cross-Region read replica, a different KMS key is used in the destination Region.

The cross-Region rule matters because KMS keys are Region-specific. A key from the source Region cannot simply be used as the destination Region’s encryption key.

Converting an unencrypted database to encrypted storage

To create an encrypted equivalent of an existing unencrypted database:

Create a DB snapshot of the unencrypted database.
Copy the snapshot and enable encryption during the copy operation.
Select the appropriate KMS key for the encrypted copy.
Restore a new RDS DB instance from the encrypted snapshot.
Update the application configuration to use the new database endpoint.
Validate the application and plan the cutover or migration process.

The result is a new DB instance, not a change to the original instance. The original endpoint remains associated with the unencrypted database until the application is deliberately migrated.

Exam-Relevant Takeaways

RDS databases use VPC networking and security groups.
Prefer separate security groups for application instances and the database.
Allow the application security group to reach the database security group on only the required port.
Public accessibility is a network exposure decision, not a substitute for access control.
TLS/SSL protects connections in transit.
RDS encryption at rest protects storage, backups, snapshots, and read replicas.
RDS encryption at rest uses AWS KMS and AES-256.
Encryption at rest must be selected when the DB instance is created.
You cannot directly encrypt an existing unencrypted DB instance.
You cannot directly decrypt an existing encrypted DB instance.
An encrypted read replica cannot be created directly from an unencrypted primary, and vice versa.
Same-Region replicas use the same KMS key; cross-Region replicas use a destination-Region KMS key.
To change encryption status, create an encrypted snapshot copy and restore a new DB instance.

Architecture Decision Guide

Requirement	Appropriate design choice	Important consideration
Allow application servers to connect to RDS	Reference the application security group in the RDS security group rule	Restrict access to the database port only
Protect database traffic in transit	Configure clients to use SSL/TLS	This is separate from encryption at rest
Protect RDS storage and backups	Enable RDS encryption at creation using AWS KMS	Encryption status cannot be changed directly later
Create an encrypted database from an unencrypted one	Encrypt a copied DB snapshot, then restore a new DB instance	The endpoint changes and applications must be updated
Create a read replica for an encrypted primary	Create an encrypted read replica	Same Region uses the same KMS key; another Region uses a different key
Make an RDS database reachable from the internet	Use public accessibility only when required and restrict security-group ingress	Public reachability increases exposure and does not eliminate the need for authentication and authorization

Common Exam Traps

Confusing TLS with encryption at rest: TLS protects network traffic; KMS-backed RDS encryption protects persisted database data.
Assuming encryption can be enabled later: RDS does not directly convert an existing unencrypted DB instance into an encrypted one.
Assuming a snapshot restore changes encryption automatically: An unencrypted snapshot restores to an unencrypted DB instance unless the snapshot is copied with encryption first.
Assuming a read replica can use a different encryption state: The replica follows the source database’s encryption status.
Forgetting the endpoint change: Restoring from an encrypted snapshot creates a new database with a new endpoint.
Using the source Region’s KMS key for a cross-Region replica: KMS keys are Region-specific; the destination uses a different key.
Opening the database to a large CIDR range unnecessarily: A security-group-to-security-group rule is usually more precise for application-to-database access.
Treating public accessibility as an authorization mechanism: Public accessibility only describes network reachability. Security groups and database authentication still control access.

Real-World Engineer Notes

Decide on encryption before provisioning production RDS databases. Retrofitting encryption requires a snapshot-copy-and-restore workflow and an application cutover.
Treat the KMS key as part of the database’s lifecycle design. Key permissions, ownership, rotation policy, and Region availability can affect backup restoration and replication operations.
Test encrypted snapshot restoration and application reconnection before an incident requires the procedure.
Use separate security groups for application and database tiers so network policy remains understandable and changes to one tier do not unintentionally expose the other.
When migrating to a newly encrypted database, plan for endpoint updates, connection draining, data consistency, and rollback.
If TLS is required, configure clients to validate the database certificate and reject plaintext connections rather than merely enabling a server-side option.

Quick Reference Summary

Network location: RDS runs in a VPC.
Network control: Security groups regulate inbound connectivity.
Application access pattern: App security group → RDS security group → database port.
In transit: SSL/TLS.
At rest: RDS encryption using AWS KMS and AES-256.
Encrypted data: Storage, backups, snapshots, and read replicas.
Creation rule: Choose encryption when creating the DB instance.
Replica rule: Read replicas retain the source encryption status.
Cross-Region rule: A destination-Region KMS key is used.
Conversion pattern: Snapshot → encrypted snapshot copy → new encrypted DB instance → application cutover.

Flashcards

Q: Where does an RDS database run?

A: Inside an Amazon VPC, with a network endpoint and IP address.

Q: What is the recommended security-group relationship for an application and RDS?

A: Give each tier a separate security group and allow the application security group to access the RDS security group on the required database port.

Q: What does TLS/SSL protect for an RDS connection?

A: Data in transit between the client or application and the database.

Q: What service manages keys for RDS encryption at rest?

A: AWS Key Management Service (AWS KMS).

Q: What encryption algorithm is associated with standard RDS encryption at rest?

A: AES-256.

Q: When must RDS encryption at rest be enabled?

A: When the DB instance is created.

Q: Can an existing unencrypted RDS DB instance be directly encrypted?

A: No. Create an encrypted copy of a snapshot and restore a new DB instance.

Q: Can an encrypted primary have an unencrypted read replica?

A: No. The read replica has the same encryption status as its source.

Q: Which KMS key is used for a same-Region read replica?

A: The same KMS key as the encrypted primary.

Q: Why does a cross-Region read replica use a different KMS key?

A: KMS keys are Region-specific, so the destination Region requires its own key.

Q: What happens to an application’s connection when a new encrypted instance is restored from a copied snapshot?

A: The application must be updated to use the new instance’s endpoint.

Q: What is the distinction between RDS encryption at rest and TDE?

A: RDS encryption protects storage and related persisted data, while TDE is a database-engine capability supported for Oracle and SQL Server and may have a performance impact.

Practice Questions

Question 1

A company has an unencrypted production RDS database. Its security policy now requires encryption at rest. The company wants to preserve the existing data while minimizing application changes. Which approach meets the requirement?

A. Enable encryption on the existing DB instance during the next maintenance window.
B. Create an encrypted read replica from the unencrypted primary.
C. Create a snapshot, copy the snapshot with encryption enabled, restore a new DB instance, and update the application endpoint.
D. Restore the unencrypted snapshot directly into an encrypted DB instance.

Correct answer: C

RDS encryption status cannot be changed directly on an existing DB instance. An encrypted snapshot copy must be restored as a new DB instance, which requires an endpoint migration.

Question 2

An encrypted RDS primary is in us-east-1. The architect must create a cross-Region read replica in us-west-2. Which statement is correct?

A. The replica must be unencrypted because KMS keys cannot be used for replicas.
B. The replica is encrypted and uses a KMS key in the destination Region.
C. The replica is encrypted and must use the exact same KMS key ARN as the source.
D. The source database must first be decrypted.

Correct answer: B

An encrypted primary produces an encrypted read replica. For a cross-Region replica, encryption uses a different KMS key in the destination Region because KMS keys are Region-specific.

Question 3

An application running on EC2 needs to connect to a private RDS MySQL database. Which security-group configuration best follows least privilege?

A. Allow inbound TCP 3306 from 0.0.0.0/0 on the RDS security group.
B. Allow inbound TCP 3306 from the EC2 instances’ security group on the RDS security group.
C. Allow all traffic from the RDS security group to the EC2 security group.
D. Allow inbound TCP 22 from the EC2 security group on the RDS security group.

Correct answer: B

The RDS security group should allow the application security group to connect on the database port, such as MySQL’s TCP 3306. This avoids broad internet exposure and limits access to the application tier.

Question 4

A compliance requirement states that database credentials and query results must be protected while traveling between an application and RDS. Which control directly addresses this requirement?

A. Enable RDS encryption at rest with AWS KMS.
B. Create a DB snapshot.
C. Configure SSL/TLS for the database connection.
D. Add a read replica.

Correct answer: C

SSL/TLS provides encryption in transit. RDS encryption at rest protects persisted data but does not by itself encrypt the network connection.

Question 5

A team wants an encrypted read replica of an unencrypted RDS primary without creating a new primary database. What should the architect conclude?

A. This is supported because replicas can always use a stronger encryption setting.
B. This is supported only when the replica is in another Region.
C. This is not directly supported; the team must use an encryption-and-restore migration pattern.
D. This requires enabling TDE on the primary.

Correct answer: C

A read replica must have the same encryption status as its source. To obtain an encrypted database from an unencrypted source, create an encrypted copy of a snapshot and restore a new DB instance.