Question

Difficulty: MediumImplementing Auto Scaling and Fault Tolerance

An e-commerce company operates a flash sales portal on AWS. The application is hosted on Amazon EC2 instances in an Auto Scaling Group (ASG) across three Availability Zones behind an Application Load Balancer (ALB). The instances require outbound internet access to verify payment transactions via third-party APIs. Currently, all private subnets route outbound traffic through a single NAT Gateway located in Availability Zone A.

During scheduled flash sales, the following issues occur:
- The ALB drops incoming requests and returns HTTP 503 service unavailable errors during the first few minutes of the sale.
- The ASG launches more instances than required during scale-out because the custom bootstrapping script takes 7 minutes to complete, which is longer than the ASG's default cooldown period of 300 seconds.
- An outage in Availability Zone A recently blocked all outbound internet traffic for the instances in the other zones.

Which combination of actions should a Solutions Architect implement to resolve these issues?

  1. Deploy a NAT Gateway in each Availability Zone, and update the private subnet route tables to use the corresponding local NAT Gateway. Submit a request to AWS Support to pre-warm the ALB prior to the scheduled flash sales. Configure an Auto Scaling lifecycle hook to keep new instances in the pending state until the bootstrapping script completes.Answer
  2. B
    Keep the single NAT Gateway in Availability Zone A and enable Multi-AZ replication on it to protect against zone failures. Rely on the ALB's built-in automatic scaling to handle the sudden flash traffic. Increase the default cooldown period of the Auto Scaling Group to 600 seconds.
  3. C
    Deploy a NAT Gateway in each Availability Zone, and update the private subnet route tables to use the corresponding local NAT Gateway. Configure the ALB with a dynamic target tracking policy based on RequestCountPerTarget to scale the load balancer. Decrease the default cooldown period of the Auto Scaling Group to 180 seconds.
  4. D
    Deploy a NAT Gateway in each Availability Zone, and create a single route table shared by all private subnets that points to all NAT Gateways. Submit a request to AWS Support to pre-warm the ALB prior to the scheduled flash sales. Decrease the default cooldown period of the Auto Scaling Group to 200 seconds.

Answer

Deploy a NAT Gateway in each Availability Zone, configure zonal routing for the private subnets, request ALB pre-warming from AWS Support, and configure an Auto Scaling lifecycle hook to manage bootstrapping delays.
The correct solution resolves all three architectural bottlenecks. First, deploying a NAT Gateway in each Availability Zone and creating separate route tables for each subnet isolates the outbound path, ensuring that a zonal outage does not disrupt traffic in other zones. Second, requesting ALB pre-warming ensures that the load balancer is ready for instant flash traffic spikes, avoiding HTTP 503 errors. Third, implementing an Auto Scaling lifecycle hook prevents the ASG from evaluating scaling policy actions while an instance is still bootstrapping, which eliminates over-provisioning caused by a bootstrapping duration that exceeds the cooldown period.

Step-by-Step Solution

1
Address the NAT Gateway single point of failure.
A NAT Gateway is deployed in each of the three Availability Zones, and the private subnet route tables are updated to point their 0.0.0.0/0 route to their local zonal NAT Gateway.
This isolates outbound failure domains to each individual Availability Zone, preventing an outage in one zone from affecting outbound traffic in other zones.
2
Address the immediate ALB scaling latency.
Submit an AWS support ticket to pre-warm the ALB to the expected capacity prior to the scheduled flash sale start times.
Standard ALB scaling is reactive and gradual. Pre-warming ensures the load balancer has enough capacity provisioned to handle the sudden, massive traffic spike without dropping connections.
3
Resolve the ASG over-provisioning (thrashing) issue during bootstrapping.
Configure an Auto Scaling lifecycle hook (e.g., EC2_INSTANCE_LAUNCHING) that puts the instance in a 'Pending:Wait' state while bootstrapping runs.
Using a lifecycle hook ensures that the ASG does not count the instance as 'InService' or initiate subsequent cooldown/scaling evaluations until the custom script has finished executing and sent a success signal.

Key Concept

Auto Scaling lifecycle hooks, zonal network redundancy, and load balancer scaling characteristics.
Rate this question