Examkin

Question

Difficulty: Very hardAuto Scaling and Elasticity

A SysOps administrator is managing an asynchronous queue-processing application running on Amazon EC2 instances within an Auto Scaling group (ASG). The ASG has a minimum capacity of 00 and a maximum capacity of 1010. To scale dynamically based on the queue size of an Amazon SQS queue, the administrator configures a target tracking scaling policy using a custom CloudWatch metric named `BacklogPerInstance`. This metric is calculated as the queue's `ApproximateNumberOfMessages` divided by the ASG's running instance capacity.

During a period of inactivity, the ASG successfully scales down to 00 instances. However, when a new batch of messages is sent to the SQS queue, the ASG fails to launch any instances, leaving the messages unprocessed.

Which of the following actions should the SysOps administrator take to resolve this issue and ensure the ASG can scale out from 00 instances?

  1. Configure an additional step scaling policy based on the queue's `ApproximateNumberOfMessages` metric to launch 11 instance when the message count is greater than 00, while keeping the target tracking policy for subsequent scaling.Answer
  2. B
    Update the custom metric collection script running on the EC2 instances to publish a default `BacklogPerInstance` value of 100100 when the running instance capacity is 00.
  3. C
    Enable detailed monitoring on the EC2 instances within the launch template and configure the target tracking policy's custom CloudWatch alarm evaluation period to 11 minute.
  4. D
    Modify the target tracking scaling policy configuration to set the estimated instance warmup to 00 seconds and decrease the scale-in cooldown period.

Answer

Configure an additional step scaling policy based on the queue's `ApproximateNumberOfMessages` metric to launch 11 instance when the message count is greater than 00, while keeping the target tracking policy for subsequent scaling.
A target tracking scaling policy requires a valid metric value to function. When an Auto Scaling group scales down to 00 instances, a custom metric representing per-instance backlog becomes mathematically undefined because of division by zero. To resolve this, a step scaling policy based on the absolute queue size (`ApproximateNumberOfMessages`) should be configured to scale the ASG from 00 to 11 instance. Once 11 instance is running, the backlog metric can be calculated, allowing the target tracking policy to manage subsequent scaling.

Step-by-Step Solution

1
Analyze the scaling behavior of a target tracking policy based on backlog per instance when instance capacity is at 00.
The backlog per instance metric is calculated by dividing queue depth by the running instance count. With 00 instances running, the formula contains a division by zero. This makes the metric undefined in CloudWatch, preventing the target tracking policy from triggering a scale-out event.
To identify why the ASG fails to launch instances from a scaled-down state of 00.
2
Design a method to transition the ASG from 00 to 11 instance when messages arrive.
A step scaling policy does not rely on a per-instance ratio and can scale based on the absolute `ApproximateNumberOfMessages` metric. Configuring it to add 11 instance when the queue size is >0> 0 bypasses the division-by-zero issue.
To establish a reliable trigger that operates when no instances are running.
3
Integrate the step scaling policy with the target tracking policy for ongoing operation.
When the step scaling policy launches the first instance, the capacity becomes 11. At this point, the backlog per instance metric becomes defined and measurable, allowing the target tracking policy to resume scaling out or scaling in based on target workload thresholds.
To combine the cost benefits of scaling to 00 with the responsiveness of target tracking scaling under load.

Key Concept

Auto Scaling Scale-to-Zero SQS Queue Mechanics
Rate this question

Topics

Auto Scaling and Elasticity

More questions from this topic