AWS Certified Solutions Architect: High Availability & Scaling Databases

In the AWS ecosystem, database reliability and performance are critical. For the SAA-C03 exam, you must distinguish between High Availability (HA)—ensuring the database stays up during a failure—and Scalability—ensuring the database can handle increased load.

The “Restaurant Kitchen” Analogy

Imagine a busy restaurant kitchen (Your Database):

  • Multi-AZ (High Availability): You have a second identical kitchen across town. If your main kitchen catches fire, the staff instantly moves to the second kitchen. The customers barely notice the delay. This is for disaster recovery.
  • Read Replicas (Scaling): You hire junior chefs who can only plate salads and desserts (Read-only tasks). This frees up the Head Chef to focus on the complex entrees (Writes). This is for performance.

Core Concepts & Well-Architected Framework

According to the Reliability Pillar, workloads must have mechanisms to recover from service disruptions. AWS RDS and Aurora provide automated failover to meet this requirement. Under the Performance Efficiency Pillar, you should use the right resource type to maintain efficiency as demand evolves, which is where Read Replicas and Amazon DynamoDB Auto Scaling come into play.

Comparison: RDS Multi-AZ vs. Read Replicas

Feature RDS Multi-AZ (HA) RDS Read Replicas (Scaling)
Primary Purpose High Availability / Disaster Recovery Scalability / Performance
Replication Type Synchronous (Strong consistency) Asynchronous (Eventual consistency)
AWS Use Case Automatic Failover in case of AZ outage Offload read-heavy workloads
Backups Taken from Standby (No impact on Primary) Not applicable
Quantity 1 Standby Instance Up to 15 (Aurora) or 5 (RDS)

Decision Matrix: “If / Then” Scenarios

  • If the application is read-heavy and the database is struggling… Then add Read Replicas.
  • If you need to ensure the database survives an Availability Zone failure… Then enable Multi-AZ.
  • If you need global low-latency reads for a NoSQL workload… Then use DynamoDB Global Tables.
  • If you need a database that scales storage automatically up to 128TB… Then choose Amazon Aurora.

Exam Tips: Golden Nuggets

  • Distractor Alert: Read Replicas are NOT for High Availability. While you can promote a replica to primary, it is not an automatic failover process like Multi-AZ.
  • Aurora Difference: Aurora is “HA by design.” It stores 6 copies of data across 3 AZs.
  • Multi-Region: For true global disaster recovery, use Cross-Region Read Replicas or Aurora Global Database.
  • DynamoDB: Remember that DAX (DynamoDB Accelerator) is for in-memory caching, while Global Tables are for multi-region replication.

Visualizing Database Architecture

Availability Zone A PRIMARY DB Availability Zone B STANDBY (HA) Synchronous (Multi-AZ) READ REPLICA Asynchronous (Scaling)
Key Services
  • Amazon RDS: Managed SQL (MySQL, Postgres, Oracle).
  • Amazon Aurora: Cloud-native, 5x faster than standard MySQL.
  • DynamoDB: NoSQL, single-digit millisecond latency.
Common Pitfalls
  • Using Multi-AZ to solve “slow read” problems (it won’t).
  • Forgetting that Read Replicas incur extra data transfer costs across regions.
  • Assuming RDS is Serverless (Only Aurora has a Serverless tier).
Quick Patterns
  • Bursting: Use RDS Proxy to handle connection pooling.
  • Caching: Put ElastiCache in front of RDS to reduce load.
  • DR: Use Cross-Region snapshots for backups.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top