RDS, Aurora & DynamoDB

Relational vs NoSQL, replicas, caching.

Intermediate30 min · lesson 9 of 15

AWS offers a database for every workload, and matching the data model to the right managed service is a core architecture skill. The big distinction is relational (RDS/Aurora) versus NoSQL (DynamoDB), with caching and analytics services alongside.

Relational: RDS and Aurora

Amazon RDS is a managed relational database (MySQL, PostgreSQL, SQL Server, Oracle, MariaDB) where AWS handles patching, backups, and replication so you run a database, not a server. Two features do the architecture heavy lifting: Multi-AZ deployment provides high availability via a synchronous standby in another AZ with automatic failover, and read replicas scale read-heavy workloads by offloading queries to asynchronous copies. Amazon Aurora is AWS’s MySQL/PostgreSQL-compatible engine with a distributed storage layer replicated across three AZs, delivering higher performance and faster failover than standard RDS. Reach for relational when you need joins, transactions, and a fixed schema.

relational vs NoSQL, and the HA/scale levers
# RELATIONAL (RDS / Aurora) NOSQL (DynamoDB)
# joins, transactions, fixed schema key-value/document, massive scale
# Multi-AZ → HA (standby + failover) managed, serverless, single-digit ms
# read replicas → scale READS auto-scales throughput, no servers
# vertical scaling for writes partition-key design drives performance
#
# cache hot reads → ElastiCache (Redis/Memcached) or DynamoDB DAX
# analytics/warehouse → Amazon Redshift

NoSQL, caching, and analytics

Amazon DynamoDB is a fully-managed, serverless NoSQL key-value and document database delivering single-digit-millisecond latency at any scale, with no servers to manage and automatic scaling — ideal for high-throughput applications, session stores, and workloads that outgrow a single relational instance. Get the partition-key design right and it scales seamlessly. To reduce read load and latency, Amazon ElastiCache (Redis or Memcached) puts a managed in-memory cache in front of a database, and DynamoDB has DAX for the same. For analytics over large datasets, Amazon Redshift is the managed data warehouse. The architect’s job is choosing the purpose-built service for the workload rather than forcing everything into one database.

Choosing a data service
1joins + transactions?
RDS / Aurora (relational)
2massive key-value scale?
DynamoDB (NoSQL, serverless)
3hot reads / latency?
ElastiCache / DAX (cache)
4analytics on big data?
Redshift (warehouse)
Pick the purpose-built database for the access pattern. Multi-AZ for HA, read replicas/caching for read scale.
Multi-AZ is for availability, read replicas are for scale
These are often confused: an RDS Multi-AZ standby is a synchronous failover target you do not read from, providing high availability; read replicas are asynchronous copies you send read queries to for scaling. Use Multi-AZ to survive an AZ failure and read replicas to offload read load — they solve different problems and are often used together.