Amazon ECS and EKS
Container orchestration services — ECS with Fargate/EC2 launch types and EKS for managed Kubernetes, covering task definitions, services, and decision criteria.
Overview
Amazon Elastic Container Service (ECS) and Amazon Elastic Kubernetes Service (EKS) are AWS's container orchestration platforms — ECS is AWS-native and tightly integrated with the AWS ecosystem, while EKS provides managed Kubernetes for teams that need Kubernetes compatibility or portability.
| Aspect | ECS | EKS |
|---|---|---|
| Orchestrator | AWS-proprietary | Kubernetes (CNCF-compliant) |
| Control plane | Fully managed, no charge | Fully managed, charged per cluster ($0.10/hr) |
| Learning curve | Lower — AWS-native concepts | Higher — full Kubernetes API surface |
| Portability | AWS-only | Multi-cloud / on-premises (EKS Anywhere) |
| Ecosystem | Deep AWS integration (CloudMap, App Mesh) | Kubernetes ecosystem (Helm, Istio, ArgoCD) |
Core Concepts
| Concept | Description |
|---|---|
| Task Definition | (ECS) Blueprint for a container group — image, CPU, memory, ports, volumes, IAM role |
| Task | (ECS) A running instance of a task definition; analogous to a Kubernetes Pod |
| Service | (ECS) Maintains a desired count of tasks behind a load balancer; handles replacement on failure |
| Cluster | Logical grouping of tasks/services (ECS) or pods/nodes (EKS) |
| Pod | (EKS) Smallest deployable unit in Kubernetes — one or more containers sharing a network namespace |
| Node | (EKS) An EC2 instance or Fargate micro-VM that runs pods |
| Fargate | Serverless compute engine — AWS manages the underlying infrastructure for tasks/pods |
| EC2 Launch Type | Tasks/pods run on self-managed EC2 instances registered to the cluster |
| ECR | Elastic Container Registry — managed Docker image repository integrated with ECS/EKS |
Launch Types: Fargate vs EC2
| Criteria | Fargate | EC2 Launch Type |
|---|---|---|
| Infrastructure management | None — fully serverless | Self-managed EC2 instances (patching, AMIs) |
| Scaling | Per-task auto scaling | Cluster capacity providers + Auto Scaling groups |
| Pricing | Per vCPU + memory per second | EC2 instance pricing (can use RIs, Spot) |
| GPU support | Not supported | Supported (GPU instances) |
| Persistent storage | EFS only | EBS, EFS, instance store |
| Daemon tasks | Not supported | Supported (one per instance) |
| Best for | Unpredictable workloads, small teams | Large-scale, cost-optimised, GPU, compliance |
SAA/SAP Tip: When a question asks for "serverless containers" or "lowest operational overhead for containers," the answer is Fargate — not Lambda (which is for functions, not containers) or EC2-based ECS.
How ECS Works
ECS Cluster
├── Service A (desired count = 3)
│ ├── Task 1 [Fargate] ← Task Definition v2
│ ├── Task 2 [Fargate]
│ └── Task 3 [Fargate]
│ └── ALB routes traffic across tasks
├── Service B (desired count = 2)
│ ├── Task 1 [EC2] ← Task Definition v1
│ └── Task 2 [EC2]
└── Capacity Provider
└── Auto Scaling Group (EC2) or FargateECS Task Networking
| Network Mode | Description | Use Case |
|---|---|---|
| awsvpc | Each task gets its own ENI + private IP (required for Fargate) | Production, security groups |
| bridge | Docker bridge network; port mapping required | Legacy EC2 workloads |
| host | Task shares EC2 host network namespace | Performance-sensitive EC2 |
| none | No network connectivity | Batch jobs with no network |
How EKS Works
EKS Cluster
├── Control Plane (managed by AWS)
│ ├── Kubernetes API Server
│ ├── etcd (managed, multi-AZ)
│ └── Controller Manager + Scheduler
└── Data Plane
├── Managed Node Group (EC2 Auto Scaling)
│ ├── Node 1 → Pod A, Pod B
│ └── Node 2 → Pod C
├── Fargate Profile
│ └── Pod D (serverless)
└── Self-Managed Nodes (custom AMI)EKS Node Types
| Node Type | Management Level | Use Case |
|---|---|---|
| Managed Node Groups | AWS-managed AMI, scaling, updates | Most workloads — recommended default |
| Fargate Profiles | Fully serverless | Batch jobs, microservices with no node management |
| Self-Managed Nodes | Full control | Custom AMIs, specialised kernels, GPU |
ECS vs EKS Decision Guide
| Decision Factor | Choose ECS | Choose EKS |
|---|---|---|
| Team runs Kubernetes today or needs portability | No | Yes |
| Multi-cloud or hybrid strategy | Not a priority | Required (EKS Anywhere) |
| Deep AWS-native integration desired | Yes | Available but more manual configuration |
| Need Helm, Istio, or CNCF ecosystem | Not applicable | Yes |
| Prefer simplicity over flexibility | Yes | No — accept Kubernetes complexity |
SAA/SAP Tip: The exam rarely asks to choose between ECS and EKS directly. Focus on Fargate vs EC2 launch type and when to use containers vs Lambda vs EC2.
Integration with Other Services
| Integration | ECS | EKS |
|---|---|---|
| Load Balancing | ALB, NLB (native) | ALB, NLB (via AWS LB Controller) |
| Service Discovery | AWS Cloud Map | CoreDNS + Cloud Map |
| Secrets | Secrets Manager, SSM | Secrets Manager CSI driver |
| Logging | CloudWatch Logs (FireLens) | Fluent Bit / Fluentd |
| IAM | Task Role | IAM Roles for Service Accounts (IRSA) |
| Service Mesh | AWS App Mesh | Istio, Linkerd, App Mesh |
Common Use Cases
- Microservices architecture — Run dozens of independently deployable services with ALB path-based routing and service discovery.
- Batch processing — Use Fargate Spot or EC2 Spot with ECS to run cost-efficient, fault-tolerant batch jobs.
- CI/CD pipelines — Build and deploy container images with CodePipeline, CodeBuild, and ECR.
- Machine learning inference — Deploy models on EKS with GPU node groups or Inferentia instances.
- Kubernetes migration — Lift-and-shift existing Kubernetes workloads to EKS with minimal rework.
- Hybrid deployment — EKS Anywhere extends Kubernetes to on-premises data centres.
SAA/SAP Exam Tips
SAA/SAP Tip: Fargate removes the need to manage EC2 instances for containers. However, it does not support GPU workloads, daemon sets, or Windows containers with EKS. If any of these are required, use the EC2 launch type.
Exam Trap: ECS Task Roles are the mechanism for granting containers access to AWS services — not instance roles. When a question mentions "least privilege for a containerised application," the answer involves Task Roles (ECS) or IAM Roles for Service Accounts / IRSA (EKS).
SAA/SAP Tip: Amazon ECR is the go-to container registry. Images are stored in S3 and can be replicated cross-region for multi-region deployments. ECR supports image scanning for vulnerabilities.
Cross-Cloud Equivalents
ECS
| Provider | Service / Solution | Notes |
|---|---|---|
| AWS | Amazon ECS | Baseline |
| Azure | Azure Container Instances (ACI) | Serverless containers; no orchestration layer |
| GCP | Google Cloud Run | Serverless containers; auto-scales to zero |
| On-Premises | Docker Compose, HashiCorp Nomad | Simpler orchestrators for single-host or small clusters |
EKS
| Provider | Service / Solution | Notes |
|---|---|---|
| AWS | Amazon EKS | Baseline |
| Azure | Azure Kubernetes Service (AKS) | Free control plane; similar managed experience |
| GCP | Google Kubernetes Engine (GKE) | Autopilot mode offers serverless-like Kubernetes |
| On-Premises | Self-managed Kubernetes, Rancher, OpenShift | Full control; significant operational overhead |
Pricing Model
| Dimension | ECS | EKS |
|---|---|---|
| Control plane | Free | $0.10/hr per cluster (~$72/month) |
| Fargate compute | Per vCPU-second + per GB-second | Same as ECS Fargate pricing |
| EC2 compute | Standard EC2 pricing (RIs, Spot apply) | Standard EC2 pricing (RIs, Spot apply) |
| ECR storage | $0.10/GB-month | $0.10/GB-month |
| Data transfer | Standard VPC/internet transfer rates | Standard VPC/internet transfer rates |
Related Services / See Also
- Amazon EC2 — underlying compute for EC2 launch type
- AWS Lambda — serverless functions (no container management)
- AWS Auto Scaling — scale ECS services and EKS node groups
- Elastic Load Balancing — distribute traffic to containers
- Amazon ECR — managed container image registry
Amazon EC2
Elastic Compute Cloud — virtual servers in the cloud covering instance types, AMIs, placement groups, Nitro, tenancy, and pricing models.
AWS Elastic Beanstalk
Platform as a Service (PaaS) — deploy and manage web applications without infrastructure complexity, covering deployment policies, environment tiers, and .ebextensions.