What "desired instances" is needed for? AWS Amazon Webservices AutoScaling group

Question

i am facing a strange situation on Amazon AWS. I don´t understand for what the desired Instances number is used for? I have an autoscaling group that contains scale up and scale down actions configured.

I have a custom PHP file that run actions Scale up and Scale down depending on some external factors. I want to know which number I have to write in desired instances to not affect my autoscaling actions.

For example:

1. I set desired to 2
2. I have 2 instances running
3. I run Scale Down action
4. Instances is 1
5. Autoscaling group will automatically start another instance, so my scale down is not useful because I ended by having 2 running

What can I do?

Many thanks!

Answer 1

The ASG will always try to maintain the Desired Capacity. If you scale up or down, and the new number of instances is different than the Desired Capacity, the ASG will add or remove an instance to go back to the desired capacity.

If you use scaling policies, and the policy condition is met, the ASG will change the Desired Capacity to match the result of your scaling policy. E.g., you have a Desired Capacity of 2, and a policy that says to scale up if the CPU utilization goes over a threshold.

If that policy is fulfilled, then the Desired Capacity will increase to 3, and so on.

So manually scaling up and down will result in your ASG restoring the number of instances to the Desired Capacity.

If you want to manually scale up and down, you could set your Max and Min to a wide value, and move Desired Capacity within it.

So you could do Max=10, Min=1, Desired=3. Then you could scale up or down just by changing the Desired Capacity. (This is how we use Auto Scaling, and I think why I gave you a bad answer before.)

If you want to terminate an instance and change the Desired Capacity at the same time, the CLI can do that.

See Terminate instance in ASG, and the CLI ASG documentation more generally.

Answer 2

These answers are all good, but I would like to add one more situation.

Say you are doing a blue/green deployment and you have bursty traffic. Your min is 1, because 50% of the time you only have 1 instance. However say you're doing CI/CD and deployments happen all the time all day long. A dev could push code to production right in the middle of a large scaling event where the instances have scaled up to 10. Now if you use a tool like terraform to deploy autoscaling groups etc... it will reset the autoscaling group back down to 1 and you run the risk of having an interruption of services.

For this reason, during a deployment, we have a terraform override value that we programmatically hand to terraform on invocation. Prior to invoking terraform, we use the aws cli to figure out the current desired capacity that autoscaling has scaled the instances to, and we pass that value onto terraform so the new autoscaling group comes up with the same number of hosts as the previous one.