85

When you setup an Auto Scaling groups in AWS EC2 Min and Max bounds seem to make sense:

  • The minimum number of instances to scale down to based on policies
  • The maximum number of instances to scale up to based on policies

However, I've never been able to wrap my head around what the heck Desired is intended to affect.

I've always just set Desired equal to Min, because generally, I want to pay Amazon the minimum tithe possible, and unless you need an instance to handle load it should be at the Min number of instances.

I know if you use ElasticBeanstalk and set a Min to 1 and Max to 2 it sets a Desired to 2 (of course!)--you can't choose a value for Desired.

What would be the use case for a different Desired number of instances and how does it differ? When you expect AWS to scale lower than your Desired if desired is larger than Min?

Ray
  • 36,097
  • 17
  • 85
  • 129
  • 2
    You are doing it right by setting your desired value equal to min because desired indicates the "current amount" on the ASG. When an alarm triggers to "increase" or "decrease" the desired amount changes (like a switch on a control panel) so that ASG creates or removes an instance. You can check my detailed answer below. – Bahadir Tasdemir Sep 09 '16 at 07:50

8 Answers8

81

Here are the explanations for the "min, desired and max" values from AWS support:

MIN: This will be the minimum number of instances that can run in your auto scale group. If your scale down CloudWatch alarm is triggered, your auto scale group will never terminate instances below this number

DESIRED: If you trip a CloudWatch alarm for a scale up event, then it will notify the auto scaler to change it's desired to a specified higher amount and the auto scaler will start an instance/s to meet that number. If you trip a CloudWatch alarm to scale down, then it will change the auto scaler desired to a specified lower number and the auto scaler will terminate instance/s to get to that number.

MAX: This will be the maximum number of instances that you can run in your auto scale group. If your scale up CloudWatch alarm stays triggered, your auto scale group will never create instances more than the maximum amount specified.

Bahadir Tasdemir
  • 8,208
  • 3
  • 44
  • 55
  • 17
    Yes, makes sense. Min and max are bounds, desired is what you set initially, but the autoscaler may adjust based on your alarm rules. Thanks. – Ray Sep 09 '16 at 13:48
  • Is there a link to the documentation? – Rod Oct 03 '18 at 13:29
  • I asked question to the AWS support. This is the formal answer. I don't know if there is any documentation. – Bahadir Tasdemir Oct 03 '18 at 13:33
  • 1
    So basically it's like setting a manual CloudWatch trip. If you set 20, the number of servers will scale up to 20 at the time of your event, but then auto-scaling down if your configuration specifies. Or to put it another way: Manually setting your min to 20, and then reducing it to 4, would also have exactly the same effect. – Chuck Le Butt Dec 05 '18 at 23:07
37

Think about it like a sliding range UI element.

enter image description here

With min and max, you are setting the lower bound of your instance scaling. Withe desired capacity, you are setting what you'd currently like the instance count to hover.

Example: You know your application will have heavy load due to a marketing email or product launch...simply scale up your desired capacity beforehand:

aws autoscaling set-desired-capacity --auto-scaling-group-name my-auto-scaling-group --desired-capacity 2 --honor-cooldown

Source

Erik Ahlswede
  • 1,996
  • 2
  • 23
  • 36
  • When would the current instance count ever drop below the level set by the slider? I know it may scale up above the desired if need, as far as the max, but I don't yet see a case where it would go under the desired. – Ray Apr 15 '16 at 16:20
  • @Ray I have responded to your question as an answer. I know its an year old question but kind of encountered this issue today and answered my own question by looking at this one. Erik, very good example on the slider part. – A.K.Desai Apr 07 '17 at 14:43
14

When you expect AWS to scale lower than your Desired if desired is larger than Min?

This happens when you set a CloudWatch alarm based on some AutoScaling policy. Whenever that alarm is triggered it will update the DesiredCount to whatever is mentioned in config.

e.g., If an AutoScalingGroup config has Min=1, Desired=3, Max=5 and there is an Alarm set on an AutoScalingPolicy which says if CPU usage is <50% for consecutive 10 mins then Remove 1 instances then it will keep reducing the instance count by 1 whenever the alarm is triggered until the DesiredCount = MinCount.

Lessons Learnt: Set the MinCount to be > 0 or = DesiredCount. This will make sure that the application is not brought down when the mincount=0 and CPU usage goes down.

A.K.Desai
  • 1,166
  • 9
  • 15
  • 1
    Yes, after reading again the webmaster post and yours I parsed out the key phase from Erik's: "currently like the instance count to hover". Tough call on which is 'the best' answer. I like the slider analogy, but still find Erik's a little vague, not mentioning clearly (for me at least) the autoscaling alamrs actually modifies the 'desired'. Your answer points this out very clearly. If your's and Eriks were combined into one it would definitely sway my selection of correct, but for now, you just both get upvotes. – Ray Apr 07 '17 at 19:20
  • Yeah, I agree with you. I only answered the unanswered part of your question. Thanks for the upvote. – A.K.Desai Apr 07 '17 at 23:38
10

"Desired" is (necessarily) ambiguous.

  • It means the "initial" number of instances. Why not just "initial" then? Because the number may change by autoscaling events.
  • So it means "current" number of instance. Why not just "current" then? Because during an autoscaling event, instances will start / terminate. Those instances do not count towards "current" number of instances. By "current", a user expects instances that are operate-able.
  • So it means "target" number of instance. Why not just "target" then? I guess "target" is just as good (ambiguous) as "desired"...
theaws.blog
  • 2,001
  • 20
  • 19
  • Thanks this was helpful. I didn't realize that value changed after the ASG was created. – jDub9 Jul 29 '19 at 16:03
  • I believe now that word 'desire' spanning across those 3 definitions. Sometimes it means an initial number sometimes current, sometimes it's just a target and sometimes it's a mix of all of them. – sobi3ch Apr 06 '20 at 07:52
  • It really helps. This should be the chosen answer! – Ryan Lyu Jun 02 '20 at 14:10
  • This should be the chosen answer. This answer is when a ninja master is talking :) –  Jul 28 '20 at 22:24
1

I noticed that desired capacity went down and no new instance came up when

  1. I set one of the instances to standby. It kept on running but was detached from ELB ( requests were not forwarded to that particular instance when accessed via ELB DNS ). No new instance has been initiated by AWS. Rather desired capacity was decreased by 1.
  2. When I changed the state of instance ( from standby ) the instance was again attached to ELB ( the instance started to get requests when accessed via ELB DNS ). The desired capacity was increased by 1 and became 2.

Hence it seems no of instances attached to ELB can't cross the threshold limit set by min and max but the desired capacity is adjusted or changed automatically based on the occurrence of scale in or scale out event. It was definitely something unknown to me.

It might be a way to let AWS know that this is the desired capacity required for the respective ELB at a given point in time.

Farwa Naqvi
  • 11
  • 3
0

Based on my reading, in layman's terms, DesiredCapacity value is automatically updated on scale-in and scale-out events.

In other words,

Scale-in or Scale-out are done by decreasing or increasing the DesiredCapacity value.

Sateesh Pagolu
  • 8,203
  • 2
  • 22
  • 42
0

Desired capacity simply means the number of instances that will come up / fired up when you launch the autoscaling. That means if desired capacity = 4, then 4 instances will keep on running until and unless any scale up or scale down event triggers. If scale up event occurs, the number of instances will go up till maximum capacity and if scale down event occurs it will go down till the minimum capacity.

Correct me if wrong, thanks.

Mukesh Singh Rawat
  • 1
0

Min and max is self explanatory but desired was confusing until i have attached Target Tracking Auto scaling policy with the ASG where CPU utilization was the target metric. Here, desired instances were scaled out and scaled in based on target CPU utilization. If any desired count are placed through cloudformation/manual, for time being ASG will create same number of instances as desired count. But later ASG policy will automatically adjust the desire instances based on target CPU utilization.

SudhirKumar
  • 179
  • 2
  • 2
  • 13