Amazon RDS and Aurora
Amazon Relational Database Service (RDS) and Amazon Aurora — managed relational databases on AWS. Covers deployment options, Multi-AZ HA, Read Replicas, Aurora architecture, and cross-cloud equivalents.
Overview
Amazon RDS and Aurora are AWS's managed Relational Database Management System (RDBMS) services — RDS for standard SQL engines (MySQL, PostgreSQL, Oracle, SQL Server), and Aurora for cloud-native, high-performance MySQL/PostgreSQL workloads.
AWS offers three levels of managed relational database control:
| Option | Control Level | Best For |
|---|---|---|
| EC2 + Self-Hosted RDB | Full (OS → DB → storage) | Custom configurations, unsupported engines, legacy systems |
| Amazon RDS | DB layer only (AWS manages OS, patching, backups) | Standard RDBMS workloads with AWS ecosystem integration |
| Amazon Aurora | Cloud-native, fully managed | High-performance, cloud-first architectures |
Amazon RDS — Relational Database Service
AWS-managed relational database supporting: MySQL, PostgreSQL, MariaDB, Oracle, Microsoft SQL Server, and Db2.
Key Features
- Automated backups — daily snapshots + transaction logs; point-in-time restore up to 35 days
- Multi-AZ deployment — synchronous standby for High Availability (HA)
- Read Replicas — asynchronous replicas for read scaling (up to 15 replicas)
- Automated patching — OS and DB engine patching managed by AWS
- Storage auto-scaling — automatically increases storage when approaching capacity
Limitations
- No OS-level (root) access
- Limited to supported engine versions
- Higher cost than self-hosted EC2
Multi-AZ Deployment (High Availability)
SAA/SAP Tip — Must Know: Multi-AZ is for HA and automatic failover, NOT for read scaling. Both primary and standby instances receive identical writes (synchronous replication), but the standby is not readable.
How It Works
- AWS provisions a standby replica in a different Availability Zone (AZ) in the same region
- All writes to the primary are synchronously replicated to the standby via Write-Ahead Log (WAL) streaming
- If the primary fails (hardware failure, AZ outage, patching), AWS automatically updates the DNS endpoint to point to the standby — no manual intervention required
- Failover typically completes in 60–120 seconds
Primary AZ-A ──(sync replication)──▶ Standby AZ-B
│ │
└─── DNS: db.cluster.rds.amazonaws.com ─┘
(endpoint transparently fails over)Multi-AZ vs. Read Replicas
| Feature | Multi-AZ | Read Replica |
|---|---|---|
| Purpose | HA / automatic failover | Read scaling |
| Replication | Synchronous | Asynchronous |
| Standby readable? | No | Yes |
| Failover? | Automatic | Manual promotion required |
| Cross-region? | No (same region, different AZ) | Yes (cross-region supported) |
| Extra charge? | Yes (double instance cost) | Yes (separate instance cost) |
Exam Trap: Enabling Multi-AZ does NOT improve read throughput. If a scenario asks for read performance improvement, the answer is Read Replicas, not Multi-AZ.
Implementing Multi-AZ
Multi-AZ is a single setting in the RDS console or via the AWS CLI/IaC:
# Enable Multi-AZ on an existing RDS instance
aws rds modify-db-instance \
--db-instance-identifier my-database \
--multi-az \
--apply-immediatelyRead Replicas
- Up to 15 Read Replicas per primary instance
- Asynchronous replication — slight replication lag possible
- Replicas are readable — distribute SELECT queries to offload the primary
- Can be promoted to a standalone primary (used for DR or migration)
- Supported cross-region — useful for global read-heavy applications
SAA/SAP Tip: For a read-heavy application with reporting queries hurting OLTP performance, the answer is usually Read Replicas + route read traffic to the replica endpoint.
Amazon Aurora
Cloud-native relational database built by AWS, compatible with MySQL and PostgreSQL engines.
Architecture
Aurora decouples compute from storage:
- Storage layer: Automatically distributed across 3 AZs, with 2 copies per AZ = 6 copies total
- Durability: Can tolerate losing 2 copies without affecting write availability; 3 copies for read availability
- Storage auto-scaling: Grows automatically in 10 GiB increments, up to 128 TiB — no manual provisioning
Key Features vs. Standard RDS
| Feature | RDS (MySQL/PostgreSQL) | Aurora |
|---|---|---|
| Read Replicas | Up to 5 | Up to 15 |
| Failover time | 60–120 seconds | < 30 seconds |
| Storage | Single-AZ block storage | 6 copies across 3 AZs |
| Throughput | Standard | Up to 5× MySQL, 3× PostgreSQL |
| Global Database | No | Yes — cross-region replication < 1 second |
| Serverless option | No | Yes — Aurora Serverless v2 |
Aurora Serverless v2
Auto-scales compute capacity (measured in Aurora Capacity Units — ACUs) up and down based on load — no manual instance sizing required. Suitable for variable or unpredictable workloads.
Aurora Global Database
Replicates data across up to 5 secondary AWS regions with typical replication lag of < 1 second (sub-second Recovery Point Objective — RPO), enabling global read access and fast cross-region Disaster Recovery (DR).
SAA/SAP Tip: For a global application needing cross-region DR with the lowest possible RPO, Aurora Global Database is the answer. RTO for a region failure is typically < 1 minute.
Exam Trap: Aurora is not available in all AWS regions. For edge or resource-constrained regions, standard RDS may be the only option.
Choosing Between RDS and Aurora
| Scenario | Choice |
|---|---|
| Need specific engine version (e.g., Oracle, SQL Server) | RDS |
| Need maximum performance for MySQL or PostgreSQL | Aurora |
| Cost is the primary constraint | RDS (Aurora is ~20% more expensive) |
| Need cross-region replication with sub-second RPO | Aurora Global Database |
| Variable workload, want auto-scaling compute | Aurora Serverless v2 |
| Need full OS-level control | EC2 + self-hosted |
Cross-Cloud Equivalents
| Provider | Service / Solution | Notes |
|---|---|---|
| AWS | Amazon RDS / Amazon Aurora | Baseline |
| Azure | Azure Database for MySQL / PostgreSQL / SQL Database | Similar managed tiers; Azure SQL offers serverless compute tier |
| GCP | Cloud SQL / AlloyDB | AlloyDB is GCP's Aurora equivalent for PostgreSQL; Cloud SQL for standard managed RDBMS |
| On-Premises | MySQL, PostgreSQL, Oracle, SQL Server | Self-managed on bare metal or VMs; manual HA setup required (e.g., Patroni for PostgreSQL) |
Pricing Model
- Billed per DB-instance-hour (instance class determines hourly rate)
- Separate charge for storage (GB-month) and IOPS (for io1 storage)
- Multi-AZ doubles instance cost (two instances running)
- Read Replicas billed as separate instances
- Aurora pricing includes storage I/O charges
Related Services / See Also
- Database Performance Fundamentals — OLTP, IOPS, WAL concepts
- Disaster Recovery Strategies — RTO/RPO and DR patterns
- Amazon DynamoDB — managed NoSQL for non-relational workloads
- Amazon ElastiCache — in-memory cache layer to reduce RDS read pressure
Amazon DynamoDB and DocumentDB
AWS managed NoSQL database services — Amazon DynamoDB (key-value / document) and Amazon DocumentDB (MongoDB-compatible). Covers data models, use cases, scaling, and cross-cloud equivalents.
Amazon Timestream
Amazon Timestream — AWS's purpose-built serverless time-series database. Covers time-series data model, storage tiers, query engine, and cross-cloud equivalents.