AWS ECS and EKS (Container Services)
AWS provides two primary services for running containerized applications at scale: ECS (Elastic Container Service) and EKS (Elastic Kubernetes Service). Both services manage the orchestration of Docker containers — deciding where containers run, ensuring they stay healthy, and scaling them based on demand.
What Is a Container?
A container packages an application along with all its dependencies — libraries, runtime, configuration — into a single portable unit. Containers run consistently across any environment: a developer's laptop, a test server, or a cloud data center.
Docker is the most popular container technology. A Docker image is the blueprint; a Docker container is a running instance of that image.
Traditional Deployment: [App Code] + [Dependencies installed on server] = works maybe... Container Deployment: [App Code + All Dependencies bundled in Docker Image] → Runs identically everywhere: laptop, staging, production
The Challenge: Container Orchestration
Running one container on a single server is straightforward. Running hundreds of containers across dozens of servers — with health monitoring, auto-restart on failure, load balancing, rolling deployments, and efficient resource allocation — requires an orchestration system. That is what ECS and EKS provide.
AWS ECS — Elastic Container Service
ECS is AWS's own container orchestration service. It is tightly integrated with the AWS ecosystem — IAM, ALB, CloudWatch, ECR, and more. ECS is simpler to operate than Kubernetes and is the preferred choice for teams that want containers without the complexity of Kubernetes.
ECS Core Concepts
Task Definition: A blueprint that describes how to run a container — which Docker image to use, CPU and memory requirements, environment variables, networking settings, and IAM role. Think of it as a recipe for running a container.
Task: A running instance of a Task Definition. One task can run one or more containers that work together.
Service: An ECS Service ensures a defined number of tasks run at all times. If a task fails or crashes, the service automatically replaces it. Services also integrate with an ALB to route traffic to healthy tasks.
Cluster: A logical group of tasks and services. The cluster defines the infrastructure where tasks run — either on EC2 instances or using Fargate.
ECS Cluster
+---------------------------------------------+
| |
| Service: web-api (desired: 3 tasks) |
| +----------+ +----------+ +----------+ |
| | Task 1 | | Task 2 | | Task 3 | |
| | [nginx] | | [nginx] | | [nginx] | |
| | [app] | | [app] | | [app] | |
| +----------+ +----------+ +----------+ |
| |
+---------------------------------------------+
``` |
[Application Load Balancer]
|
[Users]
ECS Launch Types
| Launch Type | Infrastructure | Management | Best For |
|---|---|---|---|
| EC2 Launch Type | EC2 instances managed by the user | User manages EC2 servers | Workloads needing custom instance configuration |
| Fargate Launch Type | Serverless — AWS manages all servers | No server management at all | Most use cases — simplest operation |
AWS Fargate
Fargate is a serverless compute engine for containers. With Fargate, containers run without provisioning or managing EC2 instances. CPU and memory are specified in the Task Definition, and AWS allocates the required capacity automatically. Pay only for the exact CPU and memory consumed per second.
Without Fargate (EC2 Launch Type): [Manage EC2 instances] + [Install ECS agent] + [Scale servers manually] + [Run containers] With Fargate: [Define CPU + Memory in Task Definition] → [AWS runs containers automatically] No servers to manage at all.
AWS ECR — Elastic Container Registry
ECR is AWS's private Docker image registry. It stores Docker images securely within AWS. ECS and EKS pull images directly from ECR without authentication complexity. ECR integrates with IAM for access control and scans images for security vulnerabilities automatically.
Developer builds image → pushes to ECR → ECS pulls from ECR → runs as container docker build -t my-api . docker tag my-api 123456789.dkr.ecr.ap-south-1.amazonaws.com/my-api:v1 docker push 123456789.dkr.ecr.ap-south-1.amazonaws.com/my-api:v1
AWS EKS — Elastic Kubernetes Service
EKS is a fully managed Kubernetes service on AWS. Kubernetes is an open-source container orchestration platform originally developed by Google. It is the industry standard for large-scale container management and is used by thousands of organizations worldwide.
EKS runs and manages the Kubernetes control plane — the brain of the cluster. AWS handles master node availability, version upgrades, and patching. Worker nodes (EC2 or Fargate) run the actual application containers.
Kubernetes Core Concepts
- Pod: The smallest deployable unit in Kubernetes. A pod contains one or more containers that share the same network namespace and storage.
- Node: A worker machine (EC2 instance or Fargate) that runs pods.
- Deployment: Defines the desired state — how many pods of a given container image should run. Kubernetes continuously reconciles the actual state with the desired state.
- Service: A stable DNS name and IP address for accessing a group of pods. Even if pods are replaced, the service endpoint stays the same.
- Namespace: A virtual cluster within a cluster — used to separate environments (dev, staging, production) or teams within one EKS cluster.
EKS Cluster
+-----------------------------------------------------+
| Control Plane (managed by AWS) |
| [API Server] [Scheduler] [Controller Manager] |
+-----------------------------------------------------+
| | |
Node Group (EC2 instances)
+----------+ +----------+ +----------+
| Node 1 | | Node 2 | | Node 3 |
| [Pod: app| | [Pod: app| | [Pod: app|
| [Pod: db | | [Pod: svc| | [Pod: bg |
+----------+ +----------+ +----------+
EKS Node Options
- Managed Node Groups: AWS provisions and manages EC2 instances as worker nodes. Auto Scaling is built in.
- Self-Managed Nodes: EC2 instances manually launched and added to the cluster. Full control but more responsibility.
- Fargate Profiles: Pods run on Fargate — completely serverless. No node management required.
ECS vs EKS — Which to Choose?
| Factor | ECS | EKS |
|---|---|---|
| Complexity | Simple — AWS-specific, easy to learn | Complex — requires Kubernetes knowledge |
| Ecosystem | AWS-native | Open-source, multi-cloud portable |
| Cost | No ECS control plane cost | $0.10/hour per EKS cluster (~$72/month) |
| Community | AWS-specific community | Massive Kubernetes open-source community |
| Best for | Teams new to containers, AWS-only workloads | Teams familiar with Kubernetes, multi-cloud strategy |
Real-World Example — Microservices on ECS Fargate
An e-commerce platform splits its application into microservices. Each service runs as an ECS Fargate task:
- product-service: 2 Fargate tasks — reads product data from DynamoDB.
- cart-service: 3 Fargate tasks — manages shopping carts in ElastiCache.
- order-service: 2 Fargate tasks — processes orders, writes to RDS Aurora.
- notification-service: 1 Fargate task — sends email/SMS via SNS.
An ALB routes requests to each service based on URL path rules (/products/*, /cart/*, /orders/*). Each service scales independently. A traffic spike on the cart service does not affect the product or order service.
Summary
- ECS is AWS's native container orchestration service — simpler, tightly integrated with AWS, no additional cost for the control plane.
- Fargate is a serverless compute engine for ECS and EKS — no EC2 instances to manage.
- ECR is the private Docker image registry within AWS — secure, integrated, and scalable.
- EKS runs managed Kubernetes on AWS — ideal for teams with Kubernetes expertise or multi-cloud requirements.
- For most AWS-native workloads, ECS with Fargate is the recommended starting point. Migrate to EKS when Kubernetes-specific features become necessary.
