17.11 Every Auto Scaling policy
Desired is one number. A policy is who may change it. Every example uses minimum 1, maximum 3, starting at desired 1. This lab uses simple scaling: add 1 on cpu-high-lab, remove 1 on cpu-low-lab, cooldown 300 seconds. The others are here so you can tell them apart.
Manual. Why: you are at the console. What: you type desired.
- Open
scale-lab-asg. - At 18:00 set desired from 1 to 2.
- You should see one new instance launch.
- At 19:00 set desired from 2 to 1.
- You should see one instance terminate.
- If you are asleep, none of these lines run. Desired stays where you left it.
Simple scaling (the lab). Why: one alarm, one fixed add. What: it runs when the alarm enters ALARM, then waits out a cooldown.
- Create policy
add-one-on-cpu. - Choose type Simple scaling.
- Choose add 1 when
cpu-high-labis in ALARM. - Set cooldown to 300 seconds.
- When the averages are 82 then 91, you should see desired go from 1 to 2.
- You should not see a third instance just because the alarm stays in ALARM.
- Create
remove-one-on-cputhe same way, removing 1 when CPU is at or under 30 for two periods. - You should see desired return toward 1. The OK email does not do that step.
Step scaling. Why: a continued breach should add another server. What: bands past 70, plus a warm-up.
- Create a policy of type Step scaling.
- If CPU is above 70, add 1.
- Set warm-up to 300 seconds.
- On CPU 78, you should see desired go from 1 to 2.
- After warm-up, if CPU is still 91, you should see desired go from 2 to 3.
- You should not see desired become 4, because maximum is 3.
- This is not the policy the lab buttons use. The lab uses simple scaling.
Target tracking. Why: you care about the level. What: keep average CPU near 50.
- Create a policy of type Target tracking.
- Choose average CPU utilization.
- Set the target to 50.
- With one server at 90, you should see the group add capacity.
- With two servers near 45, you should see it stop adding.
- Near 20, it may remove one, and minimum 1 should block 0.
- Do not enable this in the lab, or CloudWatch hides the alarm you built.
Scheduled scaling. Why: the rush is on a clock. What: set desired at a time.
- Create a scheduled action.
- Set the time zone to Asia/Kolkata.
- At 08:50 set desired to 2, before a 09:00 class.
- At 21:00 set desired to 1.
- You should see the extra server leave at night.
- A reel at 01:00 is not on this schedule. Keep a dynamic policy for that.
Predictive scaling. Why: a repeating peak should be ready before users arrive. What: a forecast from past load.
- Leave predictive scaling off for this lab.
- Read a forecast only after the group has history.
- If dinner is busy every evening, the forecast can raise desired before 19:00.
- A brand-new sale is not in that history. The alarm still has to catch it.
Lab
Chala, six lines in the notebook.
- Manual: at 18:00 desired becomes 2. At 19:00 it becomes 1.
- Simple: 82 then 91, desired 1 to 2. Underline this row. The lab uses it.
- Step: still above 70 after warm-up, desired 2 to 3. Maximum stops 4.
- Target tracking: aim at 50% CPU.
- Scheduled: 08:50 desired 2, 21:00 desired 1, time zone Asia/Kolkata.
- Predictive: only if past evenings show the peak. It misses a brand-new rush.