Amazon Aurora
Aurora
You need a cloud-native SQL database that automatically scales storage and offers faster replication than standard engines.
Reach for it when
- Running high-throughput MySQL or PostgreSQL workloads that have outgrown standard RDS performance limits.
- Deploying global applications that require read replicas in multiple AWS regions with sub-second lag.
- Building serverless apps where database capacity automatically scales down to zero when idle.
Do not reach for it when
- Running simple development environments that only need a small database for testing — use standard RDS MySQL or PostgreSQL instead.
- Hosting applications that do not use MySQL or PostgreSQL, such as Oracle or SQL Server — use standard RDS instead.
- Storing key-value data with simple query patterns that do not need relational joins — use DynamoDB instead.
Alternatives, and how to choose
| Service | Pick it instead when |
|---|---|
| RDS | Choose it when you need engine versions not supported by Aurora or want to minimize baseline hourly costs. |
| DynamoDB | Choose it when you need horizontally scalable non-relational storage with no connection limits. |
How you pay
- The model
- Pay per Aurora Capacity Unit (ACU) hour (for serverless) or instance hour, plus storage and I/O request volume.
- The line item that surprises people
- Aurora Serverless v2 capacity scales up rapidly during traffic spikes, causing a corresponding spike in hourly costs.
What trips people up
- While storage autoscales up to 128TB, it does not automatically scale down; you must drop tables and run manual rebuilds.
- Failing to configure minimum ACU limits on Serverless v2 can cause severe latency spikes during sudden cold starts.
- Aurora global databases share writer endpoints; you must manage application routing to send write traffic to the primary region.
Verify the live service
This page is a concept reference. Cost models are qualitative; confirm the current offering, Region and pricing before deploying.