RDS Relational Databases

Amazon RDS Multi-AZ deployments provide built-in high availability by automatically provisioning and maintaining a synchronous standby replica in a different Availability Zone. When the primary database instance fails, RDS automatically performs a failover to the standby, typically within 60–120 seconds.

For example, an e-commerce platform running MySQL on RDS enables Multi-AZ to ensure checkout processes continue during AZ outages. The synchronous replication guarantees zero data loss because every transaction is committed to both the primary and standby simultaneously.

RDS supports Multi-AZ for all database engines including MySQL, PostgreSQL, MariaDB, Oracle, and SQL Server. The failover process is fully managed: RDS updates the DNS endpoint to point to the standby, and applications connecting via the DNS endpoint automatically reconnect without code changes.

When planning Multi-AZ, consider that the standby instance does not serve read traffic. For read scaling, you must configure separate read replicas. Multi-AZ also impacts maintenance windows—database patching and instance modifications are applied first to the standby, then a failover occurs, and the primary is updated. This rolling approach minimizes downtime.

A common mistake is assuming Multi-AZ provides load balancing. It does not. The standby exists purely for failover. For workloads requiring both high availability and read scaling, combine Multi-AZ with one or more read replicas.

Read replicas are standalone database instances that use asynchronous replication from a source RDS instance. They are designed to scale read-heavy workloads and offload reporting queries from the primary. You can create up to 15 read replicas per source instance.

Consider a social media application where the primary database handles writes (new posts, comments) while read replicas serve the read-heavy feed queries. By directing read traffic to replicas, the primary instance dedicates its I/O capacity to writes, improving overall throughput.

Read replicas can be created in the same Region, across Regions, or even from a Multi-AZ primary. Cross-Region replication is useful for disaster recovery and reducing latency for geographically distributed users. For instance, a company serving users in both the US and Europe can create a read replica in eu-west-1 from a primary in us-east-1, routing European read traffic to the local replica.

Promote a read replica to a standalone instance if the primary fails and cannot recover. However, promoted replicas lose their replication relationship, so you must reconfigure replication from the new primary if needed.

Monitoring replication lag is critical. Use CloudWatch metrics like ReplicaLag to track how far behind the replica is. If lag exceeds acceptable thresholds, consider upgrading the replica instance class or optimizing slow queries on the primary.

RDS uses three types of groups to configure database behavior. Understanding each is essential for database administration.

Parameter Groups control database engine configuration values. For example, you can set innodb_buffer_pool_size for MySQL or shared_buffers for PostgreSQL through a custom parameter group. RDS provides default parameter groups, but you should create custom groups for production workloads to tune performance. Changes to parameter groups require a database reboot depending on the parameter type—dynamic parameters apply immediately, while static parameters require a restart.

Option Groups enable or disable specific database engine features not available through parameter groups. For Oracle, you might enable Timezone or Tuning packs. For SQL Server, option groups manage features like SQL Server Audit or TDE. Option groups are engine-specific and version-dependent.

DB Subnet Groups define which subnets RDS can use when creating a DB instance. For Multi-AZ deployments, the subnet group must include subnets in at least two Availability Zones. A typical configuration places DB instances in private subnets with no direct internet access, using a NAT gateway or VPC endpoints for outbound connectivity.

A production MySQL instance might use a custom parameter group with max_connections=500, an option group enabling the audit plugin, and a subnet group spanning two private subnets across AZs for failover capability.

RDS Proxy is a fully managed database proxy that sits between your application and RDS instance, pooling and sharing connections. It reduces failover time by up to 66% for Multi-AZ deployments and eliminates the need for applications to manage connection pools.

For a serverless application using AWS Lambda, thousands of concurrent Lambda functions can exhaust database connections. RDS Proxy handles connection pooling so Lambda functions share a smaller pool of database connections. This prevents connection exhaustion and improves application resilience.

Upgrade Strategies are critical for maintaining RDS instances. RDS supports two upgrade paths:

1. Automatic Minor Version Upgrades: Enable automatic upgrades to receive security patches and bug fixes. RDS applies these during your maintenance window with minimal downtime.

2. Major Version Upgrades: Requires manual initiation. Always test upgrades in a staging environment first. Use a blue/green deployment strategy—create a read replica, upgrade the replica, test it, then promote it and redirect traffic. This approach provides a rollback path if the upgrade fails.

Before any upgrade, create a manual snapshot. While automated backups are retained, manual snapshots give you a known-good restore point. Review the release notes for breaking changes, deprecated features, and new default values that might affect application behavior.

For zero-downtime upgrades, consider using RDS Blue/Green Deployments, which create a shadow environment with the new engine version, synchronize data, and perform a switchback with minimal disruption.