Musings on AutoScaling #856
Description
Note: this issue is not really an issue per se. It's a place for me to write down my thoughts and solicit feedback in place where people can easily access the document and comment.
I imagine when people want to set up autoscaling, they want to set up something like this:
Scaling -3 -1 +1 +3
activity │ │ │ │ │ │
├────────┼────────┼────────────────────────────┼─────────┼─────────┤
│ │ │ │ │ │
CPU usage 0% 10% 30% 70% 90% 100%
Disregarding TargetTracking scaling for a moment, the way to set this up is with StepScaling. You'll make a StepScaling policy which is activated by a CloudWatch alarm. The StepScaling policy has different scaling tiers depending on the distance of the current metric value to its Alarm threshold. Configuration for a step scaling policy looks like this:
Scaling -2 -1 +1 +2
activity │ │ │
◀──────────────┼───────────────┼───────────────┼───────────────────▶
│ │ │
Distance from
alarm threshold -10 0 +10
Normally, CloudWatch Alarm Actions are edge-triggered (that is, an Action occurs only when the alarm transitions from OK to ALARM or vice-versa). However, if the Alarm Action is an AutoScaling policy the Alarm keeps on triggering the AutoScaling policy periodically, so that if the alarm goes further out of spec, higher scaling tiers can be activated. (For example, the CPU usage goes to 75% and an instance is added. However, that doesn't make the load go down enough yet, and after an (undefined) while the policy is activated again and another instance is added).
The question is, how to set up step scaling policies to achieve the scaling that the user wants?
Solution 1: Two alarms, two policies
This is what I see most on the internet--a separate alarm and a separate scaling policy for scaling out and scaling in. Seems inefficient, resource-wise.
Also, AutoScaling policies seem to imply they can both scale in and scale out in a single policy, but you'd never take advantage of that in this way.
-3 -1 +1 +3
│ │ │ │ │ │
Metric ├────────┼────────┼────────────────────────────┼─────────┼─────────┤
│ │ │ │ │ │
0% 10% 30% 70% 90% 100%
║
Alarm1 > 70% ║
║
+1 +3
│ │
Policy1 ├─────────┼─────────▶
│ │
0 +20
║
Alarm2 < 30% ║
║
-3 -1
│ │
Policy2 ◀─────────┼────────┤
│ │
-60 -40
Solution 2: One alarm, one policy
Ideally, it seems like I would want just a single alarm/metric/scalingpolicy configuration. But I don't know if this would even work, it would require that the scaling policy is activated on both sides of the CloudWatch alarm, and it might not do that.
-3 -1 +1 +3
│ │ │ │ │ │
Metric ├────────┼────────┼────────────────────────────┼─────────┼─────────┤
│ │ │ │ │ │
0% 10% 30% 70% 90% 100%
║
Alarm Alarm at 70% ║
║
-3 -1 0 +1 +3
│ │ │ │
Policy ◀─────────┼────────┼────────────────────────────┼─────────┼─────────▶
│ │ │ │
-60 -40 0 +20
Solution 3: Two alarms, one policy
Another potential way to go would be to have two alarms trigger the same scaling policy (one lower-than-threshold and one greater-than-threshold) and just describe the scaling behavior with respect to the alarm thresholds on either side.
We can save on a ScalingPolicy in this way (with respect to solution 1). It's not as obvious what's going on though, and would rely on the fact that 2 different alarms give the deltas to 2 different thresholds to the same scaling policy ONLY when they're in alarm.
-3 -1 +1 +3
│ │ │ │ │ │
Metric ├────────┼────────┼────────────────────────────┼─────────┼─────────┤
│ │ │ │ │ │
0% 10% 30% 70% 90% 100%
║
Alarm1 > 70% ║
║
║
Alarm2 < 30% ║ ─
║ ┌ ┘
─ ─
└ ┐ ┌ ┘
─ ─
└ ┐ ┌ ┘
─ ─
└ ┐ ┌ ┘
─┌
-3 -1 ▼ +1 +3
│ │ │
Policy ◀───────────────────┼───────────┼───────────┼───────────────────────▶
│ │ │
-20 0 +20
Questions
Can an AutoScaling Policy be in the=> yesOKActionsof a CloudWatch Alarm? Does that work?If it does work, will it also continue evaluating and triggering the Scaling Policy periodically if it's on the=> yesOKActions, just like it does inAlarmActions?- Can a single AutoScaling policy even be the target of two CloudWatch alarms? If so, will it respect both threshold deltas as I'm expecting it to in scenario 3?
- Is there a difference between Application AutoScaling and EC2 Instance AutoScaling?
- Can I have multiple StepScalingPolicies on the same target that both scale the target at the same time? Are they going to fight? What if one has a
ChangeInCapacity = 0?