A live sports streaming platform is launching a new pay-per-view service. The registration… — AWS Certified Solutions Architect - Professional

A live sports streaming platform is launching a new pay-per-view service. The registration and stream-start portal is expected to experience a sudden burst of traffic, rising from a baseline of $100\text{ requests per second}$ to $300\text{}000\text{ requests per second}$ within $3\text{ minutes}$ of a major match starting. The backend microservices are hosted on Amazon ECS tasks using AWS Fargate, and the session metadata is stored in an Amazon Aurora PostgreSQL database. Read operations account for $90\%$ of the database workload, and Fargate tasks require approximately $90\text{ seconds}$ to bootstrap and pass health checks. The platform requires a highly scalable architecture that ensures zero dropped requests and sub-second latency for all users. Which combination of actions should a Solutions Architect recommend to optimize the performance and scalability of this architecture?

Submit a request to AWS Support to pre-warm the Application Load Balancer (ALB) to handle the target throughput, configure the Amazon ECS service auto-scaling policy with a scale-out cooldown period of 120 seconds, and deploy Amazon Aurora Replicas with Aurora Auto Scaling enabled to handle the read traffic.Answer
B
Rely on the Application Load Balancer's (ALB) default elastic scaling capabilities to dynamically adjust to the incoming traffic, configure the Amazon ECS service auto-scaling policy with a scale-out cooldown period of 120 seconds, and configure Aurora Auto Scaling with read replicas to handle the read traffic.
C
Submit a request to AWS Support to pre-warm the Application Load Balancer (ALB) to handle the target throughput, configure the Amazon ECS service auto-scaling policy with a scale-out cooldown period of 120 seconds, and enable Multi-AZ replication on the Amazon Aurora cluster, configuring the application to route read queries to the standby instance in the secondary Availability Zone.
D
Submit a request to AWS Support to pre-warm the Application Load Balancer (ALB) to handle the target throughput, configure the Amazon ECS service auto-scaling policy with a scale-out cooldown period of 5 seconds to rapidly scale up Fargate tasks, and deploy Amazon Aurora Replicas with Aurora Auto Scaling enabled to handle the read traffic.

Answer

Submit a request to AWS Support to pre-warm the Application Load Balancer (ALB) to handle the target throughput, configure the Amazon ECS service auto-scaling policy with a scale-out cooldown period of 120 seconds, and deploy Amazon Aurora Replicas with Aurora Auto Scaling enabled to handle the read traffic.

The correct solution addresses all performance and scalability requirements under a sudden traffic burst. First, submitting an AWS Support request to pre-warm the ALB ensures the entry point handles the immediate

3000\times

traffic increase without dropping connections. Second, setting a scale-out cooldown of

120\text{ seconds}

for Amazon ECS prevents service thrashing because Fargate tasks require

90\text{ seconds}

to boot and pass health checks. Finally, utilizing Amazon Aurora Replicas with Aurora Auto Scaling is the standard, best-practice method to scale a database read-heavy workload horizontally.

Step-by-Step Solution

Address the entry point of the traffic spike by pre-warming the ALB.

The Application Load Balancer is pre-provisioned to handle the instant jump from

100\text{ requests per second}

300\text{}000\text{ requests per second}

without dropping connections.

By default, ELBs scale gradually based on traffic trends, which is too slow for sudden, extreme traffic spikes.

Configure ECS service auto-scaling cooldown times based on task bootstrap latency.

The scale-out cooldown is set to

120\text{ seconds}

, which is greater than the

90\text{ seconds}

needed to bootstrap a Fargate task and pass health checks.

If the cooldown is too short (e.g.,

5\text{ seconds}

), ECS will launch additional tasks before the previously launched tasks become healthy and register, causing resource over-provisioning and thrashing.

Deploy Aurora Replicas and enable Aurora Auto Scaling for the database tier.

The database scale-out handles the

90\%

read workload horizontally.

Aurora Multi-AZ standby instances do not serve read traffic; read queries must be routed to Aurora Replicas which support horizontal scaling.

Key Concept

Handling rapid, massive traffic spikes on AWS requires pre-warming load balancers, configuring auto-scaling cooldown periods to exceed resource bootstrap times, and using read replicas rather than standby instances for horizontal database read scaling.

Question

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Topics

More questions from this topic