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

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?

    Amazon Aurora Pricing

    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

    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

    Performance vs. Cost Trade-Offs

    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

    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

    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

    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.

    ×

    Book a Demo

    Whether you’re running on AWS, Azure, GCP, or containers, Cloud ex Machina optimizes your cloud infrastructure for peak performance and cost-efficiency, ensuring the best value without overspending.