High Speed AWS Auto Scaling Groups for Web Application Auto Scaling

Have been exploring options to use machine images within Launch Templates to deploy into auto scaling groups and found some interesting steps in connecting Cloud Watch Alarm to those ASGs.

Use Cases

Creating an Auto Scaling Group (ASG) in AWS using a Launch Template is a common way to automatically scale EC2 instances based on predefined policies. Below are some sample use cases for ASG creation, demonstrating how they can be implemented with Launch Templates in AWS. Let us look at some key use cases to ASGs.

Use Case 1: Web Application Auto Scaling

In this example, you want to scale EC2 instances based on incoming web traffic. You have a web application deployed on a custom AMI, and you want to ensure that your application can scale automatically to handle varying levels of traffic.

Steps:

1. Create a Launch Template:
2. Create Auto Scaling Group (ASG):
3. Configure Scaling Policies:
4. Create the Auto Scaling Group:

Result:

As traffic increases, the Auto Scaling group will launch new EC2 instances to handle the additional load. If traffic decreases, the Auto Scaling group will terminate excess instances, ensuring cost optimization.

Use Case 2: Batch Processing Jobs (Scale Based on Queue Size)

You need to process jobs in a queue (e.g., Amazon SQS) and want to scale your worker instances dynamically based on the queue length.

Steps:

1. Create a Launch Template:
2. Create Auto Scaling Group (ASG):
3. Configure Scaling Policies:
4. Set Up CloudWatch Alarms for Queue Length:
5. Create the Auto Scaling Group:

Result:

When the SQS queue grows in size (indicating that more work is waiting to be processed), the Auto Scaling group will launch more EC2 instances to handle the load. Once the queue shrinks, instances will be terminated to save costs.

Use Case 3: High Availability Setup (Multi-Region Scaling)

You need to ensure high availability for your application by deploying instances in multiple regions. If one region goes down, your Auto Scaling Group should automatically scale instances in another region to compensate.

Steps:

1. Create a Launch Template:
2. Create Auto Scaling Groups in Multiple Regions:
3. Cross-Region Load Balancer:
4. Configure Scaling Policies:
5. Set Up Health Checks and Failover Mechanism:

Result:

This setup ensures high availability by automatically scaling instances in the secondary region if the primary region experiences issues. If traffic spikes in one region, the Auto Scaling Group will increase capacity in that region or switch to a backup region seamlessly.

Use Case 4: Cost-Effective Auto Scaling for Development and Testing

For development or testing environments where you only need to run instances during business hours, you can use Auto Scaling with a scheduled policy to scale up and down during predefined hours.

Steps:

1. Create a Launch Template:
2. Create Auto Scaling Group (ASG):
3. Configure Scheduled Scaling:
4. Configure Scaling Policies:

Result:

The Auto Scaling group will automatically launch and terminate instances based on the defined schedule, helping you save costs by only running instances when needed.

Use Case 5: Machine Learning Model Training

In a scenario where you need to train machine learning models that require a significant amount of computational power, you can use Auto Scaling to launch GPU-based EC2 instances.

Steps:

1. Create a Launch Template:
2. Create Auto Scaling Group (ASG):
3. Configure Scaling Policies:
4. Set Up CloudWatch Alarms:

Result:

The Auto Scaling group will adjust the number of EC2 instances based on the workload, ensuring that enough compute power is available for model training and scaling down to save costs once training is completed.

Introduction

After seeing these use cases, we know that using Launch Templates for creating Auto Scaling Groups in AWS allows us to automate the scaling of EC2 instances in response to changes in traffic or workload. Each use case varies, but the common theme is leveraging dynamic scaling to optimize performance and cost efficiency, ensuring that applications run smoothly at any scale. This is a summary view:

Creating an AWS-based Auto Scaling Group (ASG) with CloudWatch Alarms, using a custom Amazon Machine Image (AMI) and Launch Templates, involves some interesting steps. Summarised with the help of chatgpt below- a high-level guide to set up this infrastructure in this article:

Prerequisites:

1. Custom AMI – An AMI that has your application or environment pre-installed.
2. IAM Role – Permissions required for instances in the Auto Scaling Group to interact with AWS resources.
3. VPC, Subnet, Security Group – Networking setup for instances.
4. CloudWatch Metrics – To monitor and trigger alarms for scaling.

Step 1: Create a Custom AMI

If you don't have a custom AMI yet, you can create one from an EC2 instance with your desired configurations.

1. Launch an EC2 Instance:
2. Create an AMI:

Step 2: Create a Launch Template

Launch templates allow you to specify configuration details for the instances that are launched by your Auto Scaling Group.

1. Create a Launch Template:In the EC2 Console, go to Launch Templates > Create launch template.Provide a name for the launch template.Choose your custom AMI under the AMI ID field.Select the appropriate instance type (e.g., t3.micro, m5.large).Set the Key pair for SSH access (optional, but recommended for debugging).Configure networking settings (VPC, subnet).Select or create an IAM role that allows instances to interact with other AWS resources (e.g., S3, CloudWatch).Optionally, set up block device mapping for additional storage.Click Create launch template.

Step 3: Set Up the Auto Scaling Group

Now, create the Auto Scaling Group that will automatically scale based on CloudWatch metrics and alarms.

1. Create an Auto Scaling Group:
2. Define Desired Capacity:
3. Configure Health Checks:
4. Create Auto Scaling Group:

Step 4: Set Up CloudWatch Alarms

CloudWatch alarms monitor metrics from your Auto Scaling group or EC2 instances and trigger scaling actions.

1. Create a CloudWatch Alarm for Scaling (e.g., CPU utilization):
2. Set Scaling Policies in Auto Scaling Group:
3. Attach CloudWatch Alarms to Auto Scaling Policies:

Step 5: Test Auto Scaling and Monitoring

1. Test Scaling:
2. Monitor CloudWatch Metrics:

Step 6: (Optional) Set Up Notifications with SNS

To notify administrators when an Auto Scaling event occurs or when an alarm triggers, set up Amazon SNS.

1. Create an SNS Topic:Go to the SNS Console, create a new SNS topic (e.g., "AutoScalingNotifications").Subscribe to the topic with your email address or any other endpoint.
2. Attach SNS to CloudWatch Alarm:In the CloudWatch Alarm creation process, add an action to send notifications to the SNS topic.

Step 7: Review and Final Testing

After setting up all the components, ensure that the following works as expected:

• The Auto Scaling Group launches instances based on your custom AMI.
• CloudWatch alarms trigger scaling actions (scale-up/scale-down).
• Notifications are sent when alarms are triggered (if configured).
• Auto Scaling adjusts the number of instances according to the scaling policies.

Additional Considerations:

1. Scaling Based on Multiple Metrics: You can create composite CloudWatch alarms based on multiple metrics (e.g., both CPU and memory usage) to trigger scaling actions.
2. Instance Warm-Up Period: Configure a warm-up period to ensure new instances have enough time to start up and start serving traffic before another scaling action is triggered.
3. Cost Considerations: Keep in mind that Auto Scaling can help optimize costs by reducing the number of instances when traffic is low, but this also requires constant monitoring to avoid under-provisioning during peak periods.

This approach should help in creating a robust, scalable infrastructure using AWS Auto Scaling Groups, CloudWatch Alarms, and Launch Templates. Let me know if you need further clarification or help with specific steps!

Let us see these steps in action in following sections.

Instance based AMI creation

Navigating to public IP of this instance in EC2 to see the page load:

To create an AMI (Amazon Machine Image) from an EC2 instance, follow these steps:

1. First, launch an EC2 instance with your desired configuration and applications installed. Once the instance is set up as needed, go to the EC2 Console.
2. In the EC2 dashboard, locate the instance from which you want to create the AMI. Select the instance by checking the box next to its ID.
3. With the instance selected, click on Actions in the top menu. From the dropdown, choose Image and templates, and then select Create image.
4. In the Create Image dialog, give your image a name and description that will help you identify it later. You can also configure options such as whether to create a snapshot of the root volume and additional attached volumes.
5. Optionally, you can set a No Reboot option if you want the instance to remain running while the AMI is being created. However, it is recommended to allow the instance to reboot to ensure the consistency of the image.
6. Click on Create image once you're satisfied with the settings. AWS will start creating the image, and you can monitor the progress in the AMIs section of the EC2 console. The process may take several minutes, depending on the size of the instance and its volumes.
7. Once the image creation is complete, it will appear in the AMIs section, where you can view, launch new instances, or share the AMI as needed. You can also use this AMI in Launch Templates or Auto Scaling Groups for automatic scaling.

This process will provide you with a reusable, consistent copy of your EC2 instance that can be deployed across multiple regions or used in automated scaling solutions.

Enter a valid name:

Now AMI has been created:

Launch Template Creation

To create a Launch Template in AWS using a shared AMI, follow these steps:

Start by navigating to the EC2 Console. In the left-hand menu, click on Launch Templates under the Instances section. Then, click on the Create launch template button to begin the creation process.

In the Create Launch Template page, provide a name for the template and an optional description. In the AMI ID field, choose the Shared AMI that you want to use for the launch template. If the AMI is not in your account but has been shared with you, ensure that the shared AMI is visible in your EC2 dashboard under AMIs.

After selecting the AMI, choose the instance type that fits your needs, such as t3.micro or m5.large. You can also configure other parameters, such as network settings, key pair, IAM roles, security groups, and storage options for the instance.

Additionally, in the Advanced details section, you can specify user data (e.g., shell scripts or cloud-init configuration) that will be executed when the instance starts.

Once you've configured the template with the appropriate settings, review the details. If everything looks good, click Create launch template to finalize the process. The launch template will now be available in the Launch Templatessection of the EC2 console, and you can use it to launch EC2 instances, or even integrate it into an Auto Scaling group.

This process enables you to use a shared AMI as the base for instance creation through Launch Templates, allowing for consistent and repeatable instance deployments.

Enter a valid name to starts with:

Chosen My AMI on the list below:

Chosen t3.micro for the simplicity to creating template:

Creating a security group while launching the template to allow HTTP in VPC:

Enabling inbound traffic for HTTP:

Enabled cloud watch monitoring to create Alarm when needed to increase the scale to create instances from this launch template using AMI:

Used this code in User Data:

#!/bin/bash
sudo yum update -y
sudo yum install -y httpd
sudo amazon-linux-extras install epel -y
sudo yum install -y stress

# Starting and enabling HTTPD service
systemctl start httpd.service
systemctl enable httpd.service

# Creating simple index.html file for HTTPD base page
echo '<html><h1>Hello Gurus!</h1><h3>I live in this Availability Zone: ' > /var/www/html/index.html
curl http://169.254.169.254/latest/meta-data/placement/availability-zone >> /var/www/html/index.html
echo '</h3> <h3>I go by this Instance Id: ' >> /var/www/html/index.html
curl http://169.254.169.254/latest/meta-data/instance-id >> /var/www/html/index.html
echo '</h3></html> ' >> /var/www/html/index.html

# Restarting HTTPD service to enforce new index.html just to be safe.
systemctl restart httpd.service
        

This has helped in creating the Launch Template finally:

While Launch template getting created, AMI has been made available from pending status:

Auto Scaling Group(ASG) Creation

It is time to create ASGs using this launch template:

Use the private subnets at this stage:

Choose to create new Load Balancers:

Select Internet facing to connect public network:

Similarly choose subnets as public to connect external facing URLs:

Update HTTP routing by creating a new target group:

Choose the period of health check as 60 seconds (common for those simple EC2 setups):

Chosen 3 as desired max capacity to understand how it scales up when there is a need:

Update Avg CPU utilisation to create alarm when needed:

Chosen 60 seconds as Instance Warm up while creating this ASG:

Generally this option getting changed based on the business use case needs and I have chosen No policy for the understandings of ASG creation -otherwise recommended to choose between right options:

Now ASG is getting updated for the capacity:

Changing security group is helpful in allowing HTTP traffic:

Cloud Watch Alarms

In AWS CloudWatch, when an alarm is set to trigger based on an average of a metric like CPU utilization (referred to as "APU" in your question, which I assume refers to the CPU usage of an EC2 instance), the average value is calculated over a specified period of time, known as the "evaluation period."

When you create a CloudWatch alarm for a metric like CPU utilization, the metric data is collected at a regular interval, typically every 1 minute or 5 minutes, depending on the metric’s granularity and the settings you choose. The CloudWatch alarm evaluates the metric by calculating the average of the metric’s data points over the period specified for the alarm.

For example, if you set the alarm to trigger when the CPU utilization is above 80% for a period of 5 minutes, CloudWatch will calculate the average CPU utilization over that 5-minute period based on data points (e.g., every minute or 5 minutes). If the average CPU utilization during this evaluation period exceeds the 80% threshold you set, the alarm will go into the "ALARM" state, and the corresponding action (such as sending a notification or triggering an Auto Scaling policy) will be triggered.

So, the calculation of the average is based on the period you configure in the alarm, and it reflects the average of the metric values over that time interval, considering the granularity of the metric data points. If you choose a 5-minute period for evaluation, for example, CloudWatch will calculate the average of the metric data points over those 5 minutes to determine if the threshold condition is met.

Useful video:

Now both EC2 creation and Load Balancer creation are tracked int he activity history:

Navigate to EC2 instance and connect to it via SSH and enter this command to kick start the CPU usage via a stress test:

The command stress --cpu 2 is used to stress test the CPU of an EC2 instance (or any Linux-based machine) by generating CPU load. Specifically, it runs the stress tool, which is a utility for stress testing various system components like CPU, memory, and I/O.

Here’s a breakdown of what this command does:

1. stress: This is the command to invoke the stress tool, which is commonly used to generate system load for testing and benchmarking purposes.
2. --cpu 2: This flag tells the stress tool to spawn two processes that will each consume CPU cycles in an attempt to load the CPU. The --cpu flag is used to specify the number of CPU workers to spawn. In this case, it will run two CPU-bound processes that will continuously consume CPU resources until the tool is stopped.

Effect:

• CPU Load: By running stress --cpu 2, you're instructing the system to simulate a load by creating two processes that will use as much CPU as possible. This will cause the EC2 instance to utilize its CPU heavily, which will increase the CPU utilization metric in CloudWatch (if monitoring is enabled).
• Impact on Instance: If you're using a smaller instance type (like t2.micro or t3.micro), this could cause high CPU utilization, potentially leading to throttling or reduced performance if your instance is under a "burstable" performance model.

Common Use Cases:

• Benchmarking: To evaluate how well the EC2 instance performs under load.
• Load Testing: To simulate high CPU usage for performance testing or to ensure the instance can handle expected workloads.
• CloudWatch Monitoring: You might use this command to test CloudWatch alarms and Auto Scaling triggers based on CPU usage.

Stopping the Command:

The stress test will continue running until it is manually stopped. You can stop it by pressing Ctrl+C in the terminal or by terminating the process.

In summary, the command stress --cpu 2 is used to simulate CPU load by running two CPU-intensive processes, which will consume CPU resources and increase the overall load on the EC2 instance.

Watch this video to understand the steps involved in reaching to Cloud Watch Alarm State: Link

Summary

An Auto Scaling Group (ASG) is highly useful in AWS for a business, especially when using custom AMIs, as it allows automatic adjustment of the number of EC2 instances based on real-time demand. This scalability ensures that a business can handle varying traffic loads efficiently, without over-provisioning or under-provisioning resources.

When combined with a custom AMI, an ASG ensures that instances are launched with pre-configured applications, settings, and environments, streamlining the deployment process and maintaining consistency across all instances. With a custom AMI, businesses can create an environment tailored to their specific needs, ensuring that every new instance in the ASG is ready to serve traffic immediately upon launch.

From a cost perspective, the combination of ASG and custom AMIs offers significant benefits. The ability to scale up or down based on real-time demand ensures that businesses are only paying for the compute resources they actually need. During periods of low demand, the ASG can automatically scale down, reducing costs by terminating unnecessary instances. Conversely, during peak periods, the ASG can scale up to meet increased demand, ensuring application performance and availability without manual intervention.

This dynamic scaling is particularly beneficial in AWS's pay-as-you-go model, where businesses avoid the overhead of maintaining unused instances during off-peak hours. Moreover, the use of a custom AMI enables businesses to standardize their infrastructure and avoid configuration drift, reducing the risk of errors and improving overall operational efficiency.

In summary, leveraging an Auto Scaling Group with a custom AMI in AWS enables businesses to efficiently manage application performance while optimizing costs. By automating scaling based on actual demand, businesses can maintain high availability, ensure consistent environments, and only incur costs for the resources they actually use, which results in cost savings and improved operational agility.

👉Please feel free to share your views in the comments section on ASGs and usage of scaling options within AWS and other cloud transformation opportunities.

⚡Follow me on LinkedIn: Link

Engineering Leadership Newsletter on LinkedIn is famous for its practical, high-quality content tailored to the needs of engineering leaders. It offers valuable insights into managing teams, scaling organizations, and becoming an effective leader in the tech world, making it a go-to resource for engineering leaders looking to improve their skills and influence.

Like this article? Subscribe to Engineering Leadership , Digital Accessibility, Digital Payments Hub and Motivation newsletters to enjoy reading useful articles. Press SHARE and REPOST button to help sharing the content with your network.

#LinkedInNewsUK #FinanceLeadership