Compute
Containers on AWS
Containers package an application with its dependencies so it runs the same everywhere. AWS offers two orchestrators and two ways to run the compute underneath. The exam focuses on choosing between them.
The pieces
| Service | Role |
|---|---|
| Amazon ECR | Private container image registry (with image scanning via Inspector, replication, lifecycle policies) |
| Amazon ECS | AWS's own container orchestrator — simpler, deeply integrated with AWS |
| Amazon EKS | Managed Kubernetes control plane — standard Kubernetes APIs and ecosystem |
| AWS Fargate | Serverless compute for containers — no EC2 instances to manage; works with ECS and EKS |
| EC2 launch type / node groups | Run containers on EC2 instances you manage (more control, can be cheaper at scale, GPU support, Spot) |
| ECS Anywhere / EKS Anywhere | Run ECS/EKS-managed containers on your own on-premises infrastructure |
ECS concepts
- Task definition — the blueprint: container images, CPU/memory, ports, environment, IAM roles.
- Task — a running instance of a task definition.
- Service — keeps a desired number of tasks running, replaces failed ones, integrates with load balancers and Auto Scaling.
- Cluster — the logical group the tasks run in.
- Task role — permissions the application uses (e.g. read S3). Task execution role — permissions ECS needs to pull images and write logs.
ECS vs EKS
| Choose ECS when… | Choose EKS when… |
|---|---|
| You want the simplest AWS-native option | You already use Kubernetes or need portability |
| Small team, minimal operations | You need the Kubernetes ecosystem (Helm, operators) |
| Deep AWS integration matters most | Hybrid/multi-cloud consistency matters |
Fargate vs EC2 for containers
| Choose Fargate when… | Choose EC2 when… |
|---|---|
| Least operational overhead — no servers, patching or capacity planning | You need GPUs, specific instance types or very large sustained scale where reserved EC2 is cheaper |
| Variable or spiky workloads | You need host-level control or daemon processes |
| Isolation per task is useful | You want maximum bin-packing efficiency |
Key idea
"Run containers without managing servers" → ECS or EKS on Fargate. "Already uses Kubernetes on-premises, move to AWS with minimal change" → EKS.
Migrating applications into containers
- Containerise — write a Dockerfile, externalise configuration (environment variables, Parameter Store/Secrets Manager).
- Make it stateless — store sessions in ElastiCache/DynamoDB, files in S3 or EFS.
- Push images to ECR.
- Define task definitions or Kubernetes manifests.
- Run behind an ALB, with service auto scaling.
- Persistent storage if needed — EFS works with ECS and EKS (including on Fargate).
Scaling containers
- ECS service auto scaling — target tracking on CPU, memory or ALB request count.
- EKS — Horizontal Pod Autoscaler for pods; Karpenter or Cluster Autoscaler for nodes; Fargate for serverless pods.
Exam patterns
- "Microservices in containers, minimal operational effort" → ECS on Fargate behind an ALB.
- "Batch containers that can tolerate interruption, lowest cost" → ECS/EKS on Spot (Fargate Spot or EC2 Spot).
- "Shared file storage for containers across AZs" → EFS.
- "Store and scan container images" → ECR with scanning.
Written by Bipin Singh
Work with meSenior Full-Stack Engineer · AI & AWS. I design and run production systems on AWS — serverless, data and AI.