Skip to content

RDS and Aurora

From AWS Re/Start (August 2025) and apprenticeship coursework.

Ultra-Short Summary

RDS is AWS's managed relational database service — AWS handles patching, backups, and failover. Aurora is AWS's own relational engine that's MySQL/PostgreSQL-compatible but designed from the ground up for cloud: distributed storage, faster replication, and better scaling. For most new relational workloads, Aurora is the better choice.

RDS — Relational Database Service

AWS manages the infrastructure; you manage the data and access.

Supported engines: MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Db2

What AWS handles: - Hardware provisioning - OS and database engine patching - Automated backups and point-in-time recovery - Failover (with Multi-AZ)

What you still manage: - Schema design and queries - IAM access and security groups - Parameter groups (DB config) - Storage scaling (can enable auto-scaling)

Multi-AZ vs Read Replicas

These solve different problems — a common exam trap:

Feature Multi-AZ Read Replicas
Purpose High availability / failover Read scaling
Replication Synchronous (standby always up-to-date) Asynchronous (slight lag)
Standby readable? No — standby is passive Yes — routes read traffic
Failover Automatic, ~1-2 min DNS switch Manual promotion
Cross-region? Same region only Yes — cross-region replicas possible
Count 1 standby Up to 5 (15 for Aurora) 
Multi-AZ:
  Primary DB (AZ-a) --sync--> Standby DB (AZ-b)
  If primary fails: DNS switches to standby automatically
  Standby is NOT used for reads -- it is purely a hot spare

Read Replica:
  Primary DB --async--> Replica 1
                    --> Replica 2
  App reads go to replicas, writes go to primary
  Replica can be promoted to primary if needed (manual step)

Key rule: Multi-AZ = HA. Read Replica = performance.

RDS Backups

Automated backups:
  Daily full snapshot + transaction logs
  Retention: 1-35 days (default 7)
  Point-in-time recovery to any second in the retention window
  Stored in S3

Manual snapshots:
  Triggered by you
  Persist after the RDS instance is deleted (automated backups don't)
  Use for: migrations, long-term retention, creating read replicas in other regions

RDS Encryption

  • At rest: KMS encryption — enable at creation time, cannot add later to existing instance
  • In transit: SSL/TLS — enforce with require_secure_transport parameter
  • Encrypted snapshots can be copied to other regions (key re-encrypted with destination region's key)
  • Read replicas of encrypted instances are also encrypted

To encrypt an existing unencrypted RDS instance:

1. Take a snapshot of the unencrypted instance
2. Copy the snapshot with encryption enabled (specifying a KMS key)
3. Restore a new RDS instance from the encrypted snapshot
4. Switch your application to the new instance

Aurora

AWS's own relational engine — MySQL and PostgreSQL compatible, but re-architected for cloud.

Architecture

Aurora separates compute and storage:

  Writer Instance (primary)
        |
        +-> Shared Distributed Storage
        |   (6 copies across 3 AZs)
        |   Automatically repairs lost copies
        |
  Reader Instances (up to 15)

  Writer Endpoint --> always points to current primary
  Reader Endpoint --> load-balanced across all readers

Why this matters: - If writer fails, a reader is promoted in ~30 seconds (vs ~1-2 min for RDS Multi-AZ) - Storage auto-scales from 10GB to 128TB -- no manual storage management - Write durability confirmed after 4/6 copies acknowledge -- faster than traditional replication

Aurora vs RDS

Feature RDS MySQL Aurora MySQL
Speed Baseline Up to 5x faster reads
Storage Fixed provisioned Auto-scales 10GB-128TB
Read replicas Up to 5 Up to 15
Failover ~1-2 minutes ~30 seconds
Multi-AZ storage Separate standby instance Built-in (6 copies by default)
Cost Lower Higher (~20% more)

Aurora Serverless v2

Scales capacity automatically based on demand -- no fixed instance type:

Traffic spike:  Aurora scales up ACUs (Aurora Capacity Units) in seconds
Traffic drops:  Scales back down (can scale to near-zero)

Use case: variable workloads, dev/test, unpredictable traffic

Aurora Global Database

Spans multiple AWS regions for global reads and disaster recovery:

Primary region (writes + reads)
      |
      +-> Secondary region 1 (reads only, < 1 second lag)
      +-> Secondary region 2 (reads only)

Disaster recovery: promote secondary to primary in < 1 minute

Choosing RDS vs Aurora

Use RDS when:
  -> You need a specific engine Aurora doesn't support (Oracle, SQL Server, Db2)
  -> Cost is a priority and workload is small/steady
  -> Migrating an existing on-prem MySQL/Postgres (direct lift-and-shift)

Use Aurora when:
  -> High availability is critical (30-second failover vs 1-2 min)
  -> You need more than 5 read replicas
  -> Storage will grow unpredictably
  -> Building new MySQL or PostgreSQL compatible workloads
  -> Serverless/variable traffic (Aurora Serverless v2)

Mental Model

RDS = managed database server in a box
  AWS handles the box (OS, patching, backups)
  You handle what's inside (schema, data, queries)

Aurora = database as a cloud-native service
  Compute and storage are separate and elastic
  Storage always has 6 copies across 3 AZs
  Think less like a "server" and more like a distributed system

Multi-AZ   = spare tyre in the boot -- swaps in automatically
Read Replica = extra cashiers -- share the read workload

SAA Patterns

Scenario Answer
Highest availability for relational DB Aurora (faster failover, distributed storage)
MySQL-compatible, up to 15 read replicas Aurora
Need Oracle or SQL Server managed RDS (Aurora doesn't support these engines)
Reduce read load on primary Read Replicas
Auto-failover if primary AZ fails RDS Multi-AZ or Aurora (built-in)
Serverless, scales to near-zero Aurora Serverless v2
Encrypt existing unencrypted RDS Snapshot -> copy with encryption -> restore
Global low-latency reads + DR Aurora Global Database

Self-Quiz

  1. What's the difference between RDS Multi-AZ and a Read Replica?
  2. Can you read from the Multi-AZ standby? Why or why not?
  3. Aurora stores 6 copies of data -- where are they spread?
  4. How does Aurora Serverless v2 differ from a standard Aurora cluster?
  5. Why can't you add encryption to an existing unencrypted RDS instance directly?
  6. You need Oracle DB managed by AWS -- Aurora or RDS? Why?
  7. What's the Writer Endpoint and Reader Endpoint in Aurora?
  8. What does point-in-time recovery require in terms of backup settings?