Running Managed Databases with Amazon RDS - Multi-AZ and Read Replica Design
Ensure high availability with Multi-AZ and distribute read workloads with read replicas. This article introduces Blue/Green Deployments and RDS Proxy usage patterns.
Overview of RDS
RDS is a service that provides managed relational databases. Compared to installing a database on EC2, OS patching, DB patching, backups, and failover are all automated. It supports 6 engines: MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, and Db2, allowing existing code and tools to be migrated with minimal changes. Aurora is an AWS-proprietary engine compatible with RDS that delivers up to 5x the throughput of standard MySQL/PostgreSQL, with storage automatically replicated in 6 copies across 3 AZs for extremely high durability. RDS provides automated backups (point-in-time recovery) as standard, with configurable retention periods of 1-35 days. Manual snapshots can be retained indefinitely and are used for long-term storage or cross-region copies.
Multi-AZ and Read Replicas
Multi-AZ deployment places a primary instance and a standby instance in different Availability Zones, replicating data through synchronous replication. When the primary fails, automatic failover is triggered and the DNS endpoint switches to the standby. Failover typically completes in 1-2 minutes, though recovery may take longer if many transactions are uncommitted. Multi-AZ Cluster (available for MySQL and PostgreSQL) places 2 reader instances in different AZs, reducing failover time to under 35 seconds while also enabling reads from reader instances. Read replicas create read-only copies through asynchronous replication, reducing the primary's load by directing report and analytics queries to the read replicas. Up to 15 replicas can be deployed in the same region, and cross-region replicas are also available for disaster recovery or geographically distributed read access optimization. Performance Insights visualizes database load by wait event and SQL query, helping identify slow queries and lock contention.
Blue/Green Deployments and Proxy
RDS Blue/Green Deployments safely execute major version upgrades and parameter changes. A green environment (new version) is created, data is synchronized via replication, and then a switchover redirects traffic within one minute. If issues are detected after switchover, the old environment still exists for manual rollback. RDS Proxy provides database connection pooling and faster failover. For workloads with many short-lived connections like Lambda, it reduces database connection counts and automates connection switching during failover. Proxy reuses idle connections, mitigating the risk of reaching the max_connections limit on RDS instances. Applications simply connect to the Proxy endpoint with no code changes required, and integration with IAM authentication and Secrets Manager automates credential rotation. To learn managed databases from basics to advanced topics, books on Amazon offer a systematic approach.
RDS Cost Optimization
RDS pricing consists of instance hours, storage (gp3: approximately $0.08 per GB per month), backup storage, and data transfer. Reserved Instances offer discounts of up to 72%. Multi-AZ adds the cost of the standby instance, so choose based on your availability requirements. gp3 storage is 20% cheaper than gp2 and allows independent configuration of IOPS and throughput. Consider distributing read workloads to read replicas and downsizing the primary instance.
Comparison with Aurora - When to Choose Which
The choice between RDS standard engines (MySQL/PostgreSQL) and Aurora depends on cost structure and scaling requirements. Aurora's storage auto-scales (up to 128 TiB) without needing to pre-configure IOPS, making it suitable for workloads with unpredictable growth. RDS standard engines with gp3 storage, on the other hand, offer lower per-GB cost, and for small to medium databases where the baseline 3,000 IOPS is sufficient, they are more cost-effective. Failover times are under 30 seconds for Aurora, 1-2 minutes for RDS Multi-AZ, and under 35 seconds for RDS Multi-AZ Cluster. Aurora's reader endpoint automatically load-balances across multiple readers, whereas RDS read replicas require application-side or load-balancer-based routing. From a cost perspective, Aurora instance pricing is higher than RDS, so for smaller systems with relaxed availability requirements, RDS standard engine + Multi-AZ is often the optimal choice.
Design Pitfalls and Operational Considerations
Here are common issues encountered in RDS operations. First, parameter group change timing: dynamic parameters apply immediately, but static parameters require a DB instance reboot, causing downtime during the restart. In production, use Blue/Green Deployments to apply parameter changes safely. Second, even with storage autoscaling enabled, there is a cooldown period between expansions, and rapid data growth can exhaust free space. Set CloudWatch alarms on the FreeStorageSpace metric to receive notifications when remaining capacity drops below 20%. Third, increasing replica lag (ReplicaLag) compromises data consistency. Watch for lag increases during long-running DDL operations or backup windows, and design application-side fallback to the primary when replica lag exceeds a threshold. Fourth, set maintenance windows to the lowest-traffic time period, and design systems assuming that even Multi-AZ configurations will experience brief connection interruptions during failover.
Summary
RDS is a managed service that automates relational database operations. Multi-AZ ensures high availability, and read replicas distribute read workloads. Blue/Green Deployments safely execute major version upgrades, and RDS Proxy pools large numbers of connections from Lambda. Choosing between Aurora and standard engines depends on cost structure and scaling requirements, and understanding operational considerations around parameter groups, storage, and replica lag enables maintaining a stable database infrastructure.