Question

Difficulty: HardImplementing Auto Scaling and Fault Tolerance

A medical healthcare provider hosts a critical real-time telemedicine and remote patient monitoring platform on Amazon EC2 instances. The instances are deployed within an Auto Scaling group (ASG) across three Availability Zones (AZ-AAZ\text{-}A, AZ-BAZ\text{-}B, and AZ-CAZ\text{-}C) in private subnets. Outbound internet access is required for downloading updates and communicating with third-party medical API endpoints. A single Application Load Balancer (ALB) distributes incoming traffic to the EC2 instances.

During seasonal scheduling windows, the platform experiences sudden, near-instantaneous traffic spikes of up to 25 times25\text{ times} the baseline volume within a 3-minute3\text{-minute} window. During these surges, the following issues are observed:
- The ALB drops a significant portion of incoming requests during the initial minutes of the surge.
- The EC2 instances take approximately 10-minutes10\text{-minutes} to bootstrap (install medical compliance agents and load local cache files). During this startup period, the ASG continues to launch additional unnecessary instances, leading to extreme over-provisioning.
- A transient outage in AZ-AAZ\text{-}A disabled its NAT Gateway, which subsequently caused all outbound API calls from instances in AZ-BAZ\text{-}B and AZ-CAZ\text{-}C to fail because their route tables directed all internet-bound traffic through the NAT Gateway in AZ-AAZ\text{-}A.

Which two actions should a Solutions Architect implement to resolve these scaling and reliability issues? (Select TWO.)

  1. Deploy a NAT Gateway in a public subnet in each Availability Zone, and configure the route tables of the private subnets to route outbound traffic through the NAT Gateway in their respective Availability Zone.Answer
  2. Create a custom Amazon Machine Image (AMI) containing the compliance agents and pre-loaded cache files, and configure an Auto Scaling group warm pool with instances in the Stopped state to serve as pre-initialized capacity.Answer
  3. C
    Decrease the default cooldown period of the Auto Scaling group to 60 seconds to allow the scaling policy to quickly launch new instances in response to the sudden CPU utilization spikes.
  4. D
    Configure a single NAT Gateway in a shared services VPC, and establish VPC peering connections from the application VPC to route all outbound traffic through the shared NAT Gateway to ensure centralized redundancy.
  5. E
    Rely on the ALB's default elastic scaling behavior to dynamically adjust to the traffic spikes, and configure the Auto Scaling group's target tracking policy with a low CPU utilization threshold of 20% to trigger earlier scaling.

Answer

The Solutions Architect should deploy a NAT Gateway in a public subnet in each Availability Zone and route outbound traffic locally, and create a custom AMI paired with an Auto Scaling group warm pool containing stopped instances.
Deploying a dedicated NAT Gateway per Availability Zone removes cross-AZ dependencies and prevents single points of failure for outbound traffic. Using a custom AMI with pre-installed agents and dependencies eliminates bootstrap delays, and using an Auto Scaling group warm pool with stopped instances keeps pre-initialized resources ready to launch immediately during sudden surges without causing scaling thrashing or over-provisioning.

Step-by-Step Solution

1
Address the outbound connectivity failure by establishing multi-AZ NAT Gateway redundancy.
Deploying a NAT Gateway in each Availability Zone and routing outbound traffic from private subnets to the local NAT Gateway prevents a single AZ outage from affecting outbound connectivity for the entire VPC.
This removes the single point of failure where all private subnets depended on a single NAT Gateway in one AZ.
2
Optimize the instance startup time and scaling behavior to prevent over-provisioning.
Baking compliance agents and cache files into a custom AMI reduces bootstrap latency. Using an Auto Scaling group warm pool with stopped instances maintains pre-initialized capacity that can quickly scale out when needed.
Keeping pre-initialized instances in a warm pool stops the ASG from launching excessive instances due to a long bootstrap period.
3
Address the ALB dropped connections by planning for scheduled flash traffic.
For expected flash traffic surges, AWS Support should be contacted to pre-warm the ALB.
The ALB's default scaling cannot keep pace with near-instantaneous 25x bursts, leading to dropped requests unless pre-warmed.

Key Concept

High availability, fault tolerance, and scaling optimization in AWS environments, specifically focusing on multi-AZ NAT Gateway redundancy, minimizing ASG bootstrapping delays using warm pools and custom AMIs, and resolving Application Load Balancer scaling limitations for sudden traffic bursts.
Rate this question