Study guide
Technical reference and lesson notes
Purpose of This Lesson
Amazon ECS has two distinct scaling layers:
- Service autoscaling changes the number of running ECS tasks.
- Cluster autoscaling changes the number of EC2 container instances available to run those tasks.
Understanding which layer needs to scale is essential for selecting the correct AWS configuration and avoiding a common exam mistake: increasing task count when the cluster has insufficient host capacity, or adding EC2 instances when the application needs more task replicas.
Key Concepts
ECS Service Autoscaling
ECS service autoscaling uses AWS Application Auto Scaling to adjust the service’s desired task count. It responds to workload demand at the application or task level.
For example, if average task CPU utilization becomes too high, the service can increase the desired count from three tasks to four or more. ECS then places the additional tasks on available container instances.
Service autoscaling supports several policy types:
- Target tracking scaling: Maintains a selected metric near a target value, such as average CPU utilization.
- Step scaling: Adds or removes different numbers of tasks according to the size of a CloudWatch alarm breach.
- Scheduled scaling: Adjusts capacity at known times, such as before a predictable daily traffic increase.
Service autoscaling does not automatically provide more EC2 host capacity. If the cluster is full, new tasks may remain pending until additional container instances become available.
ECS Cluster Autoscaling
Cluster autoscaling addresses the capacity of the infrastructure running ECS tasks. In an EC2 launch type cluster, this means adjusting the number of ECS container instances.
ECS cluster autoscaling uses an ECS capacity provider associated with an EC2 Auto Scaling group. The capacity provider tracks the relationship between the capacity required by tasks and the capacity available in the Auto Scaling group.
A key metric is capacity provider reservation, which represents how much of the capacity provider’s available capacity is being reserved by ECS tasks. When the cluster requires more capacity, managed scaling can cause the associated Auto Scaling group to launch additional EC2 instances. ECS then detects the new container instance and can place pending or newly scheduled tasks on it.
Cluster autoscaling therefore operates at the host-capacity layer rather than directly changing the desired count of tasks.
Managed Scaling and Managed Instance Termination Protection
Capacity providers can use managed scaling to help maintain enough EC2 capacity for ECS tasks.
They can also use managed instance termination protection. This helps prevent the Auto Scaling group from terminating an EC2 container instance that still has running ECS tasks, reducing the risk of disrupting task placement during scale-in.
These features solve different problems:
- Managed scaling helps add or remove container instances based on ECS capacity requirements.
- Managed termination protection helps coordinate scale-in with task placement and running workloads.
Architecture Decision Guide
| Requirement | Correct scaling layer or feature | Result |
|---|---|---|
| Application traffic increases and existing hosts have spare capacity | ECS service autoscaling | Increases the desired number of tasks |
| Average task CPU or memory should remain near a target | Target tracking service autoscaling | Adjusts task count toward a target metric |
| Different workload levels require different task increments | Step scaling | Adds or removes tasks based on alarm breach magnitude |
| Traffic follows a predictable schedule | Scheduled scaling | Changes task count at defined times |
| Tasks cannot be placed because EC2 hosts lack capacity | ECS cluster autoscaling with a capacity provider | Scales the EC2 Auto Scaling group |
| ECS must coordinate EC2 capacity with task requirements | Capacity provider managed scaling | Helps maintain appropriate container-instance capacity |
| EC2 scale-in could terminate instances running tasks | Managed instance termination protection | Helps protect active task placement during termination |
A complete EC2-backed ECS design may need both layers:
- Service autoscaling adjusts how many task replicas are required.
- Cluster autoscaling adjusts how many EC2 container instances are needed to run those tasks.
Exam-Relevant Takeaways
- Service autoscaling scales tasks; cluster autoscaling scales container instances.
- ECS service autoscaling is provided through AWS Application Auto Scaling.
- Service scaling policies include target tracking, step scaling, and scheduled scaling.
- ECS cluster autoscaling for EC2 capacity uses a capacity provider connected to an EC2 Auto Scaling group.
- Capacity provider reservation is used to assess the capacity required by ECS tasks relative to the associated capacity provider.
- Scaling the service does not guarantee that new tasks can start if the cluster has no free resources.
- Scaling the cluster adds host capacity but does not, by itself, increase the desired task count for an ECS service.
- Managed instance termination protection helps prevent scale-in from removing container instances that still host running tasks.
- In scenario questions, first identify whether the bottleneck is task-level demand or underlying compute capacity.
Common Exam Traps
Confusing Task Scaling With Instance Scaling
Increasing an ECS service’s desired count creates more task replicas. It does not automatically mean that additional EC2 container instances will be launched unless cluster capacity is also configured to scale.
Scaling the Cluster When the Application Needs More Replicas
Adding EC2 instances provides room for tasks but does not increase the number of tasks serving requests. If the requirement is to maintain application capacity as CPU utilization rises, service autoscaling is the relevant control.
Assuming Capacity Providers Replace Service Autoscaling
A capacity provider manages or reports infrastructure capacity. It is not a substitute for configuring ECS service desired-count scaling.
Selecting Step Scaling for Predictable Traffic
Step scaling reacts to CloudWatch alarm thresholds. If demand is reliably predictable by time of day, scheduled scaling is usually the more direct solution.
Ignoring Scale-In Safety
An Auto Scaling group can attempt to terminate an EC2 instance during scale-in. For ECS workloads, termination protection and appropriate task draining behavior are important to avoid disrupting tasks that are still running.
Real-World Engineer Notes
- Configure service autoscaling and cluster autoscaling as complementary controls when using the ECS EC2 launch type.
- Verify that the EC2 instance type and ECS task definitions provide enough CPU and memory granularity for effective placement. A cluster may have unused aggregate capacity but still fail to place a task if no individual instance has the required resources.
- CloudWatch metrics and alarms are central to diagnosing scaling behavior. Check whether the service is failing to request more tasks or whether ECS cannot place requested tasks.
- A pending-task problem does not always indicate insufficient total EC2 capacity; placement constraints, task resource requirements, and deployment settings can also be involved.
- Scheduled scaling is useful for known demand patterns, while target tracking is generally better for variable demand.
- Managed termination protection reduces unsafe instance termination but should be considered alongside graceful task draining, deployment configuration, and application resilience.
Quick Reference Summary
- Service autoscaling: changes ECS task count.
- Cluster autoscaling: changes EC2 container-instance count.
- Application Auto Scaling: controls ECS service desired task count.
- Capacity provider: connects ECS task capacity requirements with an EC2 Auto Scaling group.
- Target tracking: maintains a metric near a target.
- Step scaling: uses alarm breach magnitude to determine the scaling adjustment.
- Scheduled scaling: changes capacity at predetermined times.
- Managed scaling: helps the Auto Scaling group provide sufficient ECS host capacity.
- Managed termination protection: helps avoid terminating instances that still run ECS tasks.
Flashcards
- Q: What does ECS service autoscaling change?
A: The desired number of running tasks in an ECS service.
- Q: What does ECS cluster autoscaling change in an EC2-backed cluster?
A: The number of EC2 ECS container instances.
- Q: Which AWS service implements ECS service autoscaling?
A: AWS Application Auto Scaling.
- Q: What are the three service autoscaling policy types covered in this lesson?
A: Target tracking, step scaling, and scheduled scaling.
- Q: When is target tracking appropriate?
A: When capacity should be adjusted to keep a metric near a defined target, such as average task CPU utilization.
- Q: How does step scaling determine the adjustment?
A: The size of the CloudWatch alarm breach determines how many tasks should be added or removed.
- Q: What ECS resource connects an EC2 Auto Scaling group to ECS cluster capacity management?
A: An ECS capacity provider.
- Q: What does capacity provider reservation indicate?
A: The capacity required or reserved by ECS tasks relative to the capacity provider’s available capacity.
- Q: Does service autoscaling launch new EC2 instances?
A: Not by itself. Cluster capacity must be provided separately, typically through a capacity provider and Auto Scaling group.
- Q: What problem does managed instance termination protection address?
A: It helps prevent the Auto Scaling group from terminating container instances that still have running ECS tasks.
Practice Questions
Question 1
An ECS service running on an EC2-backed cluster experiences increasing request volume. Average CPU utilization across the service’s tasks exceeds the desired threshold, but the container instances have sufficient free resources. What should the architect configure?
A. Increase the EC2 Auto Scaling group’s minimum size only
B. Configure ECS service target tracking autoscaling
C. Enable managed instance termination protection
D. Configure a capacity provider without service autoscaling
Correct answer: B
Explanation: The issue is increased application demand and the hosts have spare capacity. ECS service target tracking autoscaling can increase the desired task count while maintaining task CPU utilization near the target.
Question 2
An ECS service’s desired task count increases successfully, but several new tasks remain pending because the existing EC2 container instances cannot provide enough resources. Which design addresses the infrastructure bottleneck?
A. Configure cluster autoscaling through an ECS capacity provider associated with an Auto Scaling group
B. Replace target tracking with scheduled service scaling
C. Reduce the service’s desired task count
D. Enable CloudWatch Logs for the ECS service
Correct answer: A
Explanation: Service autoscaling has already requested more tasks, but the cluster lacks placement capacity. A capacity provider with managed scaling can cause the associated EC2 Auto Scaling group to add container instances.
Question 3
A workload receives a predictable traffic surge every weekday at 09:00. The architect wants additional ECS tasks running before the surge begins and fewer tasks after business hours. Which service scaling approach is most appropriate?
A. Step scaling based on a CPU alarm after the surge begins
B. Scheduled scaling for the ECS service
C. Managed instance termination protection only
D. Cluster autoscaling without changing the service desired count
Correct answer: B
Explanation: Scheduled scaling is designed for predictable demand at known times. Cluster autoscaling alone would add host capacity but would not necessarily increase the service’s task count.
Question 4
An EC2 Auto Scaling group used by an ECS capacity provider begins scaling in. The architect wants to reduce the possibility that an instance hosting active ECS tasks is terminated. Which capacity-provider capability is relevant?
A. Target tracking service scaling
B. Capacity provider reservation
C. Managed instance termination protection
D. Scheduled task scaling
Correct answer: C
Explanation: Managed instance termination protection helps coordinate Auto Scaling group scale-in with ECS task placement by protecting instances that still have running tasks.