A real-time sports betting platform hosts its live analytics and odds-calculation service … — AWS Certified Solutions Architect - Professional

A real-time sports betting platform hosts its live analytics and odds-calculation service on Amazon EC2 instances within private subnets across two Availability Zones ( $AZ-a$ and $AZ-b$ ). The EC2 instances are managed by an Auto Scaling Group (ASG) behind an Application Load Balancer (ALB). Outbound API requests to external sports data feeds are routed through a single NAT Gateway located in the public subnet of $AZ-a$ .

The platform experiences a predictable, massive spike in traffic at the start of major sporting events. During these spikes, the following issues occur:
1. The ALB returns HTTP $503$ Service Unavailable errors during the first few minutes of the traffic spike.
2. The ASG launches new instances in response to the CPU utilization target tracking policy. However, because each instance takes approximately $8\text{ minutes}$ to download reference datasets and bootstrap, the ASG continuously launches unnecessary instances during this period, leading to over-provisioning and high costs.
3. When a transient infrastructure failure occurs in $AZ-a$ , all outbound communication to external sports data feeds is lost for instances in both Availability Zones.

Which set of actions should a Solutions Architect recommend to address all of these issues while optimizing cost and fault tolerance?

Request Application Load Balancer pre-warming from AWS Support before scheduled events. Deploy a NAT Gateway in the public subnet of $AZ-b$ , and configure the route table of the private subnet in $AZ-b$ to use this new NAT Gateway. Set the `EstimatedInstanceWarmup` parameter of the target tracking scaling policy to $600\text{ seconds}$ .Cevap
B
Request Application Load Balancer pre-warming from AWS Support before scheduled events. Keep the single NAT Gateway in $AZ-a$ and route all outbound traffic from both Availability Zones through it. Set the `EstimatedInstanceWarmup` parameter of the target tracking scaling policy to $600\text{ seconds}$ .
C
Request Application Load Balancer pre-warming from AWS Support before scheduled events. Deploy a NAT Gateway in the public subnet of $AZ-b$ , and configure the route table of the private subnet in $AZ-b$ to use this new NAT Gateway. Set the default cooldown period of the Auto Scaling Group to $300\text{ seconds}$ .
D
Configure a Route $53$ active-active failover routing policy to distribute the sudden traffic spikes across multiple target groups. Deploy a NAT Gateway in the public subnet of $AZ-b$ , and configure the route table of the private subnet in $AZ-b$ to use this new NAT Gateway. Set the `EstimatedInstanceWarmup` parameter of the target tracking scaling policy to $600\text{ seconds}$ .

Cevap

Request Application Load Balancer pre-warming from AWS Support before scheduled events. Deploy a NAT Gateway in the public subnet of the second Availability Zone, configure the local private route tables accordingly, and set the scaling policy's EstimatedInstanceWarmup parameter to 600 seconds.

Deploying a NAT Gateway in the public subnet of the second Availability Zone and mapping the local private subnet route table to it establishes localized outbound routing, avoiding cross-AZ dependencies and single points of failure. Pre-warming the Application Load Balancer ensures it is immediately ready for massive, sudden traffic spikes, preventing HTTP

503

errors. Setting the EstimatedInstanceWarmup parameter to

600\text{ seconds}

(which is greater than the

8\text{ minute}

bootstrap time) ensures that newly launched instances are not included in target tracking metrics calculations until they are ready, preventing over-provisioning.

Adım Adım Çözüm

Deploy a NAT Gateway in the public subnet of

AZ-b

and update the route table of the private subnet in

AZ-b

to point to the new NAT Gateway.

Outbound traffic from the private subnet in

AZ-b

is routed locally, eliminating the single point of failure.

This resolves the fault tolerance issue where a failure in one Availability Zone impacts outbound connectivity for instances running in other zones.

Request Application Load Balancer (ALB) pre-warming from AWS Support prior to the scheduled traffic surge.

The ALB is pre-configured with sufficient capacity to handle the sudden, massive traffic spike.

This resolves the HTTP

503

errors that occur due to the load balancer being unable to scale fast enough to meet the flash traffic demand.

Configure the target tracking scaling policy with an `EstimatedInstanceWarmup` of

600\text{ seconds}

(

10\text{ minutes}

Newly launched instances are excluded from contributing to the group metric until they have completed their

8\text{ minute}

bootstrapping process.

This prevents the scaling policy from continuously launching unnecessary instances during the bootstrapping lag, optimizing resource costs.

Anahtar Kavram

Auto Scaling Warmup and Multi-AZ Load Balancing/Gateway Fault Tolerance

Tahmini Süre:3m 0s

Soru

Cevap

Adım Adım Çözüm

Anahtar Kavram

Sık Yapılan Hatalar

Konular