Container Orchestration with Amazon ECS - Task Definition and Service Design
A comprehensive guide covering task definition design, service deployment strategies, choosing between Fargate and EC2, and Auto Scaling configuration patterns.
Task Definitions and Cluster Design
An ECS task definition is a template that describes container execution specifications in JSON. A single task definition can include multiple containers, enabling the sidecar pattern where log collection or proxy containers are placed within the same task. There are two launch types: EC2 and Fargate. The EC2 launch type requires instance management but allows you to use GPUs and custom AMIs. The Fargate launch type eliminates infrastructure management, letting you run tasks by simply specifying CPU and memory per task. Revision management of task definitions also makes it easy to roll back to previous versions. Task definitions support ephemeralStorage (up to 200 GiB) for expanding temporary storage, useful for batch jobs that generate large intermediate data. Additionally, separating the task role (taskRoleArn) from the task execution role (executionRoleArn) lets you manage AWS API permissions for the container and image-pull/log-output permissions independently following the principle of least privilege.
Services and Deployment Strategies
An ECS service maintains the desired number of tasks and automatically restarts any tasks that terminate abnormally. By integrating with ALB target groups, tasks that fail health checks are automatically drained and replaced with new ones. Rolling updates use minimumHealthyPercent and maximumPercent settings to gradually replace tasks. For example, setting minimumHealthyPercent=50 and maximumPercent=200 keeps half the existing tasks running while launching new ones, then stops old tasks after the new ones pass health checks. Blue/Green deployments via CodeDeploy integration create a new task set for the updated version and gradually shift traffic, achieving zero-downtime deployments. In production, it is recommended to use CodeDeploy hooks (BeforeAllowTraffic / AfterAllowTraffic) to run automated tests and auto-rollback to the previous version within 5 minutes on test failure. ECS Service Connect provides native service discovery and load balancing between services within ECS, eliminating the need for separate App Mesh or Cloud Map configuration.
Choosing Between Fargate and EC2
Fargate is a serverless compute engine that eliminates the need to manage EC2 instances. You specify vCPU and memory per task and are billed only for the execution time. The EC2 launch type is suitable when you need to select specific instance types, use GPUs, or work with custom AMIs. Fargate Spot is designed for batch processing and fault-tolerant workloads, offering up to 70% savings compared to standard Fargate. ECS Exec lets you launch an interactive shell inside a task's container for debugging and troubleshooting. As of 2024, Fargate supports up to 16 vCPU / 120 GB memory per task, providing sufficient capacity for most web applications and data processing workloads. The EC2 launch type should be reserved for workloads requiring specialized hardware, such as ML inference on p5 instances with NVIDIA H100 GPUs or using AWS Inferentia2 on inf2 instances. For a comprehensive look at container orchestration, check out technical books (Amazon).
Cost Optimization for ECS
Fargate pricing is based on pay-per-use for vCPU (approximately $0.04048 per hour) and memory (approximately $0.004445 per GB-hour). Compute Savings Plans can provide discounts of up to 50%. With the EC2 launch type, you can leverage Spot Instances and use the binpack placement strategy to maximize instance utilization. Right-size the CPU and memory in your task definitions based on Container Insights metrics to eliminate over-provisioning. Configure target tracking policies for Service Auto Scaling to automatically adjust task counts based on CPU utilization. An often-overlooked cost factor is CloudWatch Logs data ingestion charges. If containers produce high log volumes, either control log levels through the awslogs driver or use FireLens (Fluent Bit) to filter unnecessary logs before sending them to CloudWatch, potentially saving tens of dollars per month.
Design Best Practices and Pitfalls
When configuring healthCheck in a task definition, failing to set a sufficient startPeriod (grace period) causes applications with slow startup times to enter a restart loop immediately after launch due to health check failures. For languages requiring JIT warmup such as Java or .NET, setting startPeriod to 60-120 seconds is practical. For inter-task communication, the awsvpc network mode is recommended because each task gets its own ENI, enabling security group-level access control per task. However, be aware of ENI density limits (ENI caps per instance type) that prevent packing many tasks onto small instances. For secrets management, reference values from Secrets Manager or SSM Parameter Store directly in the task definition's secrets field instead of hardcoding them in environment variables. Additionally, enabling execute-command carelessly in production allows arbitrary command execution via SSM sessions, so restrict users strictly through IAM policies.
ECS vs. EKS - Choosing the Right Orchestrator
ECS is an AWS-native orchestrator while EKS is the managed Kubernetes offering. If your team lacks Kubernetes operational experience and values tight AWS integration (native ALB integration without ALB Controller, native definitions in CloudFormation/SAM), ECS is appropriate. Conversely, if you need multi-cloud or on-premises portability, or want to leverage the OSS tool ecosystem published as Helm charts (Argo CD, Istio, Prometheus Operator, etc.), EKS has the advantage. From an operational overhead perspective, ECS + Fargate has both the control plane and data plane managed by AWS with low YAML learning costs, making it well-suited for small teams. EKS has a managed control plane, but Kubernetes-specific operations like node group upgrades, addon version management, RBAC design, and NetworkPolicy management still apply. On cost, EKS incurs a cluster fee of $0.10/hour (approximately $74/month) for the control plane, while ECS has no such fixed cost. Choose based on your workload characteristics and team skill set.
Summary
ECS provides declarative container management through task definitions and automatic recovery and scaling through services. Run containers serverlessly with Fargate and achieve up to 70% cost savings with Fargate Spot. Perform zero-downtime releases using rolling updates and Blue/Green deployments, and visualize performance with Container Insights. Understanding practical pitfalls like healthCheck startPeriod and ENI density limits, and simplifying inter-service communication with ECS Service Connect, are key to stable production operations.