2
votes

Is there a way to decide on the scaling activity of an autoscaling group based on metrics collected for a single instance among the multiple instances of an autoscaling group?

I'm tried to scale up based on alarm set for an instance which is one among the multiple instances of an autoscaling group but as I try to configure the autscaling under the cloudwatch alarm for the instance, autoscaling group doesn't show up.

As you can see in the below image Autoscaling group is not listed.

Autoscaling group is unlisted

2

2 Answers

4
votes

Auto Scaling provides a way of adding and removing (scaling-out and scaling-in) Amazon EC2 instances. It works by launching new instances and terminating instances.

Auto Scaling groups can be scaled by executing a Scaling Policy, that tells Auto Scaling whether to add or remove instances, and how many -- eg +1, -1, +50%.

The scaling policy can be triggered by an Amazon CloudWatch alarm, a schedule or manually via an API/CLI call.

When triggering a scaling policy from Amazon CloudWatch, the metrics will be based on an aggregation of the Auto Scaling group -- for example, average CPU Utilization or maximum Network Out. The metrics are calculated from the entire Auto Scaling group, not a single instance. This makes sense -- imagine an Auto Scaling group with two instances where one is at 100% CPU and the other is 0% CPU. On average, they are at 50% CPU, so there is no need to scale. It would not make sense to base the scaling action on the metrics of a single instance.

So, to answer your question, how could you decide on the scaling activity of an autoscaling group based on metrics collected for a single instance among the multiple instances of an autoscaling group? You create an Amazon CloudWatch alarm that triggers on the metrics of a single instance. The alarm can trigger an Amazon SNS topic, and you could write an AWS Lambda function that subscribes to that topic. Your Lambda function can then trigger a Scaling Policy that changes the Desired Capacity of the Auto Scaling group.

However, I would recommend against this idea. Auto Scaling could for example, decide to scale-in and might remove the instance you are specifically monitoring. Your Auto Scaling group would then not scale anymore. Also, one instance is unlikely to represent the work level of the entire Auto Scaling group. It is better to scale based upon a metric that takes into account all instances in the Auto Scaling group, or some measure of the amount of 'work' being done or awaiting work, such as the size of an Amazon SQS queue that contains work to be processed.

2
votes

John's answer is right with the recommendations and possible solutions for your problem.

Due to reputation restrictions, I cannot comment to John answer to add details.

Is there a way to decide on the scaling activity of an autoscaling group based on metrics collected for a single instance among the multiple instances of an autoscaling group?

The scenario where you will scale in/out a single instance among the multiple instance may be a sign that you need to separate the service(s) running in that instance to a separate cluster and by that you can create a different scaling policy for the autoscaling group of new cluster.

However, is the reason you want to scale out/in that specific instance is to provide more resources for specific services running on that instance? If yes, you can autoscale up/down your service and then let the scaling policy of the autoscaling group of the cluster the service belongs decide if there's a need to scale in/out the cluster. Otherwise, John is right.