Design High-Performing Architectures
Relational Database Performance and Availability
CoreChoose relational engines, topology, replicas, proxies, capacity, and failover without confusing availability and read scaling.
Aligned to the current SAA-C03 exam guide, verified August 16, 2026.
Why this matters
Relational design requires separating four decisions: engine compatibility, writer availability, read capacity, and connection pressure. Multi-AZ, read replicas, Aurora topology, proxies, and caches solve neighboring problems but are not interchangeable.
Must Know
- Choose a relational engine from application compatibility, SQL features, operational requirements, licensing, migration path, and ecosystem before optimizing topology.
- RDS manages common relational engines; Aurora is AWS-built, MySQL/PostgreSQL-compatible, and separates distributed cluster storage from database compute.
- RDS Multi-AZ deployments provide managed in-Region high availability and failover. They are not primarily a read-scaling feature.
- Read replicas are asynchronous copies used mainly for read scaling and can support explicit recovery designs; replica lag and application routing matter.
- Aurora replicas share cluster storage, serve reads through reader endpoints, and can be promoted; topology and replica placement determine failure behavior.
- RDS Proxy pools and reuses connections, helping bursty/serverless clients and failover handling. It does not cache query results.
- ElastiCache stores hot reusable data in memory to reduce read latency and database load; cache invalidation and misses remain application concerns.
- DMS moves/replicates database data with limited downtime; heterogeneous migrations may also require schema conversion outside DMS's data movement role.
Compare and Distinguish
- Multi-AZ vs read replica: choose synchronous managed HA/failover or asynchronous read scaling. Use both when both requirements exist.
- RDS vs Aurora: RDS wins for broader engine choice and conventional managed deployments; Aurora wins when its compatible engines and distributed cluster architecture meet performance/availability needs.
- RDS Proxy vs ElastiCache: Proxy reduces connection pressure and improves connection handling; ElastiCache serves cached data to avoid database reads.
- Scale up vs read replicas vs cache: scale the writer for writer/resource pressure, replicas for distributable reads, and cache for repeatable hot reads tolerant of cache semantics.
- Homogeneous vs heterogeneous migration: same-engine moves focus on data transfer; different engines add schema/code conversion and compatibility risk.
Scenario examples
- Scenario: A database must fail over automatically after an AZ failure but has little read pressure. Think: Multi-AZ, not a standalone read replica.
- Scenario: Reporting queries overload the writer and tolerate replica lag. Think: route reads to replicas.
- Scenario: Thousands of Lambda invocations create short database connections. Think: RDS Proxy addresses connection pressure; a cache would solve a different problem.
- Scenario: A hot product catalog is repeatedly read and can tolerate controlled staleness. Think: ElastiCache can reduce latency and database load.
Exam traps
- A read replica is not synchronous HA failover.
- Multi-AZ does not automatically provide a readable standby in every deployment form.
- RDS Proxy does not cache query results or increase database CPU.
- A cache is not the system of record and may return stale data.
- Aurora compatibility does not mean every engine-specific feature behaves identically.
- DMS does not automatically solve all schema and application changes in heterogeneous migration.
Key takeaways
- Separate engine, HA, read scale, connection, and cache decisions.
- Use Multi-AZ for managed failover and replicas for reads.
- Use Proxy for connections and ElastiCache for reusable data.
- Measure replica lag, connection pressure, and writer load independently.
- Choose migrations from engine compatibility and downtime constraints.
How it works
- RDS manages instances, backups, maintenance, and topology for supported engines.
- Aurora compute instances connect to distributed cluster storage; reader and writer endpoints direct traffic by role.
- Read replicas receive changes asynchronously and serve explicitly routed reads.
- RDS Proxy multiplexes client connections onto managed database connections.
When to use it
- Use RDS for supported relational engines and Aurora when its compatible architecture is advantageous.
- Use Multi-AZ for production HA, read replicas for read scaling, Proxy for bursty connections, and ElastiCache for hot data.
- Use DMS for database data movement/replication, especially when downtime must be minimized.
Security and governance implications
- Encrypt database storage and connections and keep databases in private network tiers.
- Use Secrets Manager and roles rather than embedding database credentials where supported.
- Separate backup retention and deletion permissions from routine operation.
- Restrict replica and snapshot sharing across accounts.
Operational and diagnostic signals
- For slow reads, distinguish writer saturation, replica lag, cache miss rate, query/I/O bottleneck, and network path.
- For failed failover, inspect topology, client DNS/connection reuse, transaction retry, and capacity.
- For connection errors under bursts, compare client concurrency with database connection capacity and Proxy configuration.
- For migration mismatch, separate network/data replication problems from schema/application compatibility.
More detail
- Database performance spans CPU, memory, storage I/O, locks, connections, query shape, read/write mix, and network placement.
- Replication lag affects how current read results are and whether a replica can meet recovery objectives.
- Multi-AZ and backups serve different failure cases: availability topology does not replace retained recovery points.
- Application retry and connection behavior determines how cleanly clients survive failover.
Ready for the quiz?
- Why is a read replica not a Multi-AZ substitute?
- When does Aurora beat standard RDS?
- Which symptom points to RDS Proxy?
- When does a cache beat another replica?
- What extra work appears in heterogeneous migration?
Related objectives
- D2.1.K15
- D3.3.K1
- D3.3.K5
- D3.3.K6
- D3.3.K7
- D3.3.S1
- D3.3.S2
- D3.3.S3