RDS & Aurora Performance Architecture — Overview
Database performance is the #1 DBS-C01 topic (218 questions) and appears heavily on SAA-C03 and SAP-C02. The exam tests Read Replicas, Provisioned IOPS, Performance Insights, RDS Proxy, Aurora Serverless, and Aurora Global Database patterns.
Reader endpoint (LB)
Cross-region replicas
ElastiCache for hot data
Connection multiplexing
Lambda integration
Faster failover
io2 (up to 256K IOPS)
Aurora auto-grows (128TB)
Optimized Reads (local NVMe)
Enhanced Monitoring (OS)
CloudWatch metrics
Slow query log
Aurora vs RDS — Performance Differences
| Feature | RDS (MySQL/PostgreSQL) | Aurora |
|---|---|---|
| Read Replicas | Up to 5, async replication (seconds lag) | Up to 15, shared storage (milliseconds lag) |
| Storage | EBS-based (gp3, io2), manual sizing | Auto-growing (10GB to 128TB), 6 copies across 3 AZs |
| Failover | 60-120 seconds | ~30 seconds (with RDS Proxy: seconds) |
| Throughput | Standard MySQL/PostgreSQL performance | Up to 5x MySQL, 3x PostgreSQL (AWS claims) |
| Global | Cross-region read replicas (manual promotion) | Global Database (<1s replication, managed failover) |
Read Replica Patterns
- Reader endpoint (Aurora): Load-balances across all replicas automatically. Application uses reader endpoint for reads.
- Custom endpoints: Route specific queries to specific replicas (e.g., analytics queries to larger replicas)
- Cross-region replicas: For global reads and DR. Aurora Global: <1s replication. RDS: async (minutes possible)
- Replica priority tiers: Control which replica promotes on failover (tier 0 = highest priority)
- Read/write splitting: Application sends writes to writer endpoint, reads to reader endpoint. Frameworks: ProxySQL, Spring read-replica routing.
RDS Proxy — Connection Pooling
- Problem: Lambda/serverless creates hundreds of connections. Each connection consumes DB memory. Connection storms on scale-out.
- Solution: RDS Proxy maintains persistent connection pool to DB. Lambda connects to Proxy (fast), Proxy multiplexes to DB (few connections).
- Failover: RDS Proxy detects failover and redirects connections to new primary without application reconnection (~66% faster failover).
- IAM Auth: Proxy supports IAM authentication (no password in code). Manages secrets from Secrets Manager.
- Pinning: Some session state pins connections (prepared statements, temp tables). Minimize pinning for best multiplexing.
Storage Performance
| Type | IOPS | Throughput | Use Case |
|---|---|---|---|
| gp3 | 3,000 baseline (up to 16,000) | 125 MiB/s (up to 1,000) | Most workloads (default, balanced cost/performance) |
| io2 Block Express | Up to 256,000 | Up to 4,000 MiB/s | Extreme IOPS: OLTP, SAP HANA, high-frequency trading |
| Aurora Storage | Managed (auto-optimizes) | Managed | No provisioning — Aurora manages storage performance |
Aurora Serverless v2
- Auto-scales: ACUs (Aurora Capacity Units) scale up/down in seconds based on load
- Range: Min 0.5 ACU to max 256 ACU. Set min/max bounds.
- Mixed clusters: Combine provisioned writer + Serverless v2 readers (scale reads on demand)
- Use case: Variable workloads, dev/test, infrequent access databases that need instant scaling
- vs Provisioned: Serverless costs more per ACU-hour but saves when utilization is low/variable
Aurora Global Database
- Replication: Storage-level replication, <1 second lag (not logical replication)
- Regions: 1 primary + up to 5 secondary regions (16 read replicas per region)
- Failover: Managed cross-region failover (RTO <1 minute). Secondary promotes to primary.
- Use case: Global low-latency reads + DR across regions
- Write forwarding: Secondary region can forward writes to primary (application doesn’t need to know which is primary)
Performance Insights & Monitoring
- Performance Insights: Visual dashboard showing DB load by wait events, SQL statements, hosts, users. Identifies bottleneck queries.
- Enhanced Monitoring: OS-level metrics (CPU per process, memory, swap, I/O) at 1-second granularity. More detail than CloudWatch.
- Slow query log: Log queries exceeding a time threshold. Analyze for optimization.
- CloudWatch: Standard metrics (CPU, connections, IOPS, replica lag). Set alarms.
Exam Tips
| Exam | Key Points |
|---|---|
| DBS-C01 | “Reduce read load” → Read Replicas + reader endpoint. “Lambda connection issues” → RDS Proxy. “High IOPS” → io2 or Aurora. “Global low-latency reads” → Aurora Global Database. “Variable workload DB” → Aurora Serverless v2. “Identify slow queries” → Performance Insights. “Faster failover” → RDS Proxy (66% faster). “Scale reads without provisioning” → Aurora Serverless v2 readers. |
AWS Certification Exam Practice Questions
Question 1:
An Aurora MySQL database serves a global application. Users in Europe experience 200ms read latency because the database is in us-east-1. The company needs European reads under 20ms without application changes. Which solution achieves this?
- Create a cross-region read replica in eu-west-1
- Configure Aurora Global Database with a secondary region in eu-west-1. European application uses the reader endpoint in eu-west-1.
- Use ElastiCache in eu-west-1 to cache query results
- Deploy CloudFront to cache database responses
Show Answer
Answer: B — Aurora Global Database provides <1 second storage-level replication to secondary regions. European users connect to the reader endpoint in eu-west-1 (local reads, <20ms). No application changes — just point reads to the local endpoint. Cross-region read replica (A) uses logical replication (higher lag). ElastiCache (C) requires code changes for caching logic.
Question 2:
A serverless application (Lambda + API Gateway) connects to an RDS PostgreSQL database. During traffic spikes, the database reaches max_connections (200) and Lambda functions fail. The database CPU is only at 30%. What is the root cause and fix?
- Database too small — upgrade instance size for more connections
- Connection exhaustion from Lambda — add RDS Proxy for connection pooling and multiplexing
- Increase max_connections parameter in the parameter group
- Add read replicas to distribute connection load
Show Answer
Answer: B — Lambda creates a new DB connection per invocation (no connection reuse across invocations). 200 concurrent Lambdas = 200 connections = maxed out. CPU at 30% confirms the DB isn’t overloaded — it’s connection count. RDS Proxy pools connections: hundreds of Lambdas share a small pool of DB connections (e.g., 20). Increasing max_connections (C) helps temporarily but wastes DB memory and doesn’t scale.
Question 3:
A DBA needs to identify which SQL queries are causing high DB load during peak hours. They need to see which queries consume the most CPU and I/O, and which wait events are occurring. Which tool provides this visibility?
- CloudWatch CPU Utilization metric with anomaly detection
- RDS Performance Insights — shows DB load breakdown by wait events, top SQL statements, and contributing sessions
- Enhanced Monitoring for OS-level process details
- AWS X-Ray tracing through the application
Show Answer
Answer: B — Performance Insights shows Average Active Sessions (AAS) broken down by wait events (CPU, I/O, locks, network), top SQL statements consuming resources, and contributing hosts/users. You can identify exactly which query causes load and what it’s waiting on. CloudWatch (A) shows CPU but not SQL-level detail. Enhanced Monitoring (C) shows OS processes but not SQL queries.
Related Posts
- Three-Tier Web & Caching Architecture
- Database Migration Architecture
- Serverless API Architecture
- Disaster Recovery Architecture
References
Frequently Asked Questions
When should I use Aurora vs standard RDS?
Aurora: When you need higher performance (5x MySQL), more read replicas (15 vs 5), faster failover (30s vs 120s), auto-growing storage, or global database. Standard RDS: When you need specific engine versions not yet on Aurora, lowest cost for small workloads, or Oracle/SQL Server (Aurora only supports MySQL/PostgreSQL). Aurora costs ~20% more but offers significantly better performance and availability.
RDS Proxy vs connection pooling in application (PgBouncer)?
RDS Proxy: Managed, integrates with IAM/Secrets Manager, faster failover (redirects connections seamlessly), no infrastructure to manage. Self-managed (PgBouncer): Full control, cheaper (EC2 cost only), more configuration options. Use RDS Proxy for Lambda (must-have), or when you want managed failover. Use PgBouncer when you need specific pooling configurations or cost sensitivity.