RDS & DynamoDB: Managed Databases

Chapter 5's own VPC now has somewhere real to put a database. AWS offers two genuinely different real managed database services covering two genuinely different data models — RDS for relational data, DynamoDB for a schema-flexible key-value/document model — and this chapter covers both, plus how to actually choose between them.

RDS: A Real Managed Relational Database

Amazon RDS launched 26 October 2009, supporting MySQL first. Real support for additional engines followed over the next several years: Oracle Database (June 2011), Microsoft SQL Server (May 2012), PostgreSQL (November 2013), and MariaDB (October 2015) — plus Amazon's own real, purpose-built engine, Aurora (MySQL-compatible, announced November 2014; PostgreSQL-compatible, October 2017). RDS handles real, routine operational work automatically — provisioning, OS/engine patching, and backups — that you'd otherwise manage yourself on a self-hosted database.

Multi-AZ Deployments

Announced May 2010, a real Multi-AZ deployment automatically provisions and maintains a standby replica of your database in a separate, physically distinct Availability Zone. If the primary fails (or during planned maintenance), RDS automatically fails over to that up-to-date standby — real database operations resume with no administrative intervention needed. A genuinely useful side benefit: RDS performs backups against the standby instance specifically, so the primary's own I/O is never interrupted to take one.

Read Replicas

Distinct from Multi-AZ's own failover purpose, RDS supports up to five real read replicas (for MySQL, MariaDB, and PostgreSQL) — asynchronous copies used specifically for scaling read traffic, not for failover. A real, useful engine-specific detail: MySQL and MariaDB replicas became independently writable starting October 2012, while PostgreSQL replicas remain read-only.

Automated Backups

RDS creates real automated backups with a maximum real retention period of 35 days — an initial full snapshot, then incremental snapshots afterward, letting you restore to any point within that retention window.

DynamoDB: A Real Departure From Relational

DynamoDB launched in January 2012, but its own real origin traces back further — to Amazon's own internal 2004 holiday season, when several of Amazon.com's own technologies genuinely failed under real Christmas-shopping traffic. That real crisis drove Amazon's own internal push toward a database purpose-built for fast, massively scalable primary-key lookups — a need traditional relational databases, tuned for complex joins and flexible queries, weren't well suited to at that scale. DynamoDB is the real, published result of that lineage.

Partition Keys & Sort Keys

A DynamoDB table's real primary key is either a single partition key (which physically determines where an item is stored, and must be unique across the table on its own), or a composite partition key + sort key — allowing many items to share one partition key, as long as each has its own unique sort key value within that partition. A specific partition-key/sort-key combination is guaranteed to identify at most one real item.

The Real Consistency Model

DynamoDB offers a genuine, explicit choice on every read:

• Strongly consistent read — routed to the leader node; always reflects the most recent successful write.
• Eventually consistent read (the real default) — routed to a random replica node instead, trading a real, small chance of staleness for lower cost and higher throughput. AWS's own documented figure: roughly a 1-in-3 real chance of reading slightly stale data within the write's own propagation window — though in the vast majority of real cases, that window closes within milliseconds.

RDS vs. DynamoDB: When to Use Which

Hands-On Exercises