ECS service auto scaling in AWS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

ECS Service Auto Scaling Behavior

What happens when an ECS service's auto scaling policy triggers a scale-out action?

A The ECS service scales the underlying EC2 instances but does not change the number of tasks.

B The ECS service stops existing tasks before launching new ones to maintain the current count.

C The ECS service queues scaling requests and applies them only during the next deployment.

D The ECS service immediately launches new tasks to match the desired count set by the scaling policy.

💡 Hint

Think about how ECS manages task counts when scaling.

When an ECS service auto scaling policy triggers a scale-out, ECS immediately launches new tasks to reach the new desired count.

❓ Configuration

intermediate

Configuring ECS Service Auto Scaling Target

Which AWS resource must you specify as the scalable target when configuring ECS service auto scaling?

A The ECS task definition revision number as a scalable target with resource ID format: taskdef/task-def-name

B The ECS service's task count as a scalable target with resource ID format: service/cluster-name/service-name

C The ECS cluster's EC2 instance count as a scalable target with resource ID format: cluster/cluster-name

D The ECS service's load balancer target group as a scalable target with resource ID format: targetgroup/target-group-name

💡 Hint

Auto scaling targets the number of tasks running in the service.

The scalable target for ECS service auto scaling is the ECS service's task count, identified by the resource ID format service/cluster-name/service-name.

❓ Architecture

advanced

Designing ECS Auto Scaling with CloudWatch Alarms

You want to scale your ECS service based on CPU usage. Which architecture component is essential to trigger scaling actions?

A A CloudWatch alarm monitoring the ECS service CPU utilization that triggers a scaling policy.

B An AWS Lambda function that polls ECS tasks and adjusts the desired count manually.

C An S3 event notification that triggers scaling when new objects are uploaded.

D A Route 53 health check that disables scaling when the service is unhealthy.

💡 Hint

Auto scaling reacts to metrics monitored by CloudWatch alarms.

CloudWatch alarms monitor CPU usage and trigger scaling policies to adjust ECS service task counts automatically.

❓ security

advanced

IAM Permissions for ECS Auto Scaling

Which IAM permission is required for an ECS service auto scaling role to update the desired task count?

A "cloudwatch:PutMetricAlarm" permission on CloudWatch alarms.

B "autoscaling:CreateScalingPolicy" permission on the Auto Scaling group.

C "ecs:UpdateService" permission on the ECS service resource.

D "ec2:RunInstances" permission on the EC2 instances.

💡 Hint

Think about what action changes the number of running tasks.

The ECS service auto scaling role needs "ecs:UpdateService" permission to change the desired count of tasks in the service.

✅ Best Practice

expert

Best Practice for ECS Service Auto Scaling Cooldown Period

What is the best practice for setting the cooldown period in ECS service auto scaling policies?

A Set the cooldown period to allow enough time for tasks to start and stabilize before another scaling action.

B Set the cooldown period to zero to allow immediate consecutive scaling actions for fast response.

C Set the cooldown period longer than the deployment time of the ECS service to avoid any scaling.

D Set the cooldown period to match the CloudWatch alarm evaluation period regardless of task startup time.

💡 Hint

Consider how quickly tasks become healthy after scaling.

The cooldown period should be long enough to let new tasks start and stabilize, preventing rapid scaling fluctuations.

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