RDS: relational databases without the administration
RDS (Relational Database Service) runs managed instances of MySQL, PostgreSQL, MariaDB, Oracle, and SQL Server. AWS handles OS patching, backups, hardware provisioning, and failover. You get the database engine you already know without the operational overhead of running it yourself.
Multi-AZ deployment is RDS's high availability feature. AWS maintains a synchronous standby replica in a different Availability Zone. If the primary instance fails, RDS automatically promotes the standby and updates the DNS endpoint, typically within 60-120 seconds. The standby is not accessible for reads. It exists purely for failover. Multi-AZ protects you from AZ failures, not from database-level problems like a corrupt table.
Read replicas solve a different problem: read traffic. When your application reads far more than it writes, you can create up to 15 read replicas and direct read queries to them. Unlike Multi-AZ, read replicas use asynchronous replication, which means they can lag slightly behind the primary. Read replicas can span regions, which makes them useful for both performance and disaster recovery.
Aurora, DynamoDB, and ElastiCache
Aurora is AWS's proprietary relational database engine, compatible with MySQL and PostgreSQL. The architecture is fundamentally different from standard RDS. Aurora separates compute from storage: a distributed storage layer automatically replicates data across three Availability Zones with six copies at all times. Aurora typically delivers two to three times the throughput of equivalent MySQL on RDS and costs roughly 20% more than standard RDS. Aurora Serverless adds on-demand scaling that adjusts compute capacity automatically, useful for workloads with unpredictable traffic like dev environments or infrequently accessed applications.
DynamoDB is AWS's fully managed NoSQL key-value and document database. There is no schema to define and no instance to size. DynamoDB scales to handle any amount of traffic because AWS manages the partitioning behind the scenes. The tradeoff is that queries must use the partition key, with an optional sort key. Complex relational queries across arbitrary fields require careful data modeling in advance. DynamoDB is ideal when you need single-digit millisecond latency at any scale: gaming leaderboards, session stores, shopping carts.
ElastiCache sits in front of your database as an in-memory caching layer. It supports Redis and Memcached. Redis adds persistence, replication, and data structures beyond simple key-value pairs. The use case is reducing database load by caching the results of expensive or frequently repeated queries. A user profile page that queries the database on every page load becomes a read from the cache after the first request, dropping the response time from tens of milliseconds to under a millisecond.
How to choose the correct answer
Multi-AZ: automatic failover to a standby, synchronous replication, standby is not readable. Choose for high availability, not read performance.
Read replica: asynchronous replication, readable endpoints, can be cross-region. Choose to scale read-heavy workloads or for geographic proximity.
Aurora: higher throughput than RDS, storage auto-scales, 6 copies across 3 AZs. Choose when RDS performance is a bottleneck or when you need Aurora Serverless auto-scaling.
DynamoDB: NoSQL, schema-less, unlimited scale, single-digit millisecond latency. Choose for key-value or document access patterns at high scale.
ElastiCache: in-memory cache. Redis for advanced data structures and persistence. Memcached for simple caching with multi-threading. Choose to reduce read load on any database.
RDS Proxy: connection pooling for RDS and Aurora, useful when Lambda functions create too many database connections.