2. AWS services overview

AWS has a managed equivalent for every piece of your local stack. This page maps Compose services to the AWS services that replace them in production.

Six AWS services carry the deployment. Each one replaces a piece of the Compose stack from Chapter 27, and each one solves a problem that Compose either solved by sitting on one machine or didn't have to solve at all. The list below names the service, the Compose piece it replaces, and why production needs the replacement.

  • ECR (Elastic Container Registry). Stores your Docker images in AWS. Think of it as Docker Hub but integrated with AWS services, with better security and faster pulls from ECS.
  • ECS (Elastic Container Service) with Fargate. Runs your containerized applications without managing servers. You define what containers to run and how much CPU/memory they need. AWS handles the rest.
  • RDS (Relational Database Service). Provides managed PostgreSQL databases. AWS handles backups, updates, failover, and monitoring. You connect to it like any PostgreSQL database.
  • ElastiCache. Provides managed Redis instances for caching. Same benefits as RDS: AWS manages infrastructure, you use Redis like normal.
  • ALB (Application Load Balancer). Distributes incoming HTTP/HTTPS traffic across your ECS containers. Handles SSL termination, health checks, and traffic routing.
  • CloudWatch. Centralized logging and monitoring. All your services send logs and metrics to CloudWatch. You create dashboards, set alarms, and query logs to debug issues.

Three more services sit underneath this list and rarely need direct attention once configured: IAM gates who can do what, VPC gives the resources a private network to live in, and Systems Manager Parameter Store stores the secrets the running task needs. The chapter touches each only as far as the deployment requires.

Checkpoint: AWS services

Three questions on the why of the mapping before the chapter starts running CLI commands.

Select question to reveal the answer:
What's the difference between ECR and ECS, and why do you need both?

ECR (Elastic Container Registry) stores your Docker images. Think of it as "GitHub for containers." ECS (Elastic Container Service) runs those images as actual containers. You need both because ECS pulls images from ECR when starting tasks. Without ECR, ECS wouldn't know where to get your container images. Without ECS, your images would sit in storage but never run.

Why use managed databases (RDS and ElastiCache) instead of running PostgreSQL and Redis in containers?

Managed databases take backups, failover, storage scaling, and security patches off your plate. Running Postgres or Redis in a container means re-implementing all of that yourself, on a single machine, with no automation when something goes wrong at 3am. The price difference is small; the operations difference is everything.

What problem does the Application Load Balancer solve that ECS containers alone can't?

The ALB gives the service a stable public hostname that doesn't change when a task restarts. It also terminates TLS, health-checks the tasks behind it, and rotates unhealthy ones out of the pool automatically. Without it, every task restart would change the IP the client has to reach, and there'd be no place to attach the HTTPS certificate.

Next, in section 3, we create the AWS account, lock the root login behind MFA, and set up the daily-admin IAM user that drives the rest of the chapter's CLI commands.