3.1.3. Database Scaling: RDS, DynamoDB, and Aurora
š” First Principle: Databases are the hardest component to scale because they hold state. Unlike stateless web servers (add more, remove any), databases must maintain consistency while distributing load ā which requires careful design. AWS provides managed scaling solutions for each database type, each with different trade-offs.
RDS Read Replicas:
Read replicas add read capacity to RDS without modifying the primary instance. The primary handles all writes; replicas serve reads via asynchronous replication.
| RDS Read Replica Facts | Detail |
|---|---|
| Max replicas | 15 for Aurora; 5 for RDS MySQL/PostgreSQL/MariaDB |
| Replication lag | Asynchronous ā replicas may lag seconds to minutes behind primary |
| Promotion | A read replica can be promoted to a standalone DB (breaks replication) |
| Cross-region | Read replicas can be in different regions ā useful for global read distribution |
| Cost | Each replica is billed as a separate DB instance |
Read replicas are for read scaling, not for failover. Multi-AZ is for failover.
RDS Storage Auto Scaling: RDS can automatically increase storage when free space falls below a threshold. You set a maximum storage limit. This prevents the dreaded "storage full" incident at 3 AM.
DynamoDB Scaling:
DynamoDB offers two capacity modes:
| Mode | How It Works | Best For |
|---|---|---|
| On-Demand | Instantly handles any traffic level; pay per request | Unpredictable or new workloads |
| Provisioned | You specify read/write capacity units; use Auto Scaling to adjust | Predictable workloads; cost optimization |
DynamoDB Auto Scaling (for provisioned mode): Set a target utilization (e.g., 70% of provisioned capacity). DynamoDB Auto Scaling adjusts provisioned capacity up and down as traffic changes. Set minimum and maximum capacity to control cost boundaries.
DynamoDB Accelerator (DAX): An in-memory cache specifically for DynamoDB. Reduces read latency from single-digit milliseconds to microseconds. DAX is a cluster ā you connect your application to the DAX endpoint instead of directly to DynamoDB. Works transparently for GetItem, Query, and Scan operations.
Aurora Scaling:
Aurora Auto Scaling adds and removes Aurora Replicas (read replicas) based on average CPU utilization or connections. Aurora Serverless v2 goes further ā it scales the compute capacity of the instance itself in fine-grained increments (0.5 Aurora Capacity Units at a time), making it ideal for highly variable workloads.
| Aurora Feature | Benefit |
|---|---|
| Aurora Replicas | Up to 15 low-latency read replicas (same underlying storage) |
| Aurora Auto Scaling | Adds/removes replicas based on load |
| Aurora Serverless v2 | Scales instance compute up/down in seconds; pay per ACU-hour |
| Aurora Global Database | Low-latency read replicas across regions; disaster recovery in <1 minute |
ā ļø Exam Trap: DynamoDB On-Demand mode is not always cheaper. At high, predictable request rates, Provisioned with Auto Scaling is significantly more cost-effective. On-Demand charges a higher per-request price in exchange for not having to manage capacity. The exam may test which mode to recommend based on traffic characteristics.
Reflection Question: A marketing campaign is expected to cause a 10x traffic spike of unknown duration next Tuesday at noon. Your application uses RDS MySQL for user data and DynamoDB for session data. What scaling configuration would you set up before the campaign, and which database change is the highest priority?
