ECS Service Auto Scaling and Load Balancing

A fixed desired count on an ECS service cannot respond to traffic fluctuations—you either over-provision (wasting money) or under-provision (degrading performance). ECS Service Auto Scaling automatically adjusts the desired count of tasks in response to CloudWatch metrics. It uses the Application Auto Scaling service under the hood—the same framework used by DynamoDB, Aurora, and ElastiCache. ECS service auto scaling supports target tracking, step scaling, and scheduled scaling policies.

Before adding scaling policies, register the ECS service as a scalable target in Application Auto Scaling. Specify the minimum and maximum task counts, the cluster name, and the service name as the resource ID. This creates the boundary within which auto scaling will operate. The minimum count ensures you always have baseline capacity; the maximum prevents runaway scaling from exhausting Fargate capacity or EC2 instances.

Target Tracking is the recommended auto scaling policy for most ECS services. The most common target metric is ECSServiceAverageCPUUtilization—set a target of 50-70% and ECS adds or removes tasks to maintain that CPU level. Another powerful metric is ALBRequestCountPerTarget: track the number of ALB requests per task and scale to maintain a target request rate per instance. AWS automatically handles scale-out and scale-in with appropriate cooldown periods.

Attaching an Application Load Balancer (ALB) to an ECS service distributes HTTP/HTTPS traffic across all running tasks. The ALB target group registers each task's IP (for Fargate/awsvpc) or container port (for bridge mode). ECS automatically registers new tasks with the target group as they start and deregisters them as they stop. The ALB performs health checks on each task; unhealthy tasks are drained (connections are closed gracefully) before the service terminates them.

One powerful pattern is routing different URL paths to different ECS services using ALB path-based routing. A single ALB with one HTTPS listener can route: /api/orders/* to the Orders ECS service, /api/users/* to the Users ECS service, /api/products/* to the Products ECS service—each backed by its own ECS service with independent scaling. This eliminates the need for separate load balancers per microservice, reducing cost and simplifying DNS management.

When an ECS task is being terminated (during scale-in or deployment), the ALB marks it as draining and stops routing new requests to it while allowing in-flight requests to complete. The deregistration delay (default 300 seconds, configurable 0-3600 seconds) is how long the ALB waits before forcefully closing connections. For ECS with short request durations, set a lower deregistration delay (30-60 seconds) to speed up deployments and scale-in operations. For long connections (WebSocket, file uploads), keep a higher delay.

Beyond CPU and memory, publish custom CloudWatch metrics from your application (queue depth, active sessions, business KPIs) and use them to drive scaling. For example, if each ECS task can handle 50 queue messages concurrently, publish the SQS queue depth as a custom metric and create a target tracking policy targeting 50 messages per task. This creates direct business-logic-driven scaling rather than relying on infrastructure metrics that may not correlate with application load.

Similar to EC2 Auto Scaling, ECS supports task scale-in protection. A running task can set its own scale-in protection flag via the ECS API to prevent itself from being terminated during scale-in while it's processing a critical job. This is useful for ECS tasks that act as SQS workers—a worker that just dequeued a long job can protect itself, complete the job, and then remove protection. Without this, scale-in might terminate a mid-processing task causing job duplication or data loss.

Choose your scaling metric carefully. CPU utilisation is the default and works for compute-bound workloads. Memory utilisation (ECSServiceAverageMemoryUtilization) is useful for memory-bound apps but scaling up memory requires adding tasks—if your task is limited by memory per task rather than concurrent processing, fixing the task definition's memory allocation may be better. ALBRequestCountPerTarget directly correlates to the user experience and is the most actionable metric for web APIs—scale based on actual request rate per task.

The ECS Deployment Circuit Breaker automatically detects failing deployments and rolls back to the last stable version. Without it, a bad deployment (container that fails health checks) would keep ECS trying to launch new tasks indefinitely. With the circuit breaker enabled, if a certain percentage of newly launched tasks fail health checks within a detection window, ECS marks the deployment as FAILED and automatically rolls back to the previous task definition revision. This prevents prolonged service degradation from bad deployments.

A production-ready containerised web API architecture: Route 53 resolves the domain to an ALB DNS name; the ALB terminates HTTPS (ACM certificate), applies WAF rules, and routes requests to an ECS service target group; Fargate tasks in private subnets across 3 AZs handle requests; ECS Service Auto Scaling with target tracking on ALBRequestCountPerTarget adjusts task count from 2 to 50; tasks connect to RDS Aurora and ElastiCache in private subnets. All logs go to CloudWatch Logs; metrics drive CloudWatch dashboards and alarms.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: ECS Service Auto Scaling uses Application Auto Scaling with target tracking (CPU, ALB requests, or custom metrics) to adjust task count between configured minimum and maximum bounds, ALB path-based routing enables one load balancer to serve multiple ECS microservices by routing URL paths to different target groups, and Deployment Circuit Breaker automatically rolls back failing deployments before they cause extended service degradation. This completes the ECS and containers module—next we explore Amazon EKS for Kubernetes on AWS.