AWS Aurora seems like a straightforward replacement for RDS for high-availability database clusters until you start digging into how it really works. The first production incident happens not because a node crashes, but because the application doesn't know how to switch between writer and reader during failover. Aurora is not MySQL in the cloud — it's a distributed storage with a shared volume for all cluster nodes, and without understanding this difference, architectural decisions will be wrong. Savings on Aurora instances compared to RDS can reach 30% thanks to efficient storage, but only with proper configuration. For example, a typical cluster with one writer and two readers can save up to $300 per month.
Why standard Multi-AZ RDS doesn't solve the problem under serious load
Multi-AZ RDS provides failover in 30–120 seconds — acceptable for most scenarios, but Aurora reduces this to 20–30 seconds because the standby is not just a replica, but a full cluster member with the same storage volume. This makes Aurora failover up to 4 times faster than Multi-AZ RDS.
With Aurora, failover happens in 20–30 seconds, up to 4x faster than standard Multi-AZ RDS.Add Aurora Replicas (up to 15) — and read traffic scales horizontally without copying data between nodes. On a real project — an e-commerce platform with ~800 RPS at peak — we encountered the writer instance hitting CPU saturation during concurrent transactions on checkout. The solution: reader endpoint for analytics and reports, writer only for mutations. This reduced writer node CPU from 85% to 40% during peak hours without upgrading the instance. This represents a 45% reduction in CPU usage.
How we design an Aurora cluster
We start with the engine choice: Aurora MySQL 8.0-compatible or Aurora PostgreSQL 15-compatible. This isn't just API compatibility — they have different parameter limits, different autovacuum behavior (PostgreSQL), and different JSON operation capabilities. The choice depends on the existing workload, not preferences. Our certified AWS engineers have 10+ years of experience and have implemented 50+ database migration projects.
Here are the steps to design an Aurora cluster:
- Choose the engine (Aurora MySQL or Aurora PostgreSQL) based on your workload.
- Create a cluster with a primary instance and initial Aurora parameter group.
- Add read replicas in different availability zones for failover.
- Configure Auto Scaling for reader nodes using custom metrics.
- Set up monitoring with Enhanced Monitoring and Aurora Performance Insights.
- Test failover using the AWS CLI command.
Cluster structure for production:
Primary (writer): db.r7g.xlarge or larger
Read Replica 1: db.r7g.large — same AZ as writer
Read Replica 2: db.r7g.large — second AZ (failover candidate)Aurora parameter group — the first thing we pay attention to. Aurora uses cluster-level and instance-level parameter groups. max_connections for r7g.xlarge Aurora PostgreSQL defaults to ~5000, but that doesn't mean we leave it — when using PgBouncer on top, settings change. shared_buffers in Aurora PostgreSQL is managed separately from the parameter group setting.
Aurora Auto Scaling for reader nodes is configured via aws application-autoscaling register-scalable-target with target tracking on RDSReaderAverageDatabaseConnections or RDSReaderAverageCPUUtilization. Important: scale-in cooldown should be set long enough (600+ seconds), otherwise nodes will flap under load fluctuations.
How to properly configure Aurora Global Database?
Aurora Global Database is a separate story. Replication between regions works over a dedicated replication network with lag typically under 1 second. It's not a replacement for intra-region replication; it's disaster recovery with RPO ~1s and RTO ~1 minute during regional failover. Configured via create-global-cluster, secondary region added as add-region-to-global-cluster.
More details: Amazon Aurora
How to set up monitoring and Aurora backup?
Aurora backup is automated. Backtrack — a feature often overlooked. It allows rolling back the cluster in time without restoring from a snapshot. Works only for Aurora MySQL. Configured at cluster creation, window up to 72 hours. Cost: additional I/O for storing change records. For Aurora PostgreSQL, the equivalent is PITR (Point-in-Time Recovery) via automated backups.
Enhanced Monitoring provides OS-level metrics every 1–60 seconds: cpuUtilization, diskIO, loadAverageMinute. Enabled through the IAM role rds-monitoring-role with policy AmazonRDSEnhancedMonitoringRole. Aurora Performance Insights provides deep visibility into database load, shows db.load in vCPU units, breaks down load by waits (db.lock, db.io, db.cpu), and allows drilling down to specific SQL statements. Retention: 7 days free, up to 2 years for an additional fee.
Comparison of Aurora MySQL and PostgreSQL
| Parameter | Aurora MySQL | Aurora PostgreSQL |
|---|---|---|
| Engine | MySQL 8.0-compatible | PostgreSQL 15-compatible |
| Backtrack | Yes | No (PITR) |
| JSON operations | JSON/JSONB | JSONB |
| Autovacuum | No | Yes (important to tune) |
| Max DB size | 64 TiB | 64 TiB |
Timelines and scope of work
| Scenario | Timeline |
|---|---|
| New Aurora cluster without migration | 1-2 days |
| Aurora migration from RDS/on-premises with downtime | 2-3 days |
| Live migration via DMS | 4-7 days |
| Global Database with multi-region | 5-8 days |
Cost is calculated individually after infrastructure audit. Order a database audit and get an accurate estimate and recommendations.
What is included in the work
- Consultation and audit of current database infrastructure
- Design and deployment of Aurora cluster
- Monitoring and alerting setup
- Documentation (runbook, Aurora backup/restore procedures)
- Training your team on Aurora operations
- Guaranteed fault tolerance with RTO < 1 minute
Common mistakes in Aurora configuration
Common mistakes in Aurora configuration
-
Not setting up Aurora Connection Pooling. Aurora handles connections well, but under Lambda functions or serverless loads with thousands of ephemeral connections, the database still chokes. Aurora Proxy — managed PgBouncer/ProxySQL from AWS, integrates with Secrets Manager for automatic credential rotation.
-
Using a single endpoint for everything. The cluster endpoint always points to the writer. If read queries go there too, the whole point of read replicas is lost. The reader endpoint balances across replicas with round-robin; custom endpoints allow dedicating specific nodes for analytics.
-
Ignoring Aurora-specific limits. The maximum table size in Aurora is 64 TiB per engine. Storage automatically grows in 10 GiB increments but does not automatically shrink.
aurora_oom_responseon MySQL — a parameter worth checking if nodes restart periodically without obvious reasons.
Contact us for a consultation on your project. We will help design a fault-tolerant solution and avoid common mistakes.