Amazon RDS Pricing: Complete 2026 Breakdown + Calculator

Amazon RDS pricing changed for a large segment of its user base on March 1, 2026. If you are running MySQL 5.7 or PostgreSQL 11, the Extended Support Year 3 rate doubled — a db.m5.large with 2 vCPUs now costs an extra $292/month in Extended Support charges alone, on top of your normal instance bill. A db.r5.2xlarge (8 vCPUs) adds $1,168/month. Most pricing guides published in the last year don't cover this.

The biggest 2026 change: RDS Extended Support Year 3 rates doubled on March 1, 2026 — MySQL 5.7 and PostgreSQL 11 users are affected immediately.

Amazon RDS pricing has six independently metered billing dimensions, three deployment options, and seven supported engines. That's before you factor in newer charges like Extended Support, RDS Proxy, and CPU credits — the ones that rarely show up in pricing guides but frequently appear on actual bills.

This guide covers every billing dimension with real dollar examples, walks through the four discount mechanisms available, shows five common workload cost scenarios, and calls out the hidden costs that consistently catch teams off guard. I'll also show CDK patterns for building cost-aware RDS infrastructure from the start.

For exact estimates on your specific configuration, use the CloudBurn RDS Pricing Calculator as you work through this guide.

What Drives Your Amazon RDS Bill

Amazon RDS is a fully managed relational database service — AWS handles patching, backups, failover, and replication on your behalf. That managed service premium is real. You're paying more per compute hour than raw EC2 because you're also paying for operational overhead that would otherwise fall on your team.

The billing model reflects that complexity. Rather than a single line item, your RDS bill breaks down into six independently metered dimensions. Understanding each one as a separate charge is the prerequisite to controlling the total.

There are also three deployment configurations that significantly affect the bill: Single-AZ (one DB instance in one AZ), Multi-AZ with one standby (primary plus a synchronous standby for automatic failover), and Multi-AZ with two readable standbys (three instances across three AZs, standbys serve read-only traffic). Each steps up in cost and resilience.

The Six Cost Dimensions Explained

Here's how each dimension works in practice:

1. DB instance hours (compute) - The primary cost driver. Billed per-second with a 10-minute minimum after any billable status change. The instance class, engine, and deployment type (Single-AZ vs. Multi-AZ) all affect this rate.

2. Storage (per GiB/month) - Billed on provisioned storage, not consumed storage. You pay for what you allocate, not what your data actually uses today.

3. I/O requests - Only applies to magnetic (standard) storage. General Purpose SSD and Provisioned IOPS SSD storage do not incur per-I/O charges on standard RDS. This is a key difference from Aurora Standard.

4. Provisioned IOPS - Applies to io1, io2, and gp3 storage. Charged per IOPS provisioned per month, regardless of actual IOPS consumed.

5. Backup storage (per GiB/month) - Covers automated backups and manual snapshots. Billed per GiB per month, not per second.

6. Data transfer (per GB) - Free within the same AZ, charged for cross-AZ and cross-region traffic.

How RDS Billing Works (Per-Second, Not Per-Hour)

The AWS RDS billing documentation lists prices per hour, which creates a common misconception. RDS actually bills per second (with a 10-minute minimum after any billable status change like creating, starting, or modifying an instance class).

What this means practically: stopping and starting instances for cost savings works well for dev/test. But when you stop an instance, only the compute charges stop. Storage, backup storage, and other associated resource charges continue regardless.

One more thing worth knowing: if you signed up for AWS before July 15, 2025, the free tier gives you 750 hours/month of a Single-AZ db.t2, t3, or t4g.micro on MySQL, MariaDB, PostgreSQL, or SQL Server Express Edition, plus 20 GB of gp2 storage and 20 GB of backup storage, for 12 months. If you signed up after July 15, 2025, the model changed — you get $100 in credits (plus up to $100 more for activating foundational services) valid for 12 months. Most pricing guides still describe the old 750-hour model, so this distinction matters if you're evaluating free tier options.

Amazon RDS Pricing by Component

All prices referenced below are for us-east-1 (N. Virginia) as representative figures. Prices vary by region — check the CloudBurn RDS Pricing Calculator for region-specific estimates.

This section covers what each of the six billing dimensions actually costs and how they interact.

Compute: DB Instance Hours

The instance class is the largest single line item on most RDS bills. Instance families range from db.t4g.micro (burstable, around $0.016/hr in us-east-1 for MySQL/PostgreSQL) up through memory-optimized families in the multiple-dollar-per-hour range.

For most production PostgreSQL or MySQL workloads, the db.m6g.large or db.r6g.large are common starting points. Current-generation Graviton-based families (T4g, M6g, M7g, R6g, R7g, R8g) offer better price-performance than Intel/AMD equivalents at the same or lower price. For new deployments, there's no reason to default to x86.

Multi-AZ roughly doubles the compute cost — AWS provisions and bills for both the primary and standby instances' compute, storage, and replication data transfer. Worth understanding before you enable it everywhere.

Here's a reference table for common instance types in us-east-1 (On-Demand, Single-AZ, MySQL/PostgreSQL):

These figures are directional — verify current prices on the AWS pricing page or the calculator before committing to a budget.

Storage: gp3, gp2, io2, io1, and Magnetic

gp3 is the right default for new workloads. The reason comes down to how IOPS are provisioned.

With gp2, IOPS scale with volume size at 3 IOPS per GiB of storage. If you need 3,000 IOPS on a 20 GiB database, you're stuck at 60 IOPS baseline — or you have to provision a 1,000 GiB volume just to get 3,000 IOPS. You're paying for storage you don't need in order to get the I/O throughput you do need.

gp3 breaks that coupling. You provision storage size and IOPS independently. A 20 GiB volume with 3,000 IOPS is entirely valid on gp3.

Here's how the storage types compare:

One more cost control lever worth knowing: maxAllocatedStorage in CDK (or Max allocated storage in the console) sets a ceiling on storage autoscaling. Without it, RDS can expand your volume indefinitely as data grows. Setting a realistic upper bound prevents runaway storage costs.

Provisioned IOPS Costs

For io1, io2, and gp3 storage, you're charged per IOPS provisioned per month — regardless of whether those IOPS are actually used. io2 Block Express supports up to 256,000 IOPS and 16,000 MiB/s throughput for MySQL, PostgreSQL, MariaDB, and Db2, which is the right choice for genuinely high-performance production workloads.

The most common mistake here: over-provisioning IOPS on io1/io2 because the numbers seem conservative. If you provisioned 20,000 IOPS "just in case" but your workload averages 3,000 IOPS, you're paying for 17,000 unused IOPS every month. Right-size IOPS based on actual peak usage, not worst-case estimates.

One less obvious charge: if you enable a Dedicated Log Volume (DLV) for redo logs, it's priced at 1,000 GiB and 3,000 Provisioned IOPS at standard rates. That's a fixed cost addition only relevant if you're using io1 or io2 with large, latency-sensitive workloads.

Backup Storage Costs

Backup storage covers automated backups (based on retention period) and manual snapshots (which exist until you explicitly delete them). Billing is per GiB per month, not per second.

The retention period trade-off is real: the default 7-day retention is fine for most teams. Dropping to 1 day reduces backup storage costs but shrinks your recovery window. Going to 30 days significantly increases backup storage, especially for large databases.

The silent accumulator is manual snapshots. Teams take a snapshot "just before the migration" or "for the quarterly audit" and never delete it. Those snapshots continue to accumulate charges indefinitely. A yearly cleanup of old manual snapshots is a genuinely impactful quick win.

Snapshot copies to other regions incur standard storage charges in the destination region plus cross-region data transfer. If you're copying snapshots for disaster recovery, budget for both the destination storage and the transfer cost.

Data Transfer Costs

The rule is simple: keep your application servers in the same AZ as your RDS primary instance and you pay nothing for database traffic.

Here's the full breakdown:

• Free: Data transfer between RDS and EC2 in the same Availability Zone
• Free: Multi-AZ replication data transfer between AZs
• $0.01/GB each direction: EC2 to/from RDS when they're in different AZs of the same Region (charged on the EC2 side)
• Charged: Cross-region snapshot copies (storage in destination region + transfer)
• Free: First 100 GB/month of data transfer out to the internet (aggregated across all AWS services)

The cross-AZ charge catches teams that deploy application instances and databases in different AZs thinking it improves redundancy. For Multi-AZ RDS, your standby doesn't serve traffic, so queries from the same AZ as the primary are free. For Single-AZ, co-locating your app servers with the database AZ eliminates the charge entirely.

Amazon RDS Pricing by Engine

Engine choice affects both the per-instance-hour compute price and the licensing model. The gap between open-source engines and commercial engines is significant enough to be a primary architecture decision, not a detail.

As a rough directional guide: MySQL, PostgreSQL, and MariaDB are the baseline. Oracle License Included runs roughly 3-5x the per-hour cost of an equivalent open-source instance. SQL Server Standard License Included is in a similar range. SQL Server Enterprise is substantially higher.

Open-Source Engines: MySQL, PostgreSQL, MariaDB

MySQL, PostgreSQL, and MariaDB are the lowest-cost tier. No licensing fees. For the same instance class in the same region, pricing is identical across these three engines on standard RDS.

A few engine-specific billing details worth knowing:

CPU Credits on T-series instances: T3 and T4g RDS instances run in Unlimited mode by default. When average CPU over a rolling 24-hour period exceeds the instance's baseline, AWS charges CPU credits at $0.075 per vCPU-Hour for MySQL and PostgreSQL. This charge isn't covered by Reserved Instances. A db.t3.micro running at sustained 60% CPU (well above its 10% baseline) will generate CPU credit charges continuously — often more than the base instance cost. If your workload is consistently CPU-heavy, a non-burstable M or R family instance is almost certainly cheaper in total.

Extended Support: Applies to MySQL and PostgreSQL instances on major versions past community end-of-life. More on this in the hidden costs section — it's the most impactful billing change in March 2026.

Free Tier: MySQL, MariaDB, PostgreSQL, and SQL Server Express Edition are all eligible.

Zero-ETL integrations: MySQL and PostgreSQL support zero-ETL integrations with Redshift and SageMaker. These add CDC data transfer costs and snapshot export costs on top of normal RDS charges.

Commercial Engines: Oracle, SQL Server, Db2

Oracle has two licensing models with meaningfully different cost profiles:

• License Included (LI): The Oracle SE2 software license is bundled into the per-hour price. Significantly more expensive per instance-hour than open-source engines. Does NOT support size-flexible Reserved Instances, so you need to predict your exact instance size at purchase.
• Bring Your Own License (BYOL): Use existing Oracle licenses. Supports both SE2 and Enterprise Edition. Supports size-flexible RIs. If you have existing Oracle licenses and aren't planning to modernize, BYOL is the right choice.

If you're evaluating Oracle, the migration path to Aurora PostgreSQL eliminates licensing costs entirely — worth modeling the TCO before committing to a multi-year Oracle deployment.

SQL Server includes licensing in the per-hour price. A few things that differentiate it from open-source:

• T3 instances incur CPU credit charges (same $0.075/vCPU-Hour model)
• Does NOT support size-flexible Reserved Instances
• SQL Server Developer Edition is now available on RDS — full Enterprise Edition functionality for non-production workloads under Microsoft licensing terms. Use this for staging and CI environments instead of paying for Standard or Enterprise editions.
• Optimize CPU on M7i and R7i instances lets you reduce the number of active vCPUs, lowering licensing costs while maintaining memory capacity. AWS says M7i and R7i instances with this feature offer up to 55% lower costs compared to previous-generation instances.

Db2 doesn't support gp2 or magnetic storage, but it does support size-flexible Reserved Instances. Relatively niche; if you're using it, check the engine-specific pricing page for current rates.

Single-AZ vs Multi-AZ: The Cost Reality

Multi-AZ roughly doubles your compute cost. That's the honest answer. AWS provisions and bills for both the primary instance and the standby — the standby sits in a separate AZ waiting to take over in under a minute if the primary fails.

For Multi-AZ (one standby), the standby doesn't serve read traffic. You're paying double compute for automatic failover capability. For Multi-AZ (two readable standbys), you get three instances across three AZs and the standbys can serve read-only queries — you're paying for three instances.

Here's a concrete example using db.m6g.large PostgreSQL in us-east-1:

Storage also doubles on Multi-AZ because the standby maintains a synchronous copy of the data volume. So if you're provisioning 500 GB on a Multi-AZ instance, you're effectively paying for 1 TB of EBS storage.

When Single-AZ is the right choice: dev/test environments, non-critical read-only applications, anything where a few minutes of downtime during a failover isn't a business problem. When Multi-AZ is non-negotiable: production databases, any workload where database downtime has real revenue or user impact.

Real-World RDS Monthly Cost Examples

This is the section most pricing guides skip. Here are five workload archetypes with fully calculated monthly estimates, all using On-Demand pricing in us-east-1. These are directional estimates — actual prices vary by engine and configuration. Use the CloudBurn RDS Pricing Calculator to get exact figures for your setup.

A few notes on these estimates:

The SQL Server Standard figure is higher than the MySQL/PostgreSQL standard production case with the same instance class and storage because of the bundled SQL Server SE2 license.

The high-IOPS case adds significant cost beyond compute: 10,000 provisioned IOPS on io2 is meaningful monthly spend on top of the instance and storage charges.

Now add Extended Support to any of these if you're running an EOL version. For the standard production case — db.m6g.large MySQL 5.7, 2 vCPUs, Multi-AZ — the Year 3 Extended Support charge is $0.200 × 2 vCPUs × 730 hours = $292/month extra. That's more than double the compute cost of the instance itself in the Single-AZ configuration.

Hidden Costs Most Guides Don't Cover

The six billing dimensions above are the expected costs. What follows are the charges that appear on real bills but rarely show up in pricing guides.

These aren't edge cases. I've seen all four of these catch engineering teams off guard, often after months of unknowingly paying them.

RDS Extended Support — The Bill That Doubled in March 2026

When a MySQL or PostgreSQL major version reaches community end-of-life, AWS doesn't automatically shut it down. Instead, they continue providing security patches and bug fixes for up to three additional years — and they charge you for it.

MySQL 5.7 reached end of standard support on February 29, 2024. Every team still running MySQL 5.7 has been paying Extended Support charges since March 2024.

The rate structure escalates over time:

• Year 1-2 (March 2024 – February 2026): $0.100 per vCPU-hour in us-east-1
• Year 3 (starting March 1, 2026): $0.200 per vCPU-hour

That doubling is what happened this month.

The math matters here. This is per vCPU per hour, and it applies to every running instance on the affected version — primary, standby, and read replicas:

On a Multi-AZ instance, both the primary and standby incur Extended Support charges. So double the figures above for Multi-AZ deployments.

Reserved Instance discounts do not apply to Extended Support charges. Even if you have a 3-year All Upfront RI, the Extended Support charge is billed at full rate on top.

The fix is straightforward: upgrade to a supported MySQL or PostgreSQL version. Use Amazon RDS Blue/Green Deployments for reduced-downtime upgrades. For CDK stacks, add engineLifecycleSupport: rds.EngineLifecycleSupport.OPEN_SOURCE_RDS_EXTENDED_SUPPORT_DISABLED to prevent creation of instances on unsupported versions — more on this in the IaC section.

This also applies to Aurora MySQL and Aurora PostgreSQL.

RDS Proxy Pricing

RDS Proxy pools and shares database connections. It's practically mandatory for Lambda-based applications — without it, every Lambda invocation opens a new database connection, and under load you'll exhaust the database's connection limit.

The pricing model: per vCPU per hour of the underlying provisioned instance. For Aurora Serverless v2, it's per ACU per hour consumed. Billing is per-second with a 10-minute minimum.

The default RDS Proxy endpoint has no additional charge. But if you create additional read-only or read-write proxy endpoints, each one provisions an AWS PrivateLink interface endpoint — and those incur standard PrivateLink charges.

For a db.r5.xlarge (4 vCPUs), you're paying for 4 vCPU-hours of Proxy usage per hour on top of the instance itself. At current rates, check the AWS RDS Proxy pricing page for exact per-vCPU-hour figures in your region.

Zero of the ten top-ranking RDS pricing guides cover this. If your architecture uses Lambda + RDS, you're almost certainly paying for RDS Proxy — knowing the cost model helps you track it in Cost Explorer.

CPU Credits on T3/T4g Instances

T3 and T4g instances run in Unlimited mode on RDS by default. That means they can sustain CPU usage above their baseline indefinitely. Convenient — and an invisible cost if your workload runs at sustained high CPU.

When a T3 or T4g RDS instance's average CPU exceeds its baseline over a rolling 24-hour period, AWS charges $0.075 per vCPU-Hour for MySQL and PostgreSQL. For Aurora, it's $0.090 per vCPU-Hour. Reserved Instances don't cover this charge.

A db.t3.micro has a 10% CPU baseline. If your application runs consistently at 70% CPU, you're in sustained burst mode and generating CPU credit charges every day. At that point, a non-burstable M or R family instance costs less total than the T instance plus its credit charges.

To check: look at the CloudWatch CPUCreditBalance metric. If it's consistently near zero, you're burning through credits and being charged. If you're seeing this, compare the total monthly cost of your T instance (base + CPU credits) against a comparable M6g or R6g instance.

Other Costs to Watch

A few smaller charges worth knowing about:

• Snapshot exports to S3: per-GB export charge plus S3 storage and KMS charges. Relevant if your team uses RDS-to-S3 for analytics pipelines.
• Cross-region automated backups: data transfer charges to copy snapshots and transaction logs to another region. Budget for both the destination storage and the transfer.
• Zero-ETL integrations: CDC data transfer and Redshift/SageMaker storage costs stack on top of normal RDS charges for MySQL and PostgreSQL zero-ETL setups.
• Dedicated Log Volume (DLV): adds 1,000 GiB at 3,000 Provisioned IOPS at standard rates. Only relevant for io1/io2 users, but it's a meaningful fixed monthly addition if enabled.
• Public IPv4 addresses: $0.005/hr per public IP for any RDS instance with public access enabled. Keep RDS in private subnets and this charge disappears entirely.

How to Reduce Your RDS Bill

There are four discount mechanisms for RDS: On-Demand (no commitment), Reserved Instances, Database Savings Plans, and Spot. Note that Spot is not available for RDS — a common misconception. The discount choices are On-Demand, Reserved Instances, and Database Savings Plans.

Beyond purchasing discounts, there are practical right-sizing and configuration optimizations that often have equal or greater impact. I'll cover both.

For a broader cost optimization framework beyond RDS-specific tactics, the AWS cost optimization maturity framework is worth reading alongside this guide.

Reserved Instances: Up to 69% Savings

For any database running 24/7, Reserved Instances are the highest-impact cost lever available. The math is simple: if you're going to run this database for a year or more, paying On-Demand rates is leaving significant money on the table.

Three payment options, each with different trade-offs:

The maximum 69% figure AWS cites applies to steady-state usage (meaning the RI is applied every single hour). In practice, 1-year Partial Upfront gets you to ~55-60% savings while keeping some cash available if needs change.

A few important mechanics:

Reserved Instances cover compute costs only. Storage, IOPS, backup storage, and data transfer are still billed separately at On-Demand rates.

Size-flexible RIs are available for MySQL, PostgreSQL, MariaDB, Oracle BYOL, Db2, and Aurora. If you buy a db.r5.large RI, it can apply automatically to any instance in the R5 family — a db.r5.xlarge consumes it at 2x the normalized rate, a db.r5.2xlarge at 4x, and so on. This means you don't have to precisely predict your final instance size when purchasing. Size-flexible RIs do NOT apply to SQL Server (LI) or Oracle (LI).

What's fixed at purchase: Region, engine, instance class (for non-size-flexible), deployment type, and term. You can't change these after purchasing, and RIs can't be transferred. You can purchase up to 40 per account (requestable increase).

For Multi-AZ DB Cluster coverage: either reserve 3 Single-AZ instances of the matching size, or 1 Multi-AZ RI plus 1 Single-AZ RI.

My recommended approach: run On-Demand for 1-2 months to validate steady-state usage, then buy 1-year Partial Upfront. It balances savings against flexibility well for most teams. Check the Amazon RDS Reserved Instances pricing page for current rates by engine, region, and term.

Database Savings Plans: The Flexible Alternative (re:Invent 2024)

Database Savings Plans launched at re:Invent 2024 and are completely missing from most RDS pricing guides. They're worth understanding because they solve a problem RIs don't.

The trade-off in plain terms: up to 35% savings (vs. up to 63% for RIs) in exchange for flexibility that RIs don't offer.

With Database Savings Plans, you commit to a dollar-per-hour usage amount for 1 year. The discount applies automatically to any eligible usage regardless of engine, instance family, size, region, or deployment type. If you're planning to migrate from MySQL to Aurora PostgreSQL, or from us-east-1 to eu-west-1, or from RDS to DynamoDB, your Savings Plan commitment follows.

Covered services span 11 AWS database services: Aurora (MySQL and PostgreSQL), RDS (MySQL, PostgreSQL, MariaDB, Oracle BYOL, Db2), DynamoDB, ElastiCache for Valkey, DocumentDB, Neptune, Keyspaces, Timestream, DMS, and OpenSearch.

You cannot combine Database Savings Plans with RDS Reserved Instances for the same workload. But you can use an RI for one stable workload and a Savings Plan for another that you're planning to migrate.

When Savings Plans beat RIs:

• You're planning to change engine types (Oracle to Aurora PostgreSQL)
• You're considering a region migration
• You want one commitment covering multiple different database workloads
• You're uncertain about future instance sizes

When RIs beat Savings Plans:

• Your workload is completely stable — same engine, same region, no planned migrations
• You want maximum discount (63% vs 35%)
• You're using SQL Server or Oracle LI (not covered by size-flexible RIs anyway)

Use the Savings Plan Purchase Analyzer in the AWS Billing console to simulate scenarios before committing. For a detailed comparison of all Savings Plans types, see the AWS Database Savings Plans guide and the AWS Savings Plans overview.

Right-Sizing with AWS Compute Optimizer

AWS Compute Optimizer provides specific right-sizing recommendations for RDS MySQL, RDS PostgreSQL, Aurora MySQL, and Aurora PostgreSQL. It analyzes CloudWatch metrics — CPU utilization, network throughput, database connections — and identifies whether instances are Optimized, Over-provisioned, or Under-provisioned.

When CloudWatch Database Insights is enabled, Compute Optimizer gets additional signals: DBLoad, swap utilization, memory pressure metrics, and memory kill counts for Aurora. This gives meaningfully richer recommendations than CPU alone.

Compute Optimizer also identifies idle databases (low connection count, low CPU) and recommends stopping, deleting, or converting to Aurora Serverless v2. It flags gp2 volumes eligible for gp3 migration, recommends Graviton instance migrations, and surfaces newer-generation instance upgrades. Cost Optimization Hub consolidates all of these recommendations across accounts and regions — a good starting point for a quarterly optimization review.

Graviton Instances: Better Price-Performance

Graviton-based instance families — T4g, M6g, M7g, R6g, R7g, R8g — offer better price-performance than their Intel/AMD equivalents, typically at the same or lower price. For new RDS deployments, there's no good reason to choose the Intel equivalents.

Graviton4 (m8g, r8g), launched late 2024, delivers up to 40% better performance and up to 29% better price-performance over Graviton3-based instances on Aurora, according to AWS benchmarks.

The migration process is straightforward: Compute Optimizer identifies eligible workloads. The change itself is a parameter group update plus instance class change during a maintenance window. For most open-source engine workloads, it's a low-risk upgrade with meaningful cost savings.

Quick Wins: gp3, Stop Dev Instances, Current-Gen Upgrades

A few high-ROI actions that are fast to implement:

Migrate gp2 to gp3: Independent IOPS provisioning means you stop paying for over-sized volumes. Compute Optimizer flags this automatically. For databases that were provisioned on gp2 with large volumes just to get adequate IOPS, the savings can be substantial.

Stop dev and test instances: For instances running 8 hours/day, 5 days/week instead of 24/7, stopping saves approximately 76% of compute costs. Storage and backup charges continue, but compute is the majority of the bill. Automate this with AWS Instance Scheduler or CDK start/stop schedules.

Upgrade to current-generation instance classes: M4, M5, R4, R5, T2 instances should be on the migration list. Graviton-based M6g, M7g, R6g, R7g are better on price-performance; Intel/AMD latest-gen M6i, R6i, R7i, R8g are the alternatives if you need x86. Compute Optimizer generates these recommendations automatically.

Upgrade away from Extended Support versions: If you're on MySQL 5.7 or PostgreSQL 11, this is the highest-ROI action on this list. At Year 3 rates ($0.200/vCPU-hr), every month of delay costs real money. Reserve 6-12 months for a major version upgrade project — the Extended Support cost should be funding argument enough to get it prioritized.

Delete idle snapshots: Manual snapshots accumulate silently. AWS Trusted Advisor (Business Support and above) includes idle RDS checks that surface unneeded snapshots and under-utilized instances.

RDS vs Aurora: Which Is Cheaper for Your Workload?

Aurora is not always more expensive than standard RDS. It's also not always cheaper. The answer depends on I/O patterns, workload variability, and which Aurora-specific features you actually need.

Quick framing: Aurora uses a distributed cluster volume stored across three AZs (not EBS). This gives Aurora different cost characteristics than standard RDS — primarily in how I/O is priced.

When Standard RDS Wins on Cost

For small to medium workloads with predictable, low to moderate I/O: standard RDS on gp3 storage is typically cheaper than Aurora. The key reason is that Aurora Standard charges per I/O request (read and write operations), while gp3 on standard RDS does not.

If I/O costs represent less than 25% of your hypothetical Aurora spend, you're better off on standard RDS gp3 — Aurora Standard adds per-I/O charges on top of comparable instance prices without delivering a cost benefit at that I/O level.

For dev/test: a db.t4g.micro on standard RDS with 20 GiB gp3 is the cheapest managed database option available. Aurora doesn't have a comparable micro tier.

For commercial engines (Oracle, SQL Server, Db2): Aurora MySQL and Aurora PostgreSQL aren't replacements. The RDS vs. Aurora comparison is specific to workloads that can run on MySQL or PostgreSQL.

When Aurora Saves You Money

Aurora I/O-Optimized eliminates per-I/O charges in exchange for a higher instance price. When I/O costs represent more than 25% of your total Aurora spend, switching to I/O-Optimized can save up to 40% on total costs. The configuration change can be made without downtime.

Aurora Serverless v2 scales database capacity based on actual demand, billed per ACU-second (1 ACU is approximately 2 GiB of memory with corresponding CPU and networking). For workloads with variable or unpredictable traffic, this eliminates the cost of over-provisioned capacity. It scales down to a minimum of 0 ACU (near-zero when idle) and scales up instantly.

Aurora read replicas scale more cost-efficiently than standard RDS read replicas. Aurora supports up to 15 read replicas, all sharing the same distributed cluster volume — adding a reader doesn't provision separate storage. With standard RDS, each read replica maintains its own EBS volume copy, so storage costs scale linearly with replica count.

Aurora Reserved Instances apply across instance sizes within the same family AND across Aurora Standard and Aurora I/O-Optimized configurations automatically. Aurora RI discounts reach up to 45% (1-year) and 66% (3-year) over On-Demand — slightly different from standard RDS RI rates, so compare before purchasing.

IaC Cost Patterns for RDS (AWS CDK)

Infrastructure as Code isn't just about automation. Every CDK property that configures RDS is also a cost decision — and making those decisions explicit in code makes them reviewable before they hit production.

For a broader foundation on CDK patterns, see AWS CDK best practices and Infrastructure as Code for AWS. This section focuses specifically on the cost-relevant configuration choices.

The CDK module is aws-cdk-lib/aws-rds. The key constructs are rds.DatabaseInstance for single RDS instances, rds.DatabaseCluster for Aurora, and rds.DatabaseProxy for RDS Proxy.

CDK PostgreSQL Instance with gp3 and Autoscaling

Here's a cost-aware single PostgreSQL instance with the properties that matter most for billing:

import * as cdk from 'aws-cdk-lib';
import * as rds from 'aws-cdk-lib/aws-rds';
import * as ec2 from 'aws-cdk-lib/aws-ec2';

declare const vpc: ec2.Vpc;

const instance = new rds.DatabaseInstance(this, 'PostgresInstance', {
  engine: rds.DatabaseInstanceEngine.postgres({
    version: rds.PostgresEngineVersion.VER_16_3,
  }),
  // Graviton-based burstable (T4g) — better price-performance than Intel equivalent
  instanceType: ec2.InstanceType.of(
    ec2.InstanceClass.BURSTABLE4_GRAVITON,
    ec2.InstanceSize.MEDIUM,
  ),
  vpc,
  vpcSubnets: {
    subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS,
  },
  // gp3: independent IOPS provisioning — no forced over-provisioning
  storageType: rds.StorageType.GP3,
  allocatedStorage: 100, // GiB initial allocation
  // Cost ceiling on storage autoscaling — prevents unbounded growth
  maxAllocatedStorage: 200,
  // 7-day backup retention — balance between recovery window and storage cost
  backupRetention: cdk.Duration.days(7),
  // Set true for production, false for dev/test to save ~50% on compute
  multiAz: true,
  credentials: rds.Credentials.fromGeneratedSecret('dbadmin'),
  storageEncrypted: true,
  autoMinorVersionUpgrade: true,
  // Guard against creating instances on EOL versions
  engineLifecycleSupport: rds.EngineLifecycleSupport.OPEN_SOURCE_RDS_EXTENDED_SUPPORT_DISABLED,
});

The cost-relevant properties in this example:

The engineLifecycleSupport property is the one most teams skip. Add it to every production CDK stack. If a future engine version upgrade is missed and an instance ends up on an EOL version, this flag prevents it from being created at all — forcing the upgrade rather than silently accumulating Extended Support charges.

Aurora Serverless v2 with Cost Controls

For variable workloads, Aurora Serverless v2 with explicit ACU bounds is the cost-aware configuration:

import * as rds from 'aws-cdk-lib/aws-rds';
import * as ec2 from 'aws-cdk-lib/aws-ec2';

declare const vpc: ec2.Vpc;

const cluster = new rds.DatabaseCluster(this, 'AuroraServerlessCluster', {
  engine: rds.DatabaseClusterEngine.auroraMysql({
    version: rds.AuroraMysqlEngineVersion.VER_3_01_0,
  }),
  writer: rds.ClusterInstance.serverlessV2('writer'),
  readers: [
    rds.ClusterInstance.serverlessV2('reader'),
  ],
  // Minimum ACU: 0.5 maintains connection readiness without idle waste
  serverlessV2MinCapacity: 0.5,
  // Maximum ACU: cost ceiling — prevents runaway scaling under unexpected load
  serverlessV2MaxCapacity: 16,
  vpc,
  vpcSubnets: {
    subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS,
  },
});

The two properties that control cost are serverlessV2MinCapacity and serverlessV2MaxCapacity. Setting minCapacity to 0.5 ACU keeps the cluster responsive to connections without sitting at full capacity when idle. Setting maxCapacity acts as a budget ceiling — if an unexpected traffic spike would scale beyond 16 ACU, it caps there rather than scaling to hundreds of ACUs and generating a large bill.

For Aurora I/O-Optimized, add one property to eliminate per-I/O charges:

const ioOptimizedCluster = new rds.DatabaseCluster(this, 'AuroraIOOptimized', {
  engine: rds.DatabaseClusterEngine.auroraPostgres({
    version: rds.AuroraPostgresEngineVersion.VER_15_2,
  }),
  writer: rds.ClusterInstance.provisioned('writer', {
    publiclyAccessible: false,
  }),
  // Aurora I/O-Optimized: no per-I/O charges
  // Only cost-effective when I/O > 25% of total Aurora spend
  storageType: rds.DBClusterStorageType.AURORA_IOPT1,
  vpc,
  vpcSubnets: {
    subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS,
  },
});

storageType: rds.DBClusterStorageType.AURORA_IOPT1 is one line that eliminates per-I/O charges entirely. But only use it if I/O is actually costing you more than 25% of total Aurora spend — the instance price for I/O-Optimized is higher than Standard.

If you want to see the cost impact of changing instanceType, multiAz, or serverlessV2MaxCapacity before merging a PR, CloudBurn shows the estimated monthly cost diff directly in your pull request.

Key Takeaways

RDS pricing is genuinely complex, but most bills follow predictable patterns once you understand the six dimensions and the discount mechanics.

Here's what to act on:

• If you're running MySQL 5.7 or PostgreSQL 11: Extended Support Year 3 rates doubled on March 1, 2026. Check AWS Cost Explorer for Extended Support charges right now. Every month of delay at $0.200/vCPU-hr adds up fast.
• For steady-state production databases: Reserved Instances (up to 63% savings) deliver higher maximum discounts than Database Savings Plans (35%). If you're planning engine migrations or region changes, flip to Database Savings Plans instead.
• Multi-AZ doubles compute: necessary for production, unnecessary for dev/test. Make sure your CDK stacks explicitly set multiAz: false for non-production environments.
• T3/T4g CPU credits and RDS Proxy are the two most common surprise line items. Check your Cost Explorer for both — filter by usage type "CPUCredits" and "RDSProxy" in us-east-1.
• gp3 over gp2 for any new or existing deployment. The decoupled IOPS model is strictly better than gp2's volume-size coupling.

Use the CloudBurn RDS Pricing Calculator to get an estimate for your specific configuration before your next deployment. And if you're already running RDS, open Cost Explorer filtered to the last 30 days and look for Extended Support and CPU credit charges — for a large chunk of the MySQL 5.7 user base, there's a line item that just doubled.

For broader database cost comparisons, the Amazon EC2 pricing guide covers the raw compute alternative and the AWS Database Savings Plans guide goes deeper on the commitment-based discount model that covers RDS and 13 other services.

Frequently Asked Questions