Introduction to EC2 Auto Scaling – Scaling by CPU Utilization Rate

EC2 Auto Scaling Target Tracking Policy - CPU Utilization AWS_EN

Configuring EC2 to Scale Based on CPU Utilization

We will use Auto Scaling to create a configuration for scaling out EC2. In this example, we will scale EC2 based on the CPU usage rate.
This time, select Target Tracking Scaling and specify CPU utilization as the target CloudWatch metric.


Diagram of EC2 Auto Scaling Target Tracking Policy (CPU Utilization).

Set up an EC2 Auto Scaling group in a private subnets. Attach this group to the ALB.

CloudFormation Template Files

We will build the above configuration using CloudFormation. We have placed the CloudFormation template at the following URL.

awstut-fa/026 at main · awstut-an-r/awstut-fa
Contribute to awstut-an-r/awstut-fa development by creating an account on GitHub.

Explanation of the points in template files

Attach Auto Scaling group in private subnets to ALB

In this configuration, the Auto Scaling group to be attached to ALB is located in private subnets. This is the point. The following page shows you how to attach an EC2 instance in private subnets to an ALB.

One point that differs from the above page is the target setting for the ALB target group.

Resources: ALBTargetGroup: Type: AWS::ElasticLoadBalancingV2::TargetGroup Properties: VpcId: !Ref VPC Name: !Sub "${Prefix}-ALBTargetGroup" Protocol: HTTP Port: !Ref HTTPPort HealthCheckProtocol: HTTP HealthCheckPath: / HealthCheckPort: traffic-port HealthyThresholdCount: !Ref HealthyThresholdCount UnhealthyThresholdCount: !Ref UnhealthyThresholdCount HealthCheckTimeoutSeconds: !Ref HealthCheckTimeoutSeconds HealthCheckIntervalSeconds: !Ref HealthCheckIntervalSeconds Matcher: HttpCode: !Ref HttpCode #Targets:
Code language: YAML (yaml)

Normally, the Targets property is used to specify the EC2 instance, IP address, and Lambda to be attached to the ALB. However, this time, we will not set this property. This is because the settings will be made in the Auto Scaling group described below.

Three elements that make up Auto Scaling

In order to configure Auto Scaling, the following three resources must be created.

  • Launch Configuration
  • Auto Scaling Group
  • Scaling Policy

Let’s check them in order.

Launch Configuration

The Launch Configuration for Auto Scaling have many parameters similar to those for EC2 instances.

Resources: LaunchConfiguration: Type: AWS::AutoScaling::LaunchConfiguration Properties: IamInstanceProfile: !Ref InstanceProfile ImageId: !Ref ImageId InstanceType: !Ref InstanceType LaunchConfigurationName: !Sub "${Prefix}-LaunchConfiguration" SecurityGroups: - !Ref InstanceSecurityGroup UserData: !Base64 | #!/bin/bash -xe yum update -y yum install -y httpd systemctl start httpd systemctl enable httpd ec2-metadata -i > /var/www/html/index.html yes > /dev/null
Code language: YAML (yaml)

Many properties familiar to EC2 instances are available, such as ImageId and InstanceType.
With the UserData property, you can define the initialization process for the instances created in the Auto Scaling group. In this case, we will specify that the yes command should be executed after Apache is installed and enabled. yes command is intended to increase the CPU usage of the instance to trigger scaling.

Auto Scaling Group

Specify the number of instances to be created and the target group in the Auto Scaling group.

Resources: AutoScalingGroup: Type: AWS::AutoScaling::AutoScalingGroup Properties: AutoScalingGroupName: !Sub "${Prefix}-AutoScalingGroup" DesiredCapacity: !Ref DesiredCapacity LaunchConfigurationName: !Ref LaunchConfiguration MaxSize: !Ref MaxSize MinSize: !Ref MinSize VPCZoneIdentifier: - !Ref PrivateSubnet1 - !Ref PrivateSubnet2 TargetGroupARNs: - !Ref ALBTargetGroup
Code language: YAML (yaml)

There are two key points to consider when setting up an Auto Scaling group.
The first is the number of instances to be launched in the group, which can be defined by the DesiredCapacity property as the desired number, the MaxSize property as the maximum number, and the MinSize property as the minimum number. In this case, we will set 1, 2, and 1, respectively, so that the default is 1 and the maximum is 2 instances launched.
The second point is the target group: in the TargetGroupARNs property, you can specify the resources to be associated with the Auto Scaling group. In this case, we will configure it so that when you access the ALB, you can access the EC2 instances in the Auto Scaling group. Therefore, specify the ALB target group as described earlier in the property.

Scaling Policy

The scaling policy is a rule for increasing or decreasing the number of instances.

Resources: ScalingPolicy: Type: AWS::AutoScaling::ScalingPolicy Properties: AutoScalingGroupName: !Ref AutoScalingGroup PolicyType: TargetTrackingScaling TargetTrackingConfiguration: PredefinedMetricSpecification: PredefinedMetricType: ASGAverageCPUUtilization TargetValue: !Ref TargetTrackingConfigurationTargetValue
Code language: YAML (yaml)

In this configuration, the number of instances will be increased or decreased according to the CPU utilization. In the TargetValue property, you can set the threshold value. You can set the threshold value with the TargetValue property. The target value property can be used to set the threshold value. In this example, we will set the scaling to start when the CPU utilization is 50%.


We will use CloudFormation to build this environment and check its actual behavior.

Create CloudFormation stacks and check resources in stacks

We will create a CloudFormation stack.
For information on how to create a stack and check each stack, please refer to the following page

After checking the resources in each stack, the following is the information of the main resources created this time.

  • ALB: fa-016-ALB
  • Auto Scaling Group: fa-026-AutoScalingGroup

We will also check the creation status of the resources from the AWS Management Console. First, we will check the ALB.

The ALB has been created normally.

You can see that the ALB has been created and the DNS name has been automatically assigned. We will access this DNS name later.

Next, check the Auto Scaling group.

The Auto Scaling group has been created successfully.

We can see that the number of instances and instance types are as configured in the CloudFormation template file.

From the history of the Auto Scaling group, we can see that the instances were automatically created.

Looking at the history, we can see that one instance was automatically created as per the desired number.

Automatically created instance.

We can see that one instance has indeed been created.

Accessing the ALB ①

Now that everything is ready, let’s access the ALB.

Access results to ALB 1.

We can see that the instance automatically created in the Auto Scaling group is responding as the ALB target.

Behavior at Scale Out

During the initialization process of the instance using UserData, the yes command is executed. Since it will be executed constantly, the CPU utilization will gradually increase.

CPU usage is above the threshold.

CPU usage has exceeded 50%. Scaling is started.

You can see that the second instance has been created automatically.

Looking at the Auto Scaling history, we can see that the number of instances has increased from one to two.

Automatically created the second instance.

Accessing the ALB ②

Access the ALB again.

Access results to ALB 2.

This time, in addition to the previous page, we can see the response from the second instance. In this way, by specifying the Auto Scaling group as the target group of the ALB, even if the load increases, the number of instances can be automatically increased and the system can continue to operate.


We have confirmed how to scale the number of instances in an Auto Scaling group based on CPU usage.
Confirmed how to specify the Auto Scaling group as the target group for ALB.