Quick verdict
Choose Amazon RDS if you need Oracle, SQL Server, Db2 or MariaDB, if you want new community MySQL and PostgreSQL major versions soon after release, or if a single instance with a Multi-AZ standby covers your availability needs. Choose Amazon Aurora if you run MySQL or PostgreSQL and want up to 15 read replicas on shared storage, automatic storage growth, capacity that scales (including to zero) with Aurora Serverless v2, fast copy-on-write clones or a cross-Region Global Database. Aurora has more pricing choices to get right, notably Aurora Standard versus Aurora I/O-Optimized.
Amazon RDS (Relational Database Service) is AWS's managed service for standard database engines. The RDS User Guide lists six: IBM Db2, MariaDB, Microsoft SQL Server, MySQL, Oracle Database and PostgreSQL. Each DB instance stores its data on Amazon EBS volumes (General Purpose gp2/gp3 or Provisioned IOPS io1/io2 Block Express), and AWS handles backups, patching, failure detection and recovery. AWS describes RDS as its recommended default for most relational deployments.
Amazon Aurora is managed through the same RDS console and APIs, but it is a separate engine family: Aurora MySQL-Compatible Edition and Aurora PostgreSQL-Compatible Edition. Its defining difference is storage. The Aurora User Guide describes a single virtual cluster volume on SSDs, with copies of the data across three Availability Zones, shared by the writer and all reader instances in the cluster. Compute can be provisioned instances, Aurora Serverless v2 capacity, or a mix of both.
This page compares the two inside AWS. For Aurora MySQL against community MySQL, see Amazon Aurora vs MySQL; for choosing between clouds, see AWS RDS vs Google Cloud SQL.
Side by side
| Aspect | Amazon RDS | Amazon Aurora |
|---|---|---|
| Engines | Db2, MariaDB, SQL Server, MySQL, Oracle, PostgreSQL | MySQL-compatible and PostgreSQL-compatible only |
| Storage | EBS volumes per instance (gp2, gp3, io1, io2 Block Express); you allocate size; up to 64 TiB for MySQL, MariaDB, PostgreSQL and Db2 | Shared cluster volume across three AZs; grows automatically, up to 256 TiB on specific engine versions; billed for space used |
| High availability | Multi-AZ DB instance (one standby, not readable) or Multi-AZ DB cluster (two readable standbys) | Aurora Replicas in other AZs are promoted on failover; storage is already replicated |
| Read scaling | Read replicas use the engine's asynchronous replication; created manually, no replica autoscaling | Up to 15 Aurora Replicas reading the same cluster volume; reader endpoint balances connections |
| Serverless option | None; you can stop an instance for up to 7 days | Aurora Serverless v2: 0 to 256 ACUs, auto-pause at 0 ACUs on recent versions |
| Cross-Region | Cross-Region read replicas | Aurora Global Database: up to 10 secondary Regions |
| Cloning and rewind | Restore from snapshot or point in time to a new instance | Copy-on-write clones; Backtrack (Aurora MySQL only, up to 72 hours) |
| New community versions | PostgreSQL majors within 30 days of the first minor; MySQL LTS majors within 6 months | PostgreSQL majors within 8 months; MySQL LTS majors within 12 months |
| Pricing model | Instance hours plus allocated storage (and provisioned IOPS/throughput) | Instance or ACU hours plus storage used, plus I/O requests on Aurora Standard (none on I/O-Optimized) |
| Main trade-off | Widest engine choice and newest versions, but storage and replicas are per instance | Shared storage, fast replicas and serverless, but only two engines and a later version cadence |
Key differences
Storage architecture: EBS volumes versus a shared cluster volume
An RDS DB instance owns its storage. The RDS storage documentation describes EBS volumes in two families, Provisioned IOPS SSD (io1 and io2 Block Express) and General Purpose SSD (gp2 and gp3), with Db2, MySQL, MariaDB and PostgreSQL instances up to 64 TiB, and Oracle and SQL Server up to 256 TiB when you attach additional storage volumes. You choose the size and, on gp3 and Provisioned IOPS, the performance; storage autoscaling can raise the allocation, and you pay for what is allocated. Magnetic storage is deprecated, and from 1 July 2026 snapshots can no longer be restored to it.
Aurora separates compute from storage. Per the Aurora User Guide, data lives in a cluster volume with copies across three Availability Zones (the Serverless v2 page describes six copies across three AZs), and "the amount of replication is independent of the number of DB instances in your cluster". Adding a reader does not copy table data; it attaches to the volume that already holds it. The volume grows automatically, can reach 256 TiB on specific engine versions, and on current versions shrinks again when you drop tables, so you are billed for space used rather than space allocated. Temporary files and sorts use separate local storage on each instance, so local storage limits still apply to large temporary tables.
Replicas and failover
RDS offers two Multi-AZ shapes. A Multi-AZ DB instance deployment has one synchronous standby that provides failover but does not serve reads. A Multi-AZ DB cluster deployment has a writer and two reader instances in three AZs that can serve read traffic. Separate read replicas use each engine's native asynchronous replication, can be in other Regions, are billed as normal instances and must be added or removed by hand; AWS states that RDS does not autoscale read replicas.
In Aurora, every additional instance in a cluster is an Aurora Replica reading the shared volume. A cluster can have up to 15, and AWS documents replica lag as "usually much less than 100 milliseconds" after a write, rising with heavy write activity. If the writer fails, Aurora promotes a replica, with a brief interruption during which requests fail; AWS notes that promotion is much faster than recreating the primary, and that a cluster without replicas is unavailable while the instance recovers. For multi-Region needs, Aurora Global Database adds up to 10 read-only secondary Regions, replicated through the storage layer with latency AWS describes as typically under a second.
Aurora Serverless v2 and idle databases
RDS has no serverless mode: you pick an instance class and resize it. For idle development databases you can stop an instance for up to 7 consecutive days, after which RDS starts it automatically; storage and backups are still charged while it is stopped, and AWS warns that starting can take from minutes to hours.
Aurora Serverless v2 measures capacity in Aurora capacity units (ACUs), each about 2 GiB of memory with corresponding CPU and networking. You set a range per cluster, from 0 to 256 ACUs on current versions, and capacity changes in increments as small as 0.5 ACU while connections and transactions stay open. A minimum of 0 ACUs enables auto-pause (Aurora MySQL 3.08 and higher; Aurora PostgreSQL 16.3, 15.7, 14.12, 13.15 and higher). AWS documents a typical resume time of about 15 seconds, and 30 seconds or longer if the instance has been paused for more than 24 hours. Auto-pause does not happen while RDS Proxy is attached, on the primary of a Global Database, or while logical or binlog replication is enabled on the writer.
Aurora Standard versus Aurora I/O-Optimized
Aurora has two cluster storage configurations. Aurora Standard charges for instances, storage and a rate per million read and write I/O requests. Aurora I/O-Optimized charges no I/O at all, in exchange for higher storage and compute rates. AWS's own guidance is that I/O-Optimized is the better choice when I/O spending is 25% or more of total Aurora spending. You can move from Standard to I/O-Optimized once every 30 days and back at any time; switching is online for non-NVMe instances but needs an engine restart on NVMe-based instances.
RDS has no per-request I/O charge on gp2 or gp3, but you pay for provisioned IOPS and throughput above the gp3 baseline whether or not you use them. In our assessment, RDS bills are easier to predict, while Aurora rewards measuring your actual I/O before choosing a configuration.
Engine versions: Aurora follows later
Both services publish version currency timelines. RDS for PostgreSQL targets new major versions within 30 days of the community's first minor release and minors within 7 days; Aurora PostgreSQL targets majors within 8 months and minors within 3 months. In practice, PostgreSQL 18 reached RDS on 14 November 2025 and Aurora on 11 June 2026. On the MySQL side, RDS for MySQL added 8.4 on 21 November 2024, while Aurora MySQL 8.4 arrived with 8.4.7 on 21 May 2026.
Aurora offers long-term support (LTS) minor versions for teams that want to stay on one minor for longer, and both services offer paid RDS Extended Support after a major version leaves standard support. If you need a new community feature soon after release, RDS is usually first.
Aurora-only features, and Aurora DSQL
Because of the shared volume, Aurora can create clones with a copy-on-write protocol: a clone initially shares pages with its source and only stores pages that change, with up to 15 copy-on-write clones before further clones become full copies. Aurora MySQL also has Backtrack, which rewinds a cluster to an earlier time without a restore, within a window of up to 72 hours; it must be enabled when the cluster is created and is not available for Aurora PostgreSQL.
Amazon Aurora DSQL, generally available since 27 May 2025, is a different product despite the name: AWS describes it as a serverless, distributed, PostgreSQL-compatible database with an active-active multi-Region architecture. It is not a storage option for an Aurora cluster; evaluate it separately if you need multi-Region writes.
Pricing and licensing
Amazon RDS. The RDS pricing pages describe On-Demand instances billed per instance-hour (per-second increments with a 10-minute minimum) and Reserved Instances on 1- or 3-year terms. Storage is billed per GB-month of allocated storage, by type; Provisioned IOPS are charged whether used or not; backup storage and data transfer are extra. Multi-AZ deployments run additional standby instances. Prices vary by engine, instance class and Region, so use the AWS Pricing Calculator for a real estimate. Some engines and micro instance classes are eligible for the AWS Free Tier, with Single-AZ only.
Amazon Aurora. Listed on the Aurora pricing page in October 2026 for US East (N. Virginia), in USD: Aurora Standard storage 0.10 USD per GB-month plus 0.20 USD per million I/O requests; Aurora I/O-Optimized storage 0.225 USD per GB-month with no I/O charges. Aurora Serverless v2 is billed per ACU-hour, measured per second: 0.12 USD on Aurora Standard and 0.156 USD on I/O-Optimized. Provisioned instances are billed per instance-hour by class, plus backup storage, data transfer and optional features such as Backtrack and Global Database replication.
AWS states on the pricing page that customers whose I/O spend exceeds 25% of their Aurora bill can save "up to 40%" with I/O-Optimized; that is a vendor claim, not our calculation. Because Aurora storage is billed on use and replicas share it, the comparison with RDS depends on how many replicas you run and how I/O-heavy the workload is.
Pricing checked on the vendors' official pages on 7 October 2026. Prices change; confirm before buying.
Where each one leads
Amazon RDS strengths
- Six engines, including Oracle, SQL Server, Db2 and MariaDB
- New community MySQL and PostgreSQL versions usually arrive sooner than on Aurora
- Simple model: instance plus allocated storage, no per-request I/O charges
- Multi-AZ DB cluster option (on supported engines) gives two readable standbys
- Instances can be stopped for up to 7 days to save compute costs
Amazon Aurora strengths
- Shared cluster volume replicated across three AZs, independent of instance count
- Up to 15 low-lag Aurora Replicas that act as failover targets
- Aurora Serverless v2 scales in 0.5 ACU steps and can pause at 0 ACUs
- Copy-on-write clones, Global Database and (for MySQL) Backtrack
- Storage grows automatically and is billed on space used
Limitations
Amazon RDS limitations
- Read replicas copy data asynchronously and must be added or removed by hand
- No serverless or scale-to-zero option; stopped instances restart after 7 days
- You size and pay for allocated storage and provisioned IOPS in advance
- Multi-AZ DB instance standbys cannot serve reads
Amazon Aurora limitations
- Only MySQL- and PostgreSQL-compatible engines
- New major versions arrive months after RDS (PostgreSQL 18 about seven months later)
- Pricing has more moving parts: I/O charges on Standard, configuration switches limited to once every 30 days
- Aurora-specific features (Backtrack, clones, Global Database) do not exist outside AWS
- Auto-paused Serverless v2 instances take about 15 seconds or more to resume
When to choose each
Choose Amazon RDS if
- You need Oracle, SQL Server, Db2 or MariaDB as a managed service
- You want the newest PostgreSQL or MySQL major version soon after release
- A single primary with a Multi-AZ standby meets your availability target
- You want predictable bills without per-request I/O charges
Choose Amazon Aurora if
- You run MySQL or PostgreSQL and need several read replicas with low lag
- Load is spiky or idle for long periods and Serverless v2 capacity fits
- You want fast copy-on-write clones of production for testing
- You need cross-Region disaster recovery with Aurora Global Database
- Storage growth is hard to predict and you prefer paying for what is used
When neither is right
- You want branch-per-pull-request Postgres with data, and scale to zero as the default: see Neon vs AWS RDS.
- You are choosing between clouds rather than within AWS: see AWS RDS vs Google Cloud SQL or Google Cloud SQL vs AlloyDB.
- You need multi-Region active-active writes: look at Amazon Aurora DSQL, a separate PostgreSQL-compatible distributed service.
- You have not yet chosen an engine: start with MySQL vs PostgreSQL.
Final recommendation
For most MySQL and PostgreSQL workloads on AWS, both services are sound choices, and the deciding factors are practical. Amazon RDS is the simpler and broader option: more engines, faster access to new versions and a pricing model that is easy to forecast. Amazon Aurora earns its extra complexity when you need several replicas, serverless capacity, fast clones or cross-Region failover, because its shared storage makes those features native. Measure your I/O before choosing between Aurora Standard and I/O-Optimized, and check that the engine version you need is available on Aurora before committing.
Frequently asked questions
Is Amazon Aurora part of Amazon RDS?
Aurora is managed through the same RDS console, CLI and API, and AWS documents it in a separate Aurora User Guide. It is its own engine family (MySQL-compatible and PostgreSQL-compatible) with a different, shared storage architecture, and it is priced separately.
Is Aurora always faster than RDS?
AWS markets Aurora with performance claims, but we have not tested either service and do not repeat those figures. Performance depends on instance class, storage configuration, workload and tuning; benchmark your own workload on both before deciding.
Can Aurora scale to zero?
Yes, with Aurora Serverless v2 on supported versions (Aurora MySQL 3.08 and higher; Aurora PostgreSQL 16.3, 15.7, 14.12, 13.15 and higher). Setting the minimum capacity to 0 ACUs enables auto-pause after an idle interval of 5 minutes to 1 day. AWS documents a typical resume of about 15 seconds. Storage is still charged while paused.
When should I use Aurora I/O-Optimized?
AWS recommends Aurora I/O-Optimized when I/O charges are 25% or more of your total Aurora spend, and Aurora Standard below that. Check the I/O line on your bill or in Cost Explorer first. You can switch to I/O-Optimized once every 30 days and switch back at any time.
How do I move from RDS to Aurora?
For MySQL and PostgreSQL, AWS documents creating an Aurora read replica of an RDS instance, then promoting it once replication has caught up; for MySQL, AWS also documents migrating directly from an RDS snapshot. Test the target engine version first, because Aurora may not yet offer the latest minor you run on RDS.
What is Aurora DSQL?
Amazon Aurora DSQL, generally available since May 2025, is a serverless, distributed, PostgreSQL-compatible database with active-active multi-Region support. It is a separate service from Aurora PostgreSQL clusters rather than a configuration of them.
Sources
- Amazon RDS User Guide: What is Amazon RDS
- Amazon RDS User Guide: DB instance storage
- Amazon RDS User Guide: Multi-AZ deployments
- Amazon RDS User Guide: Read replicas
- Aurora User Guide: Amazon Aurora storage
- Aurora User Guide: Replication with Aurora
- Aurora User Guide: How Aurora Serverless works
- Aurora User Guide: Auto-pause for Aurora Serverless
- Aurora PostgreSQL release calendar
- RDS for PostgreSQL release calendar
- Amazon Aurora pricing
- Amazon RDS for PostgreSQL pricing
- AWS: Amazon Aurora DSQL is generally available (May 2025)
Checked October 2026.
How we research comparisons: our editorial method.