Table of Contents

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.
AWS Aurora Pricing in Context: What Are You Paying For?
Aurora Serverless
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:
- ACUs: Pay-per-second.
- Storage: $0.10/GB-month. (This is a representative rate often cited for regions like US East (N. Virginia), but actual storage pricing varies across regions.)
- I/O Requests: Charged separately; can spike costs quickly.
- Backups: Free up to the DB size while the cluster exists, then $0.021/GB-month. (The backup storage cost beyond the free amount similarly varies by region.)
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.
What Is RDS?
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.
Aurora vs. Traditional RDS
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 |
Key Aurora Pricing Factors
- Compute (Instances)
Provisioned instances are billed per second (5-minute minimum), based on type (e.g., db.r6g.large). Serverless v2 uses Aurora Capacity Units (ACUs), combining CPU and memory with fine-grained scaling, but no Reserved Instance discounts. Graviton2 (r6g) offers ~20% better price-performance than r5. - Storage
Billed at $0.10 per GB-month, auto-scaling in 10 GB increments up to 128 TB — no provisioning required. - I/O Requests
Charged at $0.20 per million operations. Each page read/write counts as one I/O, making OLTP or log-heavy workloads costly. Often exceeds storage costs. Monitor VolumeReadIOPs in CloudWatch. - Backups
Free up to the size of the cluster while it exists. After deletion, storage is charged at $0.021 per GB-month. - Snapshots
Manual snapshots cost $0.021 per GB-month and persist until deleted — a common source of hidden costs. - Data Transfer
Free within the same region. Cross-region replication and internet egress are billed, with internet transfer starting at $0.09/GB.
Aurora PostgreSQL Pricing Characteristics vs. MySQL
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.
Aurora Instance Pricing: The Core Cost Driver
AWS Aurora pricing is dominated by instance type, whether you're running on-demand, reserved, or serverless v2 capacity.
Aurora Instance Classes
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.
AWS Aurora Pricing Models
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.
Pricing Comparison Table
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 |
- Lower values = typically US East (N. Virginia) / US West (Oregon).
- Higher values = often Asia Pacific (Tokyo, Sydney) or Europe (London, Frankfurt).
- Serverless v2 rates fluctuate by region, though generally in the $0.06-$0.08 ACU/hr range.
- 1 ACU ≈ 2 GiB memory + variable CPU. Aurora Serverless auto-scales from 0.5 to 128 ACUs.
Performance vs. Cost Trade-Offs in Aurora
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.
Generational Performance Gaps vs. Cost Gaps
AWS has historically improved performance-per-dollar with each new generation (e.g., r4 → r5 → r6g). But recent trends show:
- Price increases across newer generations (e.g., r6g → r7g or r8g) without equivalent, measurable performance gains.
- Benchmarks (especially in database workloads) reveal modest uplift, often <10%, while price deltas can be 15–25%.
In other words, the performance-per-dollar ratio is declining, which breaks the usual AWS value promise.
New Generations Often Lack RI Support
- r6g → Fully reservable (1-year or 3-year RI).
- r7g/r8g → Currently on-demand only in many regions.
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.
Burstable T Class vs. Production-Grade Instances
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 |
- T-class instances use CPU credits: idle time accrues credits, heavy usage burns them.
- Once credits are exhausted, performance is throttled, sometimes catastrophically for transactional DBs.
T3 is fine for dev/test or sporadic read-only apps. But for production, predictable latency matters more than a low hourly rate.
Aurora Storage Pricing and I/O Considerations
Storage Cost per GB-Month
Aurora's storage model is:
- $0.10 per GB-month (for both Aurora MySQL and PostgreSQL).
- Charged based on the actual used storage, not provisioned volumes.
You get:
- Auto-growing SSD-backed storage up to 128 TB.
- 6-way replication across 3 AZs—this durability is baked into the price.
Snapshot and backup storage (beyond the free tier) is billed separately at $0.021 per GB-month.
Auto-Scaling vs. Provisioned IOPS
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…
I/O Request Pricing: The Silent Cost Bomb
Aurora charges $0.20 per 1 million I/O requests, and here's where it gets tricky:
- An "I/O request" is not a SQL statement, but a low-level page read/write.
- A single query can generate dozens or hundreds of I/O requests.
- Writes are even more expensive: Aurora synchronously writes across 3 AZs.
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.
Cost Optimization Tips for Aurora I/O
1. Batch Writes- Group inserts and updates into fewer, larger transactions.
- Reduces page-level writes and minimizes log syncing overhead.
- Offload analytics and dashboards to Aurora Replicas.
- Helps avoid read-write contention on the primary.
- Cache frequent reads at the application layer or use DAX/Redis for high-velocity reads.
- More in-memory caching = fewer disk reads
- Full table scans are I/O killers. Use proper indexing and EXPLAIN plans to verify.
- Key metrics: VolumeReadIOPs, VolumeWriteIOPs, and DatabaseConnections.
- Spike detection = tuning opportunity.
TL;DR for Engineering + Development Teams
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 |
- Lower end of ranges typically reflects US East (N. Virginia) and US West (Oregon).
- Higher end reflects more expensive regions like Asia Pacific (Tokyo, Sydney) and Europe (London, Frankfurt).
- These prices are representative; exact rates can be confirmed via AWS Pricing Calculator for your chosen region.
Aurora PostgreSQL Pricing vs. Aurora MySQL Pricing
Side-by-Side Cost Comparison (us-east-1)
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).
Performance and Compatibility Trade-Offs
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.
Engine-Specific Behaviors That Influence Cost
1. Write Amplification in PostgreSQL- PostgreSQL writes full-page images during checkpoints, especially after crash recovery or vacuum events.
- This leads to higher I/O even for small transactions.
- Poor tuning in PostgreSQL leads to aggressive background I/O.
- Optimizing autovacuum_naptime and related params helps reduce surprise IOPS charges.
- More efficient in terms of small-page updates and log flushing.
- Lower write IOPS footprint in many OLTP scenarios.
- Running older PostgreSQL engines (e.g., 13 or 14) could cost more per unit of work than upgrading to 15+ or 17.
- Example: PostgreSQL 17 shows up to 5x speedup for index-heavy bulk reads (e.g., analytics or archival reads). That's a performance/dollar uplift hiding behind a simple engine upgrade.
Cost Optimization Insights
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 |
- Aurora PostgreSQL costs slightly more and can generate more I/O, but pays off in analytics or extensible use cases.
- Aurora MySQL is more operationally efficient out of the box, especially for high-throughput transactional systems.
- Upgrading PostgreSQL versions can be a dark horse for ROI, a small investment in upgrade effort can drastically improve performance-per-dollar.
- Evaluate engine choice not just by sticker price, but by how your workload interacts with engine behaviors.
Free Tier, Backups, and Hidden Costs
What's Actually Free in Aurora?
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:
- Aurora instances aren't free, even for development or low-usage cases. The free tier applies only to standard RDS engines like MySQL and PostgreSQL (non-Aurora).
- Storage is billable from byte one. There's no free storage allowance like with some other AWS services.
- I/O requests are always charged at $0.20 per million, with no complimentary buffer.
- Backups are free, conditionally: AWS covers up to 100% of your database size in backup storage, but only while the cluster exists. Once you delete the cluster, backup costs start accumulating.
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."
Backup and Snapshot Pricing: A Hidden Cost Sinkhole
Aurora offers automatic backups and manual snapshots, but both come with caveats:
- Automatic backups are free up to the size of your active data, but again, only while your DB is active. Delete the cluster, and that same backup data becomes billable.
- Manual snapshots are billed at $0.021 per GB per month, regardless of how often the data is accessed or how old it is. AWS stores these like hot SSD data, even if you're treating them like cold archives.
- There's no built-in retention policy, which means snapshots tend to pile up quietly in the background until your bill surprises you.
You're essentially paying full freight for static data, which is not exactly a fair deal for what's often long-term insurance.
Cross-Region Replication and Data Transfer: The Global Tax
If you're using Aurora Global Databases or simply backing up data across regions, get ready for recurring data transfer fees:
- Cross-region replication costs around $0.20 per GB, and you pay that on every write, not just during initial sync.
- Copying snapshots between regions adds even more, typically $0.02–$0.03 per GB copied.
- In the event of a failover or active-active configuration, standard inter-region egress fees kick in, which can grow rapidly under load.
Even modest workloads with global footprints can rack up thousands in passive transfer charges each month.
Network Egress: When "Free" Isn't Free
While traffic within the same AZ or region is usually free, anything leaving your VPC is a different story:
- Data sent to the public internet is billed after the first free gigabyte per month, starting at $0.09 per GB.
- Cross-region traffic, even within AWS, is often charged at $0.02–$0.05 per GB, depending on the regions involved.
- If you're exporting data for analytics, external integrations, or user-facing apps, this becomes a hidden but significant cost.
Caching, using S3 Transfer Acceleration, or layering in CloudFront can help, but left unchecked, outbound data costs are a budget killer.
How to Estimate Aurora Costs Using the AWS Pricing Calculator
Go to calculator.aws.amazon.com. Click "Create Estimate", then choose "Amazon Aurora" under "Add service".
2. Choose Engine & Region
- Select either Aurora MySQL-Compatible or Aurora PostgreSQL-Compatible.
- Pick your deployment region. This affects instance pricing and data transfer costs significantly.
- Primary Instance Type: Choose your instance family (e.g., db.r6g.large). Use Graviton2 if cost is a concern and your app supports ARM.
- Number of Replicas: For read scaling or high availability.
- Instance Count: Include additional instances like dev/test if applicable.
- Aurora's storage auto-scales, so the estimate is based on the average used storage in GB.
- Input expected growth per month to model long-term costs.
- This is a hidden cost center. Use CloudWatch or historical data to guess IOPS.
- Default reads/writes per day won't cut it — estimate high if you're unsure.
- Input the anticipated size of backups beyond the free limit (equal to your DB size).
- Include manual snapshots if you retain them long-term.
- Add replication costs if you're deploying active-active or doing regional backups.
- Don't forget to factor in inter-region data transfer fees.
Once complete, review the monthly cost breakdown. You can export to CSV or share a public link.
Tips for Modeling Realistic Aurora Workloads
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.
Common Mistakes to Avoid
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.
Conclusion
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.
Effortlessly Manage Your Cloud, Improve Efficiency, and Increase Your Returns.
Newsletter Signup
Subscribe to our newsletter to receive the latest news.