What is Amazon Aurora in AWS: RDS Grown Up, When Plain RDS Wins

Amazon Aurora is AWS’s high-performance relational database — a fully managed engine compatible with MySQL and PostgreSQL that delivers up to 6x the throughput of the stock databases on similar hardware. But the thing that makes it “RDS grown up” is not speed; it is a counterintuitive architectural choice: Aurora separates storage from compute entirely. Your data lives as a distributed cluster volume — six copies across three Availability Zones — independent of any server, and the database instances that process it are stateless windows into that storage. That one decision is why Aurora’s read replicas have essentially no replication lag, why failover happens in seconds, why storage grows to 256 TiB without provisioning, and why a Global Database can span continents. It is also why Aurora costs more per hour — which is exactly where plain RDS still wins, and this guide covers both sides honestly.

Every database decision is really two decisions stacked: which engine (PostgreSQL or MySQL or something else), and how much operational pain you are willing to absorb to run it. Plain RDS answered the second question by managing the server for you — patching, backup, failover detection. Aurora goes a step further and redesigns the storage itself so that the hardest parts of database administration (replication, failover, storage scaling, cross-Region copies) stop being your problem at the architectural level. The trade is money: Aurora instances cost more per hour than equivalent RDS instances, and whether that premium ever pays back depends entirely on your workload. This page gives you the full picture, both directions.

Jake’s developer friend is back — the one who built the login for the repair-shop portal. The portal needs a database now: repair tickets, customer records, status history. The friend said “RDS Postgres, obviously” and then opened the console and saw the dropdown: RDS for PostgreSQL, Aurora PostgreSQL, Aurora Serverless, Aurora DSQL. Four options that all say “PostgreSQL” somewhere in the name. He called Jake to ask which one, Jake called Ethan, and the question turned out to have a genuinely interesting answer — because the right choice for a repair shop with three hundred customers is not the right choice for a bank, and the reason is architecture, not marketing tiers.

What Amazon Aurora Actually Is

Amazon Aurora is a fully managed relational database engine compatible with MySQL and PostgreSQL. The word compatible is doing real work in that sentence: the code, tools, and applications you use today with your existing MySQL and PostgreSQL databases work with Aurora — your ORM, your psql client, your SQL queries. Underneath that familiar interface, the storage and replication layers are rebuilt from the ground up for cloud-scale, which is where the performance and resilience gains come from: up to 6x the throughput of stock PostgreSQL and up to 6x stock MySQL on similar hardware.

Aurora is part of the managed database service Amazon RDS — the same console, the same AWS CLI commands, the same API operations for provisioning, patching, backup, recovery, failure detection, and repair. If you have used RDS, you already know how to operate Aurora. The management model differs in one key way: Aurora operations work on entire clusters of database servers synchronized through replication, instead of individual database instances. The cluster is the unit; the instances inside it are interchangeable parts.

Migration from RDS to Aurora is a first-class path: you can bring data from RDS for MySQL and RDS for PostgreSQL into Aurora by snapshot-and-restore, or by setting up one-way replication, or by using push-button migration tools. The path back is less traveled, which is worth knowing before you choose.

The Architecture: Why Storage and Compute Split Up

Traditional databases — including the ones RDS runs — treat the database server as the unit of truth. The data lives on disks attached to that server; replicas are separate servers that receive a stream of changes from the primary; failover means promoting a replica and waiting for it to catch up. This works, but every hard problem in database administration (replication lag, failover time, storage provisioning, cross-Region copies) traces back to the same root: the data is attached to a specific server.

Aurora cuts that root. The storage layer is a distributed service in its own right: a cluster volume that holds your data as six copies across three Availability Zones, managed entirely by the service. The database instances — the compute — are stateless readers and writers into that volume. When a write happens, it goes to the storage layer, which persists it across those six copies; every instance in the cluster sees the same data at the same logical point. There is no “replication lag” to monitor because the replicas are not copying from the primary — they are all reading from the same shared volume.

Three consequences follow directly from that arrangement:

• Storage grows automatically — up to a maximum of 256 TiB per cluster volume. You never provision storage, and you never resize it. Older engine versions cap at 128 TiB, so check your version before planning a very large dataset.
• Failover is fast — because the storage volume is already multi-AZ and the instances are stateless, promoting a new primary is a metadata operation, not a data-recovery operation. Aurora also repairs failed segments of the cluster volume continuously and transparently, using the remaining healthy copies.
• Read replicas are cheap and instant — adding a replica means adding another compute instance pointed at the existing volume, not copying data. Aurora supports multiple read replicas per cluster, and a reader endpoint load-balances traffic across them automatically.

“Wait — if the replicas all read from the same volume, how is that not just one database with extra connections?” Jake asked.

“Because the writes still go through one primary instance at a time,” Ethan said. “The volume is shared, but write coordination is not — a single writer maintains ordering, and that writer can change in seconds when failover happens. The replicas serve reads from the shared volume without adding write contention. It is the same split a restaurant makes: one kitchen coordinates the cooking, but every waiter can see the same order board.”

Aurora vs RDS: The Real Differences

Both services are fully managed, both support encryption at rest and in transit, IAM integration, automatic backups, Multi-AZ deployment, and read replicas. Both remove the operational burden of patching, backup, failover, and scaling. The difference is scope: RDS provides fully managed database engines — MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, and Db2 — optimized for total cost of ownership; Aurora redesigns the underlying storage and replication layer for cloud-native performance and resilience, on MySQL and PostgreSQL compatibility. If you want the deeper tour of the RDS side, our RDS guide covers the managed-database model from the ground up.

One more architecture detail worth knowing because it explains where the throughput gain comes from: Aurora moves the logging and replication work into the distributed storage layer. A traditional database writes each change to a log, then to the data files, then replicates the log to followers — three passes over the same change. Aurora’s instances write only the log records to the storage layer, and the storage subsystem applies them to the data pages in the background, across all six copies, in parallel. Fewer round-trips per transaction is the quiet source of the “up to 6x” figure — and also why the exact speedup depends on your write pattern, not just your hardware.

When Plain RDS Wins: The Honest Counter-Argument

Aurora is the better architecture. That does not make it the better choice, and this section exists because the title promised it. Here are the five cases where plain RDS is the right answer:

1. You need an engine Aurora does not offer. Oracle, SQL Server, MariaDB, and Db2 exist on RDS and only on RDS. If your application is built on SQL Server stored procedures or an Oracle schema, Aurora is not in the conversation.
2. Your workload is small and steady. Aurora’s per-hour instance premium buys instant failover, multiple replicas, 256 TiB, and global replication. A repair-shop portal with three hundred users will use none of those today, or in five years. The premium is the same either way.
3. You need a feature from community PostgreSQL or MySQL that Aurora’s customization replaces. Aurora uses customized engines, and a small number of community extensions and features behave differently or are unavailable. The compatibility is high but not identical — the comparison pages for each engine version list the differences, and a niche extension on that list can decide the whole question.
4. You want the simplest possible mental model. One RDS instance is a box you connect to. An Aurora cluster is a writer, a reader endpoint, a cluster volume, and a set of instances — and every one of those words is a concept you now carry. For a first database, RDS teaches less vocabulary.
5. Your I/O bill is light and your instance bill is what matters. Aurora’s I/O-Optimized pricing removes per-request I/O charges by raising instance and storage rates — a trade that wins for I/O-heavy workloads and loses for I/O-light ones. A read-mostly small app may be cheaper on plain RDS before Aurora’s features even enter the conversation.

“PostgreSQL-Compatible” and “MySQL-Compatible”: What Those Words Actually Mean

Aurora does not run the stock community editions of PostgreSQL and MySQL. It runs customized engines built to take advantage of the fast distributed storage — and the compatibility promise is that your application does not notice. Your SQL works, your drivers work, your tools work. The engine version numbers track the community releases (Aurora MySQL version 3 is compatible with MySQL 8.0; version 8.4 tracks MySQL 8.4), with the differences documented in per-version comparison pages.

The compatibility has practical edges worth knowing. On the MySQL side, Aurora adds features the community edition lacks — backtracking (rewinding the cluster to an earlier point in time without restoring from a backup), Fast DDL for instant schema changes on large tables, and enhanced binlog replication. On the PostgreSQL side, Aurora supports a curated set of extensions including pgAudit for audit logging, pglogical for logical replication, and Trusted Language Extensions for building your own — plus performance features like parallel query and Optimized Reads that use the local storage on certain instance classes for faster scans.

What compatibility does not mean: Aurora PostgreSQL is not “PostgreSQL with a different logo.” The engine is modified, some parameters behave differently, and a handful of community features are replaced by Aurora-specific implementations. The comparison pages between each Aurora version and its community counterpart exist precisely because the differences are real, and a niche dependency on the wrong side of the list is a valid reason to stay on plain RDS.

Aurora Serverless v2: Scaling That Feels Invisible

Aurora Serverless v2 is not a separate deployment model — it is a scaling mode for regular Aurora clusters. Instead of choosing a fixed instance size, you set a capacity range in ACUs (Aurora Capacity Units), and the cluster adjusts capacity in fine-grained increments as the workload changes, automatically. A development database can sit near the floor all afternoon, then handle a build’s worth of queries in a burst, then drop back — without anyone resizing anything.

The use cases the documentation names as ideal: variable workloads with sudden unpredictable increases (a traffic site that spikes when it starts raining, an e-commerce site during promotions), new applications where you cannot predict the load, and development and test environments that should cost nothing when nobody is using them. With auto-pause, the database can scale to 0 ACUs and resume on the next connection — which is about as close to “a database that costs nothing while idle” as a full SQL engine gets.

One companion feature worth knowing: the RDS Data API — a HTTP endpoint that lets you query the database without managing connection pools, connections, or drivers. It pairs naturally with serverless compute like Lambda, where opening a database connection per invocation is the classic bottleneck. If your app is event-driven (API Gateway → Lambda → database), Serverless v2 plus the Data API is the pattern the pieces were designed for.

Aurora Global Database: One Database, Many Regions

Aurora Global Database extends the cluster across AWS Regions: one primary Region where writes land, and secondary Regions with their own local read clusters, replicated with low latency. Your users in Singapore read from Singapore; your users in Virginia read from Virginia; your writes go to one place and appear everywhere almost instantly.

The disaster-recovery angle is the quieter selling point: if the primary Region has a problem, you can promote a secondary Region to take over — and because the secondary Regions already have full copies of the data with their own clusters running, the promotion is fast. A headless secondary (a secondary cluster without instances) can keep a warm data copy in a Region for disaster recovery at compute-free cost. Aurora is positioned for up to 99.999% multi-Region availability, and Global Database is the feature that earns that number.

Write forwarding closes the loop: a secondary Region can forward writes back to the primary, so an application deployed in multiple Regions can treat its nearest Aurora cluster as its database — reads local, writes forwarded — and the consistency behavior is configurable. For a repair shop this is irrelevant; for an app with users on three continents, it is the difference between a database and a geography lesson.

Aurora DSQL and Aurora Limitless: The New Frontier

Two newer entries in the Aurora family deserve their own section because they answer the question the original cluster model cannot: what happens when one database is genuinely not enough?

Aurora DSQL is a serverless distributed SQL database — PostgreSQL-compatible, with active-active architecture across Regions, designed for 99.99% single-Region and 99.999% multi-Region availability. The pitch: virtually unlimited scale without database sharding or instance upgrades, zero infrastructure management, no patching or maintenance downtime. Where Aurora’s cluster model still has a primary writer, DSQL aims for distributed writes that scale horizontally. It is the newest member of the family and the one to watch for workloads that outgrow even Aurora’s single-writer ceiling.

Aurora PostgreSQL Limitless Database takes the sharding path instead: a standard Aurora cluster with a DB shard group — multiple shard instances plus routers that present the shards as a single logical database. You create limitless tables that the system distributes across shards, and ordinary SQL keeps working. The target workload: relational data whose write throughput or storage exceeds what a single Aurora instance can deliver, while the application still wants to see one database. You can add shards, split a shard, and add routers as capacity grows — the scaling knobs the classic cluster model does not have.

The honest framing for both: they exist for the top of the scale curve, not the middle. A repair-shop portal needs neither. A fintech that outgrew its Aurora cluster’s write ceiling yesterday needs one of them, and the choice between distributed-SQL (DSQL) and sharded-relational (Limitless) is an architecture conversation with your team, not a checkbox in a blog post.

The Pricing Decision: Standard vs I/O-Optimized

Aurora bills four things: instance hours (per ACU or per instance class), storage per GB-month, I/O requests, and backup storage beyond the free allocation. The pricing decision that catches everyone is the Standard vs I/O-Optimized choice, because it changes what you pay for fundamentally:

The rule of thumb: if your monthly I/O bill would exceed the instance and storage premium, I/O-Optimized saves money; if not, Standard does. The decision hinges on your workload’s ratio of I/O operations to instance-hours, and you can switch between the two modes — so the choice is not permanent, but it is not free to flip casually either.

On the shared-responsibility side, the split is clean: AWS handles the infrastructure, the patching, the storage, the failover; you handle query tuning — the work of adjusting SQL and indexes to your data and workload, which Performance Insights and CloudWatch metrics are there to help you see. No managed database service tunes your queries for you; that is the part that stays yours, and CloudWatch is the standard window into what the database is actually doing.

Aurora vs DynamoDB vs Redshift: Which Database, Actually

The “which AWS database” question deserves its own decision table, because Aurora, DynamoDB, and Redshift are not competitors — they are three different answers to three different questions:

Jake’s repair portal lands squarely in Aurora-or-RDS territory (relational data, SQL queries, a schema that joins customers to tickets to history), and the first-project walkthrough on this site shows the DynamoDB path for the workloads where it fits. The interesting hybrid: Aurora’s zero-ETL integration with Redshift lets transactional data flow into analytics automatically — worth knowing exists, because it removes the ETL pipeline that used to be the tax for wanting both. And S3 remains the fourth member of this conversation for anything that is files rather than queries.

Creating Your First Aurora Cluster in the Console

Aurora lives in the RDS console — the same console you would use for plain RDS, which is the point: the management surface is shared. The guided flow:

1. Open the RDS console and choose Create database. Select Amazon Aurora as the engine type, then choose Aurora PostgreSQL or Aurora MySQL and the version. The version picker lists compatibility targets — “compatible with PostgreSQL 16,” “compatible with MySQL 8.0” — so you can match whatever your application already runs.
2. Choose the capacity type: Provisioned (fixed instance classes) or Serverless v2 (an ACU range that scales). For a first cluster with unknown traffic, Serverless v2 with a low minimum and a modest maximum is the forgiving choice; for steady production, provisioned is the predictable one.
3. Set the cluster configuration: DB cluster identifier, master credentials, and the network (VPC and subnet group). Aurora requires a VPC — this is not optional — and the default VPC works for a first cluster.
4. Choose Standard or I/O-Optimized pricing. For a first database with light traffic, Standard is the lower-risk start; you can switch to I/O-Optimized later if the I/O line on the bill grows.
5. Review and create. The cluster provisions a writer instance first; you can add read replicas from the cluster’s actions menu afterward. The connection strings you will use are the writer endpoint (for writes) and the reader endpoint (load-balanced across replicas) — connect to endpoints, not to instances, and failover stays invisible to your application.

The deeper tutorial territory — custom parameters, IAM database authentication, Performance Insights, RDS Proxy for connection pooling — lives in the Aurora User Guide, and the full series from first S3 bucket to working project is at the free AWS learning hub. The relevant order for a first full app: S3 → IAM → RDS or Aurora → Lambda → API Gateway → then the security services once something is worth guarding.

When It Breaks: the Honest Failure Modes

Aurora failure modes are quieter than most — the architecture absorbs the dramatic ones — but the quiet ones still bite:

And the when-nothing-works paragraph: if the cluster is unreachable and the console shows no events, the VPC is the first suspect — security groups, subnet routes, and network ACLs stop more database connections than any database setting ever has. CloudWatch’s cluster-level metrics (volume read/write latency, replica lag, database connections) tell you whether the storage layer is healthy, which with Aurora’s architecture it almost always is; the problem is nearly always on the network or the application side. AWS re:Post is the community for the cases the metrics do not explain, and Performance Insights is the tool that names the specific query causing the pain.

Frequently Asked Questions

What is Amazon Aurora used for?

Aurora is used for relational workloads that need more than a single database server can deliver — high-throughput applications, read-heavy workloads needing many replicas, databases that must survive a datacenter failure with seconds of downtime, and applications serving users across multiple Regions. It is MySQL- and PostgreSQL-compatible, so existing applications work without modification.

Is Amazon Aurora the same as RDS?

No, but they are related. Aurora is part of the RDS family — the same console, CLI, and API — but it redesigns the storage and replication layer underneath the engine. RDS manages database instances; Aurora manages clusters of instances sharing a distributed storage volume with six copies across three Availability Zones.

What's the difference between Aurora and RDS?

The core difference is the storage architecture. RDS attaches storage to each instance and replicates by copying from the primary; Aurora separates storage into a distributed service that all instances share. That gives Aurora faster failover, no replica lag, automatic storage growth to 256 TiB, and multiple replicas — at a higher per-hour cost. RDS offers more engine choices (Oracle, SQL Server, MariaDB, Db2) and a lower baseline price.

Does Amazon Aurora support PostgreSQL?

Yes — Aurora PostgreSQL is a fully managed, PostgreSQL-compatible engine. Your existing SQL, drivers, and tools work. The engine is customized to take advantage of Aurora’s distributed storage, and version-by-version comparison pages document the differences from community PostgreSQL.

Does Amazon Aurora support MySQL?

Yes — Aurora MySQL is fully MySQL-compatible, tracking community versions (version 3 is compatible with MySQL 8.0, version 8.4 with MySQL 8.4). Aurora MySQL also adds features the community edition lacks, like backtracking (rewinding the cluster without restoring a backup) and Fast DDL.

What is Aurora Serverless v2?

A scaling mode for Aurora clusters where you set a capacity range in ACUs (Aurora Capacity Units) and the database adjusts automatically in fine-grained increments. It can scale to 0 ACUs with auto-pause for dev and test, handle variable workloads with sudden spikes, and scale back down when the surge ends — all within a standard Aurora cluster, not a separate deployment model.

What is Aurora Global Database?

An Aurora feature that extends a cluster across AWS Regions: one primary Region for writes, secondary Regions with local read clusters, replicated with low latency. It serves local reads globally, supports fast cross-Region disaster recovery, and is the feature behind Aurora’s 99.999% multi-Region availability positioning.

What is Aurora DSQL?

Aurora DSQL is a serverless distributed SQL database — PostgreSQL-compatible, with active-active architecture designed for 99.99% single-Region and 99.999% multi-Region availability. It aims for virtually unlimited scale without sharding or instance upgrades, and removes the operational burden of patching and maintenance. It is the newest member of the Aurora family, built for workloads that outgrow a single-writer cluster.

How much does Amazon Aurora cost?

Aurora bills instance hours, storage per GB-month, I/O requests, and backup storage. On Standard pricing, you pay per million I/O requests; on I/O-Optimized, I/O is free but instance and storage rates are higher. I/O-Optimized wins for I/O-heavy workloads; Standard wins for I/O-light ones. Aurora instances also cost more per hour than equivalent RDS instances — that premium is the architecture.

Is Amazon Aurora free?

Not in the traditional free-tier sense. Since March 2026, Aurora PostgreSQL is on the AWS Free Tier through the credits model — $100 in credits at sign-up, up to $100 more for activating foundational services — and on the free plan, AWS stops resources when credits run out rather than charging. An idle Aurora cluster on a paid plan, however, bills instance hours continuously.

When should I use plain RDS instead of Aurora?

Five honest cases: you need Oracle, SQL Server, MariaDB, or Db2 (Aurora does not offer them); your workload is small and steady (the premium buys features you will never use); you depend on a community feature Aurora’s customized engine replaces; you want the simplest mental model for a first database; or your I/O-light workload makes Aurora’s higher instance rates a pure loss.

Is Amazon Aurora a relational database?

Yes. Aurora is a relational database engine — SQL queries, joins, transactions, schemas — compatible with MySQL and PostgreSQL. It is not NoSQL; for key-value and document patterns, DynamoDB is the AWS service designed for that job.

Does Aurora support Oracle or SQL Server?

No. Aurora is compatible with MySQL and PostgreSQL only (plus the new DSQL, which is PostgreSQL-compatible). Oracle and SQL Server are available on plain RDS. If your application is built on either engine, Aurora is not in the conversation — RDS is the managed option.

What is the I/O-Optimized pricing option?

A billing mode that removes all I/O charges in exchange for higher instance and storage rates. It wins for I/O-heavy workloads where the I/O savings exceed the rate premium, loses for I/O-light ones, and is switchable between modes. The decision rule: if your monthly I/O bill would exceed the premium, switch.

Is Amazon Aurora NoSQL?

No. Aurora is a relational (SQL) database — it runs SQL, supports joins and transactions, and follows the PostgreSQL and MySQL data models. AWS’s NoSQL offering is DynamoDB, which is key-value and document-based. They solve different problems: Aurora for relational workloads, DynamoDB for access-pattern-driven scale.

What is Aurora Limitless Database?

Aurora PostgreSQL Limitless Database adds horizontal sharding to Aurora: a DB shard group (multiple shard instances plus routers) presents many shards as one logical database, with limitless tables that the system distributes automatically. It targets relational workloads whose write throughput or storage exceeds a single Aurora instance, while the application still sees one database.

👉 Also Read:

1. 🪣 What Is Amazon S3? — cloud storage, the service everything else leans on.
2. 💻 What Is Amazon EC2? — renting computers by the hour: the heart of the cloud.
3. 💽 What Is Amazon EBS? — the "hard drive" your cloud computer uses, and why it is not inside it.
4. 🔐 What Is AWAS IAM? — who may touch what: the permissions layer that keeps you safe.
5. 💰 AWS Billing in Plain English — the money post: free plan, budgets, and the traps.
6. ⚡ What Is AWS Lambda? — serverless: code that runs without any computer to manage.
7. 🗄️ What Is Amazon DynamoDB? — the serverless database: instant answers at any size, pennies a month.
8. 🚪 What Is Amazon API Gateway? — the front door: routes, sign-in checks, the 29-second rule, and the 3.5× pricing trap.
9. 📬 What Is Amazon SQS? — the waiting line: receive-process-delete, the visibility timeout, and why duplicate delivery is a feature your code must survive.
10. 📢 What Is Amazon SNS? — the broadcaster: one event, many listeners, and why a delivery to nobody still counts as success.
11. Full series on this for beginners

Revision note. Written September 2026. AWS iterates the Aurora family quickly — DSQL and Limitless are both young and their feature sets will move. If you have been putting off the RDS-vs-Aurora decision because it felt like an architecture exam, take heart: the honest answer for most first databases is plain RDS, the honest answer for most growing ones is Aurora, and the migration path between them is a snapshot — start simple, and let the workload tell you when it has grown up.