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 runs an internal browser-based application. The application runs on Amazon EC2 instances behind an Application Load Balancer. The instances run in an Amazon EC2 Auto Scaling group across multiple Availability Zones. The Auto Scaling group scales up to 20 instances during work hours, but scales down to 2 instances overnight. Staff are complaining that the application is very slow when the day begins, although it runs well by mid-morning.
How should the scaling be changed to address the staff complaints and keep costs to a minimum?
Other
Community
UAnonymous
A
Implement a scheduled action that sets the desired capacity to 20 shortly before the office opens.
B
Implement a step scaling action triggered at a lower CPU threshold, and decrease the cooldown period.
C
Implement a target tracking action triggered at a lower CPU threshold, and decrease the cooldown period.
D
Implement a scheduled action that sets the minimum and maximum capacity to 20 shortly before the office opens.
Explanation:
Explanation
The problem described is a classic cold start issue where the application is slow at the beginning of the workday because the Auto Scaling group has scaled down to only 2 instances overnight. When staff arrive and start using the application, the system needs time to scale up from 2 to 20 instances, causing poor performance during the initial surge.
Let's analyze each option:
Option A: Implement a scheduled action that sets the desired capacity to 20 shortly before the office opens.
- ✅ CORRECT: This proactively scales up the instances before staff arrive, ensuring sufficient capacity is available when the workday begins.
- ✅ Cost-effective: Instances are only running at full capacity during work hours, not overnight.
- ✅ Predictable: Since the usage pattern is predictable (office hours), scheduled scaling is appropriate.
Option B: Implement a step scaling action triggered at a lower CPU threshold, and decrease the cooldown period.
- ❌ Incorrect: This is reactive scaling that waits for high CPU usage before scaling. By the time CPU thresholds are triggered, users are already experiencing slowness.
- ❌ Not cost-minimizing: Lower thresholds might cause unnecessary scaling during non-peak times.
Option C: Implement a target tracking action triggered at a lower CPU threshold, and decrease the cooldown period.
- ❌ Incorrect: Similar to option B, this is reactive scaling. Target tracking is good for maintaining performance but doesn't solve the cold start problem.
- ❌ Not optimal: The cooldown period prevents rapid scaling, but decreasing it might cause scaling oscillations.
Option D: Implement a scheduled action that sets the minimum and maximum capacity to 20 shortly before the office opens.
- ❌ Incorrect: Setting both minimum and maximum to 20 would prevent any scaling down overnight, increasing costs unnecessarily.
- ❌ Not cost-minimizing: This would keep 20 instances running 24/7, which defeats the purpose of scaling down overnight.
Key AWS Concepts:
- Scheduled Actions: Best for predictable workload patterns with known peak times.
- Desired Capacity: The number of instances the Auto Scaling group attempts to maintain.
- Cold Start Problem: When applications need time to scale up from minimal capacity, causing poor initial performance.
Best Practice: For predictable workloads with known business hours, use scheduled scaling to ensure capacity is available before demand increases, while still allowing scaling down during off-hours to save costs.
Comments
Loading comments...