Amazon Elastic Container Service
ECS
You need to run and scale Docker containers in production without the complexity of managing a Kubernetes cluster.
Reach for it when
- Deploying microservice applications packaged as Docker containers that need to scale automatically.
- Running background worker containers that process tasks from an SQS queue continuously.
- Migrating legacy software stacks to containers without modifying the core system architecture.
Do not reach for it when
- Deploying complex, open-source container architectures that require standard Kubernetes APIs — use EKS instead.
- Running short-lived, event-driven scripts that execute in seconds with irregular schedules — use Lambda instead.
- Hosting simple static websites with no backend code or database interactions — use S3 and CloudFront instead.
Alternatives, and how to choose
| Service | Pick it instead when |
|---|---|
| EKS | Choose it when you require Kubernetes API compatibility and advanced cloud-agnostic orchestrations. |
| Lambda | Choose it when running short-lived backend tasks that can execute within 15 minutes. |
How you pay
- The model
- Pay for the EC2 instances in your cluster or the CPU/memory provisioned for Fargate tasks.
- The line item that surprises people
- Leaving Fargate tasks running with high CPU/memory allocations when idle accumulates high continuous fees.
What trips people up
- Task definitions are immutable; updating an application requires creating and deploying a new task revision.
- ECS tasks on Fargate do not share local storage; temporary data is lost when a task is rescheduled or terminated.
- Failing to configure proper container health checks can cause ECS to route traffic to dead or booting tasks.
Verify the live service
This page is a concept reference. Cost models are qualitative; confirm the current offering, Region and pricing before deploying.