What is AWS Database? Differences and Concepts of RDS, DynamoDB, and Aurora

When considering building a system using AWS, it's not uncommon to come to a halt over the question of what database to use. AWS offers multiple database services, including RDS, DynamoDB, and Aurora, but because each has a different philosophy and role, it can be difficult to understand the differences between them just by listing their names.

When you look at technical articles, you will find many explanations of performance comparisons and minor differences in functionality. However, sometimes considerations proceed without clarifying the basis for making decisions, such as "Which should I assume for my system?" or "Are these services separate in the first place?"

In this article, we will clarify the concept of databases in AWS and explain the three major services, RDS, DynamoDB, and Aurora, from the perspective of "differences in positioning" rather than "differences in functionality."

How AWS thinks about databases

The assumptions for database design in AWS are significantly different from those in on-premises environments. The first thing to keep in mind is that AWS assumes that you choose a database based on its purpose.

In on-premise systems, it was common to have one relational database such as MySQL or PostgreSQL, and to use it for a wide range of purposes, from business systems to analytical purposes. This was because, given the constraints of hardware and operational systems, it was more realistic to have "one type that can handle everything."

On the other hand, AWS provides the database itself as a service, with options optimized for each purpose.

Do you prioritize transaction processing, tolerance for large amounts of access, or high availability? These differences in requirements lead to differences in the underlying database design philosophy.

If you don't understand this difference and choose a database simply because you've used it on-premises or because it's well-known, you're likely to run into design and operational issues later on. With AWS, it's natural to first categorize your needs and then choose a database that suits them.

Another important point is that AWS databases are essentially managed services.

A managed database is a system in which AWS takes on a certain level of tasks such as OS management, middleware patching, backups, and recovery in the event of a failure.

However, being managed does not mean that you don't have to think about anything. While operational effort is reduced, different decisions are required than with on-premises systems when it comes to scaling, designing availability, and thinking about costs. It is more appropriate to think of this as a shift in where responsibility lies, rather than a loss of responsibility.

Typical database types that can be used with AWS

AWS offers a wide range of database services, but the first thing to understand is not to try to understand them all side by side. It is enough to first clarify which types of databases are available and what they do.

Databases commonly used on AWS can be broadly divided into two types: relational databases and NoSQL databases. In this article, we will focus on RDS, Aurora, and DynamoDB, which are representative examples of databases that are frequently used and can be difficult to design.

Relational (RDS/Aurora)

A relational database is a traditional database that defines the relationships between tables and manipulates data using SQL. It has been widely used for handling structured data, such as in business systems and web applications.

AWS offers relational databases as managed services, with Amazon RDS and Amazon Aurora being the most popular.

RDS is a service that allows you to use existing database engines such as MySQL, PostgreSQL, Oracle, and SQL Server on AWS as is. It is easy to migrate from on-premise or other environments and can be thought of as an extension of your existing database.

On the other hand, Aurora is a database that has been redesigned for AWS while being compatible with RDS. Although it looks similar to RDS, its internal structure and approach to availability are different, and it is designed with higher scale and fault tolerance in mind.

Although these two are classified as relational services, they are not "services of the same level."

The choice between the two is determined not by performance but by system size, availability requirements, and operational philosophy.

NoSQL (DynamoDB)

NoSQL databases are databases designed with a different philosophy than relational databases. They do not assume relationships between tables or complex SQL, and instead focus on processing large amounts of access at high speeds.

Amazon DynamoDB is AWS's representative NoSQL database.

DynamoDB is a serverless managed database, meaning users do not need to worry about the number of servers or storage capacity. Because it scales automatically in response to increases or decreases in access volume, it is often used in high-traffic API and event-driven systems.

However, DynamoDB is not a replacement for RDS or Aurora. Because the design philosophy of data structure and access patterns is significantly different, it should be understood as "an alternative to use in situations where RDB is not suitable."

What is Amazon RDS?

Amazon RDS is a managed relational database service provided by AWS. Its greatest feature is that it allows you to use common database engines such as MySQL and PostgreSQL on AWS as is.

RDS is designed to be a database that you are familiar with on-premise or VPS, and to leave infrastructure management to AWS.

What you can and can't do with RDS

With RDS, you can choose from major engines such as MySQL, PostgreSQL, MariaDB, Oracle, and SQL Server. A major advantage is that it can be used as an extension of existing database operations, without requiring major changes to the way you write SQL or the implementation on the application side.

On the other hand, because RDS is a managed service, you cannot freely change the OS or middleware. Tasks such as applying OS patches, updating the DB engine, taking backups, and recovering from failures are managed by AWS, but there are certain restrictions on configuration and version selection.

Rather than viewing this as a "restriction," it is more realistic to think of it as a division of operational responsibilities. While users are freed from OS-level tasks and daily maintenance, they are still responsible for application-related tasks such as table design, index design, and query optimization.

Scaling and availability are also considered differently from on-premises. RDS allows you to scale up by changing the instance size and ensures availability through a multi-AZ configuration, but it is not a mechanism for unlimited automatic scaling. You must select a configuration after first determining the expected load and availability requirements.

Typical cases where RDS is suitable

RDS is often chosen when migrating an existing relational database to AWS. It allows you to move your on-premises MySQL or PostgreSQL database to the cloud without making major design changes.

RDS is also a good choice as a backend for general web applications. The characteristics of RDS are fully utilized when handling structured information such as user management, order data, and business data.

Another typical example is a system that you want to run on AWS first. Even if you plan to rescale or reconfigure it in the future, choosing RDS as your first step will allow you to get familiar with the AWS environment while leveraging your existing knowledge.

RDS is not the most powerful or flexible database, but it is easy to use as an extension of your existing database and can be a realistic starting point for AWS.

What is Amazon DynamoDB?

Amazon DynamoDB is a fully managed NoSQL database provided by AWS.

Although it is called a "database" like RDS and Aurora, its design philosophy is completely different.

The key to understanding DynamoDB is not to think of it as a replacement for relational databases. Because their uses and assumptions are different, comparing them on an equal footing will lead to misunderstandings.

The philosophy behind DynamoDB

DynamoDB's table design assumptions are different from relational databases. Rather than assuming relationships between tables or complex joins, the design first defines the access pattern: "which key to use and how to retrieve data."

DynamoDB is also designed to prioritize scalability and availability over transaction processing. While it does provide certain transactional functionality, it is not intended to be used in business systems in the same way as a typical RDB.

Another major feature is that it is a serverless database.

With DynamoDB, users do not need to be concerned about the number of servers, instance size, or storage capacity. It is designed as a database that scales automatically in response to increases or decreases in load and does not require infrastructure operation.

For this reason, the design of DynamoDB focuses on "how to use data" rather than "how to operate the database."

Why DynamoDB?

The biggest reason people choose DynamoDB is its resilience to high traffic. Even in systems where access numbers spike and drop suddenly, stable performance can be maintained without having to carefully consider scale design.

DynamoDB is also a great option for those who don't want to worry about scale or who have limited resources to allocate to infrastructure operations. It can be designed according to usage without requiring advance capacity planning or server expansion.

Due to its characteristics, DynamoDB is often used in event-driven systems and API infrastructures.

By combining it with serverless services such as Lambda, you can configure your entire application in a scalable and simple manner.

On the other hand, business systems that make heavy use of complex searches and relationships are difficult to design and implement. DynamoDB is an alternative option for solving situations where RDS is difficult, so it is important to use it appropriately.

What is Amazon Aurora?

Amazon Aurora is a relational database designed by AWS. It is compatible with MySQL and PostgreSQL, so it is often mentioned alongside RDS, but Aurora is not a "superior version of RDS."

Although its appearance and usability are similar to RDS, the internal structure and underlying concepts are different. To properly understand Aurora, it is important to understand that compatibility does not necessarily mean the same mechanism.

Aurora is not a "better version of RDS"

Aurora is an RDS-compatible database engine, but its architecture has been redesigned for AWS. While RDS is a managed version of an existing database engine, Aurora is designed for use in a cloud environment.

Its greatest feature is its storage-separated architecture. Aurora separates database computation and storage, and automatically replicates data across multiple AZs. This structure enables fast recovery and failover in the event of a failure.

The approach to availability and performance is also different from RDS. Aurora prioritizes a configuration that makes the entire system less susceptible to downtime, rather than stable operation of a single instance. Another feature is that read-only read replicas can be easily added, making it easy to distribute read loads.

Instead, Aurora's configuration and pricing are more complex than RDS's. It's not a simple step-by-step approach of "switch to Aurora when RDS is not enough," but rather a service that you should decide on from the start based on whether it meets your requirements.

Cases where Aurora is suitable

Aurora is suitable for systems where high availability is essential. The design philosophy of Aurora is useful when you want to minimize the impact of a failure or when downtime is extremely intolerable.

It is also suitable for systems with high read loads. Because it is based on the premise of scaling out using read replicas, it is effective for web services and business systems with a lot of read-only access.

Due to these characteristics, Aurora is often the database of choice for medium to large scale systems.

On the other hand, for small systems and simple configurations, RDS is often sufficient.

Aurora is not a database that you choose because of its high performance. If you think of it as a choice for systems where high availability and scalability are necessary design considerations, it will be easier to make a mistake.

Comparison of RDS, DynamoDB, and Aurora

We've looked at the features of Amazon RDS, Amazon DynamoDB, and Amazon Aurora individually. We'll compare them side by side and explain the differences between them from a design perspective.

Differences in Data Models

Both RDS and Aurora are relational databases, and they allow you to flexibly handle data using SQL, based on the relationships between tables. This premise is useful when you want to organize and manage existing business data or structured information.

On the other hand, DynamoDB is a NoSQL database and does not assume relations or joins.

By designing a data structure that is optimized for anticipated access patterns, we achieve high-speed and stable processing.

In other words, RDS/Aurora is a model that emphasizes "data relationships," while DynamoDB is a model that emphasizes "how to extract data."

Differences in scaling methods

RDS is designed to scale up by changing the instance size, so you need to predict load fluctuations to some extent before selecting a configuration.

Aurora is based on a storage-separated architecture and read replicas, and focuses on scaling while maintaining availability and read performance.

DynamoDB is designed so that users are not aware of the scale. It automatically adjusts its processing capacity in response to increases or decreases in access volume, eliminating the need for advance capacity planning.

This difference also lies in how much to design in advance and how much to leave to the service.

Differences in operational thinking

Although RDS is a managed database, its operation is similar to that of a traditional database. Backups and patching are handled by the user, but performance tuning and configuration selection are left to the user's discretion.

Aurora is a database that operates on the premise of a configuration that is less likely to stop, rather than reducing operational load. Rather than "preventing" failures, the main idea is to "minimize the impact" if a failure does occur.

DynamoDB is designed to minimize the need to worry about database operations, allowing you to focus on designing your application without having to worry about server management or scaling.

Suitable system scale

RDS is a realistic option that is widely used in small to medium-sized systems, and is often the first choice for migrating existing databases or general web applications.

Aurora is effective for medium to large-scale systems and configurations that require high availability and high read performance. By choosing it when your requirements are clear, you can take advantage of its design advantages.

DynamoDB is chosen for its traffic characteristics rather than its scale. It is effective for APIs that generate high traffic even on a small scale, or for systems that are expected to scale rapidly.

The choice of database is not determined by its performance.

When comparing RDS, DynamoDB, and Aurora, people tend to focus on performance and availability. However, choosing a database on AWS is not determined by performance benchmarks.

The actual decision will depend on the system assumptions and operational reality. Here we will look at the main points to consider when choosing a database.

Business characteristics

The first thing to look at is what kind of business the system supports. If you need to accurately manage business data and reference and update it under complex conditions, a relational database is the natural choice.

On the other hand, for systems that rely on events, state management, or simple key lookups, NoSQL may be a better fit for the design. If the nature of the business and the way data is handled do not match, operation will be difficult no matter how high-performance the database you choose.

Access Patterns

The next important thing is how the database is accessed. The appropriate database will vary depending on factors such as the read/write ratio, peak usage, and number of simultaneous connections.

If access is relatively stable, RDS is sufficient.

If your read load is heavy and availability is a priority, the Aurora configuration is an option.

On the other hand, the characteristics of DynamoDB come into play when there are sudden increases or decreases in access.

Operational structure

The extent to which you can devote yourself to operations is also an important factor. The appropriate choice will depend on whether you have a dedicated database staff member or whether the application staff member will also be in charge of this role.

Although RDS and Aurora are managed databases, configuration and tuning decisions are required. On the other hand, DynamoDB can be designed to minimize infrastructure operations, making it effective when operational resources are limited.

Future expansion

The last thing to consider is future changes. Systems change over time as the number of users increases, features are added, and they integrate with other systems.

While RDS may be sufficient in the initial stages, if availability requirements become strict, you may need to consider Aurora. It is also realistic to configure a system where you isolate specific processes and use DynamoDB in conjunction with RDS.

The important thing is not to choose the "strongest database" from the start, but to create a premise that can withstand change. With AWS, the premise is that you combine and review options according to your requirements.

Summary

The key to understanding AWS databases is not to memorize the differences between RDS, DynamoDB, and Aurora, but to understand the assumptions on which each option was designed.

RDS is a practical option that allows you to use your existing relational database on AWS as is. DynamoDB is a database with a different concept, designed for systems that require high traffic and scale.

Aurora is a relational database redesigned for AWS, designed for medium to large-scale systems that prioritize high availability and read performance.

It's not about which is better, but which assumptions fit your system. When selecting an AWS database, you need to think about it from this perspective.

First, we organize the business characteristics, access patterns, and operational structure to determine which type of database is most suitable. Then, by specifically considering the design, fees, and operational methods of individual services, we can come up with a reasonable configuration.

If you keep this way of thinking in mind, even when you are unsure which AWS database to choose, you will be able to make a decision more easily without being swayed by comparisons and numbers.