RDS and Aurora: Multi-AZ and Read Replicas

Amazon RDS Multi-AZ is a high-availability feature that automatically creates and manages a synchronous standby replica in a different Availability Zone (AZ). Its primary purpose is to provide automatic failover with zero data loss (RPO=0) and a typical RTO of 1-2 minutes. This is not a read scaling solution—the standby is not accessible for reads or writes. The exam tests this distinction heavily.

When you enable Multi-AZ on an RDS instance (supported engines: MySQL, MariaDB, PostgreSQL, Oracle, SQL Server), RDS provisions a primary instance in one AZ and a standby instance in another AZ. The replication is synchronous: every write transaction must be committed on both the primary and standby before the primary acknowledges the write to the client. This ensures that the standby is always fully consistent.

At the network level, RDS uses Amazon’s private network for replication traffic, which incurs no data transfer costs between AZs (but inter-AZ data transfer costs apply for data out). The replication is handled by the database engine’s native synchronous replication mechanism:

During a failover event, RDS automatically detects the primary failure (health checks, network connectivity) and upgrades the standby to become the new primary. The DNS record for the RDS endpoint is updated to point to the new primary. Applications using the CNAME endpoint experience a brief downtime (typically 60-120 seconds) while the DNS change propagates and the new primary accepts connections.

Read Replicas are separate RDS instances that receive asynchronous replication from a source RDS instance. They are designed for read scaling, not high availability. You can have up to 15 Read Replicas per source (for MySQL, MariaDB, PostgreSQL, Oracle, SQL Server). Replicas can be in the same region, cross-region, or even cross-account.

Replication is asynchronous: the source sends changes to the replica via the database engine’s native replication (e.g., MySQL’s binary log replication, PostgreSQL’s streaming replication). The source does not wait for the replica to acknowledge; therefore, the replica may lag behind. Replication lag is measured in seconds and can be monitored via CloudWatch metrics (ReplicaLag). The exam often tests that Read Replicas can be promoted to standalone instances (breaking replication) but this is not automatic and involves data loss if not fully caught up.

To create a Multi-AZ DB instance via CLI:

aws rds create-db-instance \
    --db-instance-identifier mydb-multi-az \
    --db-instance-class db.r5.large \
    --engine mysql \
    --master-username admin \
    --master-user-password password \
    --multi-az \
    --allocated-storage 100

To create a Read Replica:

aws rds create-db-instance-read-replica \
    --db-instance-identifier mydb-replica \
    --source-db-instance-identifier mydb \
    --db-instance-class db.r5.large

To verify Multi-AZ status:

aws rds describe-db-instances --db-instance-identifier mydb-multi-az --query 'DBInstances[0].MultiAZ'

To check replication lag (MySQL):

SHOW SLAVE STATUS\G

Look at Seconds_Behind_Master.

A large e-commerce company runs its transactional database on RDS MySQL with Multi-AZ enabled. The database handles thousands of writes per second during peak hours. The Multi-AZ setup ensures that if the primary fails, the standby takes over with zero data loss, preventing lost orders. The RTO of ~90 seconds is acceptable for their business. They also use three Read Replicas to offload read traffic for product catalog queries. The replicas are in the same region but different AZs. They monitor ReplicaLag and have alerts if lag exceeds 5 seconds. During flash sales, they temporarily add more replicas (up to 15) to handle the read spike. A common misconfiguration is setting the Read Replica's instance class too small, causing replication lag to grow under heavy write load on the source. They learned to ensure the replica has at least as much compute and storage as the source.

A SaaS provider serves customers worldwide. They use RDS PostgreSQL with cross-region Read Replicas to provide low-latency reads in different AWS regions. The primary is in us-east-1, with replicas in eu-west-1 and ap-southeast-1. Applications in those regions connect to the local replica for read operations, reducing latency from 200ms to 10ms. They also use Multi-AZ for the primary in us-east-1 to ensure high availability. A challenge they faced was cross-region data transfer costs: each GB of replication data from us-east-1 to eu-west-1 costs $0.02. They optimized by filtering replication to only essential tables using PostgreSQL's publication/subscription feature. They also set up automated failover using AWS DMS for cross-region disaster recovery, since Read Replicas cannot be automatically promoted across regions.

A bank uses RDS Oracle with Multi-AZ to meet regulatory requirements for zero data loss. They also configure automated backups with a retention period of 35 days. Their compliance team requires that all database changes be auditable. They enable detailed monitoring and publish logs to CloudWatch Logs. They test failover quarterly by performing a manual failover using the AWS Console or CLI (aws rds failover-db-instance). During one test, they discovered that their application's connection pool was caching the old IP address, causing prolonged downtime. They fixed it by configuring the application to use the RDS endpoint with a short DNS TTL and by using RDS Proxy. This scenario underscores the exam's emphasis on using the CNAME endpoint and not hardcoding IPs.