What Is Amazon RDS?
Amazon Relational Database Service (RDS) provisions and operates relational database engines — MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, and Amazon's own Aurora — without you having to install software, patch an operating system, or manage storage volumes by hand. You choose an instance class (compute and memory), an allocated storage size, and an engine version, and AWS handles the underlying EC2 host, automated backups, minor-version patching windows, and monitoring integration with CloudWatch. This differs sharply from running MySQL yourself on an EC2 instance, where you are responsible for every layer from the kernel up to replication scripts.
Cricket analogy: Choosing RDS over self-managed MySQL is like a franchise hiring a full support staff — physio, analyst, groundskeeper — instead of asking Virat Kohli to also mow the pitch between overs; AWS handles the groundwork so the engine just plays.
Multi-AZ Deployments and High Availability
A Multi-AZ RDS deployment maintains a synchronous standby replica in a different Availability Zone from the primary instance. Every write to the primary is replicated synchronously to the standby before the commit is acknowledged, so the standby is always current. If the primary fails, hardware degrades, or you perform maintenance, RDS automatically fails over to the standby, typically within 60 to 120 seconds, and the DNS endpoint your application uses is repointed automatically — you don't need to change connection strings. Multi-AZ is purely for availability and durability; the standby is not used to serve read traffic in the classic single-standby RDS model (Aurora's Multi-AZ works differently, with readable replicas).
Cricket analogy: Multi-AZ is like a team carrying an identical twin of the strike bowler warming up in the other net — if Jasprit Bumrah pulls a hamstring mid-over, the twin steps onto the field ready-formed, without the match being abandoned.
Read Replicas and Horizontal Read Scaling
Read replicas use the database engine's native asynchronous replication to copy data from a source instance to one or more replica instances, which can live in the same region or, for MySQL, PostgreSQL, MariaDB, and Aurora, in a different region entirely. Because replication is asynchronous, replicas can lag behind the source by a small, variable amount — this is eventual consistency, not the synchronous guarantee of a Multi-AZ standby. Applications route read-heavy traffic, such as reporting queries or product catalog lookups, to replicas to reduce load on the primary, which remains the only target for writes. A read replica can also be promoted to a standalone, writable instance, which is useful for disaster recovery drills or regional migrations.
Cricket analogy: Read replicas are like regional radio commentators re-broadcasting the same match feed from Mumbai to Kolkata with a slight delay — fans everywhere get the action, but the delay means they hear Rohit Sharma's boundary a second after it actually happened.
# Create a read replica of an existing PostgreSQL RDS instance
aws rds create-db-instance-read-replica \
--db-instance-identifier orders-db-replica-1 \
--source-db-instance-identifier orders-db-primary \
--db-instance-class db.r6g.large \
--availability-zone us-east-1b
# Promote the replica to a standalone writable instance
aws rds promote-read-replica \
--db-instance-identifier orders-db-replica-1Backups, Snapshots, and Point-in-Time Recovery
RDS automated backups take a daily full snapshot during a configurable backup window and continuously capture transaction logs, letting you restore to any second within the retention period (1–35 days) using point-in-time recovery. Manual snapshots you take yourself persist indefinitely, even after the source instance is deleted, and can be shared or copied across accounts and regions — the mechanism most teams use for long-term archival or compliance retention beyond the automated window.
Multi-AZ improves availability and durability, but it is not a performance or scaling feature — the standby sits idle for reads in the standard RDS Multi-AZ model. If your bottleneck is read throughput rather than uptime, add read replicas instead of assuming Multi-AZ will help; conflating the two is a common cost-wasting mistake.
- RDS is a managed relational database service covering MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, and Aurora.
- Multi-AZ deployments maintain a synchronous standby in another AZ for automatic failover and high availability.
- Read replicas use asynchronous replication and are for scaling read traffic, not for high availability.
- A read replica can be promoted to a standalone, writable database instance.
- Automated backups support point-in-time recovery within a 1–35 day retention window.
- Manual snapshots persist after instance deletion and can be copied or shared across accounts and regions.
- Multi-AZ and read replicas solve different problems — availability versus read scalability — and are often used together.
Practice what you learned
1. What happens to application connection strings during an RDS Multi-AZ failover?
2. Which statement best distinguishes RDS read replicas from a Multi-AZ standby?
3. How long can automated RDS backups be retained to support point-in-time recovery?
4. What happens to a manual RDS snapshot if you delete the source database instance?
5. Which action converts a read replica into an independent, writable database?
Was this page helpful?
You May Also Like
DynamoDB Basics
Amazon DynamoDB is a fully managed, serverless NoSQL key-value and document database designed for single-digit-millisecond performance at any scale.
AWS KMS Basics
AWS Key Management Service (KMS) creates and controls the cryptographic keys used to encrypt data across AWS services, without exposing the underlying key material.
IAM Policies Explained
IAM policies are JSON documents that define permissions, and understanding their structure and evaluation logic is essential to securing an AWS account.