Amazon RDS Architecture, Scaling, and High Availability – SAP-C02 Study Guide

Purpose of This Lesson

Amazon Relational Database Service (Amazon RDS) is a managed service for running relational databases without having to administer the underlying operating system, database installation, patching workflow, or routine backups yourself. For SAP-C02, the most important decisions involve selecting a database engine, distinguishing Multi-AZ from read replicas, and choosing between vertical scaling and horizontal read scaling.

RDS is primarily suited to online transaction processing (OLTP) workloads that require relational data models, SQL, transactions, and familiar database engines.

Key Concepts

Managed relational database service

An RDS DB instance runs on AWS infrastructure and uses attached storage. You select a DB instance class with an appropriate combination of compute and memory, along with the database engine, storage configuration, networking, and availability options.

A DB instance can host multiple user-created databases, depending on the selected engine and configuration. RDS resources are deployed inside a VPC and are typically placed in private subnets when they do not require direct internet access.

RDS uses Amazon EBS-backed storage for its database storage. Backups include:

• Automated backups, which support point-in-time recovery within the configured retention period.
• Manual snapshots, which are retained until explicitly deleted and can be copied for backup or migration purposes.

Supported database engines

RDS supports several familiar relational engines:

• Amazon Aurora – AWS-designed, MySQL- and PostgreSQL-compatible relational database engine.
• MySQL – Open-source relational database engine.
• PostgreSQL – Open-source relational database engine with extensive SQL functionality and extensibility.
• MariaDB – Community-developed MySQL-compatible engine.
• Oracle – Available through licensing options such as license included or Bring Your Own License, depending on the edition and configuration.
• Microsoft SQL Server – Available in supported SQL Server editions and licensing models.

Engine selection affects compatibility, licensing, feature availability, operational procedures, and migration complexity. A workload that depends on Oracle-specific packages, SQL Server features, or engine-specific extensions may not be a straightforward migration to Aurora or an open-source engine.

Vertical scaling: scaling up

Vertical scaling changes the DB instance class to provide more CPU and memory. It is appropriate when the database engine or workload needs more compute capacity, including increased write-processing capability.

Important characteristics:

• The DB instance class is changed to a larger or smaller class.
• A restart or failover can be required, creating an availability interruption unless the change is planned with an appropriate high-availability design.
• Vertical scaling increases the capacity of the database writer; it does not distribute writes across multiple RDS instances.
• Storage capacity and I/O characteristics are separate design considerations from the instance class.

Horizontal read scaling: read replicas

A read replica is an asynchronously replicated copy of an RDS database. It is designed to serve read traffic, allowing an application to distribute read requests between the primary DB instance and one or more replicas.

The application must intentionally route read operations to the replica. RDS does not automatically redirect arbitrary read traffic to a read replica. Common application patterns include:

• A writer endpoint or connection for transactions and updates.
• A reader connection, routing layer, or application-side logic for read-only queries.

Read replicas can be useful for:

• Increasing read throughput.
• Offloading reporting or analytics queries from the primary.
• Creating a source for a migration or data distribution workflow.
• Providing a cross-Region copy for disaster recovery.

Because replication is asynchronous, a replica can lag behind the source. It should not be treated as a guaranteed current copy for strongly consistent reads or as a replacement for synchronous high availability.

Multi-AZ deployments

A Multi-AZ RDS deployment maintains a primary DB instance and a synchronous standby in a different Availability Zone. The standby is kept current and is intended for high availability and automatic failover rather than read scaling.

Applications connect through the RDS endpoint rather than directly addressing an individual host. During a supported failure or maintenance event, RDS changes the endpoint’s DNS resolution so the standby becomes the new primary. The application generally continues using the same endpoint, although existing connections may need to reconnect.

Key properties:

• The standby is in a separate Availability Zone.
• Replication to the standby is synchronous.
• The standby is not normally available for application read traffic.
• Multi-AZ improves availability and failover capability; it does not increase read throughput.
• A Multi-AZ deployment can be combined with read replicas.

Cross-Region replication and disaster recovery

An RDS read replica can be created in another AWS Region. Replication across Regions is asynchronous, so the destination can have a recovery point objective determined by replication lag and operational procedures.

If the primary Region becomes unavailable, the cross-Region replica can be promoted to an independent primary. Promotion is not the same as automatic Multi-AZ failover: it requires a regional disaster-recovery procedure, including application endpoint changes, DNS updates, configuration changes, and validation.

Exam-Relevant Takeaways

• Multi-AZ is primarily for high availability and automatic failover. It uses synchronous replication to a standby in another Availability Zone.
• Read replicas are primarily for read scaling. They use asynchronous replication and require application-level read routing.
• A Multi-AZ standby is not a read replica. Do not select Multi-AZ when the requirement is higher read throughput.
• Vertical scaling is used when more compute or write capacity is needed. Changing the instance class can cause an interruption or failover.
• Read replicas can be placed in another Availability Zone or Region. Cross-Region replicas are especially relevant to disaster recovery and regional isolation.
• RDS endpoints abstract the active database host. Applications should use the provided endpoint and reconnect after failover.
• Backups and high availability solve different problems. Backups support recovery from logical corruption, accidental deletion, or historical restore points; Multi-AZ supports infrastructure failure and failover.
• Asynchronous replication implies possible data loss during a source failure. Evaluate the replica lag and the required RPO before choosing a read replica as a DR mechanism.

Architecture Decision Guide

Requirement	Appropriate RDS capability	Important design consideration
More CPU or memory for the database	Change the DB instance class	A restart or failover may be needed; plan for an interruption
More write-processing capacity	Vertical scaling of the primary	Standard RDS read replicas do not distribute writes
More read throughput	Read replicas	Route read traffic to replicas in the application or data-access layer
Automatic failover for an AZ failure	Multi-AZ deployment	Synchronous standby; standby is not for normal reads
Regional disaster recovery	Cross-Region read replica	Promotion and application recovery are operational steps; replication is asynchronous
Point-in-time recovery	Automated backups	Configure retention and test restoration procedures
Long-term or explicitly retained backup	Manual DB snapshot	Retained until deleted; manage copies and lifecycle deliberately
Compatibility with existing commercial database features	Matching RDS engine, such as Oracle or SQL Server	Review licensing, edition, extensions, and migration compatibility
Managed MySQL- or PostgreSQL-compatible database with AWS-specific architecture	Aurora	Validate engine compatibility, features, cost, and operational requirements

Common Exam Traps

• Confusing Multi-AZ with read replicas: Multi-AZ provides a standby for failover; it does not normally serve reads.
• Assuming read replicas are synchronous: RDS read-replica replication is asynchronous, so replica lag is possible.
• Assuming read scaling happens automatically: The application must use the replica endpoint or a reader-routing mechanism.
• Using a read replica to improve write performance: Standard read replicas serve reads; they do not create a multi-writer RDS database.
• Treating a cross-Region replica as automatic regional failover: Promotion, DNS, connection configuration, and application validation are still required.
• Connecting to an instance-specific hostname: Use the RDS endpoint so failover can redirect the application to the active primary.
• Relying only on Multi-AZ for data recovery: Multi-AZ does not protect against every logical error, such as an accidental delete replicated to the standby. Backups and snapshots are still required.
• Assuming scaling is always online: Changing the DB instance class can require a restart or failover, so maintenance windows and connection retry behavior matter.
• Choosing an engine without checking compatibility: SQL syntax, extensions, stored procedures, licensing, and vendor-specific capabilities can determine whether migration is practical.

Real-World Engineer Notes

• Use separate security groups and private subnets for database instances. Permit database ports only from approved application security groups rather than broad CIDR ranges.
• Design applications to tolerate RDS failover: use connection retries, sensible timeouts, connection-pool validation, and idempotent transaction handling where appropriate.
• Monitor replica lag before using a read replica for reporting, failover preparation, or migration. A replica that is behind may not satisfy the required recovery point.
• Keep read-after-write consistency in mind. If a user must immediately read data they just wrote, route that request to the writer or use an approach that accounts for replication lag.
• Test both backup restoration and Multi-AZ failover. A configured feature is not proof that the recovery process meets the required RTO and RPO.
• Place cross-Region replicas and copied snapshots under an explicit DR plan. Document promotion order, secrets and parameter updates, DNS behavior, application configuration, and rollback.
• Size storage, I/O, CPU, and memory independently. A larger DB instance class does not automatically solve a storage-throughput bottleneck.

Quick Reference Summary

• RDS: Managed relational databases for SQL and OLTP workloads.
• Vertical scaling: Change the DB instance class for more compute, memory, and write capacity; may require interruption.
• Read replica: Asynchronous copy used to scale reads; application must route reads to it.
• Multi-AZ: Synchronous standby in another AZ for high availability and automatic failover; not a read-scaling feature.
• Cross-Region read replica: Asynchronous regional DR option that must be promoted during recovery.
• Automated backups: Point-in-time recovery capability within the configured retention period.
• Manual snapshots: Explicitly retained backup artifacts.
• Endpoint: Use the RDS endpoint so applications can follow the active primary after failover.

Flashcards

1. Q: What type of workload is Amazon RDS primarily designed for?

A: Relational OLTP workloads requiring SQL, transactions, and a supported database engine.

1. Q: What is the main purpose of a Multi-AZ RDS deployment?

A: High availability and automatic failover to a standby in another Availability Zone.

1. Q: Is a Multi-AZ standby normally used for read traffic?

A: No. It is a standby for failover, not a read replica for application scaling.

1. Q: How does RDS replication to a read replica differ from Multi-AZ replication?

A: Read-replica replication is asynchronous; Multi-AZ standby replication is synchronous.

1. Q: What must an application do to use an RDS read replica?

A: Explicitly route read operations to the replica.

1. Q: Which RDS scaling approach improves write capacity?

A: Vertical scaling by changing the primary DB instance class.

1. Q: Why can a cross-Region read replica be useful for disaster recovery?

A: It provides a copy in another Region that can be promoted if the primary Region fails.

1. Q: What is a major limitation of using a read replica for DR?

A: Asynchronous replication can leave the replica behind, creating potential data loss based on replication lag.

1. Q: Why should applications use an RDS endpoint instead of an instance-specific address?

A: The endpoint can resolve to the new primary after failover.

1. Q: What is the difference between automated backups and manual snapshots?

A: Automated backups support point-in-time recovery within retention settings; manual snapshots are explicitly retained until deleted.

1. Q: Can Multi-AZ and read replicas be used together?

A: Yes. Multi-AZ can protect the primary through failover while read replicas handle read scaling.

1. Q: What should be checked before selecting an RDS engine for migration?

A: SQL compatibility, extensions, stored procedures, licensing, editions, and vendor-specific features.

Practice Questions

Question 1

A production application uses Amazon RDS for PostgreSQL. It requires automatic failover if the database host or Availability Zone fails. The application does not need additional read throughput. Which design best meets the requirement?

A. Create a read replica in the same Availability Zone
B. Deploy the DB instance using Multi-AZ
C. Create a cross-Region read replica and route all reads to it
D. Increase the DB instance class

Correct answer: B

Explanation: Multi-AZ provides a synchronous standby in another Availability Zone and supports automatic failover. A read replica is intended for read scaling and uses asynchronous replication. Increasing the instance class addresses capacity rather than high availability.

Question 2

A reporting workload generates many read queries against an RDS MySQL production database. The reports can tolerate slightly stale data, but transaction performance on the primary must be protected. What is the best solution?

A. Add a read replica and route reporting queries to it
B. Enable Multi-AZ and send reports to the standby
C. Increase the database backup retention period
D. Promote the primary database to a larger Region

Correct answer: A

Explanation: A read replica is designed to offload read traffic and can tolerate asynchronous replication lag when stale data is acceptable. A Multi-AZ standby is not normally available for reporting queries.

Question 3

A company needs a recovery copy of its RDS database in a second Region. During a regional outage, operators can execute a documented recovery procedure, and the business accepts a small amount of potential data loss. Which option is most appropriate?

A. Multi-AZ deployment in the primary Region
B. A cross-Region read replica that can be promoted
C. A same-AZ read replica with synchronous replication
D. A larger DB instance class in the primary Region

Correct answer: B

Explanation: A cross-Region read replica provides a geographically separate copy and can be promoted during a regional disaster. Replication is asynchronous, so the design must account for replica lag and the resulting RPO. Multi-AZ protects against an AZ-level failure, not a full regional outage.

Question 4

An RDS database is approaching its CPU and memory limits, and write latency is increasing. The team wants a solution that increases the capacity of the active writer. Which action is most suitable?

A. Add a read replica and send writes to it
B. Change the DB instance class to a larger class
C. Enable Multi-AZ and use the standby for writes
D. Increase automated backup retention

Correct answer: B

Explanation: Changing the DB instance class vertically scales the database and increases available compute and memory for the writer. Read replicas and Multi-AZ standbys do not provide a standard multi-writer RDS architecture, and backup retention does not improve runtime capacity.

Question 5

An application connects directly to the hostname of the current RDS primary instance. After a failover, the application continues trying the old host and does not recover automatically. Which design correction is most appropriate?

A. Use the RDS endpoint and implement connection retry handling
B. Send all traffic to the Multi-AZ standby hostname
C. Replace RDS with a read replica
D. Disable automated backups

Correct answer: A

Explanation: The RDS endpoint abstracts the active database host and can resolve to the new primary after failover. Applications should also handle dropped connections and retry using appropriate timeout and pool settings.