Amazon RDS: Managed Relational Databases

A relational database stores data in tables — rows and columns, similar in shape to a spreadsheet — with relationships defined between tables. A classic example: a Customers table (one row per customer) and an Orders table (one row per order), where each order references exactly one customer through a shared column.

Amazon RDS (Relational Database Service) runs a relational database engine on your behalf, taking on operational work a self-managed database on an EC2 instance would leave entirely to you: automated backups, software patching for the database engine, and simplified provisioning of the underlying compute and storage. This is the same Shared Responsibility shift Module 3 described for EC2 versus a fully managed service — RDS sits further toward "AWS manages more of the operational burden" than a database you install and run yourself on a raw EC2 instance.

What stays the customer's job either way: designing the schema (which tables, which columns, which relationships), writing correct queries, and the data itself — RDS manages the database engine's operation, not your application's data model.

RDS supports multiple relational database engines — the customer chooses which engine an RDS instance runs, based on their own requirements and any existing familiarity or compatibility needs. This lesson deliberately doesn't rank engines against each other; the meaningful point for a beginner is that RDS is a managed platform for running a relational engine, not a single fixed database product.

Karoo Retail, introduced back in Module 1, needs to track customers and their orders, with orders always belonging to exactly one customer, and reporting that joins across both tables (which customers ordered which products, and when). This is a strong relational fit: bounded, structured entities with defined relationships between them — exactly what RDS's underlying relational engines are built to enforce and query efficiently.