ECS service auto scaling in AWS - Deep Dive

Overview - ECS service auto scaling

What is it?

ECS service auto scaling automatically adjusts the number of running containers in an Amazon ECS service based on demand. It helps keep your application responsive by adding more containers when traffic increases and reducing them when traffic decreases. This process happens without manual intervention, ensuring efficient use of resources. Auto scaling uses rules and metrics to decide when and how to scale.

Why it matters

Without ECS service auto scaling, you would have to guess how many containers your application needs and manually change that number. This can lead to slow responses during busy times or wasted money during quiet times. Auto scaling solves this by matching resources to real demand, improving user experience and saving costs. It also reduces the risk of downtime caused by too few containers.

Where it fits

Before learning ECS service auto scaling, you should understand basic ECS concepts like clusters, services, and tasks. After mastering auto scaling, you can explore advanced topics like custom scaling policies, integration with CloudWatch alarms, and multi-service scaling strategies.

Mental Model

Core Idea

ECS service auto scaling is like a smart thermostat that adjusts the number of containers running to keep your application comfortable under changing demand.

Think of it like...

Imagine a restaurant kitchen that adds more chefs when many customers arrive and sends some home when it’s quiet. ECS service auto scaling works the same way by adding or removing containers based on how busy your app is.

┌───────────────────────────────┐
│       ECS Service Auto Scaling │
├───────────────┬───────────────┤
│ Metrics       │ Scaling Rules │
│ (CPU, Memory, │ (Thresholds,  │
│ Requests)     │ Target Values)│
├───────────────┴───────────────┤
│       Adjust Number of Tasks   │
│  (Add or Remove Containers)   │
└───────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding ECS Services and Tasks

Concept: Learn what ECS services and tasks are and how they run containers.

An ECS service manages running copies of your application called tasks. Each task runs one or more containers. The service keeps the desired number of tasks running to serve your app. If a task stops, the service starts a new one to replace it.

Result

You know that ECS services control how many containers run your app and keep them healthy.

Understanding ECS services and tasks is essential because auto scaling changes the number of these tasks to match demand.

2

Foundation

Basics of Auto Scaling Concepts

Concept: Learn what auto scaling means and why it helps applications.

Auto scaling automatically changes the number of resources based on rules and metrics. For ECS, it changes how many tasks run. This helps apps handle more users without slowing down and saves money when fewer resources are needed.

Result

You grasp the basic idea that auto scaling adjusts resources automatically to keep apps efficient and responsive.

Knowing auto scaling basics prepares you to understand how ECS uses it to manage container counts.

3

Intermediate

Setting Up Target Tracking Scaling Policies

🤔Before reading on: do you think target tracking policies adjust tasks based on fixed numbers or dynamic metrics? Commit to your answer.

Concept: Target tracking policies automatically adjust tasks to keep a metric near a target value.

In ECS, you can create a target tracking policy that keeps CPU usage or request count near a set target. For example, keep average CPU at 50%. If CPU rises, ECS adds tasks; if it falls, ECS removes tasks. This policy uses CloudWatch metrics and adjusts smoothly.

Result

Your ECS service automatically scales tasks up or down to maintain the chosen metric near the target.

Understanding target tracking policies helps you create simple, effective auto scaling that reacts to real-time app load.

4

Intermediate

Using Step Scaling for Fine Control

🤔Before reading on: do you think step scaling changes tasks gradually or all at once? Commit to your answer.

Concept: Step scaling changes the number of tasks in steps based on how much a metric deviates from a threshold.

Step scaling lets you define multiple thresholds and how many tasks to add or remove at each step. For example, if CPU is 60%, add 1 task; if 80%, add 3 tasks. This gives more control over scaling behavior compared to target tracking.

Result

You can fine-tune scaling actions to respond differently depending on how busy your app is.

Knowing step scaling allows you to customize scaling for complex workloads and avoid sudden big changes.

5

Intermediate

Integrating CloudWatch Alarms with Scaling

Concept: Learn how CloudWatch alarms trigger scaling actions based on metrics.

CloudWatch monitors metrics like CPU or memory. You create alarms that watch these metrics and trigger scaling policies when thresholds are crossed. ECS uses these alarms to know when to add or remove tasks automatically.

Result

Your ECS service reacts to real-time performance data to scale tasks appropriately.

Understanding CloudWatch alarms is key because they connect your app’s health data to scaling decisions.

6

Advanced

Handling Scale-In Protection and Cooldowns

🤔Before reading on: do you think cooldown periods prevent or allow rapid scaling changes? Commit to your answer.

Concept: Learn how cooldowns and scale-in protection prevent too-frequent scaling and accidental task removal.

Cooldown periods pause scaling actions for a set time after a scale event to avoid rapid changes. Scale-in protection marks tasks to prevent them from being removed during scale-in, protecting important tasks. These features keep scaling stable and safe.

Result

Your ECS service scales smoothly without removing critical tasks or flapping between sizes.

Knowing cooldowns and protection prevents common scaling problems like instability and service disruption.

7

Expert

Advanced Scaling with Custom Metrics and Multiple Services

🤔Before reading on: can ECS auto scaling use custom business metrics or only CPU/memory? Commit to your answer.

Concept: Explore using custom CloudWatch metrics and coordinating scaling across multiple ECS services.

You can create custom metrics like request latency or queue length and use them in scaling policies. Also, when running multiple services that depend on each other, you can coordinate scaling to keep the whole system balanced. This requires careful metric design and policy setup.

Result

Your ECS services scale based on meaningful business signals and work together smoothly under load.

Understanding custom metrics and multi-service scaling unlocks powerful, real-world scaling strategies beyond simple CPU or memory triggers.

Under the Hood

ECS service auto scaling works by monitoring CloudWatch metrics continuously. When a metric crosses a defined threshold, CloudWatch alarms trigger scaling policies. These policies call the ECS API to adjust the desired count of tasks in the service. ECS then launches or stops tasks to match the new desired count. Cooldown periods and scale-in protection help manage timing and task safety during scaling.

Why designed this way?

This design separates monitoring (CloudWatch) from scaling decisions (policies) and execution (ECS service). It allows flexibility to use many metrics and customize scaling behavior. The use of alarms and policies decouples components for reliability and easier updates. Alternatives like manual scaling or fixed schedules were less responsive and efficient.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ CloudWatch    │──────▶│ CloudWatch    │──────▶│ ECS Service   │
│ Metrics       │       │ Alarms        │       │ Desired Count │
└───────────────┘       └───────────────┘       └───────────────┘
                                │                       │
                                ▼                       ▼
                       ┌───────────────┐       ┌───────────────┐
                       │ Scaling       │       │ ECS Scheduler │
                       │ Policies      │       │ Launch/Stop   │
                       └───────────────┘       └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does ECS service auto scaling instantly add tasks the moment CPU spikes? Commit to yes or no.

Common Belief: ECS auto scaling instantly adds tasks as soon as CPU usage goes up.

Reality: Scaling actions take time due to cooldown periods and task startup delays; scaling is not instant.

Why it matters: Expecting instant scaling can lead to confusion and poor planning for traffic spikes, causing temporary slowdowns.

Quick: Can ECS auto scaling remove tasks that are still processing important requests? Commit to yes or no.

Common Belief: Auto scaling can remove any task at any time, even if it is busy.

Reality: Scale-in protection can prevent removal of tasks that are critical or still handling requests.

Why it matters: Without protection, scaling in could disrupt user sessions or cause errors.

Quick: Does ECS auto scaling only work with CPU and memory metrics? Commit to yes or no.

Common Belief: ECS auto scaling only supports CPU and memory metrics for scaling decisions.

Reality: You can use custom CloudWatch metrics like request count or latency for scaling.

Why it matters: Limiting to CPU/memory misses opportunities to scale based on real business needs.

Quick: Does setting a high desired count guarantee your app will handle any load? Commit to yes or no.

Common Belief: Setting a high desired count means your app can handle unlimited traffic without issues.

Reality: Other factors like container startup time, backend limits, and network can still cause bottlenecks.

Why it matters: Over-relying on task count can lead to false confidence and unexpected failures.

Expert Zone

1

Scaling policies can be combined and layered, but their interactions can cause unexpected scaling behavior if not carefully tested.

2

Cooldown periods must be tuned to balance responsiveness and stability; too short causes flapping, too long delays scaling.

3

Custom metrics require careful design and reliable reporting to avoid scaling on noisy or incorrect data.

When NOT to use

ECS service auto scaling is not ideal for workloads with very unpredictable or spiky traffic that requires instant scaling; consider AWS Lambda or serverless architectures instead. Also, for very simple or static workloads, manual scaling may be simpler and cheaper.

Production Patterns

In production, teams often use target tracking for CPU combined with custom metrics like queue length. They implement scale-in protection for critical tasks and use CloudWatch dashboards to monitor scaling events. Multi-service applications coordinate scaling with event-driven triggers or AWS Step Functions.

Connections

Load Balancing

ECS auto scaling works closely with load balancers to distribute traffic evenly across tasks.

Understanding load balancing helps grasp why scaling tasks improves performance and availability.

Serverless Computing

Serverless platforms automatically scale functions similar to ECS auto scaling but without managing containers.

Knowing serverless scaling concepts clarifies the benefits and limits of container-based auto scaling.

Thermostat Control Systems

Both use feedback loops to maintain a target state by adjusting resources based on measurements.

Recognizing feedback control principles helps understand how scaling policies maintain application performance.

Common Pitfalls

#1 Setting scaling policies without cooldown periods causes rapid scaling up and down.

Wrong approach:

CreateScalingPolicy --policy-name "ScaleUp" --adjustment 2 --cooldown 0

Correct approach:

CreateScalingPolicy --policy-name "ScaleUp" --adjustment 2 --cooldown 300

Root cause:

Ignoring cooldowns leads to scaling flapping, wasting resources and causing instability.

#2 Using only CPU utilization as a metric when the app is bottlenecked on request latency.

Wrong approach:

SetTargetTrackingScalingPolicy --target-metric CPUUtilization --target-value 50

Correct approach:

SetTargetTrackingScalingPolicy --target-metric CustomRequestLatency --target-value 100

Root cause:

Choosing irrelevant metrics causes scaling to miss real performance issues.

#3 Not enabling scale-in protection on tasks handling long-running requests.

Wrong approach:

No scale-in protection configured; tasks get terminated during scale-in.

Correct approach:

EnableScaleInProtection on tasks processing critical requests.

Root cause:

Lack of protection causes service interruptions and user errors.

Key Takeaways

ECS service auto scaling automatically adjusts the number of running containers to match application demand, improving performance and cost efficiency.

It uses CloudWatch metrics and alarms combined with scaling policies to decide when and how to scale tasks.

Target tracking and step scaling policies offer different ways to control scaling behavior based on metrics.

Cooldown periods and scale-in protection are essential to prevent unstable scaling and protect important tasks.

Advanced use includes custom metrics and coordinating scaling across multiple services for complex applications.

Practice

1. What is the main purpose of ECS service auto scaling?

easy

A. Store container logs for analysis

B. Manually start and stop containers

C. Automatically adjust the number of running containers based on demand

D. Create new ECS clusters automatically

Solution

1. Step 1: Understand ECS service auto scaling function

   ECS service auto scaling changes the number of containers automatically to match workload.

2. Step 2: Compare options to this function

   Only Automatically adjust the number of running containers based on demand describes automatic adjustment of container count based on demand.

3. Final Answer:

   Automatically adjust the number of running containers based on demand -> Option C

4. Quick Check:

   Auto scaling adjusts container count = Automatically adjust containers [OK]

Hint: Auto scaling means automatic container count changes [OK]

Common Mistakes:

• Confusing auto scaling with manual container management
• Thinking auto scaling creates clusters
• Believing auto scaling stores logs

2. Which of the following is the correct way to specify a target tracking scaling policy for CPU utilization in ECS service auto scaling?

easy

A. "TargetValue": 50, "PredefinedMetricSpecification": {"PredefinedMetricType": "ECSServiceAverageCPUUtilization"}

B. "TargetValue": "high", "PredefinedMetricSpecification": {"PredefinedMetricType": "CPUUsage"}

C. "TargetValue": 100, "MetricName": "MemoryUtilization"

D. "TargetValue": 30, "PredefinedMetricSpecification": {"PredefinedMetricType": "NetworkIn"}

Solution

1. Step 1: Identify correct metric type for CPU utilization

   The predefined metric for ECS CPU is "ECSServiceAverageCPUUtilization" with a numeric target value.

2. Step 2: Check option syntax and metric correctness

   "TargetValue": 50, "PredefinedMetricSpecification": {"PredefinedMetricType": "ECSServiceAverageCPUUtilization"} uses correct metric type and numeric target value 50, which is valid.

3. Final Answer:

   "TargetValue": 50, "PredefinedMetricSpecification": {"PredefinedMetricType": "ECSServiceAverageCPUUtilization"} -> Option A

4. Quick Check:

   Correct metric and numeric target = "TargetValue": 50, "PredefinedMetricSpecification": {"PredefinedMetricType": "ECSServiceAverageCPUUtilization"} [OK]

Hint: Use numeric target and correct predefined metric name [OK]

Common Mistakes:

• Using string instead of number for TargetValue
• Using wrong metric names like CPUUsage
• Mixing memory or network metrics for CPU scaling

3. Given this ECS service auto scaling configuration snippet:

{"MinCapacity": 2, "MaxCapacity": 5, "TargetValue": 60}

What happens when CPU utilization stays at 70% for a long time?

medium

A. The service scales up to 5 containers to reduce CPU load

B. The service scales down to 2 containers to save cost

C. The service keeps running 2 containers without change

D. The service crashes due to high CPU

Solution

1. Step 1: Understand scaling triggers from CPU target

   TargetValue 60 means ECS tries to keep CPU near 60%. If CPU is 70%, it needs more containers.

2. Step 2: Apply min and max capacity limits

   Min is 2, max is 5. Scaling up is allowed up to 5 containers to reduce CPU load.

3. Final Answer:

   The service scales up to 5 containers to reduce CPU load -> Option A

4. Quick Check:

   CPU above target scales up containers = The service scales up to 5 containers to reduce CPU load [OK]

Hint: CPU above target scales up, below scales down [OK]

Common Mistakes:

• Thinking service scales down when CPU is high
• Ignoring max capacity limit
• Assuming service crashes on high CPU

4. You configured ECS service auto scaling but the service never scales out even when CPU is high. What is a likely cause?

medium

A. The service has no load balancer attached

B. The target CPU utilization is set to 100%

C. The ECS cluster has no running tasks

D. The maximum capacity is set equal to the minimum capacity

Solution

1. Step 1: Analyze scaling limits

   If max capacity equals min capacity, no room to scale out exists.

2. Step 2: Check other options

   Target 100% means scaling triggers only at max CPU, but scaling can still happen. No running tasks or load balancer affect service but not scaling limits directly.

3. Final Answer:

   The maximum capacity is set equal to the minimum capacity -> Option D

4. Quick Check:

   Max equals min blocks scaling out = The maximum capacity is set equal to the minimum capacity [OK]

Hint: Max capacity must be greater than min capacity to scale out [OK]

Common Mistakes:

• Ignoring max and min capacity settings
• Assuming load balancer affects scaling triggers
• Confusing target CPU with scaling limits

5. You want to configure ECS service auto scaling to keep container count between 3 and 10, scaling based on memory usage targeting 70%. Which configuration is correct?

hard

A. MinCapacity: 10, MaxCapacity: 3, TargetValue: 70, PredefinedMetricType: ECSServiceAverageMemoryUtilization

B. MinCapacity: 3, MaxCapacity: 10, TargetValue: 70, PredefinedMetricType: ECSServiceAverageMemoryUtilization

C. MinCapacity: 3, MaxCapacity: 10, TargetValue: 70, PredefinedMetricType: ECSServiceAverageCPUUtilization

D. MinCapacity: 3, MaxCapacity: 10, TargetValue: 30, PredefinedMetricType: ECSServiceAverageMemoryUtilization

Solution

1. Step 1: Set correct min and max container counts

   MinCapacity must be less than MaxCapacity, so 3 and 10 is valid, 10 and 3 is invalid.

2. Step 2: Use correct metric and target value for memory

   Memory scaling uses ECSServiceAverageMemoryUtilization with target 70% to trigger scaling.

3. Step 3: Verify options

   MinCapacity: 3, MaxCapacity: 10, TargetValue: 70, PredefinedMetricType: ECSServiceAverageMemoryUtilization matches all requirements: correct min/max, target 70, memory metric.

4. Final Answer:

   MinCapacity: 3, MaxCapacity: 10, TargetValue: 70, PredefinedMetricType: ECSServiceAverageMemoryUtilization -> Option B

5. Quick Check:

   Correct min/max and memory target = MinCapacity: 3, MaxCapacity: 10, TargetValue: 70, PredefinedMetricType: ECSServiceAverageMemoryUtilization [OK]

Hint: Min < Max and match metric to resource (memory or CPU) [OK]

Common Mistakes:

• Setting max less than min capacity
• Using CPU metric for memory scaling
• Setting wrong target value for scaling