Almost every application needs to store data in an organized way: users, orders, products… For that, we use databases. AWS lets you run databases without having to manage them yourself, thanks to managed services. The most important is RDS, and that's where we start this chapter.

Setting up and maintaining a database “by hand” is hard and delicate work:

• Installing and configuring the database software.
• Applying security patches.
• Making regular backups.
• Configuring high availability in case the server fails.
• Monitoring performance.

Doing all this well requires a specialist (a DBA, database administrator) and a lot of time. RDS automates almost all of this for you.

RDS stands for Relational Database Service. It is a managed service to run relational databases without dealing with heavy administration.

Remember Chapter 1: RDS is an example of PaaS. AWS takes care of the operating system, installation, patches, backups, and infrastructure; you only take care of your data and your queries.

“Relational database” means that data is organized in tables with rows and columns, related to each other (like connected spreadsheets). They are queried with the SQL language. These are the “classic” databases, ideal when data has a clear and consistent structure.

Analogy: Using RDS is like renting a car with a driver and maintenance included instead of buying the car and taking care of the checkups, insurance, and breakdowns yourself. You decide where to go (your data); AWS takes care of the rest.

RDS is not a new database: it runs the popular database engines that already exist. You choose the one you prefer:

Key advantage: if your application already used, for example, MySQL or PostgreSQL, you can move it to RDS without changing the code. It’s the same engine, but managed by AWS.

Here RDS shines in security and resilience. Remember the availability zones from Chapter 3. The Multi-AZ option in RDS does the following:

• Maintains an exact copy (standby replica) of your database in ANOTHER availability zone, synchronized in real time.
• If the primary database fails (due to hardware issues or an AZ outage), RDS automatically switches to the standby copy, usually in one or two minutes, without you having to do anything.

Analogy: It’s like having a backup driver sitting next to you on a long trip. If the main driver feels unwell, the backup instantly takes the wheel and the trip continues almost without interruption.

Important: The Multi-AZ standby replica is not used for queries; it’s only “waiting” in case the primary fails. Its sole purpose is high availability. To distribute the read load, you use read replicas (we’ll see this now).

Sometimes the problem isn’t that the database fails, but that it receives too many read queries and gets overloaded. That’s what read replicas are for.

A read replica is an additional copy of your database that serves only for reading (queries), not for writing. You distribute reads between the primary and the replicas, easing the load.

Analogy: Imagine a library with a single librarian overwhelmed by people coming to consult books. You hire several assistants (replicas) who only handle queries. Catalog modifications (writes) are still done only by the head librarian (the primary), to avoid chaos.

Real example: A news website has lots of people reading articles and few people writing them. It creates several read replicas: millions of readers query the replicas, while the few journalists write to the primary database. This way, the site can handle huge spikes in read traffic.

This is the most common conceptual mistake in this topic:

Mental rule: Multi-AZ = availability (a standby backup). Read replica = performance (assistants handling reads). They are often used together.

• Automatic backups and the ability to restore to a specific point in the past.
• Patching of the engine and operating system.
• High availability with Multi-AZ.
• Read scaling with replicas.
• Integrated monitoring.
• Encryption of data at rest and in transit.

• RDS is a managed service (PaaS) for relational databases (tables + SQL): AWS handles patches, backups, and administration; you handle your data.
• Supports popular engines (PostgreSQL, MySQL, MariaDB, Oracle, SQL Server, and Aurora); you can migrate without changing code.
• Multi-AZ = high availability: standby copy in another AZ that automatically takes over if the primary fails.
• Read replicas = performance: copies that handle read queries to ease the load.
• Don’t confuse them: one is for tolerating failures, the other for scaling reads. They are often combined.

In the next subchapter, we’ll look at Aurora, AWS’s own database engine, and why it often outperforms “classic” RDS.