Amazon RDS Deployment Options: Single-AZ, Multi-AZ, and Read Replicas

Amazon RDS deployment options solve different problems. Single-AZ is simple and lower cost, Multi-AZ is designed for high availability and failover, and read replicas distribute read traffic. Larger workloads may combine high availability with read scaling, or use a Multi-AZ DB cluster that includes readable instances.

This is Part 32 of the AWS Cloud Practitioner Study Notes. Part 29 introduced RDS, Aurora, Multi-AZ, and read replicas, while Part 31 explained how backups solve a different problem from high availability.

The deployment comparison

Deployment	High availability	Read scaling	Automatic failover	Typical use
Single-AZ DB instance	No AZ redundancy	No	No	Development, testing, and cost-sensitive workloads
Multi-AZ DB instance deployment	Yes	No readable standby	Yes	Standard production high availability
Multi-AZ DB cluster	Yes	Yes, through reader instances	Yes	MySQL or PostgreSQL workloads needing HA and read capacity
RDS read replicas	Not by themselves	Yes	No automatic primary failover	Read-heavy workloads and some DR designs

The exam shortcut is simple: Multi-AZ is primarily for availability; read replicas are primarily for read scaling. The newer Multi-AZ DB cluster is the important exception because its two standby instances can serve read traffic.

1. Single-AZ deployment

A Single-AZ DB instance runs in one Availability Zone without a standby instance in another AZ.

Application
    │
    ▼
RDS DB instance
    │
    └── Availability Zone A

Advantages include lower cost, a simple topology, and less configuration. The trade-off is that an Availability Zone failure can make the database unavailable until the service or instance is restored.

Single-AZ is often appropriate for development, testing, prototypes, temporary environments, or workloads where the business accepts the availability risk. It is not a substitute for a production high-availability design.

Exam shortcut: “lowest cost,” “development,” or “test environment” → Single-AZ.

2. Standard Multi-AZ DB instance deployment

A standard Multi-AZ DB instance deployment has a primary DB instance and one standby DB instance in a different Availability Zone. RDS maintains the standby for failover support using synchronous replication.

Application
    │
    ▼
Primary DB instance (AZ-A)
    │
    │ synchronous replication
    ▼
Standby DB instance (AZ-B)

If the primary becomes unavailable, RDS promotes the standby and updates the DB endpoint so the application can reconnect. This provides high availability and automatic failover within the Region.

The standby is not a read replica for application traffic. In a standard Multi-AZ DB instance deployment, it does not serve normal read queries.

Use standard Multi-AZ when the requirement is:

• High availability
• Automatic failover
• Protection from an Availability Zone or instance failure
• A production database with one active writer and one failover standby

Multi-AZ does not protect against accidental deletes or corrupt application writes. Those changes can be replicated to the standby. Use automated backups and point-in-time recovery for logical data recovery, as explained in Part 31.

Exam shortcut: “improve database availability” or “automatic failover” → Multi-AZ.

3. RDS read replicas

An RDS read replica is a read-only copy of a source DB instance. RDS updates it using asynchronous replication, so the replica can lag behind the primary.

Primary DB instance
        │
        │ asynchronous replication
        ├── Read replica 1
        ├── Read replica 2
        └── Read replica 3

The application sends writes to the primary and suitable read-only queries to the replicas. This is useful when a news site, product catalogue, or reporting workload receives many more reads than writes.

Read replicas help with:

• High volumes of SELECT queries
• Read-heavy web applications
• Reporting queries that should not compete with writes
• Read access in another Availability Zone or Region
• Some disaster-recovery designs where a replica can be promoted manually

Read replicas do not automatically fail over as the primary’s standby. If the primary fails, a replica can be promoted to a standalone DB instance, but this is an operational recovery action rather than standard Multi-AZ automatic failover.

Read replicas also do not increase write capacity. If the bottleneck is inserts, updates, locks, transactions, or poor query design, adding more read replicas will not solve the underlying write problem.

Exam shortcut: “CPU is high because of many read queries” or “scale read traffic” → Read replica.

Multi-AZ versus read replica

Feature	Standard Multi-AZ DB instance	RDS read replica
Main purpose	High availability	Read scaling
Replication	Synchronous standby replication	Asynchronous replication
Serves application reads?	No	Yes
Automatic failover	Yes	No automatic primary failover
Data lag	Designed as a standby copy	Replica lag is possible
Write scaling	No	No
Typical exam phrase	“Availability” or “failover”	“Read performance” or “many readers”

If a standard RDS workload needs both capabilities, combine Multi-AZ for the primary database with one or more read replicas for read traffic.

4. Multi-AZ DB cluster

AWS also provides a newer Multi-AZ DB cluster deployment model. It has one writer DB instance and two reader DB instances in three separate Availability Zones in the same Region.

                   Writer endpoint
                         │
                  Writer DB (AZ-A)
                    /           \
       reader replication       reader replication
                  /               \
          Reader DB (AZ-B)   Reader DB (AZ-C)
                 \               /
                   Reader endpoint

The two reader instances can serve read traffic through the reader endpoint and can become failover targets. AWS describes this deployment as semisynchronous rather than identical to the traditional Multi-AZ DB instance model.

Multi-AZ DB clusters provide:

• A writer and two reader instances
• Three Availability Zones
• Automatic failover
• A reader endpoint for read-only connections
• Increased read capacity compared with a single writer

Multi-AZ DB clusters are not the same as Aurora DB clusters. The RDS Multi-AZ DB cluster option is supported for MySQL and PostgreSQL engines according to current AWS documentation. Check Region, engine version, and instance-class support before selecting it.

Multi-AZ DB cluster versus read replica

Feature	Multi-AZ DB cluster	RDS read replica
High availability	Yes	No, by itself
Automatic failover	Yes	No automatic primary failover
Readable secondary instances	Yes	Yes
Replication model	Semisynchronous cluster replication	Asynchronous replication
Data lag	Designed for low lag	Lag is possible
Failover target	Reader instance can be promoted automatically	Replica promotion is manual
Endpoint model	Writer and reader endpoints	Instance endpoints or application routing

The key conceptual difference is not simply “both have copies”. A Multi-AZ DB cluster’s reader instances are part of the high-availability cluster. A standard RDS read replica is an independently managed read-only copy updated asynchronously.

5. Combining Multi-AZ and read replicas

Many production architectures need both resilience and read capacity:

                         Application
                         /          \
                    Writes          Reads
                       │              │
                       ▼              ▼
                Primary DB       Read replicas
                       │
             synchronous standby
                       │
                       ▼
                 Standby DB

This design provides:

• Multi-AZ high availability for the primary
• Automatic failover to the standby
• Read scaling through asynchronous read replicas
• Separation of write and read workloads

Use it when the application has a conventional RDS DB instance architecture and needs both protection from infrastructure failure and more read capacity. A Multi-AZ DB cluster may be an alternative for supported MySQL or PostgreSQL workloads that want readable cluster instances as part of the deployment.

6. Aurora readers are a related concept

Amazon Aurora uses a cluster architecture with a writer and optional Aurora Replicas. Aurora Replicas can serve read traffic and can be promoted during failover, depending on the cluster configuration.

Do not mix every replica term together:

• RDS Multi-AZ standby: failover target; standard standby is not readable.
• RDS read replica: asynchronous read-only copy; no automatic primary failover by itself.
• Multi-AZ DB cluster reader: readable cluster instance and failover target.
• Aurora Replica: read-only instance in an Aurora cluster and potential failover target.

Choosing the right deployment

Need the lowest cost and can accept AZ risk?
└── Single-AZ

Need standard production high availability and automatic failover?
└── Multi-AZ DB instance deployment

Need more read capacity from an RDS DB instance?
└── Read replicas

Need high availability and read scaling for supported MySQL/PostgreSQL RDS clusters?
└── Multi-AZ DB cluster

Need both standard Multi-AZ failover and asynchronous read scaling?
└── Multi-AZ DB instance + read replicas

The final decision should also consider cost, engine support, Region availability, connection routing, replication lag, failover testing, and the application’s tolerance for stale reads.

Common exam questions

Scenario	Likely answer
Lowest-cost deployment for development	Single-AZ
Automatic failover after an AZ failure	Multi-AZ
Improve availability without using the standby for reads	Standard Multi-AZ DB instance
Scale read-heavy traffic	Read replicas
High availability plus read scaling in a supported RDS cluster	Multi-AZ DB cluster
Both standard HA and asynchronous read scaling	Multi-AZ plus read replicas
Scale write capacity	Read replicas do not solve this; review the writer, schema, queries, and architecture
Recover from accidental deletion	Automated backups and point-in-time recovery, not Multi-AZ alone

Memory map for CLF-C02

• Single-AZ → lower cost
• Multi-AZ DB instance → high availability and automatic failover
• Read replica → read scaling and asynchronous replication
• Multi-AZ DB cluster → high availability plus readable instances for supported engines
• Multi-AZ + read replicas → standard HA and separate asynchronous read scaling

The one-sentence rule is: Single-AZ saves money, Multi-AZ survives infrastructure failure, read replicas handle more readers, and a Multi-AZ DB cluster combines HA with readable instances when supported.

Conclusion

Choose the RDS deployment based on the failure or performance problem you are solving. Single-AZ is a cost-focused option. A standard Multi-AZ DB instance protects availability with a non-readable standby. A read replica scales reads asynchronously but does not provide automatic primary failover on its own.

The newer Multi-AZ DB cluster adds two readable instances across three Availability Zones, so it can provide both high availability and read capacity for supported MySQL and PostgreSQL workloads. For the Cloud Practitioner exam, learn the classic Multi-AZ versus read-replica distinction first, then recognise the newer cluster model when the question provides those details.

Sources

• Amazon RDS Multi-AZ deployments
• Amazon RDS Multi-AZ DB clusters
• Connecting to Multi-AZ DB cluster writer and reader endpoints
• Amazon RDS read replicas
• Creating a Multi-AZ DB cluster