Amazon RDS Fundamentals
Managed relational databases — Multi-AZ for availability, read replicas for scale, and RDS Proxy for connection management, without running the database server yourself.
Want a visual for this topic?
Generate a diagram tailored to Amazon RDS Fundamentals — the AI picks whichever visual (architecture, flowchart, ER diagram, etc.) best fits this specific AWS concept.
Sign in to generate a visual →🎓 Learning objectives
- •Explain what RDS manages for you versus running a database on EC2 yourself
- •Explain the difference between Multi-AZ and Read Replicas
- •Explain what RDS Proxy solves and when you'd need it
- •Choose an appropriate RDS engine and deployment configuration for a given workload
What is it?
Amazon RDS (Relational Database Service) is a managed service for running relational databases — MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, and AWS's own Aurora (a MySQL/PostgreSQL-compatible engine built for the cloud) — where AWS handles provisioning, patching, backups, and failover, while you interact with it as a normal database using standard drivers and SQL.
Why it exists
Running a production database on a self-managed EC2 instance means you're responsible for OS patching, database engine patching, configuring and testing backups, setting up replication for high availability, and manually handling failover during an outage — all specialized, error-prone operational work that has nothing to do with your actual application logic. RDS exists to take that operational burden off your team while still giving you a real, standard relational database underneath.
Problem it solves
It solves the operational-burden problem (no OS/engine patching, automated backups, one-click Multi-AZ), the availability problem (Multi-AZ gives automatic failover to a standby with no application changes needed), the read-scaling problem (Read Replicas offload read traffic from the primary), and the connection-management problem (RDS Proxy pools and manages connections for serverless/high-concurrency applications).
Intuition
Running your own database on EC2 is like owning a car and being responsible for every oil change, tire rotation, and repair yourself. RDS is like a car with a full-service maintenance plan — you still drive it exactly like normal, but a professional handles the maintenance schedule, and if something needs urgent attention, they handle that too, often before you'd even notice.
Analogy
A serviced apartment versus owning a house: in a serviced apartment (RDS), you live your life normally, but plumbing, electrical, and structural maintenance are handled by the building management on a schedule and during emergencies; in your own house (self-managed database on EC2), you're the one who has to notice the leak, find a plumber, and coordinate the fix yourself.
Technical explanation
Multi-AZ deployments maintain a synchronous, byte-for-byte standby replica in a different AZ; if the primary fails a health check, RDS automatically fails over to the standby, typically within 60-120 seconds, and updates the DNS endpoint's target — no application configuration change is needed, only a brief connection interruption during the failover itself. Read Replicas use the database engine's native asynchronous replication (introducing eventual consistency, a small replication lag) to maintain one or more read-only copies that can serve SELECT queries, reducing load on the primary; unlike a Multi-AZ standby, a Read Replica can also be promoted to a standalone writable instance if needed. RDS Proxy sits between your application and the database, pooling and multiplexing many application-side connections into a smaller number of actual database connections, which is critical for serverless (Lambda) or highly concurrent applications where opening a fresh database connection per invocation would otherwise exhaust the database's connection limit.
Architecture
A production web application typically runs its primary RDS instance in Multi-AZ mode for automatic failover, with one or more Read Replicas serving read-heavy reporting or analytics queries so they don't compete with transactional writes on the primary. A serverless API built on Lambda connecting to that same RDS instance places RDS Proxy in front of it, since Lambda's concurrent, short-lived invocations would otherwise open and close database connections far faster than the database can handle efficiently.
Workflow
- Choose a database engine matching your application's existing compatibility needs (or Aurora if starting fresh and wanting cloud-native performance/scaling characteristics). 2) Enable Multi-AZ for any production workload where downtime has real cost. 3) Add Read Replicas once read traffic genuinely becomes a bottleneck on the primary, not preemptively. 4) Add RDS Proxy if your application connects via Lambda or otherwise opens many short-lived connections. 5) Configure automated backups and a retention period matching your recovery point objective.
Example
An e-commerce platform runs its order database on RDS PostgreSQL with Multi-AZ enabled, so a single AZ failure triggers automatic failover with only a brief connection blip rather than an outage. Their internal analytics dashboard queries a Read Replica instead of the primary, so heavy reporting queries never slow down the checkout flow. Their newly-added serverless order-confirmation Lambda function connects through RDS Proxy, since without it, traffic spikes would open far more direct database connections than the instance's connection limit allows.
Real-world usage
RDS underlies a huge share of AWS-hosted transactional applications, cited across AWS's own case studies as the default relational database choice for teams that don't want to operate database infrastructure themselves; RDS Proxy is specifically recommended by AWS whenever Lambda functions connect directly to RDS, since Lambda's elastic, spiky concurrency model is a well-documented mismatch for traditional database connection limits without pooling.
Trade-offs
Multi-AZ trades roughly double the compute cost for automatic, fast failover — worthwhile for nearly any production workload where downtime has real business cost, but unnecessary overhead for genuinely non-critical dev/test databases. Read Replicas trade eventual consistency (replication lag) for horizontal read scaling — appropriate for read-heavy analytics/reporting workloads that can tolerate slightly stale data, not appropriate for anything requiring strict read-after-write consistency without careful routing logic.
Visual explanation
Picture a primary RDS instance in one Availability Zone, with a synchronously-replicated standby instance in a second AZ (Multi-AZ) — invisible to the application, which connects to one stable endpoint regardless of which physical instance is currently primary. Separately, one or more Read Replicas (asynchronously replicated, in the same or different Regions) each have their own separate endpoint that the application explicitly directs read-only queries to, offloading that traffic from the primary.
Advantages
- —
Automated backups, patching, and Multi-AZ failover remove significant operational burden compared to self-managed databases
- —
Read Replicas let you scale read capacity horizontally without re-architecting the application beyond directing specific queries to a different endpoint
- —
RDS Proxy solves the connection-exhaustion problem for serverless/highly concurrent applications without application-level connection pooling code
- —
Point-in-time recovery lets you restore to any second within your backup retention window, not just to a specific daily snapshot
Disadvantages
- —
Less low-level control than a self-managed database — you can't SSH into the underlying host or install arbitrary OS-level extensions
- —
Multi-AZ roughly doubles compute cost since a full standby instance runs continuously, even though it's not directly serving traffic
- —
Read Replica lag (eventual consistency) means a read immediately after a write might not reflect that write yet if directed to a replica
- —
Vertical scaling (resizing the instance) or engine version upgrades typically require a brief downtime window unless carefully orchestrated with blue/green deployment features
Common mistakes
- —
Confusing Multi-AZ (high availability failover, synchronous, invisible to the app) with Read Replicas (read scaling, asynchronous, requires explicit application routing) — they solve different problems and one doesn't substitute for the other
- —
Directing a read-immediately-after-write query to a Read Replica and being surprised the just-written data isn't there yet, due to replication lag
- —
Connecting Lambda functions directly to RDS without RDS Proxy, exhausting the database's connection limit during traffic spikes
- —
Not enabling Multi-AZ for a production database 'to save cost,' then experiencing extended downtime during an AZ-level failure that automatic failover would have handled in about a minute
- —
Forgetting that a Read Replica CAN be promoted to a standalone primary (useful for scaling or migration) but a Multi-AZ standby is not directly accessible or promotable the same way during normal operation
In the AWS Console
- 1
AWS Console → RDS → Create database
Choose an engine (e.g. PostgreSQL, or Aurora for cloud-native scaling), instance size, and under 'Availability & durability' toggle Multi-AZ deployment.
Multi-AZ roughly doubles the instance cost — factor this into sizing decisions, but it's the standard recommendation for any production workload.
- 2
RDS → Databases → select your instance → Actions → Create read replica
Choose the Region (same or different) and instance size for the replica; RDS handles setting up the ongoing asynchronous replication automatically.
Your application must be explicitly updated to direct read-only queries to the replica's distinct endpoint — RDS doesn't do this routing for you automatically.
- 3
AWS Console → RDS → Proxies → Create proxy
Select the target RDS database, configure the IAM role for Secrets Manager-based credential access (RDS Proxy requires storing DB credentials in Secrets Manager, not typed directly).
Update your application's (or Lambda's) connection string to point at the proxy's endpoint instead of the database's direct endpoint after setup.
- 4
RDS → Databases → select instance → Maintenance & backups → Automated backups
Set the backup retention period (1-35 days) matching your recovery point objective, and review the backup window timing.
Longer retention windows increase backup storage cost but extend how far back point-in-time recovery can reach.
🎤 Interview questions
What's the difference between RDS Multi-AZ and a Read Replica? (Listen for: Multi-AZ is synchronous, for automatic failover/high availability, invisible to the app; Read Replica is asynchronous, for read scaling, requires explicit application routing to a separate endpoint.)
Why would a Lambda function connecting to RDS need RDS Proxy? (Listen for: Lambda's concurrent, short-lived invocations can open far more direct DB connections than the instance's connection limit supports; RDS Proxy pools and multiplexes connections to prevent exhaustion.)
What happens during an RDS Multi-AZ failover from the application's perspective? (Listen for: brief connection interruption (typically under 2 minutes), then reconnection succeeds automatically since the endpoint DNS now points at the promoted standby — no application code change needed.)
Why might a read served from a Read Replica show stale data? (Listen for: asynchronous replication introduces lag; a write to the primary may not have propagated to the replica yet at the moment of the read.)
How would you decide whether a workload needs Multi-AZ, Read Replicas, both, or neither? (Listen for: Multi-AZ for any production workload where downtime has real cost; Read Replicas only once read traffic is a measured bottleneck on the primary — not a default, add based on actual need.)