Overview

High-level RDS and Aurora pricing model and the main levers you can use to control spend.

Pricing Model

Amazon Relational Database Service (RDS) runs managed relational databases such as MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, and Amazon Aurora. You pay for the capacity and features you turn on rather than managing hardware yourself.1

Amazon Aurora is still part of RDS, but it ships with its own distributed storage engine. Compute nodes connect to a multi-AZ storage layer, so instead of attaching per-instance EBS volumes you pay for shared Aurora storage and, if you use Aurora Serverless v2, for Aurora capacity units (ACUs). Compared with standard RDS engines, Aurora tends to have higher storage costs yet can reduce the number of read replicas you need because storage-level replication is already built in and very fast.

High-level cost drivers:

  • Compute – Instance-hours for provisioned DB instances, or Aurora Capacity Units (ACUs) for Aurora Serverless.
  • Storage – GB-month for database storage; some engines auto-grow up to a configured limit.
  • I/O and backups – Per-I/O charges for some engines, Aurora I/O, and GB-month for backup and snapshot storage.
  • Networking and availability – Cross-AZ and cross-region traffic for Multi-AZ, read replicas, and replication links.

Data transfer specifics to keep in mind:

  • Inter-region replication or client traffic is charged per GB with regional brackets (for example, sending data from us-east-1 to us-west-2 is roughly $0.02/GB—verify the latest rates on the pricing page).2
  • Data transfer between Availability Zones for DB cluster replication is free, so moving to Multi-AZ Aurora or RDS doesn’t add an inter-AZ replication fee.
  • Traffic between Aurora and EC2 instances in the same Availability Zone is free, which matters when co-locating application tiers with the database.

Exact prices depend on engine, region, instance family, storage type, and features, so always validate assumptions with the current RDS pricing pages rather than trusting outdated numbers.2

Major Cost Drivers

When you look at RDS and Aurora spend in Cost Explorer, the biggest line items are usually:

  • Over-provisioned compute – Instances or ACUs sized for peak that run at low utilization most of the time.
  • Storage growth – Application data, logs, and historical tables that accumulate in the primary volume.
  • High availability and replicas – Multi-AZ deployments and read replicas that duplicate compute.
  • Backups and snapshots – Long-retained automated backups and manual snapshots for large databases.
  • Cross-AZ / cross-region traffic – Replication and inter-AZ data flows for resilience and latency.
  • Extended Support charges – Per-vCPU fees for running older engine versions past their standard end-of-support date. Treat Extended Support as failure demand, not a normal operating mode; see RDS Extended Support for how to minimize reliance on it.

Key cost reduction strategies

  1. Right-size instances or Aurora capacity – Use utilization metrics to pick instance sizes or ACU baselines that match typical, not peak, load. See Right-size instances for a practical approach.
  2. Reserved Instances for steady workloads – For 24×7 production databases, use RDS Reserved Instances to commit to a baseline and get discounted instance pricing. AWS documentation states potential savings of up to 69% versus On-Demand when RIs are fully utilized over 3-year terms.3 See the dedicated page at RDS Reserved Instances for details, and consider switching to newer generations or Graviton first where supported.
  3. Align storage with access patterns – Move cold or archival data to cheaper storage (S3/Glacier) so primary volumes hold mostly hot data. See Optimize storage for storage type selection and cost control.
  4. Review Multi-AZ and replicas – Keep the replicas and standbys you really need and remove those created for temporary migrations or experiments.
  5. Scale down non-production – Use smaller instance types or stop dev/test/staging databases outside working hours where feasible.
  6. Evaluate newer generations and Graviton – AWS benchmarks for Graviton-based RDS instances show improved price-performance for many workloads, though the benefit varies by engine and workload characteristics. Always validate with your own load tests and Cost Explorer data.4 See Switch to Graviton for compatibility checks and a rollout checklist.
  7. Manage backup retention – Tune automated backup periods and prune manual snapshots to avoid paying for excessive backup storage. See Backups and snapshots for retention guidance.
  8. Avoid Extended Support – Plan engine upgrades proactively to avoid per-vCPU Extended Support fees for out-of-date versions. See RDS Extended Support for when and how to minimize reliance on it.

Resources

Footnotes

  1. Amazon RDS product page ↩

  2. Amazon RDS pricing ↩ ↩2

  3. Amazon RDS Reserved Instances ↩

  4. Leveling up Amazon RDS with AWS Graviton4 benchmarks ↩