What is Amazon Aurora? A plain-English explainer

Aurora is an RDS engine, not a separate service

Our what-is-amazon-rds explainer covers Amazon RDS itself: a managed service that takes care of the operational work of running a relational database — patching, backups, replication, failover — across a choice of engines. Aurora is one of those engine choices, alongside standard MySQL, PostgreSQL, and others.

That means Aurora inherits everything RDS handles for you operationally — you still work with it through RDS the same way you would any other RDS engine — but the engine itself, the software actually storing and serving your data, is AWS’s own cloud-native build rather than an off-the-shelf MySQL or PostgreSQL install.

What makes Aurora different from a standard engine

Standard MySQL or PostgreSQL was designed for on-premises hardware and adapted to run in the cloud. Aurora was designed for the cloud from the start, with a storage layer that separates compute from storage and replicates data across multiple locations automatically, which is what gives it its higher performance and availability characteristics compared with the standard engines running the equivalent workload.

From an application’s point of view, though, Aurora still speaks MySQL or PostgreSQL — you connect and query it the same way. The difference is under the bonnet, in how the database stores, replicates and recovers data, not in the interface your code talks to.

Relational, not NoSQL

Aurora is a relational database — structured tables, rows and columns, related by keys and queried with SQL — the same model as any MySQL or PostgreSQL database. Our relational-vs-nosql-databases explainer covers that distinction and where a document or key-value store like DynamoDB would be the better fit instead. Choosing Aurora is a choice of relational database engine, not a choice between relational and NoSQL.

When you would choose Aurora

Aurora suits applications already built around MySQL or PostgreSQL that want higher performance and availability than the standard engine delivers, without giving up SQL compatibility or rewriting application code. It is a reasonable default choice within RDS for new relational workloads on AWS for the same reason.

It is less necessary for small, low-traffic databases where the standard engine’s performance and availability are already more than sufficient, or where minimising cost is the overriding concern — Aurora’s cloud-native architecture is built to justify itself at higher-demand workloads.

How Aurora fits alongside other managed databases

Aurora is AWS’s own take on a managed relational database, sitting inside the broader category covered by RDS. Azure and Google Cloud offer their own managed relational database services too — Azure SQL Database and Google Cloud SQL — though neither is a direct architectural equivalent to Aurora specifically; Aurora’s distinguishing feature is that cloud-native storage layer, built by AWS rather than adapted from an existing engine.

Pricing model, and where Aurora appears in certification study

Aurora is billed on a consumption basis through RDS — pay for the compute and storage the database actually uses, rather than a flat licence. Exact rates and options change, so treat that as the model rather than a figure and check AWS’s own pricing page for current numbers.

Aurora appears in the Solutions Architect Associate and Developer Associate exams as AWS’s cloud-native relational database option, and in the Data Engineer Associate around building data pipelines on top of relational sources. As with the other services covered here, this article stays introductory — engine-specific configuration and tuning is exam-depth material our /revision study library is built to cover.