Amazon Web Services services
4 / 24
Amazon Web Services

Managed Databases — RDS, Aurora & DynamoDB

Offload database operations: pick relational (RDS/Aurora) or serverless NoSQL (DynamoDB).

Three options, and the interview is about choosing between them.

RDS/Aurora is hiring a managed kitchen that still cooks classic recipes (SQL, joins) but where someone else handles the cleaning and a backup chef stands ready. DynamoDB is a vast automated vending network: instant retrieval by slot number (key), infinitely expandable, but you must know the slot in advance rather than browse.

Key Concepts

1
    RDS        managed PostgreSQL, MySQL, MariaDB, SQL Server, Oracle
    Aurora     AWS's MySQL/PostgreSQL-compatible engine, faster
    DynamoDB   serverless NoSQL, single-digit millisecond
2
RDS removes the operations, not the engine. AWS handles patching, backups and failover; it is still PostgreSQL, with its schema, joins and transactions.
3
Multi-AZ and read replicas solve different problems, and conflating them is a common mistake:
4
    Multi-AZ        a SYNCHRONOUS standby in another AZ.
                    For availability. You cannot read from it.
    read replica    ASYNCHRONOUS copy. For read scaling.
                    Lags, so it can serve stale data.
5
Aurora separates compute from storage. The storage layer replicates six ways across three AZs and is shared by up to 15 replicas, so failover is seconds rather than a minute, and adding a replica copies no data.
6
    Aurora Serverless v2   scales capacity in fine increments
    Aurora Global Database cross-region, roughly one second lag
7
DynamoDB is a different model, not a faster database. You design around access patterns and a partition key — there are no joins, and an unplanned query means a full table scan.
8
    on-demand      pay per request, no capacity planning
    provisioned    cheaper when steady, with auto-scaling
    Global Tables  multi-region, active-active
    Streams        change data capture into Lambda
    TTL            expire rows automatically
9
The choosing rule. Relational when queries are varied or unknown and consistency across tables matters. DynamoDB when the access patterns are few, known, and must stay fast at any scale.
10
Connection handling differs too. RDS has a connection limit that Lambda can exhaust — RDS Proxy exists for exactly that — while DynamoDB is an HTTP API with no pool to manage.
11
What the interviewer is probing.1. "Multi-AZ or read replica — which gives you high availability?" Probing: a distinction people conflate. Stalls: "Both." Moves up: Multi-AZ is a synchronous standby for availability and you cannot read from it; replicas are asynchronous for read scaling and can serve stale data.
12
2. "What does Aurora change architecturally?" Probing: the storage layer. Stalls: "It is faster MySQL." Moves up: compute is separated from a storage layer replicated six ways across three AZs and shared by the replicas, so failover is seconds and adding a replica copies no data.
13
3. "When would you choose DynamoDB over RDS?" Probing: whether the choice is reasoned. Stalls: "When you want NoSQL." Moves up: when the access patterns are few and known and must stay fast at any scale; RDS when queries are varied or unknown and you need joins.
14
4. "Lambda exhausts your RDS connections. What do you do?" Probing: the serverless and relational mismatch. Stalls: "Increase the limit." Moves up: RDS Proxy pools and reuses connections, which is what it exists for.
Use cases:rdsauroradynamodbnosql