AWS
Intermediate 15 min read AWS

AWS Managed Databases

RDS, Aurora, DynamoDB and the cache layer

RDS for relational, DynamoDB for key-value, Aurora for MySQL/Postgres at scale. Managed databases trade some control for patch-free ops, backups and HA wiring.

RDSAuroraDynamoDBElastiCachemanaged databasemulti-AZ
Prerequisites: AWS Service Map Managed Databases
Before we start

What you will learn

  • Choose between RDS, Aurora and DynamoDB for a workload
  • Understand managed HA (multi-AZ) and read replicas
  • Apply connection pooling and caching patterns
In 60 seconds

RDS is managed MySQL/Postgres (and others) with standby, backups and patching handled for you. Aurora is a distributed, MySQL/Postgres-compatible engine with better scaling. DynamoDB is a fully managed key-value/NoSQL service with single-digit-ms scaling. ElastiCache is managed Redis/Memcached for caching.

Introduction

What is this?

Amazon RDS provisions, patches, backs up and oversees relational engines (PostgreSQL, MySQL, MariaDB, Oracle, SQL Server). Multi-AZ deploys a standby in another AZ with automatic failover. Aurora is built for high throughput: replicas share a multi-node storage layer with fast failover. DynamoDB scales partitions automatically, keeps 3 copies across AZs and serves key-value access at single-digit milliseconds. ElastiCache (Redis) fronts databases and session stores. All live inside your VPC.

Motivation

Why do you need it?

  • Running your own Postgres/MySQL is still the biggest hidden ops cost — upgrades, backups, HA scripting.
  • DynamoDB removes capacity worry for spiky key-value workloads (at a price/throughput trade-off).
  • Aurora blurs the line: relational semantics with wide scaling and automated failover.
  • Managed HA wiring (multi-AZ, replicas) is the fastest path to an availability target.
Think about it

Mental model

Imagine

A bank vault with staff vs a secure locker room

Think of

RDS/Aurora vs DynamoDB

RDS/Aurora: complex relational queries, a trained staff manages the room. DynamoDB: you bring a key, a locker door opens instantly; fast but you do the modeling yourself.

Mechanics

How it works

  • RDS manages a DB instance: automated snapshots, point-in-time recovery, minor/major version upgrades, failover for multi-AZ.
  • Aurora separates storage: compute nodes read/write a shared, 6-copy storage layer across AZs — outages replace storage access, not data.
  • DynamoDB stores items by partition key (optionally sorted by sort key); partitions split automatically under load with on-demand or provisioned throughput.
  • Read replicas (RDS/Aurora) offload reads and can be promoted; DynamoDB offers global tables for cross-region replication.
  • ElastiCache sits ahead of the DB as a cache/rate limiter; invalidation is your contract to keep it correct.

Choosing a managed database.

Relational + strong SQL
Key/value, predictable keys
Hot reads / sessions
HA & scale
Real world

In production

  • An e-commerce store runs Postgres on RDS with multi-AZ, two read replicas for search, and ElastiCache for carts.
  • A gaming backend keeps player state in DynamoDB with global tables in two regions for active-active reads.
  • A fintech chooses Aurora because it needs Postgres semantics plus the 6x-copy storage insulation.
Guidelines

Best practices

  • Turn on automated backups with a defined retention and multi-AZ from day one.
  • Pool connections (PgBouncer/RDS Proxy) instead of letting apps each open dozens.
  • Offload reads to replicas/cache and keep writes on the primary.
  • Start with on-demand DynamoDB; move to provisioned only when throughput is predictable.
Watch out

Common mistakes

  • Choosing DynamoDB for ad-hoc analytic SQL — it has no joins; model-first or choose RDS/Aurora.
  • Ignoring connection count: 100 app pods × 30 connections exhausts the default pool.
  • Running analytics against the primary write instance.
  • Forgetting long-term snapshots cost money; retention your choice, not a default to forget.
Root cause analysis

Common issues

Error
Connection refused from app fleet
Root cause

Database reachable only from its SG peers, or pool exhausted

Fix

Verify SG ingress from app subnets; add RDS Proxy/PgBouncer and lower per-app max_connections.

Error
DynamoDB throttles during a spike
Root cause

Provisioned throughput underestimated, or hot partition key

Fix

Switch to on-demand or re-model with the hot keys spread; retry with exponential backoff.

Error
Failover takes minutes and app breaks
Root cause

App doesn't reconnect on new endpoint/standby

Fix

Use the RDS endpoint (DNS) and enable preserved connection failure handling; test failover in a game day.

When things break

Debugging tips

  • Slow queries: check the slow-query log and the query plan (EXPLAIN) before buying more IOPS.
  • Database 'hang': look at lock chains, not just CPU — a long transaction blocking others is common.
  • DynamoDB throttle: inspect consumed vs provisioned capacity; raise on-demand or fix hot keys.
  • Cache/db divergence: compare cache hit rate and trace the invalidation path.
Interviews

Interview checkpoint

Practice

Hands-on lab

Provision a DynamoDB Table Read-Only and Local
25 min · beginner
In progress
Objectives
  • Provision a DynamoDB table with a partition key
  • Run put/get operations via CLI
  • Run the exact same flow against DynamoDB Local for offline practice

Provision a DynamoDB Table Read-Only and Local

25 min · beginner

0/4 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

Which service is the natural fit for a key-value access pattern with predictable keys and high scale?

2

Read replicas automatically become writable under multi-AZ failover.

Go deeper

Official documentation

AWS — RDS user guide
docs
AWS — DynamoDB developer guide
docs
AWS — Aurora user guide
docs