Aurora vs RDS: what is the difference?
Amazon Aurora is part of the Amazon RDS family, so the real question is Aurora versus the "standard" RDS engines — Aurora is AWS’s cloud-native, MySQL- and PostgreSQL-compatible engine built for higher performance and availability, while standard RDS runs the usual engines directly and supports more of them. This is not a comparison between two competing services; it is a choice of engine within one managed relational database service. This guide explains what each option actually is, the differences that matter when choosing between them, and when the extra capability Aurora offers is worth it.
What each option is
Our what is Amazon RDS explainer and what is Amazon Aurora explainer cover each in depth; the point worth stating plainly here is that Aurora is an engine option you choose within RDS, alongside engines such as MySQL, PostgreSQL, MariaDB, Oracle and SQL Server. RDS is the managed service that runs all of these; Aurora is AWS’s own engine, re-engineered for the cloud, that you can run inside that same managed service.
The key differences
Because Aurora is an RDS option rather than a separate product, the differences are about engine choice and capability, not about the underlying managed service:
- Engine choice and compatibility — Aurora is compatible with MySQL and PostgreSQL specifically; standard RDS supports those two plus several other engines (MariaDB, Oracle, SQL Server), so it covers a wider range of existing applications.
- Performance and availability design — Aurora is built cloud-native from the ground up, with its storage and replication architecture designed for higher performance and availability than the standard engines running unmodified.
- Breadth of supported engines — if your application depends on an engine Aurora does not support, standard RDS is the only option within the RDS family.
- Simplicity vs capability — standard RDS engines behave close to running that engine yourself, which is familiar and predictable; Aurora adds cloud-native capability on top, at the cost of being AWS-specific rather than a drop-in vanilla engine.
- Migration path — moving to Aurora from MySQL or PostgreSQL is generally straightforward given the compatibility; moving to or from a different engine (Oracle, SQL Server) is a bigger undertaking regardless of Aurora.
When to choose standard RDS
Choose a standard RDS engine when you need an engine Aurora does not support, when your application was built against a specific engine’s exact behaviour, or when the extra performance and availability capability of Aurora is not something your workload needs. Simplicity and a closer match to "the engine as everyone knows it" are reasonable, valid choices.
When to choose Aurora
Choose Aurora when you are on MySQL or PostgreSQL (or can be) and want the higher performance and availability design Aurora offers over the standard engine running unmodified. It is a strong fit for applications that have outgrown a standard instance’s performance or availability characteristics, without needing to change database engines conceptually.
Both are managed by the same service
Because Aurora is delivered through RDS, choosing between them does not mean choosing between two different operational models — both get automated backups, patching and the rest of what RDS manages for you. The decision is really "which engine", made inside one service, not "which platform".
Where this appears in cert study
Understanding Aurora as an RDS engine option, and knowing when its extra capability is worth choosing over a standard engine, is core material in the Solutions Architect Associate and Developer Associate exams, and comes up again in the Data Engineer Associate when reasoning about database performance and availability trade-offs.
Original practice questions, timed mock exams and revision notes. No card, nothing to pay.