AWS Aurora promises high performance and cloud-native scalability, but understanding its pricing model is another story. Between serverless ACUs, I/O charges, storage scaling, and hidden network fees, many teams underestimate what Aurora will actually cost them. In this guide, we break down every component of AWS Aurora pricing—compute, storage, I/O, backups, and more—so you can predict cloud expenses accurately, choose the right configurations, and avoid surprise line items on your AWS bill.
Aurora Serverless is built for workloads with unpredictable traffic, automatically scaling capacity up and down. You're billed per second based on Aurora Capacity Units (ACUs)—a mix of compute and memory—with a five-minute minimum.
Cost Breakdown:
There's no support for Reserved Instances, so it's strictly pay-as-you-go with no long-term discounts. Reserved pricing is only available for Aurora provisioned instances, not Aurora Serverless.
Architectural Notes:
Aurora Serverless v2 offers finer scaling than v1 but still has cold starts, doesn't support traditional read replicas, and is best suited for spiky or development workloads.
Amazon RDS (Relational Database Service) is the umbrella service under which both Aurora and traditional engines like MySQL, PostgreSQL, Oracle, and SQL Server run.
Aurora is AWS's homegrown, cloud-native RDS engine with a distributed, fault-tolerant storage layer and 5x performance claims over vanilla MySQL.
Feature |
Amazon Aurora |
Traditional RDS (e.g., MySQL/Postgres) |
Performance |
Up to 5x (MySQL), 3x (Postgres) |
Standard performance |
Storage Architecture |
Distributed, SSD-backed |
EBS-based, AZ-local |
High Availability |
Built-in with up to 15 replicas |
Up to 5 read replicas |
Scaling |
Auto-scaling (Serverless v2) |
Manual instance resizing |
Failover Time |
~30s |
1–2 minutes |
Storage Auto-Scaling |
Yes (up to 128 TB) |
Limited auto-scaling |
Pricing Model |
Higher base cost, no RIs (Serverless) |
Lower base cost, RI/Savings Plan options |
Backtrack Feature |
Yes (point-in-time within 72 hrs) |
No |
Multi-Master Support |
Limited (Aurora Multi-Master) |
Not available |
Regional Availability |
Limited in some regions |
More widely supported |
Characteristic |
Aurora PostgreSQL |
Aurora MySQL |
Instance Pricing |
Slightly higher (10–20%) |
Slightly lower |
I/O Behavior |
More write-intensive = higher I/O cost |
Generally lighter write I/O |
Feature Parity |
Fewer features (e.g., no backtrack) |
More features (e.g., backtrack, fast DDL) |
Extensions |
Supports PostGIS, pg_partman, etc. |
Fewer open-source extensions |
Performance Profile |
Stronger for complex queries & analytics |
Better for OLTP or read-heavy workloads |
Compatibility |
Closer to vanilla PostgreSQL |
Has some Aurora-only MySQL quirks |
Aurora PostgreSQL workloads tend to generate more I/O (e.g., full-page writes), which can spike costs despite similar base pricing.
AWS Aurora pricing is dominated by instance type, whether you're running on-demand, reserved, or serverless v2 capacity.
Aurora supports a subset of standard RDS instance classes, optimized for different workloads:
Instance Class |
CPU/Memory Balance |
Best Use Case |
db.t3 |
Burstable, budget-tier |
Dev/test, staging, low-throughput apps |
db.r5 |
General purpose, x86-based |
Balanced workloads, legacy compatibility |
db.r6g |
Graviton2-based (ARM) |
Production-grade, cost-optimized compute |
db.r6i |
Latest Intel-based gen |
x86-specific dependencies with better perf |
db.x2g |
Memory-optimized (ARM) |
In-memory DBs, analytics-heavy apps |
Graviton2 (e.g., r6g) offers ~20% better price/performance than x86 (e.g., r5). Use unless you rely on x86-only libraries.
Pricing Model |
Description |
Discount Potential |
Flexibility |
On-Demand |
Pay per second (10-min minimum) |
No discount |
High |
Reserved |
1- or 3-year commitment to instance class & region |
Up to 72% off |
Low (locked config) |
Serverless v2 |
Pay per second per ACU used (auto-scales) |
No RI/Savings Plan |
High (autoscaling) |
Reserved pricing only applies to provisioned Aurora instances, not Serverless.
Note that actual prices vary, so these are representative of common ranges (e.g., US East (N. Virginia) at the low end, Asia Pacific or Europe at the higher end):
Instance Type |
vCPU |
RAM (GiB) |
On-Demand Hourly (USD) |
1-YR RI (No Upfront) |
3-YR RI (All Upfront) |
db.r5.large |
2 |
16 |
$0.24 - $0.32 |
$0.16 - $0.22 |
$0.10 - $0.14 |
db.r6g.large |
2 |
16 |
$0.20 - $0.27 |
$0.14 - $0.19 |
$0.086 - $0.12 |
db.r6g.2xlarge |
8 |
64 |
$0.81 - $1.05 |
$0.55 - $0.72 |
$0.35 - $0.46 |
Serverless v2 |
— |
— |
$0.06 - $0.08 per ACU/hr |
N/A |
N/A |
Aurora's compute layer follows the classic AWS EC2 generational treadmill, but lately, that treadmill is costing more to stay on, without necessarily running faster.
AWS has historically improved performance-per-dollar with each new generation (e.g., r4 → r5 → r6g). But recent trends show:
In other words, the performance-per-dollar ratio is declining, which breaks the usual AWS value promise.
New Generations Often Lack RI Support
Adopting newer generations locks you out of the 40–70% discount band if you rely on RI-based savings strategies for predictable workloads.
This forces a painful choice: pay the premium for newer hardware, or stick with older generation RIs and risk missing out on chip-level improvements.
Class |
Characteristics |
Trade-Off |
db.t3.* |
Burstable CPU, credits-based |
Cheap, but unpredictable under load |
db.r5/r6g |
Steady-state compute, fixed performance |
Higher cost, predictable performance |
T3 is fine for dev/test or sporadic read-only apps. But for production, predictable latency matters more than a low hourly rate.
Aurora's storage model is:
You get:
Snapshot and backup storage (beyond the free tier) is billed separately at $0.021 per GB-month.
Unlike traditional RDS:
Aurora does not use provisioned IOPS. Storage auto-scales with usage, and IOPS are tied to actual read/write activity.
This sounds elegant, but…
Aurora charges $0.20 per 1 million I/O requests, and here's where it gets tricky:
Here's an example: A chatty microservice with 500 reads/sec and 50 writes/sec could generate ~47 million I/O/day, which is $282/month just in I/O fees.
Component |
Cost Metric |
Optimization Levers |
Storage |
$0.10 - $0.13 / GB-month |
Data archival, pruning, snapshot cleanup |
I/O Requests |
$0.20 - $0.22 / million requests |
Query tuning, batching, read replicas |
Snapshots |
$0.021 - $0.025 / GB-month |
TTL automation, avoid orphaned snapshots |
Backup Storage |
Free up to DB size, then $0.021 - $0.025 / GB-month |
Use lifecycle rules beyond base usage |
Cost Component |
Aurora PostgreSQL |
Aurora MySQL |
Instance Pricing |
~5–10% higher on average |
Slightly lower |
Storage |
$0.10 per GB-month (same) |
$0.10 per GB-month (same) |
I/O Requests |
$0.20 per million (same) |
$0.20 per million (same) |
Backups/Snapshots |
$0.021 per GB-month |
$0.021 per GB-month |
Serverless v2 ACU/hr |
~$0.06–0.07 |
~$0.06 |
Reserved Instance |
Available (r6g, etc.) |
Available |
PostgreSQL engine support lags slightly behind MySQL in Aurora, and often includes fewer features (e.g., no backtrack).
Dimension |
Aurora PostgreSQL |
Aurora MySQL |
Query Performance |
Better for complex joins, CTEs, analytics |
Slightly faster for OLTP/simple queries |
Extension Support |
PostGIS, pg_partman, pg_cron, etc. |
Limited; less extensible |
DDL Performance |
Slower, lacks "Fast DDL" |
Has Fast DDL, non-blocking ALTERs |
Backtrack Support |
Not available |
Available |
Replication Options |
Aurora Replicas only |
Aurora & MySQL replicas |
Engine Version Lag |
Often 1+ version behind latest PostgreSQL |
Slightly closer to MySQL release cadence |
Choose PostgreSQL for data modeling flexibility, analytics, and standards compliance. Choose MySQL for simplicity, faster cold starts, and if you need features like backtrack.
Tactic |
Applies To |
Cost Benefit |
Upgrade to newer PostgreSQL |
PostgreSQL |
Improved performance per I/O |
Disable unused extensions |
PostgreSQL |
Lower startup time, smaller snapshot size |
Use Fast DDL when schema evolves |
MySQL |
Shorter downtime = less wasted compute |
Monitor autovacuum tuning |
PostgreSQL |
Avoid excessive background IOPS |
Split read-heavy workloads |
Both |
Offload to replicas to isolate IOPS |
Despite being part of the RDS family, Aurora does not qualify for AWS's free tier in any meaningful way. Here's what that means:
So in short, the "free tier" is functionally nonexistent for Aurora users. You're paying for everything from the moment you hit "Launch DB Cluster."
Aurora offers automatic backups and manual snapshots, but both come with caveats:
You're essentially paying full freight for static data, which is not exactly a fair deal for what's often long-term insurance.
If you're using Aurora Global Databases or simply backing up data across regions, get ready for recurring data transfer fees:
Even modest workloads with global footprints can rack up thousands in passive transfer charges each month.
While traffic within the same AZ or region is usually free, anything leaving your VPC is a different story:
Caching, using S3 Transfer Acceleration, or layering in CloudFront can help, but left unchecked, outbound data costs are a budget killer.
Start by overestimating I/O if exact numbers aren't available. Aurora's per-million request pricing can add up fast. Include all environments in your estimate, not just production, and don't forget read replicas if you're using them for scaling or failover. If your app serves external users, account for network egress, especially beyond the free 1 GB/month. Lastly, model data growth over time, as Aurora auto-scales storage and charges accordingly.
A common mistake is ignoring I/O costs, which often rival or exceed compute charges. Many teams also forget to include replicas or dev/staging clusters. Backup storage isn't free if your cluster is deleted, and manual snapshots persist unless cleaned up. Data transfer to the internet is another blind spot, where even modest outbound traffic adds up. Finally, overlooking regional pricing differences can inflate your costs by 10–25% without you realizing it.
Aurora offers powerful capabilities, but its billing structure is far from straightforward. Costs stack up across compute classes, unmonitored I/O, lingering snapshots, and cross-region traffic. Choosing the right engine, upgrading versions strategically, and modeling realistic workloads are critical to optimizing both performance and price. By understanding what you're really paying for—and why—you can make smarter infrastructure decisions that align with both your technical and financial goals.
Optimize your cloud environment and regain control of your costs with Cloud Ex Machina. Reach out to us today for a demo.