Amazon ECS
Fully managed container orchestration service for Docker
ECS is like a manager for your Docker containers. You have containerized applications (packaged with all dependencies), and you need to run them, scale them, and ensure they stay healthy. ECS handles all of this: it schedules containers on servers, monitors health, restarts failed containers, and scales based on demand. You define tasks (what containers to run) and services (how many copies, load balancing), and ECS handles the rest. It's like having an operations team that ensures your containers are always running optimally, without you managing the underlying infrastructure.
ECS orchestrates Docker containers using clusters (groups of EC2 instances or Fargate), task definitions (container specifications), and services (maintain desired count of tasks). You can use EC2 launch type (you manage instances) or Fargate launch type (serverless). Task definitions specify container image, CPU/memory, networking, and IAM roles. Services ensure desired task count, integrate with ALB/NLB for load balancing, and support auto-scaling.
Key Capabilities
- Task definitions (versioned JSON configs) specify container image, CPU, memory, port mappings, environment variables, and volume mounts for one or more containers
- Services maintain a desired task count, automatically replacing failed tasks and integrating with ALB or NLB for traffic distribution
- Supports two launch types: Fargate (no EC2 management) and EC2 (self-managed instances for workloads needing more control or GPU access)
- Service auto-scaling adjusts task count based on CloudWatch metrics such as CPU utilization or custom application metrics
- ECS Exec enables interactive shell access into running containers for debugging without exposing SSH or adding debug tooling to images
- Service Connect provides built-in service-to-service networking with DNS-based discovery and connection metrics between ECS services
Gotchas & Constraints
Gotcha #1: ECS on EC2 requires managing cluster capacity; use Fargate for serverless. Gotcha #2: Task networking modes (bridge, host, awsvpc) affect how containers communicate; awsvpc is recommended. Constraints: Maximum 1,000 tasks per service, maximum 10 containers per task definition, and task CPU/memory must match specific combinations.
A microservices application has 20 services, each containerized. Running them on EC2 requires complex orchestration. They use ECS with Fargate: create task definitions for each service (specify Docker image, CPU, memory, environment variables), create services (desired count, load balancer integration), and deploy to an ECS cluster. ECS schedules tasks on Fargate, with no server management. They configure auto-scaling: scale based on CPU or request count. They use Application Load Balancer for traffic distribution and service discovery for inter-service communication. For CI/CD, they integrate with CodePipeline, so new Docker images trigger automatic ECS deployments with rolling updates (zero downtime). They enable Container Insights for monitoring to track CPU, memory, and network metrics per service.
The Result
simplified container management, automatic scaling, and zero infrastructure overhead.