Amazon RDS Multi-AZ vs Read Replicas & Blue/Green Deployments

Recap: What Aurora Changed About the Availability Conversation

Foundations You'll Need Today

1. Why This Is on the Exam

Almost every SAP-C02 scenario that involves a relational database eventually forces a choice between three things that sound similar and behave nothing alike. The exam is not testing whether you can recite the definition of Multi-AZ; it is testing whether you can read a requirement like "the database must survive an AZ failure with no data loss" or "reporting queries are saturating the primary" or "we need to move from MySQL 5.7 to 8.0 without a long outage" and map it to exactly one of these three features without over-building. That mapping problem is the reason this day exists, and it sits squarely in Domain 2 (Design Resilient Architectures) with a secondary pull into Domain 4 (Design Cost-Optimized Architectures), because the wrong answer is usually the more expensive one.

The trap is linguistic. Multi-AZ gives you a standby that is a full copy of your data, and read replicas give you copies of your data too, so candidates assume they are variations on the same theme. They are not. A Multi-AZ standby is invisible to your application, cannot serve reads, and exists solely so that a failure can be absorbed without a human being paged. A read replica is visible, addressable, serves reads, and exists to take load off the primary. A Blue/Green Deployment is not a runtime topology at all — it is a change-management mechanism that happens to create a second environment. Three different problems, three different tools, and the exam will hand you a scenario where the requirement sentence contains the deciding keyword if you know what to look for.

There is also a cost dimension that the exam likes to probe. Multi-AZ roughly doubles the instance cost of a database because you are paying for a second instance you never query. Read replicas also cost money but they earn their keep by absorbing read traffic, so the justification is different. Blue/Green Deployments are transient — you pay for the green environment only during the upgrade window — which makes them cheap relative to the risk they retire. A scenario that says "minimize cost while meeting a 15-minute RTO" is often testing whether you understand that Multi-AZ is not a disaster recovery strategy at all, since it protects against an AZ failure inside one region and does nothing for a regional outage.

2. How Each Mechanism Actually Works

Multi-AZ is synchronous block-level replication to a standby in a different Availability Zone. When your application commits a transaction, the primary writes to its storage and the write is acknowledged only after it has been durably recorded on the standby's storage as well. That synchronous acknowledgement is the entire point: it means the standby is never behind, so a failover cannot lose committed transactions. The standby runs the same engine version on the same instance class, sits in a different AZ, and is not reachable by your application — there is no endpoint for it, no connection string, no way to send it a query. When the primary fails a health check, RDS flips the DNS record behind your database's single endpoint to point at the standby, which is promoted to primary. Your application reconnects to the same hostname and, after a brief connection interruption, is talking to a different physical instance.

Read replicas work on a completely different principle. They are independent database instances that receive changes asynchronously from the primary, using the source engine's native replication mechanism — binlog-based for MySQL and MariaDB, write-ahead log streaming for PostgreSQL, and engine-specific log shipping for SQL Server and Oracle. Because the replication is asynchronous, a read replica is always some amount of time behind the primary, and that lag is a first-class operational metric rather than an implementation detail. Each replica has its own endpoint, so your application can route read-only queries to it explicitly. A replica can be promoted to a standalone primary, which is how you do a controlled cutover or recover from a primary that is unrecoverable — but promotion is a one-way door, and any transactions the replica had not yet received at the moment of promotion are simply gone.

Blue/Green Deployments are a different category of thing entirely. When you create one, RDS provisions a complete green environment — a primary and, if the source is Multi-AZ, a standby — running the target engine version, and sets up logical replication from the blue (current production) environment to the green one. The green environment is a real, queryable database that you can point a staging application at, run your migration scripts against, and load-test. Because replication is logical rather than physical, the two environments can run different engine versions, which is what makes major-version upgrades possible. When you are satisfied, you trigger a switchover: RDS briefly blocks writes on blue, waits for green to catch up, renames the environments so that green takes over the production endpoint, and then blue becomes the old environment you can delete. The switchover is measured in seconds to a couple of minutes, not hours.

3. The Core Decision Boundary

Every scenario question on this topic reduces to one question: what is the requirement actually asking for? If the requirement is about surviving failure without losing data, the answer is Multi-AZ. If it is about handling more read traffic than a single instance can serve, the answer is read replicas. If it is about changing the database — engine version, schema, parameters — with a rollback path, the answer is Blue/Green. The exam rarely states the requirement in those words, so the skill being tested is translation: "the application must remain available if an Availability Zone fails" is Multi-AZ, "the analytics team's queries are degrading checkout latency" is read replicas, and "we must upgrade the engine with less than five minutes of downtime and be able to revert" is Blue/Green.

The boundary gets interesting when a scenario asks for more than one of these at once, which is common in the harder questions. A production database that must survive an AZ failure, serve a reporting workload, and be upgradeable is a Multi-AZ primary with one or more read replicas hanging off it, and the Blue/Green Deployment is created from that Multi-AZ primary so the green environment inherits the same topology. These compose cleanly because they operate at different layers — Multi-AZ is a storage-level property of the primary, read replicas are separate instances consuming its replication stream, and Blue/Green is a temporary logical-replication overlay. What does not compose is trying to use one to do another's job, and that is where the distractors live.

4. Configuration Modes and Their Tradeoffs

Multi-AZ has a small number of knobs and each one has a clear cost. The instance class of the standby mirrors the primary, so enabling Multi-AZ roughly doubles your compute bill for that database — there is no option to run a smaller standby. You choose the standby's Availability Zone or let RDS pick one, and the choice matters only for capacity planning and for avoiding a correlated failure with the primary's AZ. For engines that support it, there is a Multi-AZ cluster deployment option that adds two readable standbys behind a reader endpoint, which is the one configuration where Multi-AZ and read scaling overlap; it is worth knowing it exists because a scenario that asks for both high availability and read offload on a single managed cluster is pointing at it. Failover priority is configurable in the cluster form, letting you control which standby takes over first.

Read replicas are where the configuration space opens up, and the tradeoffs are mostly about lag and cost. You can create replicas in the same AZ, a different AZ, or a different region; cross-region replicas are the standard answer for regional read latency and for a coarse disaster recovery posture, at the cost of higher replication lag because the data crosses region boundaries. Replicas can be chained — a replica of a replica — which reduces load on the primary but compounds lag down the chain. You can promote a replica to a standalone instance, which breaks the replication link permanently and is the mechanism behind both planned cutovers and emergency recovery. The critical tradeoff to internalize is that asynchronous replication means a replica is a lagging copy, and any scenario that requires the replica to be exactly current is a scenario that is actually asking for Multi-AZ.

Blue/Green Deployments trade a temporary doubling of infrastructure for a dramatically reduced change window. The green environment runs the target engine version and, by default, the same instance class as blue, so you pay for a second full database for the duration of the upgrade — typically hours to a few days, not months. You control the switchover timing explicitly, which means you can schedule it for a low-traffic window and you can abandon the whole exercise by deleting green if validation fails. The main constraint is that logical replication does not cover every object type identically across engines, so you must validate that your schema, users, and stored procedures replicated correctly before switching. There is also a switchover timeout: if green cannot catch up within the configured window, the switchover aborts and blue continues serving, which is a safety property rather than a failure.

5. Sizing, Limits and Quotas

The numbers that matter here are mostly about how far each mechanism scales and what it costs you in latency. Multi-AZ failover is documented as typically completing in one to two minutes, driven by DNS propagation and instance promotion rather than by data volume, since the standby is already current. That is the number to quote when a scenario asks how long an AZ failure costs you. Read replica lag is not a fixed number — it depends on write volume, network path, and replica capacity — but the operational rule is that a replica running the same instance class as the primary under a comparable read load will generally keep up, while an undersized replica will fall progressively further behind. Cross-region replicas add the inter-region network round trip to every replication batch, so their lag is structurally higher than same-region replicas.

Blue/Green switchover is documented as typically under a minute of write downtime, which is the figure that makes it the answer to "minimize downtime during a major version upgrade" scenarios. The green environment must be able to keep up with the blue write rate during the replication phase, so an undersized green instance is a common cause of a switchover that never converges. There are also engine-version constraints: Blue/Green Deployments support specific source and target version pairs, and not every engine supports them at all, so a scenario involving an engine that lacks the feature has to fall back to snapshot-restore or replica-promotion strategies. Read replicas have a per-primary limit that varies by engine, and Multi-AZ cluster deployments have their own instance-count ceilings.

6. Failure Modes and What They Look Like in Production

The most common production failure with read replicas is lag that nobody is watching until it becomes a correctness bug. The symptom is subtle: a user writes a record, the application immediately reads it back from a replica, and the record is not there. This is not a database bug; it is the application being written as though replication were synchronous. The first diagnostic move is to check the replica lag metric — ReplicaLag in CloudWatch for MySQL and MariaDB, and the equivalent for other engines — and correlate it with write volume. If lag spikes during batch jobs or bulk imports, the fix is usually to route those reads to the primary or to size the replica up. If lag grows monotonically and never recovers, the replica has fallen too far behind and may need to be recreated from a snapshot.

Multi-AZ failures are rarer but more disruptive when they happen, because the failover is automatic and the application experiences it as a connection drop. The symptom is a burst of connection errors lasting roughly the failover window, followed by recovery with no operator action. The diagnostic move is to check the RDS event log for the failover event and confirm the new AZ, then verify that the application's connection pool actually reconnected rather than holding dead connections. A surprising number of "the database is down" incidents after a Multi-AZ failover are actually connection-pool misconfiguration: the database recovered in ninety seconds but the application kept handing out stale connections for twenty minutes. Setting a short connection lifetime and enabling pool validation is the standard mitigation.

Blue/Green failures cluster around the switchover. If logical replication cannot keep up, the switchover times out and aborts, leaving blue in place — which is safe but means your maintenance window was wasted. If replication silently skipped objects that logical replication does not support, you discover it after switchover when the application hits a missing stored procedure or a user that did not carry over. The diagnostic move before switching is to compare object counts and definitions between blue and green, and to run the application's own test suite against green. After a switchover, the old blue environment still exists and can be used to investigate what differed, which is a genuine advantage over an in-place upgrade where the previous state is gone.

7. The Operational and SRE Angle

From an SRE perspective these three features map onto three different reliability concerns, and each needs its own monitoring. Multi-AZ is about availability, so the metric that matters is whether failover actually works — and the only way to know is to test it, which is what the RDS reboot-with-failover operation is for. A database that has been running Multi-AZ for two years without a tested failover is an untested assumption, not a guarantee. The alarm shape is straightforward: alert on the RDS event category for failover events so that an automatic failover is visible to the team even though it required no action, because an unexplained failover is a signal that something upstream is wrong.

Read replicas are about capacity and correctness, so the alarms are lag-based and the SLO implication is about read freshness. A reasonable pattern is to alarm when replica lag exceeds a threshold that your application can tolerate — if the application can accept five seconds of staleness, alarm at ten — and to treat sustained lag as a capacity signal rather than a transient. The runbook for a lagging replica is short: identify whether the cause is write volume, replica size, or a long-running query on the replica blocking replication, then either scale the replica, move the offending reads, or kill the blocking query. The subtle SRE point is that read replicas introduce a consistency boundary into your architecture, and that boundary should be documented as an explicit SLO rather than discovered by a user.

Blue/Green Deployments are a change-management control, so they belong in the deployment pipeline rather than in the on-call rotation. The operational discipline is to treat the switchover as a deployable event with a rollback plan, to validate green with production-shaped traffic before switching, and to keep blue around long enough to investigate if something goes wrong. The metric worth tracking is switchover duration over time, because a switchover that used to take thirty seconds and now takes four minutes is telling you that green is struggling to keep up with blue's write rate — a leading indicator that the next upgrade will be harder.

8. Edge Cases and Exam Gotchas

The single most-tested gotcha is that Multi-AZ does not scale reads. Candidates see a standby that holds a full copy of the data and assume it can serve queries; it cannot, and any scenario that pairs "high availability" with "offload reporting" is testing whether you know that. The exception is the Multi-AZ cluster deployment, which does expose a reader endpoint — but that is a distinct configuration, not the default, and the exam will usually signal it explicitly if it is in play. The second most-tested gotcha is that Multi-AZ is not disaster recovery. It protects against an AZ failure within one region; a regional outage takes both the primary and the standby with it, and the answer for that is a cross-region read replica, a cross-region snapshot copy, or an Aurora Global Database if the engine allows it.

On the replica side, the gotcha is promotion. Promoting a read replica is irreversible in the sense that the replica becomes an independent primary and stops following the original; there is no "demote back" operation. It is also lossy, because the replica was behind at the moment of promotion. A scenario that says "we need to fail over to the replica with no data loss" is internally contradictory for standard RDS and the correct answer is usually to point out that Multi-AZ is the mechanism that provides that property. Cross-region replicas add a second gotcha: they cannot be promoted into a Multi-AZ configuration in one step, and the promotion process for a cross-region replica is a multi-step operation rather than a single API call.

For Blue/Green, the gotchas are about scope and support. Not every engine supports Blue/Green Deployments, and among those that do, not every version pair is supported, so a scenario that specifies an unusual engine or version may be steering you toward a different strategy. Logical replication does not carry every object type, so a database with heavy use of engine-specific features may need manual remediation before switchover. And the switchover is not instantaneous — it involves a brief write block — so a scenario demanding literally zero downtime is not satisfiable by Blue/Green either; the honest answer is "under a minute," and the exam expects you to know the difference between near-zero and zero.

9. This vs. the Services It Gets Confused With

The confusion set here is small but the exam exploits it relentlessly. Multi-AZ gets confused with read replicas because both create a second copy of the data. Read replicas get confused with Multi-AZ for the same reason, in the opposite direction. Blue/Green Deployments get confused with both because they also create a second environment, and with snapshot-restore because both are upgrade strategies. The distinguishing question is always what the second copy is for: absorbing failure, absorbing read load, or absorbing change risk. Once you can answer that in one word, the scenario resolves.

There is also a cross-service confusion worth naming. Aurora has its own versions of all three ideas — Aurora Replicas, Aurora Global Database, and Aurora Blue/Green Deployments — and they behave differently from their standard-RDS counterparts in ways that matter. Aurora Replicas share the same storage volume as the writer, so they have far lower lag than a binlog-based read replica and can be promoted in seconds. Aurora Global Database replicates at the storage layer, as Day 22 covered, which is why its cross-region lag is measured in milliseconds rather than seconds. If a scenario names Aurora, the standard-RDS intuitions about lag and promotion time are the wrong ones to apply.

Hands-On Lab: Validate a Major-Version Upgrade with Blue/Green

Scenario Question Drills (20 min)

Peek into Tomorrow: When the Database Itself Is the Bottleneck

Sources