Multi-AZ synchronous standby for high availability vs asynchronous read replicas for scaling reads, automated backups and point-in-time restore, and parameter groups for tuning without SSH access.
Published September 23, 2026
RDS is a managed relational database service — the concrete AWS answer to the database-scaling patterns from Database Scaling Specifics (read replicas, and the operational side of running a production database) without self-managing the underlying instance.
Primary (AZ-1) ──synchronous replication──▶ Standby (AZ-2)
— a write isn't confirmed until the standby has it too
— if the primary fails, RDS automatically fails over to the standby
(typically within 1-2 minutes), with the same connection endpoint
Multi-AZ deployment maintains a synchronous standby replica in a DIFFERENT availability zone specifically for HIGH AVAILABILITY, not read scaling — a write is only acknowledged once it's replicated to the standby, and if the primary AZ has an outage, RDS automatically fails over, with applications reconnecting to the SAME endpoint (RDS handles the DNS/networking switch). This is purely a durability/availability mechanism — the standby isn't used to serve read traffic at all, which is exactly what read replicas exist for instead.
Primary ──asynchronous replication──▶ Read Replica 1
└──▶ Read Replica 2
— replicas can lag the primary slightly (replication lag)
— application routes READ queries to replicas, WRITES always to primary
Read replicas are asynchronous (the primary doesn't wait for replicas before confirming a write, unlike Multi-AZ's synchronous standby) and exist specifically to SCALE READ THROUGHPUT — directly implementing the read-replica pattern from Database Scaling Specifics and Back-of-Envelope Estimation's read-heavy-workload reasoning. The asynchronous nature means replicas can briefly lag the primary (replication lag), so an application reading its own just-written data immediately afterward risks reading stale data from a replica — the same read-your-own-writes consistency concern that shows up whenever eventual consistency is chosen for a read path. A read replica can also be PROMOTED to a fully independent, standalone primary if needed (e.g. for disaster recovery, or to split off a heavily-loaded workload entirely).
RDS takes automated daily backups plus continuously captures transaction logs, enabling point-in-time restore — recovering the database to any specific moment within the configured retention window (not just to the most recent daily backup), which matters enormously for recovering from something like an accidental bulk-delete: restoring to the moment just BEFORE the mistake happened, rather than losing everything since the last nightly backup.
A managed RDS instance doesn't give direct SSH/OS-level access to tune the database engine's configuration file directly (unlike self-hosting on EC2) — parameter groups are RDS's mechanism for adjusting engine-level settings (connection limits, query timeout thresholds, logging verbosity) declaratively, through the AWS API/console, without needing host access at all. This is the managed-service tradeoff named in EC2 made concrete: less low-level control (no direct config file editing), in exchange for AWS handling patching, failover, and backup operational burden.
Q: Can a Multi-AZ deployment ALSO have read replicas? A: Yes, and this is a common production configuration — Multi-AZ provides the failover/HA guarantee for the PRIMARY, while separate read replicas (which can themselves optionally be Multi-AZ for their own HA) scale read throughput; the two mechanisms solve different problems and are frequently combined, not alternatives to choose between.
Q: Does Multi-AZ failover require any application-level changes to handle? A: Ideally no — RDS keeps the same connection ENDPOINT before and after failover, with the DNS simply repointing to the new primary; applications need reasonable CONNECTION RETRY logic (their connection pool should reconnect after a brief failover-induced interruption) but don't need to know a failover happened or manually redirect anywhere.
Q: How would you decide how many read replicas to provision? A: Based on actual observed read QPS relative to what a single instance can handle (Back-of-Envelope Estimation's methodology, applied here) — monitoring replica CPU/connection utilization (Metrics & Monitoring) over real traffic is the correct way to determine this, not a fixed guess made upfront without data.
Q: What's a scenario where point-in-time restore alone isn't sufficient? A: A retention-window limit — point-in-time restore only covers the configured backup retention period (commonly up to 35 days); recovering data from before that window, or meeting longer compliance-driven retention requirements, needs a separate long-term backup/archival strategy (potentially exporting snapshots to S3 with its own lifecycle policy, from the S3 lesson).