Chapter 28: AWS Production Deployment

1. AWS production deployment

The Chapter 27 Compose stack ran the API + Postgres + Redis on one laptop. This chapter moves the same components to AWS managed services, one to one: ECR holds the Docker image, ECS Fargate runs the container, RDS hosts PostgreSQL, ElastiCache hosts Redis, and an Application Load Balancer fronts the whole thing with an ACM-issued TLS certificate. The migration is mostly mechanical; the load-bearing decisions are IAM (who can do what) and security groups (what can talk to what).

What you'll learn
  • How each Compose service maps to its AWS managed equivalent (Postgres -> RDS, Redis -> ElastiCache, API container -> ECS Fargate task), and where the production-only concerns live (IAM, VPC, ALB)
  • IAM essentials: lock the root account, use a daily-admin IAM user, write least-privilege roles for the deployment and the running task
  • How to push a tagged image to ECR and have ECS pull it on every task start
  • Running containers on Fargate: task definitions, services, log routing to CloudWatch, debugging from aws ecs describe-services output
  • Security groups as the production analogue of Compose's service-to-service networking; what to open and what to keep closed
  • Fronting the API with an Application Load Balancer and serving HTTPS via a free ACM certificate
What you'll build
  • An AWS account with a hardened root login, an admin IAM user for daily work, and billing alerts
  • An ECR repository with the Chapter 27 image pushed and tagged
  • An RDS PostgreSQL instance and an ElastiCache Redis cluster, both in a VPC with security groups scoped to the ECS service
  • An ECS Fargate cluster + service running the API container, with logs going to CloudWatch
  • An Application Load Balancer fronting the service, with an ACM certificate serving HTTPS
  • A task-definition.json committed to the repo so the deployment is reproducible

The shape of the move

Every piece of the Compose stack has a one-to-one AWS analogue. The image you built with docker build goes to ECR (Elastic Container Registry) instead of staying local. The Postgres container becomes an RDS instance; AWS handles patches, backups, and HA. The Redis container becomes an ElastiCache cluster; same managed-service tradeoff. The API container runs on ECS Fargate, which is "run a container without thinking about the VM underneath". A new piece, the Application Load Balancer, fronts the service so the API has a stable public hostname and TLS termination.

The hard part isn't any individual service; it's the connective tissue. IAM roles decide whether your CLI can push to ECR and whether the running task can read the RDS password from Parameter Store. Security groups decide whether the ECS service can talk to RDS at all. A wrong setting in either is the most common reason a freshly-deployed API returns nothing but timeouts; we walk through both explicitly.

What this chapter does not cover

Three things sit one step beyond this chapter's scope and earn explicit forward pointers. Continuous deployment (push to git, image builds and deploys automatically) is Chapter 29's CI/CD work. Auto-scaling rules and multi-region resilience are also Chapter 29 / Chapter 30 territory. Infrastructure-as-code (Terraform, CloudFormation, CDK) is a deliberate omission; the chapter uses the AWS CLI throughout so each step's effect is visible, and the closing review names the IaC tools you'd reach for next.

How the chapter is laid out

Next, in section 2, we walk through the Compose-to-AWS map so the rest of the chapter has the right mental model before any CLI commands run.