A municipal government operates a smart-city environmental telemetry platform that monitor… — AWS Certified Solutions Architect - Professional

A municipal government operates a smart-city environmental telemetry platform that monitors sensor networks across the metropolitan area. The ingestion application is hosted on Amazon EC2 instances in an Auto Scaling Group (ASG) behind an Application Load Balancer (ALB) distributed across three Availability Zones. The EC2 instances run a telemetry processing application that requires approximately $8\text{ minutes}$ to bootstrap, initialize configuration caches, and pass health checks.

The platform experiences a highly predictable daily traffic surge at 7:00 AM local time when thousands of environmental sensors activate simultaneously to transmit night-time logs. During this surge, incoming traffic rises from $10,000\text{ requests per second}$ to $350,000\text{ requests per second}$ in a $5\text{-minute}$ window, resulting in frequent HTTP 502 (Bad Gateway) and HTTP 504 (Gateway Timeout) errors. Furthermore, the platform's outbound transmissions to external environmental monitoring agencies fail completely if Availability Zone A experiences an outage, as the subnet route tables in all Availability Zones point to a single NAT Gateway located in Availability Zone A.

The solutions architect must redesign the architecture to prevent request drops during the daily surge, ensure high availability for outbound traffic, and minimize administrative and operational overhead.

Which combination of actions should the solutions architect implement to meet these requirements?

A
Configure a target tracking scaling policy based on average CPU utilization with the instance warm-up time set to $120\text{ seconds}$ to scale out quickly during spikes. Request AWS Support to pre-warm the ALB to handle the daily traffic peaks. Keep the single NAT Gateway in Availability Zone A and configure an AWS Lambda function to update the route tables to redirect outbound traffic to a fallback NAT Gateway in Availability Zone B during an outage.
B
Configure scheduled scaling to scale out the ASG at 6:45 AM daily. Deploy a NAT Gateway in each of the three public subnets, and update the private route tables accordingly. Rely on the ALB's default automatic scaling capacity to handle the traffic surge as new instances are launched, and adjust the target tracking policy warm-up time to $480\text{ seconds}$ .
Configure scheduled scaling to scale out the ASG at 6:45 AM daily using an ASG Warm Pool with pre-warmed instances to bypass the bootstrapping delay. Request AWS Support to pre-warm the ALB to handle the target traffic volume by 7:00 AM daily. Deploy a NAT Gateway in the public subnet of each Availability Zone, and update the route tables of the private subnets to use the local NAT Gateway in their respective Availability Zone.Answer
D
Configure scheduled scaling to scale out the ASG at 6:45 AM daily using an ASG Warm Pool with pre-warmed instances. Request AWS Support to pre-warm the ALB to handle the target traffic volume. Retain the single NAT Gateway in Availability Zone A and configure the route tables of private subnets in the other Availability Zones to route outbound traffic through Availability Zone A.

Answer

The correct solution is to configure scheduled scaling to scale out the ASG using an ASG Warm Pool to eliminate the

8\text{-minute}

bootstrapping lag, request AWS Support to pre-warm the ALB to handle the sudden

35\text{x}

traffic spike, and deploy independent NAT Gateways in each Availability Zone to ensure high availability and eliminate the single point of failure.

The correct response implements scheduled scaling 15 minutes before the daily surge (

6:45\text{ AM}

) using an ASG Warm Pool, which ensures instances are bootstrapped and ready to transition to the in-service state immediately. Furthermore, pre-warming the ALB ensures the load balancer can handle the

350,000\text{ requests per second}

peak without dropping connections, and deploying a NAT Gateway in each Availability Zone removes the single point of failure for outbound API tracking updates.

Step-by-Step Solution

Address the application bootstrapping lag.

By using scheduled scaling combined with an ASG Warm Pool containing stopped or running pre-warmed instances, the bootstrapping time is reduced to seconds, allowing capacity to be ready before the 7:00 AM surge.

Since standard bootstrapping takes

8\text{ minutes}

and the surge completes in

5\text{ minutes}

, reactive or dynamic scaling will always scale out too late, causing capacity deficits.

Address the load balancer scaling delay.

Requesting AWS Support to pre-warm the ALB to scale the underlying load balancer capacity to handle the

350,000\text{ requests per second}

target volume by 7:00 AM.

ALBs scale automatically but cannot absorb a sudden

35\text{x}

spike in 5 minutes without dropping requests. Pre-warming configures the target capacity in advance.

Ensure fault tolerance for outbound traffic.

Deploy a NAT Gateway in the public subnet of each of the three Availability Zones and update route tables to use local NAT Gateways.

Consolidating routing to a single NAT Gateway in Availability Zone A introduces a single point of failure, violating the fault tolerance and high availability requirements.

Key Concept

Mitigating rapid flash traffic surges and single-point-of-failure routing in multi-AZ VPC architectures.

Question

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Topics