What if your servers could prepare for busy times all by themselves, without you lifting a finger?
Why Scheduled scaling in AWS? - Purpose & Use Cases
Imagine you run a website that gets a lot busier every weekday morning and evening. You try to guess when to add more servers and when to remove them by logging in and changing settings manually.
This manual way is slow and easy to forget. Sometimes you add servers too late or remove them too early, causing slow websites or wasted money. It's like trying to catch a bus by guessing its arrival time without a schedule.
Scheduled scaling lets you set a plan for your servers to grow or shrink automatically at specific times. It's like setting an alarm clock that adjusts your resources exactly when you need them, without any manual work.
Login to console -> Change server count -> Save -> Repeat daily
Set schedule: At 8 AM increase servers to 10; At 6 PM decrease to 2
It enables your system to be ready for busy times and save money during quiet times, all automatically and reliably.
A retail website automatically adds more servers every morning before customers start shopping and reduces them late at night when traffic is low, ensuring smooth shopping and cost savings.
Manual scaling is slow and error-prone.
Scheduled scaling automates resource changes at set times.
This improves performance and reduces costs effortlessly.
Practice
Solution
Step 1: Understand scheduled scaling concept
Scheduled scaling is designed to change resource capacity automatically based on a set schedule.Step 2: Compare options with the concept
Only To automatically adjust resources at specific times describes automatic adjustment at specific times, matching scheduled scaling.Final Answer:
To automatically adjust resources at specific times -> Option AQuick Check:
Scheduled scaling = automatic timed resource adjustment [OK]
- Confusing scheduled scaling with manual scaling
- Thinking it handles security or backups
- Assuming it reacts only to traffic, not time
Solution
Step 1: Review cron expression format in AWS
AWS cron expressions have six fields: minutes, hours, day-of-month, month, day-of-week, year.Step 2: Validate each option
cron(0 12 * * ? *) is valid: minute=0, hour=12, day-of-month=*, month=*, day-of-week=?, year=*. cron(0 0 0 0 ? *) has invalid zero day-of-month and month values. cron(60 24 * * ? *) has invalid 60 minutes and 24 hours. cron(* * * * *) has only five fields, missing year.Final Answer:
cron(0 12 * * ? *) -> Option DQuick Check:
Valid AWS cron = 6 fields, correct ranges [OK]
- Using 5-field cron instead of 6-field
- Setting minutes or hours out of range
- Confusing day-of-week and day-of-month
{"ScheduledActionName": "ScaleUpMorning", "StartTime": "2024-07-01T08:00:00Z", "DesiredCapacity": 5}What will happen at 8 AM UTC on July 1, 2024?
Solution
Step 1: Understand the scheduled action parameters
The action named "ScaleUpMorning" is set to start at 8 AM UTC on July 1, 2024, with DesiredCapacity 5.Step 2: Interpret the effect of StartTime and DesiredCapacity
At the StartTime, the capacity will be set to 5. EndTime is optional and does not block the action.Final Answer:
The resource capacity will be set to 5 -> Option AQuick Check:
StartTime triggers capacity change to DesiredCapacity [OK]
- Thinking EndTime is required to trigger scaling
- Assuming capacity decreases without explicit setting
- Ignoring the StartTime effect
cron(0 25 * * ? *)Why does the scaling not trigger as expected?
Solution
Step 1: Check the hour field in the cron expression
The hour field is set to 25, but valid hour values are 0 to 23.Step 2: Understand cron validation rules in AWS
AWS rejects cron expressions with invalid field values, so the scaling action won't trigger.Final Answer:
The hour value 25 is invalid in cron expressions -> Option CQuick Check:
Hour must be 0-23 in AWS cron [OK]
- Assuming minute 0 is invalid
- Thinking day-of-week is mandatory
- Using 5 fields instead of 6
Solution
Step 1: Understand the scheduling requirements
Capacity should be 2 at 11 PM daily and 10 at 7 AM on weekdays only.Step 2: Match cron expressions to requirements
cron(0 23 * * ? *) runs daily at 11 PM; cron(0 7 ? * MON-FRI *) runs at 7 AM Monday to Friday. Two separate scheduled actions are needed with correct DesiredCapacity values.Final Answer:
Create two scheduled actions: one with cron(0 23 * * ? *) setting DesiredCapacity=2, another with cron(0 7 ? * MON-FRI *) setting DesiredCapacity=10 -> Option BQuick Check:
Separate cron for each time and capacity [OK]
- Trying to set two capacities in one scheduled action
- Using rate expressions instead of cron for weekdays
- Missing weekday restriction for morning scale-up
Ready to prove it?
Pass the test and this pattern moves unknown
