What is a container orchestrator?
Imagine you have ten restaurant locations, each needing a specific number of cooks, servers, and cashiers on shift at all times. If someone calls in sick, you need a manager to immediately find a replacement. A container orchestrator is that manager — it ensures the right number of containers are running, restarts them when they crash, and distributes traffic across healthy ones. Amazon ECS (Elastic Container Service) is AWS's built-in version of that manager.
Kubernetes isn't the only way
While EKS (Kubernetes) gets all the hype, Amazon ECS (Elastic Container Service) runs some of the largest workloads on the planet — including Amazon.com's own retail infrastructure. The two services represent fundamentally different philosophies:
- EKS is Un-Opinionated: It gives you a blank canvas. You choose the networking plugin (CNI), the ingress controller, the logging agent, and the monitoring stack. It is powerful but requires significant assembly and ongoing maintenance.
- ECS is Opinionated: It is built purely for AWS. It assumes you want CloudWatch for logs, ALBs for load balancing, IAM for security, and ECR for image storage. Every integration is pre-wired. You configure rather than assemble.
This is not a weakness — it is a deliberate design choice. ECS trades flexibility for operational simplicity. A team of three engineers can run a production ECS cluster with confidence. Running EKS at the same scale typically requires dedicated platform engineers.
The Core Hierarchy
ECS has three layers, each mapping to a familiar concept:
| ECS Concept | Equivalent | Purpose |
|---|---|---|
| Task Definition | Docker Compose file | Blueprint: what to run and how |
| Task | Running container (Pod) | The actual running instance |
| Service | ReplicaSet / Deployment | Keeps N tasks alive, handles rollouts |
Understanding this hierarchy is the foundation for everything else in ECS. A Service runs Tasks. Tasks are created from Task Definitions. You never skip a layer.