Multi-AZ and Automated Backups

Multi-AZ is an RDS high-availability feature that automatically provisions a synchronous standby replica in a different Availability Zone within the same Region. AWS manages the replication transparently—you connect using a single DNS endpoint and RDS routes traffic to the primary.

If the primary instance fails due to hardware, network, or OS issues, RDS performs an automatic failover to the standby in approximately 60–120 seconds. Your application reconnects using the same DNS endpoint, which now resolves to the standby's IP address.

You can enable Multi-AZ when creating an RDS instance or by modifying an existing one. When enabling on a running instance, AWS takes a snapshot of the primary, restores it in a second AZ, then synchronises using the engine's native replication. This process can cause brief I/O suspension on the primary, so schedule it during a low-traffic window or accept the maintenance window timing.

Multi-AZ is supported for all RDS engines including MySQL, PostgreSQL, MariaDB, Oracle, and SQL Server, and it does not require any application-level changes.

When a failover occurs, RDS updates the DNS CNAME of the DB endpoint to point to the standby within about 60 seconds. Your application must reconnect after detecting a TCP connection drop. To minimise reconnection delays:

• Use a short DNS TTL (typically already set to 5 seconds by RDS)
• Implement exponential backoff with retry in your connection logic
• Use connection pooling tools like RDS Proxy that automatically reconnect

Failover is also triggered manually for maintenance or instance class changes, enabling near-zero downtime upgrades when Multi-AZ is enabled.

A common exam confusion is between Multi-AZ (for availability) and Read Replicas (for scalability). Key differences:

• Multi-AZ standby: synchronous replication, no read traffic served, automatic failover, same Region
• Read Replica: asynchronous replication, serves read traffic, no automatic failover, can be cross-Region

Multi-AZ does not improve read performance—the standby is inaccessible for queries. To both improve availability AND scale reads, use Multi-AZ on the primary and add Read Replicas separately.

RDS automatically creates daily full database snapshots and captures transaction logs every 5 minutes. Together these enable point-in-time recovery (PITR) to any second within the backup retention period. You can restore the database to its state at any point in that window.

Automated backups are enabled by default and can be retained from 1 to 35 days. Setting retention to 0 disables automated backups (and PITR). The backup window is a 30-minute period you specify or let AWS choose during off-peak hours.

The backup window is when daily snapshots are taken. During this window, storage I/O may briefly pause on Single-AZ deployments. Multi-AZ deployments take the snapshot from the standby, eliminating primary I/O impact.

The maintenance window is a separate weekly period when AWS applies OS patches, engine minor upgrades, and instance modifications. Best practice is to set both windows to low-traffic periods and ensure they do not overlap.

To restore to a specific point in time, RDS first restores the most recent daily snapshot and then replays transaction logs up to the requested timestamp. The result is a new DB instance—PITR never overwrites the source instance, giving you a safe recovery path that does not interrupt production.

After the restored instance is available, you update your application's connection string to point to the new endpoint, verify data integrity, then delete the original if the recovery was intentional. Typical restore time is proportional to the database size and log volume since the last snapshot.

In addition to automated backups, you can take manual snapshots at any time. Unlike automated backups, manual snapshots are not subject to the retention period—they persist until you explicitly delete them.

Manual snapshots are ideal for capturing the state before a major schema migration, an application upgrade, or at the end of a billing cycle for compliance archiving. You can also share manual snapshots with other AWS accounts or copy them across Regions for disaster recovery.

You can copy automated or manual snapshots to another AWS Region for disaster recovery. The copy is a full snapshot stored in the destination Region's S3 infrastructure. Once copied, you can restore a new RDS instance in that Region if your primary Region becomes unavailable.

Snapshot copies can be encrypted at the destination even if the source is unencrypted (and vice versa). Cross-region copies incur data transfer costs. Use AWS Backup or an EventBridge-triggered Lambda to automate periodic cross-region snapshot copies.

Amazon RDS Proxy sits between your application and RDS and pools database connections. This is especially useful for Lambda functions that may open thousands of short-lived connections and exhaust the database connection limit. RDS Proxy multiplexes connections so the database sees far fewer active connections.

During a Multi-AZ failover, RDS Proxy holds application connections and re-establishes the database connection to the new primary, reducing application reconnection time to seconds rather than minutes. RDS Proxy also integrates with Secrets Manager to rotate credentials without application downtime.

RDS now offers two Multi-AZ options: Multi-AZ DB Instance (classic, one standby) and Multi-AZ DB Cluster (two readable standby instances in different AZs). The cluster mode uses semi-synchronous replication and allows read traffic on standbys, offering higher availability and read scalability without separate Read Replicas.

For the SAA-C03 exam, the classic Multi-AZ DB Instance is most commonly tested. Remember: Multi-AZ Cluster is the newer option where standbys can serve reads, while the classic standby cannot.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: Multi-AZ provides synchronous standby replication with automatic failover in 60–120 seconds, automated backups enable PITR to any second within the retention window (1–35 days), and manual snapshots persist indefinitely and can be copied cross-Region for DR. Next up we explore Read Replicas for distributing read traffic and improving read throughput.