Cloud ex Machina blog

AWS Aurora Pricing Explained: What You Really Pay for and Why

Written by Samuel Cozannet | Sep 2, 2025 2:00:00 PM

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.
2. Use Read Replicas for Heavy Reads
  • Offload analytics and dashboards to Aurora Replicas.
  • Helps avoid read-write contention on the primary.
3. Leverage Result Caching (where safe)
  • Cache frequent reads at the application layer or use DAX/Redis for high-velocity reads.
4. Use r6g or x2g for better memory utilization
  • More in-memory caching = fewer disk reads
5. Avoid "lazy" queries
  • Full table scans are I/O killers. Use proper indexing and EXPLAIN plans to verify.
6. Monitor with CloudWatch
  • 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.

2. Autovacuum Overhead
  • Poor tuning in PostgreSQL leads to aggressive background I/O.
  • Optimizing autovacuum_naptime and related params helps reduce surprise IOPS charges.

3. Aurora MySQL's I/O Model
  • More efficient in terms of small-page updates and log flushing.
  • Lower write IOPS footprint in many OLTP scenarios.

4. Version Lag = Missed Optimizations
  • 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

1. Start at 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.
3. Configure Cluster Settings
  • 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.
4. Storage Configuration
  • 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.
5. Estimate I/O Requests
  • 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.
6. Backup Storage
  • Input the anticipated size of backups beyond the free limit (equal to your DB size).
  • Include manual snapshots if you retain them long-term.
7. Enable Global Databases or Cross-Region if Needed
  • Add replication costs if you're deploying active-active or doing regional backups.
  • Don't forget to factor in inter-region data transfer fees.
8. Review Summary & Export
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.