Containers — Concept (ECS, EKS, Fargate, ECR, App Runner)
Why this group
Modern apps ship as containers. AWS gives you several options to run them — pick by orchestrator and infrastructure model.
Orchestrators
| Service | What | Use |
|---|
| ECS (Elastic Container Service) | AWS-native orchestrator | Simple, deeply integrated with AWS, lower learning curve |
| EKS (Elastic Kubernetes Service) | Managed Kubernetes | Standard Kubernetes API, multi-cloud portability |
| App Runner | Fully managed app deploy from container/source | Quickest path for a simple web app |
Infrastructure models
| Model | What | Use |
|---|
| EC2 launch type | You manage EC2 cluster nodes (capacity providers, ASG) | Want full control, GPU, lower per-hour |
| Fargate launch type | Serverless containers — no nodes | Don't want to manage hosts; pay per vCPU + GB-second |
ECR
- Elastic Container Registry = private Docker registry.
- IAM-controlled, KMS encryption, vulnerability scanning, lifecycle policies.
- Public ECR exists for sharing images publicly.
ECS concepts
- Task definition = blueprint (image, CPU, memory, env vars, IAM task role, ports).
- Task = a running instance.
- Service = long-running tasks managed by ECS (desired count + LB).
- Cluster = logical grouping; can have EC2 capacity providers and/or Fargate.
- Auto-scaling at service level: target tracking on CPU/memory or custom metrics.
EKS concepts
- Control plane managed by AWS (multi-AZ).
- Worker nodes: self-managed EC2, managed node groups, or Fargate profiles.
- Integrates with VPC CNI, AWS Load Balancer Controller (ALB/NLB), IRSA (IAM Roles for Service Accounts).
- Better for teams already on K8s, GitOps tooling, cross-cloud.
Fargate (deep dive)
- Each task / pod runs in its own isolation boundary.
- Pricing: vCPU + GB-second.
- No host management — patches handled.
- Works with both ECS and EKS.
- Supports Spot pricing (Fargate Spot) for fault-tolerant workloads.
App Runner
- Drop a container image (or source repo) → service URL with HTTPS, auto-scaling, deployments.
- No VPC setup needed (private VPC connectivity is an option).
- Best for stateless web services / APIs.
Common patterns
- ECS + Fargate behind ALB for web services.
- ECS + EC2 with GPU instances for ML inference.
- EKS + Fargate profiles for Kubernetes workloads.
- Lambda + ECR container image for serverless container deployment.
When to use vs alternatives
| Need | Use |
|---|
| Quickest container web service | App Runner |
| AWS-native orchestration, simple | ECS (+ Fargate) |
| Kubernetes API, portability | EKS |
| Serverless containers, no node ops | Fargate (ECS or EKS) |
| GPU / custom OS / high-density | ECS on EC2 |
| Short-lived event-driven function | Lambda (not container) |
Common exam scenarios
- "Run containerized web service, no infra management" → ECS on Fargate behind ALB.
- "Team uses Kubernetes, must stay portable" → EKS (Fargate or managed nodes).
- "Reduce container compute cost for batch" → Fargate Spot or EC2 Spot capacity provider.
- "Need GPU containers for ML inference" → ECS on EC2 (p3/p4/g5 instances).
- "Auto-deploy from GitHub commit to running service" → App Runner or ECS + CodePipeline.
- "Container image security scanning" → ECR image scanning (basic or enhanced via Inspector).
Exam tip
- Fargate = no servers; pay per task. Best default for new container workloads.
- ECS = simpler / AWS-native; EKS = K8s API everywhere.
- If a question says "without managing servers" + containers → Fargate.
References