Examkin

Soru

Zorluk: Çok zorImplementing Auto Scaling and Fault Tolerance

A digital media platform hosts a live-streaming transcoding application on Amazon EC2 instances in an Auto Scaling group (ASG) behind an Application Load Balancer (ALB). The instances are deployed across three Availability Zones (AZ−AAZ-A, AZ−BAZ-B, and AZ−CAZ-C) in private subnets. Outbound connectivity to external video ingestion APIs is routed through a single NAT Gateway located in AZ−AAZ-A.

During scheduled major sporting events, traffic spikes instantly from 500500 to 80,00080,000 requests per second. During these events, two major failures occur:
1. The ALB drops initial connections with HTTP 502502 and 503503 errors.
2. The ASG launches a large number of instances that remain in a pending state while downloading and compiling transcoding binaries (which takes 77 minutes). Because the average CPU utilization remains high during this startup window, the ASG continuously launches more instances than required, causing a severe cost overrun.

The company requires a solution that eliminates connection drops, prevents over-provisioning during scale-out, and ensures that outbound connectivity is resilient to an Availability Zone outage. Which solution meets these requirements with the lowest operational overhead?

  1. A
    Configure an Amazon CloudFront distribution in front of the ALB to cache dynamic transcoding requests. Increase the ASG's default cooldown period to 480480 seconds and configure a step scaling policy based on CPU utilization. Deploy a NAT Gateway in each of the three Availability Zones, and update the route table of each private subnet to route outbound traffic through its local NAT Gateway.
  2. B
    Request AWS Support to pre-warm the ALB based on the expected traffic profile. Configure a lifecycle hook for the ASG to keep instances in the `Pending:Wait` state while compiling binaries, and complete the lifecycle action once healthy. Configure a target tracking scaling policy with an `EstimatedInstanceWarmup` of 120120 seconds. Deploy a single NAT Gateway in AZ−BAZ-B, and update the route tables of private subnets in AZ−AAZ-A and AZ−CAZ-C to use the NAT Gateway in AZ−BAZ-B as a backup if AZ−AAZ-A fails.
  3. Request AWS Support to pre-warm the ALB based on the expected traffic profile. Configure a lifecycle hook for the ASG to keep instances in the `Pending:Wait` state while compiling binaries, and complete the lifecycle action once healthy. Configure a target tracking scaling policy with an `EstimatedInstanceWarmup` of 480480 seconds. Deploy a NAT Gateway in each of the three Availability Zones, and update the route table of each private subnet to route outbound traffic through its local NAT Gateway.Cevap
  4. D
    Request AWS Support to pre-warm the ALB based on the expected traffic profile. Configure a lifecycle hook for the ASG to keep instances in the `Pending:Wait` state while compiling binaries, and complete the lifecycle action once healthy. Configure a target tracking scaling policy with an `EstimatedInstanceWarmup` of 480480 seconds. Update the route tables of all private subnets to route outbound traffic through a Transit Gateway connected to a central VPC containing a single NAT Gateway in AZ−AAZ-A.

Cevap

Request AWS Support to pre-warm the ALB, configure an ASG lifecycle hook to wait for instance initialization, set the target tracking EstimatedInstanceWarmup to 480 seconds, and deploy local NAT Gateways across all three Availability Zones.
The correct option addresses all three issues in the architectural scenario. First, requesting AWS Support to pre-warm the ALB ensures that the load balancer can handle the massive burst of traffic without dropping connections. Second, using an ASG lifecycle hook allows instances to complete their 77-minute binary compilation before receiving traffic, and setting `EstimatedInstanceWarmup` to 480480 seconds (88 minutes) ensures the target tracking policy does not include these initializing instances in metric evaluations, preventing over-provisioning. Finally, deploying a NAT Gateway in each Availability Zone removes the single point of failure for outbound traffic.

Adım Adım Çözüm

1
Request Application Load Balancer pre-warming from AWS Support.
Ensures the ALB has pre-provisioned capacity to handle the sudden burst of traffic from 500500 to 80,00080,000 requests per second.
Prevents HTTP 502/503 errors caused by the ALB's normal scaling lag when hit with an instantaneous flash traffic spike.
2
Configure an ASG lifecycle hook and set the scaling policy's EstimatedInstanceWarmup parameter.
Pauses the scaling state transition until bootstrapping completes, and instructs target tracking to exclude launching instances from metric evaluations for 480480 seconds.
Ensures that newly launched instances are not included in the metrics used for scaling decisions until they are fully initialized, preventing rapid over-provisioning and cost overruns during the 77-minute startup window.
3
Deploy a dedicated NAT Gateway in each of the three Availability Zones.
Outbound traffic from each AZ's private subnet is routed through a local NAT Gateway.
Eliminates the single point of failure in AZ−AAZ-A, ensuring that an outage in one AZ does not impact outbound connectivity for instances in the remaining healthy zones.

Anahtar Kavram

Auto Scaling Group scaling policies and warmup configurations combined with load balancer pre-warming and multi-AZ NAT gateway redundancy.
Bu soruyu puanla

Konular

Implementing Auto Scaling and Fault Tolerance