Comparing Aurora and RDS: Pricing, Performance, and How to Choose

Both Amazon RDS and Amazon Aurora are services used to operate relational databases on Amazon Web Services (AWS). However, Aurora is one of the database engines available for Amazon RDS, and its architecture, performance, availability, and pricing differ from RDS for MySQL/PostgreSQL.

For small-scale business systems with stable loads, RDS is sufficient. On the other hand, if high availability, read performance, and future scalability are required, Aurora should be considered first. Simply deciding "Aurora because it's high-performance" or "RDS because it seems cheap" may lead to choosing a configuration that does not meet the requirements.

This article provides a comparison table of Aurora and RDS, explaining their performance, availability, pricing, and key points to consider when choosing between them.

Differences between Aurora and RDS

Aurora and RDS differ in their supported engines, architectures, storage structures, availability, and pricing structures. First, let's summarize the main differences in a table.

RDS is a versatile managed database service that allows you to choose from multiple database engines. In addition to MySQL and PostgreSQL, you can also select Oracle and SQL Server. For standard business systems and small to medium-sized web applications, RDS is sufficient.

Aurora is one of the database engines available on Amazon RDS. It's available as a MySQL-compatible and PostgreSQL-compatible engine, and employs a cluster configuration with separate compute and storage. If high availability, read performance, and future scalability are among your requirements, consider prioritizing Aurora.

However, Aurora is not simply a backward-compatible alternative to RDS. For small-scale applications with stable loads, RDS is simpler in terms of configuration and cost than Aurora.

The relationship between Amazon RDS and Amazon Aurora

RDS and Aurora are not entirely separate services. Aurora is one of the database engines available with Amazon RDS. Therefore, when considering the differences between RDS and Aurora, it's essential to first understand their relationship.

RDS is a managed database service, and Aurora is a database engine that can be selected for RDS.

Amazon RDS is a managed service for running relational databases on AWS. It allows you to manage all the tasks necessary for database operation, such as server management, backups, patching, and availability configuration, using AWS's infrastructure.

RDS allows you to choose from multiple database engines, including MySQL, PostgreSQL, MariaDB, Oracle, and SQL Server. Aurora is one of them.

However, Aurora is not simply a managed version of common MySQL or PostgreSQL databases. It is a database engine designed by AWS for the cloud, and is used as a MySQL-compatible or PostgreSQL-compatible engine.

While it can be used in a similar way to RDS for MySQL/PostgreSQL, the storage structure, availability, replicas, and pricing differ from the standard RDS engine.

The comparison should be between the "RDS standard engine" and the "Aurora."

While the term "difference between RDS and Aurora" is often used, in practice, it's more accurate to consider it a comparison between the "standard RDS engine" and "Aurora."

If you're using MySQL, you'll compare RDS for MySQL and Aurora MySQL. If you're using PostgreSQL, you'll compare RDS for PostgreSQL and Aurora PostgreSQL.

On the other hand, if you're using Oracle or SQL Server, Aurora is not an option. First, check which database engine you'll be using, and if MySQL/PostgreSQL compatibility is acceptable, compare whether the standard RDS engine or Aurora better suits your requirements.

The main differences between Aura and RDS

The differences between Aurora and RDS are not just performance. Because the architecture, storage, availability, supported engines, and pricing structures differ, even though both are MySQL/PostgreSQL compatible, the design and operational approaches will vary.

Differences between architecture and storage

The standard RDS engine is built around DB instances. You allocate storage to the instances and design the capacity, storage type, Multi-AZ configuration, read replicas, and more.

Aurora uses a cluster configuration that separates compute and storage. Data is stored on cluster volumes and is redundant across multiple Availability Zones (AZs). Each DB instance accesses and operates on this shared storage.

This difference in configuration directly impacts scalability and recovery in the event of a failure. With RDS, instances and storage are designed individually. With Aurora, storage automatically expands, reducing the design and effort required for capacity expansion.

However, even with automatic storage expansion, cost management is still necessary. As data volume and I/O increase, charges will be incurred based on usage.

Differences between performance, availability, and replicas

Aurora is designed for high-load read/write operations and large-scale access. While the standard RDS engine can handle typical business systems and web applications, Aurora should be prioritized for systems with heavy read loads or those where future access increases are anticipated.

The availability designs also differ. The standard RDS engine ensures high availability through a Multi-AZ configuration. Aurora is based on distributed storage spanning multiple Availability Zones, and has strengths in disaster recovery and failover.

There are also differences in replica configurations. Aurora allows you to create up to 15 Aurora replicas. For systems with a lot of read processing, such as search, list view, report viewing, and API access, the load can be distributed across multiple replicas.

On the other hand, for systems with low load, Aurora's performance and replica configuration cannot be fully utilized. For small-scale business applications or systems with stable access volumes, the standard RDS engine is simpler in terms of configuration and cost.

Differences in compatible engines and pricing structures

The standard RDS engine supports multiple database engines, including MySQL, PostgreSQL, MariaDB, Oracle, and SQL Server. Aurora cannot be selected for systems using Oracle or SQL Server.

Aurora is a MySQL-compatible and PostgreSQL-compatible database engine. It can be considered for migration or new adoption in MySQL/PostgreSQL-based systems. However, it's important not to assume completely identical behavior. The current version, extensions, SQL, and application-side connection specifications should be checked beforehand.

The pricing structures also differ. With the standard RDS engine, costs are affected by DB instances, storage, backups, data transfer, and provisioned IOPS depending on the storage type. With Aurora, in addition to DB instances, storage, backups, and replica configurations, I/O charges differ depending on whether you choose Aurora Standard or Aurora I/O-Optimized.

Comparing only instance prices can lead to misjudging actual costs. RDS costs should include storage type, while Aurora costs should include pricing modes and I/O volume. For small, low-load systems, the standard RDS engine is more suitable, while for systems requiring high availability and read scalability, Aurora should be prioritized.

When should you choose RDS?

RDS is suitable for standard business systems and small to medium-sized web applications. If high read scale and complex replica configurations are not required, RDS offers simpler configuration and pricing than Aurora.

For example, RDS is sufficient for applications with relatively stable loads, such as internal systems, administration panels, order management, member management, and inquiry management. If a system is not designed to handle sudden spikes in access, the opportunities to leverage Aurora's high availability and scalability are limited.

Even when using Oracle or SQL Server, RDS is the better choice. Aurora is a MySQL-compatible and PostgreSQL-compatible engine, but it does not support Oracle or SQL Server. If you want to maintain the database engine of your existing system, RDS is a more practical option.

RDS can be your first choice if the following conditions apply:

• Used in small to medium-sized business systems.
• Access numbers and load are stable.
• Use Oracle or SQL Server
• I want to keep the structure and pricing simple.
• Large-scale distributed reading is not required.
• There are no requirements to leverage Aurora's performance and availability.

RDS is by no means an inferior option to Aurora. For standard requirements, RDS provides a more balanced configuration. It's more important to choose a configuration that suits the system's size, load, and operational structure than to choose a database with more features than necessary.

When should you choose Aurora?

Aurora is suitable for systems that require high availability, read performance, and future scalability. If database downtime or performance degradation directly impacts sales, customer experience, or service continuity, Aurora should be considered as a priority over the standard RDS engine.

E-commerce sites, SaaS applications, reservation systems, membership services, and media sites are prime examples of systems prone to increased traffic and read loads. In configurations with frequent searches, list views, report views, and API access, Aurora Replica can be used to distribute read processing.

Aurora is a strong contender even for systems where availability is paramount. Aurora is designed for distributed storage spanning multiple Availability Zones (AZs), offering superior recovery and failover capabilities in the event of a failure. When service disruption would have a significant impact, the reasons for choosing Aurora over the standard RDS engine become clear.

We also consider Aurora if we have a clear vision of future scaling. If an increase in the number of users or transactions is anticipated, designing with Aurora in mind from the start reduces the risk of having to significantly revise the configuration later. However, a mere expectation that it "might increase someday" is not a strong enough justification; the decision should be made in conjunction with growth plans and load forecasts.

Aurora can be your first choice if the following applies to you:

• Use this for services that are significantly affected by database downtime.
• Emphasis on high availability and fault tolerance
• High read access
• An increase in the number of users and transactions is expected in the future.
• We want to improve performance and availability while maintaining MySQL/PostgreSQL compatibility.
• I want to distribute the read load using replicas.
• We want to reduce the operational burden of storage expansion and availability design.

Aurora is not simply a service you choose because it's high-performance. It's a service you choose when the standard RDS engine is insufficient to meet your requirements, taking into account availability, read load, future scalability, and operational burden.

Points to check before choosing Aura

Aurora is a high-performance, highly available database engine, but it's not suitable for all systems. Because its configuration, pricing structure, and compatibility differ from the standard RDS engine, judging it solely on performance can lead to discrepancies in cost and operation.

Aurora is not a simple backward compatible version of RDS.

Aurora is a service that offers higher availability and read scale than the standard RDS engine. However, it is not backward compatible with RDS.

For small-scale business systems or applications with stable access volumes, the opportunities to leverage Aurora's strengths are limited. Choosing Aurora for systems that don't require high availability or replica configurations will result in an over-configured system, increasing costs and operational complexity.

Furthermore, while Aurora uses a MySQL-compatible and PostgreSQL-compatible engine, it is not identical to RDS for MySQL or RDS for PostgreSQL. The storage structure, cluster configuration, failover, and parameter settings differ. Operating under the same assumptions as existing RDS systems will lead to oversights during design and migration.

You should choose Aurora if the standard RDS engine falls short in terms of performance, availability, read scale, and operational burden. You shouldn't choose it simply because "it's high-performance" or "AWS seems to recommend it."

Check the price and compatibility in advance.

Aurora pricing cannot be determined solely by the per-instance cost. In addition to DB instances, storage, I/O, backups, replica configurations, and other factors also affect the cost.

In systems with high read/write I/O activity or configurations utilizing multiple replicas, costs can exceed expectations. When comparing with the standard RDS engine, estimates should include current load, data volume, access trends, backup retention period, and the number of replicas.

We also check compatibility beforehand. Aurora is MySQL and PostgreSQL compatible, but depending on the versions, extensions, SQL, stored procedures, and application-side connection settings used in existing systems, verification may be necessary.

When migrating from existing RDS for MySQL or RDS for PostgreSQL to Aurora, it is essential to perform operational checks in a test environment before the production migration. Checking query behavior, connection settings, failover behavior, monitoring items, and backup operations will help reduce problems after the migration.

Summary: Choose between Aurora and RDS based on your requirements.

The difference between Aurora and RDS is not just performance. RDS is a managed database service that allows you to choose from multiple database engines, while Aurora is a cloud-oriented database engine that can be selected with RDS.

For small to medium-sized business systems with stable loads, RDS is sufficient. If you want to keep the configuration and costs simple when using Oracle or SQL Server, RDS can be your first choice.

For services significantly impacted by database downtime, systems with high read access rates, and systems where future load increases are anticipated, Aurora should be considered first. However, Aurora is not backward compatible with RDS. We will choose the option that best meets our requirements, considering factors such as cost, compatibility, and operational structure.