AWS Certified Solutions Architect - Associate
Get started today
Ultimate access to all questions.
Deep dive into the quiz with AI chat providers.
We prepare a focused prompt with your quiz and certificate details so each AI can offer a more tailored, in-depth explanation.
A company's application runs on Amazon EC2 instances behind an Application Load Balancer (ALB). The instances run in an Amazon EC2 Auto Scaling group across multiple Availability Zones. On the first day of every month at midnight, the application becomes much slower when the month-end financial calculation batch runs. This causes the CPU utilization of the EC2 instances to immediately peak to 100%, which disrupts the application.
What should a solutions architect recommend to ensure the application is able to handle the workload and avoid downtime?
Other
Community
UAnonymous
A
Configure an Amazon CloudFront distribution in front of the ALB.
B
Configure an EC2 Auto Scaling simple scaling policy based on CPU utilization.
C
Configure an EC2 Auto Scaling scheduled scaling policy based on the monthly schedule.
D
Configure Amazon ElastiCache to remove some of the workload from the EC2 instances.
Explanation:
Explanation
The correct answer is C. Configure an EC2 Auto Scaling scheduled scaling policy based on the monthly schedule.
Why this is the correct solution:
-
Predictable workload pattern: The problem clearly states that the CPU utilization peaks to 100% on a predictable schedule - "On the first day of every month at midnight." This is a known, recurring pattern.
-
Scheduled scaling is ideal for predictable patterns: EC2 Auto Scaling scheduled scaling policies are specifically designed for predictable workload changes. You can configure the Auto Scaling group to increase capacity before the expected load arrives, ensuring sufficient resources are available when the batch job runs.
-
Proactive vs reactive approach:
- Option B (simple scaling policy based on CPU utilization) is reactive - it would only scale out AFTER the CPU utilization has already peaked, which means the application would experience disruption before scaling kicks in.
- Option C (scheduled scaling) is proactive - it scales out BEFORE the expected load arrives, preventing the disruption entirely.
-
Other options analysis:
- Option A (CloudFront): CloudFront is a CDN for caching static content and improving delivery performance. It won't help with CPU-intensive batch processing workloads.
- Option D (ElastiCache): While caching can help with certain workloads, the problem describes a "month-end financial calculation batch" which is likely CPU-intensive processing that cannot be cached. ElastiCache wouldn't remove this type of computational workload.
Implementation approach: The solutions architect should configure a scheduled scaling action that:
- Increases the desired capacity of the Auto Scaling group before midnight on the first day of each month
- Maintains the increased capacity during the batch processing period
- Scales back down to normal capacity after the batch job completes
This ensures the application has sufficient compute resources to handle the predictable monthly workload spike without disruption.
Comments
Loading comments...