Post Syndicated from Emma White original https://aws.amazon.com/blogs/compute/supporting-aws-graviton2-and-x86-instance-types-in-the-same-auto-scaling-group/
This post is written by Tyler Lynch, Sr. Solutions Architect – EdTech, and Praneeth Tekula, Technical Account Manager.
As customers seek performance improvements and to cost optimize their workloads, they are evaluating and adopting AWS Graviton2 based instances. This post provides instructions on how to configure your Amazon EC2 Auto Scaling group (ASG) to use both Graviton2 and x86 based Amazon EC2 Instances in the same Auto Scaling group with different AMIs. This allows you to introduce Graviton2 based instances as part of a multiple instance type strategy.
For example, a customer may want to use the same Auto Scaling group definition across multiple Regions, but an instance type might not available in that region yet. Implementing instance and architecture diversity allow those Auto Scaling group definitions to be portable.
Solution Overview
The Amazon EC2 Auto Scaling console currently doesn’t support the selection of multiple launch templates, so I use the AWS Command Line Interface (AWS CLI) throughout this post. First, you create your launch templates that specify AMIs for use on x86 and arm64 based instances. Then you create your Auto Scaling group using a mixed instance policy with instance level overrides to specify the launch template to use for that instance.
Finally, you extend the launch templates to use architecture-specific EC2 user data to download architecture-specific binaries. Putting it all together, here are the high-level steps to follow:
- Create the launch templates:
- Launch template for x86– Creates a launch template for x86 instances, specifying the AMI but not the instance sizes.
- Launch template for arm64– Creates a launch template for arm64 instances, specifying the AMI but not the instance sizes.
- Create the Auto Scaling group that references the launch templates in a mixed instance policy override.
- Create a sample Node.js application.
- Create the architecture-specific user data scripts.
- Modify the launch templates to use architecture-specific user data scripts.
Prerequisites
The prerequisites for this solution are as follows:
- The AWS CLI installed locally. I use AWS CLI version 2 for this post.
- For AWS CLI v2, you must use 2.1.3+
- For AWS CLI v1, you must use 1.18.182+
- The correct AWS Identity and Access Management(IAM) role permissions for your account allowing for the creation and execution of the launch templates, Auto Scaling groups, and launching EC2 instances.
- A source control service such as AWS CodeCommit or GitHub that your user data script can interact with to
git clone the Hello World Node.js application.
- The source code repository initialized and cloned locally.
Create the Launch Templates
You start with creating the launch template for x86 instances, and then the launch template for arm64 instances. These are simple launch templates where you only specify the AMI for Amazon Linux 2 in US-EAST-1 (architecture dependent). You use the AWS CLI cli-input-json feature to make things more readable and repeatable.
You first must add the lt-x86-cli-input.json file to your local working for reference by the AWS CLI.
- In your preferred text editor, add a new file, and copy paste the following JSON into the file.
{
"LaunchTemplateName": "lt-x86",
"VersionDescription": "LaunchTemplate for x86 instance types using Amazon Linux 2 x86 AMI in US-EAST-1",
"LaunchTemplateData": {
"ImageId": "ami-04bf6dcdc9ab498ca"
}
}
- Save the file in your local working directory and name it
lt-x86-cli-input.json.
Now, add the lt-arm64-cli-input.json file into your local working directory.
- In a text editor, add a new file, and copy paste the following JSON into the file.
{
"LaunchTemplateName": "lt-arm64",
"VersionDescription": "LaunchTemplate for Graviton2 instance types using Amazon Linux 2 Arm64 AMI in US-EAST-1",
"LaunchTemplateData": {
"ImageId": "ami-09e7aedfda734b173"
}
}
- Save the file in your local working directory and name it
lt-arm64-cli-input.json.
Now that your CLI input files are ready, create your launch templates using the CLI.
From your terminal, run the following commands:
aws ec2 create-launch-template \
--cli-input-json file://./lt-x86-cli-input.json \
--region us-east-1
aws ec2 create-launch-template \
--cli-input-json file://./lt-arm64-cli-input.json \
--region us-east-1
After you run each command, you should see the command output similar to this:
{
"LaunchTemplate": {
"LaunchTemplateId": "lt-07ab8c76f8e021b0c",
"LaunchTemplateName": "lt-x86",
"CreateTime": "2020-11-20T16:08:08+00:00",
"CreatedBy": "arn:aws:sts::111111111111:assumed-role/Admin/myusername",
"DefaultVersionNumber": 1,
"LatestVersionNumber": 1
}
}
{
"LaunchTemplate": {
"LaunchTemplateId": "lt-0c65656a2c75c0f76",
"LaunchTemplateName": "lt-arm64",
"CreateTime": "2020-11-20T16:08:37+00:00",
"CreatedBy": "arn:aws:sts::111111111111:assumed-role/Admin/myusername",
"DefaultVersionNumber": 1,
"LatestVersionNumber": 1
}
}
Create the Auto Scaling Group
Moving on to creating your Auto Scaling group, start with creating another JSON file to use the cli-input-json feature. Then, create the Auto Scaling group via the CLI.
I want to call special attention to the LaunchTemplateSpecification under the MixedInstancePolicy Overrides property. This Auto Scaling group is being created with a default launch template, the one you created for arm64 based instances. You override that at the instance level for x86 instances.
Now, add the asg-mixed-arch-cli-input.json file into your local working directory.
- In a text editor, add a new file, and copy paste the following JSON into the file.
- You need to change the subnet IDs specified in the
VPCZoneIdentifier to your own subnet IDs.
{
"AutoScalingGroupName": "asg-mixed-arch",
"MixedInstancesPolicy": {
"LaunchTemplate": {
"LaunchTemplateSpecification": {
"LaunchTemplateName": "lt-arm64",
"Version": "$Default"
},
"Overrides": [
{
"InstanceType": "t4g.micro"
},
{
"InstanceType": "t3.micro",
"LaunchTemplateSpecification": {
"LaunchTemplateName": "lt-x86",
"Version": "$Default"
}
},
{
"InstanceType": "t3a.micro",
"LaunchTemplateSpecification": {
"LaunchTemplateName": "lt-x86",
"Version": "$Default"
}
}
]
}
},
"MinSize": 1,
"MaxSize": 5,
"DesiredCapacity": 3,
"VPCZoneIdentifier": "subnet-e92485b6, subnet-07fe637b44fd23c31, subnet-828622e4, subnet-9bd6a2d6"
}
- Save the file in your local working directory and name it
asg-mixed-arch-cli-input.json.
Now that your CLI input file is ready, create your Auto Scaling group using the CLI.
- From your terminal, run the following command:
aws autoscaling create-auto-scaling-group \
--cli-input-json file://./asg-mixed-arch-cli-input.json \
--region us-east-1
After you run the command, there isn’t any immediate output. Describe the Auto Scaling group to review the configuration.
- From your terminal, run the following command:
aws autoscaling describe-auto-scaling-groups \
--auto-scaling-group-names asg-mixed-arch \
--region us-east-1
Let’s evaluate the output. I removed some of the output for brevity. It shows that you have an Auto Scaling group with a mixed instance policy, which specifies a default launch template named lt-arm64. In the Overrides property, you can see the instances types that you specified and the values that define the lt-x86 launch template to be used for specific instance types (t3.micro, t3a.micro).
{
"AutoScalingGroups": [
{
"AutoScalingGroupName": "asg-mixed-arch",
"AutoScalingGroupARN": "arn:aws:autoscaling:us-east-1:111111111111:autoScalingGroup:a1a1a1a1-a1a1-a1a1-a1a1-a1a1a1a1a1a1:autoScalingGroupName/asg-mixed-arch",
"MixedInstancesPolicy": {
"LaunchTemplate": {
"LaunchTemplateSpecification": {
"LaunchTemplateId": "lt-0cc7dae79a397d663",
"LaunchTemplateName": "lt-arm64",
"Version": "$Default"
},
"Overrides": [
{
"InstanceType": "t4g.micro"
},
{
"InstanceType": "t3.micro",
"LaunchTemplateSpecification": {
"LaunchTemplateId": "lt-04b525bfbde0dcebb",
"LaunchTemplateName": "lt-x86",
"Version": "$Default"
}
},
{
"InstanceType": "t3a.micro",
"LaunchTemplateSpecification": {
"LaunchTemplateId": "lt-04b525bfbde0dcebb",
"LaunchTemplateName": "lt-x86",
"Version": "$Default"
}
}
]
},
...
},
...
"Instances": [
{
"InstanceId": "i-00377a23630a5e107",
"InstanceType": "t4g.micro",
"AvailabilityZone": "us-east-1b",
"LifecycleState": "InService",
"HealthStatus": "Healthy",
"LaunchTemplate": {
"LaunchTemplateId": "lt-0cc7dae79a397d663",
"LaunchTemplateName": "lt-arm64",
"Version": "1"
},
"ProtectedFromScaleIn": false
},
{
"InstanceId": "i-07c2d4f875f1f457e",
"InstanceType": "t4g.micro",
"AvailabilityZone": "us-east-1a",
"LifecycleState": "InService",
"HealthStatus": "Healthy",
"LaunchTemplate": {
"LaunchTemplateId": "lt-0cc7dae79a397d663",
"LaunchTemplateName": "lt-arm64",
"Version": "1"
},
"ProtectedFromScaleIn": false
},
{
"InstanceId": "i-09e61e95cdf705ade",
"InstanceType": "t4g.micro",
"AvailabilityZone": "us-east-1c",
"LifecycleState": "InService",
"HealthStatus": "Healthy",
"LaunchTemplate": {
"LaunchTemplateId": "lt-0cc7dae79a397d663",
"LaunchTemplateName": "lt-arm64",
"Version": "1"
},
"ProtectedFromScaleIn": false
}
],
...
}
]
}
Create Hello World Node.js App
Now that you have created the launch templates and the Auto Scaling group you are ready to create the “hello world” application that self-reports the processor architecture. You work in the local directory that is cloned from your source repository as specified in the prerequisites. This doesn’t have to be the local working directory where you are creating architecture-specific files.
- In a text editor, add a new file with the following Node.js code:
// Hello World sample app.
const http = require('http');
const port = 3000;
const server = http.createServer((req, res) => {
res.statusCode = 200;
res.setHeader('Content-Type', 'text/plain');
res.end(`Hello World. This processor architecture is ${process.arch}`);
});
server.listen(port, () => {
console.log(`Server running on processor architecture ${process.arch}`);
});
- Save the file in the root of your source repository and name it
app.js.
- Commit the changes to Git and push the changes to your source repository. See the following commands:
git add .
git commit -m "Adding Node.js sample application."
git push
Create user data scripts
Moving on to your creating architecture-specific user data scripts that will define the version of Node.js and the distribution that matches the processor architecture. It will download and extract the binary and add the binary path to the environment PATH. Then it will clone the Hello World app, and then run that app with the binary of Node.js that was installed.
Now, you must add the ud-x86-cli-input.txt file to your local working directory.
- In your text editor, add a new file, and copy paste the following text into the file.
- Update the
git clone command to use the repo URL where you created the Hello World app previously.
- Update the
cd command to use the repo name.
sudo yum update -y
sudo yum install git -y
VERSION=v14.15.3
DISTRO=linux-x64
wget https://nodejs.org/dist/$VERSION/node-$VERSION-$DISTRO.tar.xz
sudo mkdir -p /usr/local/lib/nodejs
sudo tar -xJvf node-$VERSION-$DISTRO.tar.xz -C /usr/local/lib/nodejs
export PATH=/usr/local/lib/nodejs/node-$VERSION-$DISTRO/bin:$PATH
git clone https://github.com/<<githubuser>>/<<repo>>.git
cd <<repo>>
node app.js
- Save the file in your local working directory and name it
ud-x86-cli-input.txt.
Now, add the ud-arm64-cli-input.txt file into your local working directory.
- In a text editor, add a new file, and copy paste the following text into the file.
- Update the
git clone command to use the repo URL where you created the Hello World app previously.
- Update the
cd command to use the repo name.
sudo yum update -y
sudo yum install git -y
VERSION=v14.15.3
DISTRO=linux-arm64
wget https://nodejs.org/dist/$VERSION/node-$VERSION-$DISTRO.tar.xz
sudo mkdir -p /usr/local/lib/nodejs
sudo tar -xJvf node-$VERSION-$DISTRO.tar.xz -C /usr/local/lib/nodejs
export PATH=/usr/local/lib/nodejs/node-$VERSION-$DISTRO/bin:$PATH
git clone https://github.com/<<githubuser>>/<<repo>>.git
cd <<repo>>
node app.js
- Save the file in your local working directory and name it
ud-arm64-cli-input.txt.
Now that your user data scripts are ready, you need to base64 encode them as the AWS CLI does not perform base64-encoding of the user data for you.
- On a Linux computer, from your terminal use the
base64 command to encode the user data scripts.
base64 ud-x86-cli-input.txt > ud-x86-cli-input-base64.txt
base64 ud-arm64-cli-input.txt > ud-arm64-cli-input-base64.txt
- On a Windows computer, from your command line use the
certutil command to encode the user data. Before you can use this file with the AWS CLI, you must remove the first (BEGIN CERTIFICATE) and last (END CERTIFICATE) lines.
certutil -encode ud-x86-cli-input.txt ud-x86-cli-input-base64.txt
certutil -encode ud-arm64-cli-input.txt ud-arm64-cli-input-base64.txt
notepad ud-x86-cli-input-base64.txt
notepad ud-arm64-cli-input-base64.txt
Modify the Launch Templates
Now, you modify the launch templates to use architecture-specific user data scripts.
Please note that the contents of your ud-x86-cli-input-base64.txt and ud-arm64-cli-input-base64.txt files are different from the samples here because you referenced your own GitHub repository. These base64 encoded user data scripts below will not work as is, they contain placeholder references for the git clone and cd commands.
Next, update the lt-x86-cli-input.json file to include your base64 encoded user data script for x86 based instances.
- In your preferred text editor, open the
ud-x86-cli-input-base64.txt file.
- Open the
lt-x86-cli-input.json file, and add in the text from the ud-x86-cli-input-base64.txt file into the UserData property of the LaunchTemplateData object. It should look similar to this:
{
"LaunchTemplateName": "lt-x86",
"VersionDescription": "LaunchTemplate for x86 instance types using Amazon Linux 2 x86 AMI in US-EAST-1",
"LaunchTemplateData": {
"ImageId": "ami-04bf6dcdc9ab498ca",
"UserData": "IyEvYmluL2Jhc2gKeXVtIHVwZGF0ZSAteQoKVkVSU0lPTj12MTQuMTUuMwpESVNUUk89bGludXgteDY0CndnZXQgaHR0cHM6Ly9ub2RlanMub3JnL2Rpc3QvJFZFUlNJT04vbm9kZS0kVkVSU0lPTi0kRElTVFJPLnRhci54egpzdWRvIG1rZGlyIC1wIC91c3IvbG9jYWwvbGliL25vZGVqcwpzdWRvIHRhciAteEp2ZiBub2RlLSRWRVJTSU9OLSRESVNUUk8udGFyLnh6IC1DIC91c3IvbG9jYWwvbGliL25vZGVqcyAKZXhwb3J0IFBBVEg9L3Vzci9sb2NhbC9saWIvbm9kZWpzL25vZGUtJFZFUlNJT04tJERJU1RSTy9iaW46JFBBVEgKZ2l0IGNsb25lIGh0dHBzOi8vZ2l0aHViLmNvbS88PGdpdGh1YnVzZXI+Pi88PHJlcG8+Pi5naXQKY2QgPDxyZXBvPj4Kbm9kZSBhcHAuanMK"
}
}
- Save the file.
Next, update the lt-arm64-cli-input.json file to include your base64 encoded user data script for arm64 based instances.
- In your text editor, open the
ud-arm64-cli-input-base64.txt file.
- Open the
lt-arm64-cli-input.json file, and add in the text from the ud-arm64-cli-input-base64.txt file into the UserData property of the LaunchTemplateData It should look similar to this:
{
"LaunchTemplateName": "lt-arm64",
"VersionDescription": "LaunchTemplate for Graviton2 instance types using Amazon Linux 2 Arm64 AMI in US-EAST-1",
"LaunchTemplateData": {
"ImageId": "ami-09e7aedfda734b173",
"UserData": "IyEvYmluL2Jhc2gKeXVtIHVwZGF0ZSAteQoKVkVSU0lPTj12MTQuMTUuMwpESVNUUk89bGludXgtYXJtNjQKd2dldCBodHRwczovL25vZGVqcy5vcmcvZGlzdC8kVkVSU0lPTi9ub2RlLSRWRVJTSU9OLSRESVNUUk8udGFyLnh6CnN1ZG8gbWtkaXIgLXAgL3Vzci9sb2NhbC9saWIvbm9kZWpzCnN1ZG8gdGFyIC14SnZmIG5vZGUtJFZFUlNJT04tJERJU1RSTy50YXIueHogLUMgL3Vzci9sb2NhbC9saWIvbm9kZWpzIApleHBvcnQgUEFUSD0vdXNyL2xvY2FsL2xpYi9ub2RlanMvbm9kZS0kVkVSU0lPTi0kRElTVFJPL2JpbjokUEFUSApnaXQgY2xvbmUgaHR0cHM6Ly9naXRodWIuY29tLzw8Z2l0aHVidXNlcj4+Lzw8cmVwbz4+LmdpdApjZCA8PHJlcG8+Pgpub2RlIGFwcC5qcwoKCg=="
}
}
- Save the file.
Now, your CLI input files are ready. Next, create a new version of your launch templates and then set the newest version as the default.
From your terminal, run the following commands:
aws ec2 create-launch-template-version \
--cli-input-json file://./lt-x86-cli-input.json \
--region us-east-1
aws ec2 create-launch-template-version \
--cli-input-json file://./lt-arm64-cli-input.json \
--region us-east-1
aws ec2 modify-launch-template \
--launch-template-name lt-x86 \
--default-version 2
aws ec2 modify-launch-template \
--launch-template-name lt-arm64 \
--default-version 2
After you run each command, you should see the command output similar to this:
{
"LaunchTemplate": {
"LaunchTemplateId": "lt-08ff3d03d4cf0038d",
"LaunchTemplateName": "lt-x86",
"CreateTime": "1970-01-01T00:00:00+00:00",
"CreatedBy": "arn:aws:sts::111111111111:assumed-role/Admin/myusername",
"DefaultVersionNumber": 2,
"LatestVersionNumber": 2
}
}
{
"LaunchTemplate": {
"LaunchTemplateId": "lt-0c5e1eb862a02f8e0",
"LaunchTemplateName": "lt-arm64",
"CreateTime": "1970-01-01T00:00:00+00:00",
"CreatedBy": "arn:aws:sts::111111111111:assumed-role/Admin/myusername",
"DefaultVersionNumber": 2,
"LatestVersionNumber": 2
}
}
Now, refresh the instances in the Auto Scaling group so that the newest version of the launch template is used.
From your terminal, run the following command:
aws autoscaling start-instance-refresh \
--auto-scaling-group-name asg-mixed-arch
Verify Instances
The sample Node.js application self reports the process architecture in two ways: when the application is started, and when the application receives a HTTP request on port 3000. Retrieve the last five lines of the instance console output via the AWS CLI.
First, you need to get an instance ID from the autoscaling group.
- From your terminal, run the following commands:
aws autoscaling describe-auto-scaling-groups \
--auto-scaling-group-name asg-mixed-arch \
--region us-east-1
- Evaluate the output. I removed some of the output for brevity. You need to use the
InstanceID from the output.
{
"AutoScalingGroups": [
{
"AutoScalingGroupName": "asg-mixed-arch",
"AutoScalingGroupARN": "arn:aws:autoscaling:us-east-1:111111111111:autoScalingGroup:a1a1a1a1-a1a1-a1a1-a1a1-a1a1a1a1a1a1:autoScalingGroupName/asg-mixed-arch",
"MixedInstancesPolicy": {
...
},
...
"Instances": [
{
"InstanceId": "i-0eeadb140405cc09b",
"InstanceType": "t4g.micro",
"AvailabilityZone": "us-east-1a",
"LifecycleState": "InService",
"HealthStatus": "Healthy",
"LaunchTemplate": {
"LaunchTemplateId": "lt-0c5e1eb862a02f8e0",
"LaunchTemplateName": "lt-arm64",
"Version": "2"
},
"ProtectedFromScaleIn": false
}
],
....
}
]
}
Now, retrieve the last five lines of console output from the instance.
From your terminal, run the following command:
aws ec2 get-console-output –instance-id d i-0eeadb140405cc09b \
--output text | tail -n 5
Evaluate the output, you should see Server running on processor architecture arm64. This confirms that you have successfully utilized an architecture-specific user data script.
[ 58.798184] cloud-init[1257]: node-v14.15.3-linux-arm64/share/systemtap/tapset/node.stp
[ 58.798293] cloud-init[1257]: node-v14.15.3-linux-arm64/LICENSE
[ 58.798402] cloud-init[1257]: Cloning into 'node-helloworld'...
[ 58.798510] cloud-init[1257]: Server running on processor architecture arm64
2021-01-14T21:14:32+00:00
Cleaning Up
Delete the Auto Scaling group and use the force-delete option. The force-delete option specifies that the group is to be deleted along with all instances associated with the group, without waiting for all instances to be terminated.
aws autoscaling delete-auto-scaling-group \
--auto-scaling-group-name asg-mixed-arch --force-delete \
--region us-east-1
Now, delete your launch templates.
aws ec2 delete-launch-template --launch-template-name lt-x86
aws ec2 delete-launch-template --launch-template-name lt-arm64
Conclusion
You walked through creating and using architecture-specific user data scripts that were processor architecture-specific. This same method could be applied to fleets where you have different configurations needed for different instance types. Variability such as disk sizes, networking configurations, placement groups, and tagging can now be accomplished in the same Auto Scaling group.
Zachariah Elliott works as a Solutions Architect focusing on EdTech at AWS. He is passionate about helping customers build Well-Architected solutions on AWS. He is also part of the IoT Subject Matter Expert community at AWS and loves helping customers develop unique IoT-based solutions.
Pranusha Manchala is a Solutions Architect at AWS who works with education companies. She has worked with many EdTech customers and provided them with architectural guidance for building highly scalable and cost-optimized applications on AWS. She found her interests in machine learning and started to dive deep into this technology. She enjoys cooking, baking, and outdoor activities in her free time.
