After the serverless blog (subchapter 33.1), we take a step up in complexity with the second project: a REST API with containers. While the blog was 100% serverless, this project takes you into the world of containers (Chapter 17) and relational databases (Chapter 8), combining ECS Fargate, RDS, and a load balancer (ALB). This is a very common pattern in the real world for backend applications, and it consolidates a different (and highly sought-after) part of your knowledge.

A REST API is a "gateway" that other applications (a website, a mobile app...) use to make requests to obtain or modify data. For example, an API for a store that the mobile app uses to query products, create orders, etc. It is the backend "brain" that serves data and logic to clients.

This project builds that API, but using containers to run it and a relational database for the data.

The project combines three main services, each with its role:

Remember containers (Chapter 17): they package your application with everything it needs to run the same way anywhere. ECS with Fargate (subchapter 17.3) runs those containers without you having to manage the underlying servers (Fargate is the serverless option for containers). Here, your API goes inside a container that ECS Fargate runs and scales.

💡 This project lets you practice the container workflow we saw: package the app in a Docker image (subchapter 17.1), store it in ECR (subchapter 17.2), and run it in ECS Fargate (subchapter 17.3).

RDS (Chapter 8) provides the relational database (managed by AWS) where the API stores and queries data (products, orders, users...). Unlike the blog (which used DynamoDB, NoSQL), here we use a relational (SQL) database, suitable when data has structured relationships. RDS manages it for you (backups, patches...).

The Application Load Balancer (ALB) (subchapter 13.1) distributes requests among your API containers. If you have several containers running the API (to handle more load), the ALB distributes the traffic among them evenly, and checks their health (remember health checks, subchapter 13.2). It is the "gateway" that receives clients and directs them.

This is how the pieces fit together:

Clients reach the ALB, which distributes their requests among the API containers (in ECS Fargate), and these read/write to the RDS database. If more traffic arrives, ECS Fargate adds more containers and the ALB includes them in the distribution: it scales automatically.

This project strengthens an important (and very employable) part of the book, different from the serverless blog:

⚠️ Best practices to apply (that you have learned in the book):

• Put the database in private subnets (Chapter 6), not accessible directly from the internet: only the API should be able to talk to it.
• Store the database password in Secrets Manager (subchapter 23.6), never in the code or in .tfvars (remember subchapter 19.4).
• Use Security Groups (Chapter 6) so that only the ALB talks to the containers, and only the containers to the database.

Real-world example: someone wants to consolidate their knowledge of containers and relational databases (different from the serverless blog). They build a REST API for a store: package the application in a Docker image, store it in ECR, run it in ECS Fargate (multiple containers), put an ALB in front to distribute traffic, and use RDS for the data (products, orders), with the database in private subnets and the password in Secrets Manager. Everything is deployed with Terraform. By building it, they face real challenges —how to securely connect containers to the database, how to configure the ALB and health checks— and by solving them, they internalize how a real container architecture works. They end up with a real, scalable, and secure API, and a solid grasp of a highly sought-after pattern in the market.

• The REST API with containers project is a step up from the serverless blog, taking you into the world of containers (Ch. 17) and relational databases (Ch. 8). A REST API is the backend "gateway" that other apps make requests to.
• It combines three pieces: ECS Fargate (runs the API in containers without managing servers, auto-scales, Ch. 17), RDS (the relational database, Ch. 8), and ALB (distributes traffic among containers, Ch. 13).
• Architecture: clients → ALB (distributes) → containers in ECS Fargate → RDS (data). It scales automatically by adding containers.
• Consolidates: containers (Docker/ECR/ECS, Ch. 17), RDS (Ch. 8), load balancing (Ch. 13), networking and security (Chs. 6, 23), all with Terraform.
• ⚠️ Apply best practices: database in private subnets, password in Secrets Manager (never in code), and restrictive Security Groups.

In the next subchapter, we will tackle a project from the data world: a data platform with Glue, Athena, and Redshift.