Amazon ECS — Container Service

Amazon Elastic Container Service (ECS) is a fully managed container orchestration service that allows you to run, stop, and manage Docker containers on a cluster. Before containers, developers faced the "it works on my machine" problem—applications behaved differently across environments due to inconsistent dependencies, libraries, and operating system versions. Containers solve this by packaging the application code, runtime, system tools, and libraries into a single, lightweight executable image that runs consistently anywhere.

However, running containers at scale introduces new challenges: how do you schedule containers across multiple servers, handle failures, scale up/down based on demand, manage networking, and integrate with storage and monitoring? This is where orchestration tools like ECS come in. ECS automates these operational tasks, allowing you to focus on building applications rather than managing clusters.

ECS operates on a few fundamental concepts:

The workflow: 1. You create a task definition (JSON or YAML) that describes your container. 2. You launch a task or define a service that runs the task definition. 3. ECS places the task on an available compute resource (EC2 instance or Fargate) based on CPU/memory requirements and launch type. 4. The container agent pulls the container image from a registry (Amazon ECR or Docker Hub) and starts the container. 5. ECS monitors the task health and restarts it if needed.

ECS offers two launch types that determine how compute resources are managed:

Task definitions are JSON documents that specify:

- Container image URL (e.g., 123456789012.dkr.ecr.us-east-1.amazonaws.com/my-app:latest) - CPU and memory limits: For Fargate, you must specify task-level CPU and memory (e.g., 256 vCPU, 0.5 GB). For EC2, you can specify container-level limits that sum up to the instance capacity. - Networking mode: - awsvpc: Each task gets its own elastic network interface (ENI) with a private IP address. This is the recommended mode for Fargate and EC2 tasks that need direct VPC networking. - bridge: Uses Docker's built-in bridge network. Ports are mapped from the host to the container. - host: Container uses the host's network stack directly. - IAM role: An IAM role that the container assumes to access AWS services (e.g., S3, DynamoDB). - Logging: Configuration for CloudWatch Logs, FireLens, or other log drivers.

An ECS service ensures that a specified number of tasks are always running. You can attach an Application Load Balancer (ALB) or Network Load Balancer (NLB) to distribute traffic. The service performs health checks on tasks and automatically replaces unhealthy ones. You can also configure auto scaling based on metrics like CPU utilization or request count per target.

Running containers on-premises requires you to manage everything: servers, container runtime (Docker), orchestration (Kubernetes or Docker Swarm), networking, storage, and monitoring. With ECS, AWS handles the orchestration control plane, integrates with other services, and provides a managed scaling experience. The trade-off is cost predictability and potential vendor lock-in.

A mid-sized e-commerce company wants to migrate from a monolithic application to microservices. They have services for product catalog, user authentication, shopping cart, and payment processing. Each service has different scaling requirements—the catalog might need more instances during flash sales, while authentication is steady. They choose ECS with Fargate to avoid managing servers. They create separate task definitions for each service, each with its own container image stored in Amazon ECR. They deploy each service as an ECS service behind an Application Load Balancer. For the catalog service, they set up auto scaling based on request count per target. During Black Friday, the catalog scales from 10 to 200 tasks seamlessly. The team uses AWS CloudWatch Logs to centralize logging and AWS X-Ray for tracing requests across services. Cost: they pay only for the vCPU and memory consumed per second. A common mistake is not setting appropriate memory limits, causing tasks to be killed by the OOM killer—they fixed this by monitoring and adjusting task definitions.

A financial firm runs nightly batch jobs that process transaction data and generate reports. Each job runs for 30 minutes to 2 hours and requires consistent compute resources. They use ECS with the EC2 launch type to take advantage of Reserved Instances for cost savings. They create a cluster of m5.large instances with a Savings Plan. They submit each batch job as a standalone ECS task (not a service) using the RunTask API. The task definition specifies the container image with the processing script, and the task is placed on an available EC2 instance. They use Amazon CloudWatch Events to trigger tasks on a schedule. If an instance fails, the task is rescheduled on a healthy instance. They monitor task failures and retry logic using Step Functions. The team learned that they must properly size the EC2 instances—over-provisioning wastes money, under-provisioning causes tasks to fail due to insufficient resources.

A startup wants to host a Node.js web application with a PostgreSQL database. They containerize the application and run it on ECS with Fargate. They also run a sidecar container for log forwarding using FireLens. The database runs on Amazon RDS. They set up an Application Load Balancer in front of the ECS service for HTTPS termination. For development, they use a single task; for production, they run 3 tasks across two Availability Zones. They use AWS CodePipeline to automate deployment: when code is pushed to GitHub, CodeBuild builds the Docker image, pushes it to ECR, and updates the ECS service. A common pitfall: they initially forgot to set the task IAM role to allow access to RDS, causing connection failures. They also learned to configure health check endpoints to avoid false positives from the load balancer.