Amazon SQS Driven EC2 Scaling based on backlog metrics

Are you looking for an efficient way to scale your EC2 instances with respect to the available messages in your Amazon SQS queue for individual instances? This blog talks about the best practices to be considered when creating a target policy to scale EC2, whenever backlog per instance increases. Whether you’re a new AWS user or an experienced one, these insights will help you optimize performance and reduce your cost while leveraging the best features on the cloud.

The current scalability issue with SQS

Let’s consider a scenario where an EC2 instance is being used to handle 15 messages at a time and a target policy is created in such a way that when available messages in the SQS are greater than 15 the EC2 instance will scale up to meet the requirements. However, let’s say there are 45 messages in the queue, and since the scaling policy is not designed to stop the provisioning with respect to the load the EC2 instance will be scaled up to the maximum auto-scaling capacity every time the SQL queue limit is reached until the scale down policy is triggered.

In AWS, optimizing resource allocation is crucial for efficiency and cost-effectiveness. By combining Amazon EC2 instances with Amazon SQS, you can implement a dynamic scaling strategy that adapts to your workload. This intelligent scaling policy continues provisioning instances until the workload is efficiently managed. When the queue size decreases, cost-saving scale-down actions are initiated. This approach maximizes resource utilization while minimizing costs, offering flexibility and automation to handle varying workloads seamlessly.

How does backlog metric math targeting policy help?

Let’s use the same case as above where we’re having 1 EC2 instance capable of handling 15 messages, now we have deployed 1 more EC2 instance. So, currently, both 2 EC2 instances are handling 30 messages (15 per Instance) this is called backlog per instance. So if we make the target scaling policy to depend and scale using the backlog per instance metric we can save lots of effort and cost in the process.

Creating auto-scaling with metric math as EC2 backlogs of SQS queue

Creating SQS queue and EC2 instance:

Here’s our 8-step guide to implement the above solution. Assuming we have an EC2 instance that can handle up to 30 messages from an SQS queue.

Creating Auto Scaling Group:

Step 1: On the Auto Scaling group console page and click on Create Auto Scaling Group.

Step 2: Select the required launch template.

Step 3: Configure the network settings.

(Optional)

Step 4: Select Load Balancer if it needs to be created newly or we can select the existing one.

Step 5: This is an important step. We have to enable Monitoring for sending the metrics to cloud watch which we will be using for math metric calculation.

Step 6: For now, select the scaling policies as None.

Step 7: Review the configurations and create the Auto Scaling Group.

Now the auto scaling group is created with 1 EC2 instance with respect to given capacities.

Creating Target tracking policy with Backlog per instance metric math:

Cloudwatch supports all arithmetic operations. Hence we are leveraging this feature to get the backlog per instance by using the following logic.

Backlog per instance = sum of (number of messages in the queue) / (number of InService instances)

m1 = sum of (number of messages in the queue)
m2 = number of InService instances

e1 = m1/m2 (e1 is our backlog per instance math metric)

Note: For creating this target tracking policy we need to use AWS CLI.

Step 1: Create a config.json with the following content on the cloudshell. And change the name of SQS and ASG according to your requirements (marked in red).

{
 "CustomizedMetricSpecification": {
  "Metrics": [{
    "Label": "Number of messages waiting to be processed",
    "Id": "m1",
    "MetricStat": {
     "Metric": {
      "MetricName": "ApproximateNumberOfMessagesVisible",
      "Namespace": "AWS/SQS",
      "Dimensions": [{
       "Name": "QueueName",
       "Value": "sqs-queue.fifo"
      }]
     },
     "Stat": "Sum"
    },
    "ReturnData": false
   },
   {
    "Label": "The number of InService instances in ASG",
    "Id": "m2",
    "MetricStat": {
     "Metric": {
      "MetricName": "GroupInServiceInstances",
      "Namespace": "AWS/AutoScaling",
      "Dimensions": [{
       "Name": "AutoScalingGroupName",
       "Value": "sqs-handling-asg"
      }]
     },
     "Stat": "Average"
    },
    "ReturnData": false
   },
   {
    "Label": "Backlog per instance",
    "Id": "e1",
    "Expression": "m1 / m2",
    "ReturnData": true
   }
  ]
 },
 "TargetValue": 30
}

Step 2: In the JSON configuration we have used the logic mentioned above to scale up with a target value of 30. (i.e.: When the backlog per instance increases above 30 the servers will scale)

Step 3: To apply this scaling policy to our auto-scaling group. Run the following command on AWS CLI. Change the policy name and auto-scaling group name as per your environment. (marked in red).

aws autoscaling put-scaling-policy \
--policy-name sqs-backlog-target-tracking-scaling-policy \
--auto-scaling-group-name sqs-handling-asg \
--policy-type TargetTrackingScaling \
--target-tracking-configuration file://config.json

Step 4: Now this will be reflected in the console under Auto Scaling Group -> Automatic Scaling

To test this ASG sends a bulk of messages to your SQS. Use the below shell script for sending 100 messages. Update your SQS URL and value of i for repetition on the script.

#!/bin/bash
QUEUE_URL="https://sqs.us-east-2.amazonaws.com/<ACCOUNT_ID>/sqs-queue.fifo"
MESSAGE="this is sqs-asg testing message"
for ((i=1; i<=120; i++))
do
 aws sqs send-message \
--queue-url "$QUEUE_URL" \
--message-body "$MESSAGE" \
--message-group-id "$i" \
--message-deduplication-id "$i"
 done

Once you run the above script, 120 messages will be sent to the queue, making the server scale up to 4 instances.

The ASG will launch the required servers.

As demonstrated, we can use Cloudwatch’s metric math to leverage the Auto Scaling Group’s target policy to scale your instances with respect to the SQS backlog per instance.

Conclusion:

In conclusion, leveraging SQS backlog metrics to drive auto scaling for EC2 instances is a powerful strategy for optimizing your AWS resources. By closely monitoring the queue size and intelligently scaling your EC2 fleet based on workload demands, you can achieve cost-effective resource allocation and efficient workload management. This approach not only maximizes resource utilization but also provides the flexibility and automation needed to seamlessly handle varying workloads in your AWS environment.

As AWS users, whether new or experienced, incorporating these best practices into your scaling policies empowers you to adapt dynamically to changing demands while minimizing costs. The synergy between EC2 and SQS, guided by intelligent scaling policies, enables you to strike the perfect balance between performance and efficiency in your cloud infrastructure. As you continue your AWS journey, keep exploring innovative ways to optimize your resource allocation, and always stay updated with the latest insights from AWS services and metrics.

Author:

This blog post is written by our Cloud Engineer Ashwin V.