Autoscaling in Aws Linux
Autoscaling in Aws Linux
Lab overview
In this lab, you use the AWS Command Line Interface (AWS CLI) to create an Amazon
Elastic Compute Cloud (EC2) instance to host a web server and create an Amazon
Machine Image (AMI) from that instance. You then use that AMI as the basis for
launching a system that scales automatically under a variable load by using Amazon
EC2 Auto Scaling. You also create an Elastic Load Balancer to distribute the load
across EC2 instances created in multiple Availability Zones by the auto scaling
configuration.
Starting architecture:
Final architecture:
Final architecture showing an Elastic Load Balancer and EC2 instances in an Auto
scaling group in private subnets spread across two Availability Zones.
Objectives
After completing this lab, you will be able to do the following:
Configure scaling policies and create an Auto Scaling group to scale in and scale
out the number of servers based on a variable load.
Duration
This lab requires approximately 45 minutes to complete.
Wait until the message "Lab status: ready" appears, and then choose X to close the
Start Lab panel.
At the top of these instructions, choose AWS to open the AWS Management Console on
a new browser tab. The system automatically signs you in.
Tip If a new browser tab does not open, a banner or icon at the top of your browser
will indicate that your browser is preventing the site from opening pop-up windows.
Choose the banner or icon, and choose Allow pop-ups.
Arrange the AWS Management Console so that it appears alongside these instructions.
Ideally, you should be able to see both browser tabs at the same time to follow the
lab steps.
Important: Do not change the lab Region unless specifically instructed to do so.
On the AWS Management Console, in the Search bar, enter and choose EC2 to open the
EC2 Management Console.
Choose Connect.
Note: If you prefer to use an SSH client to connect to the EC2 instance, see the
guidance to Connect to Your Linux Instance.
Now that you are connected to the Command Host instance, you can configure and use
the AWS CLI to call AWS services.
To confirm that the Region in which the Command Host instance is running is the
same as the lab (the us-west-2 Region), run the following command:
To update the AWS CLI software with the correct credentials, run the following
command:
aws configure
At the prompts, enter the following information:
Default region name: Enter the name of the Region from the previous steps in this
task (for example, us-west-2). If the Region is already displayed, press Enter.
Now you are ready to access and run the scripts detailed in the following steps.
cd /home/ec2-user/
Task 1.3: Creating a new EC2 Instance
In this task, you use the AWS CLI to create a new instance that hosts a web server.
To inspect the UserData.txt script that was installed for you as part of the
Command Host creation, run the following command:
more UserData.txt
This script performs a number of initialization tasks, including updating all
installed software on the box and installing a small PHP web application that you
can use to simulate a high CPU load on the instance. The following lines appear
near the end of the script:
Copy the KEYNAME, AMIID, HTTPACCESS, and SUBNETID values into a text editor
document, and then choose X to close the Credentials panel.
In the following script, replace the corresponding text with the values from the
previous step.
The output of this command provides you with an InstanceId. Subsequent steps in
this lab refer to this value as NEW-INSTANCE-ID. Replace this value as needed
throughout this lab.
Copy and paste the InstanceId value into a text editor to use later.
To use the aws ec2 wait instance-running command to monitor this instance's status,
replace NEW-INSTANCE-ID in the following command with the InstanceID value that you
copied in the previous step. Run your modified command.
Your instance starts a new web server. To test that the web server was installed
properly, you must obtain the public DNS name.
To obtain the public DNS name, in the following command, replace NEW-INSTANCE-ID
with the value that you copied previously, and run your modified command:
In a new browser tab, enter the output that you copied from the previous step.
It could take a few minutes for the web server to be installed. Wait 5 minutes
before continuing to the next steps.
In the following command, replace PUBLIC-DNS-ADDRESS with the value that you copied
in the previous steps, and then run your modified command.
http://PUBLIC-DNS-ADDRESS/index.php
If your web server does not appear to be running, check with your instructor.
To create a new AMI based on this instance, in the following aws ec2 create-image
command, replace NEW-INSTANCE-ID with the value that you copied previously, and run
your adjusted command:
You can perform the following task by using either the AWS CLI or the AWS
Management Console. For this lab, you use the AWS Management Console.
On the EC2 Management Console, in the left navigation pane, locate the Load
Balancing section, and choose Load Balancers.
In the Load balancer types section, for Application Load Balancer, choose Create.
On the Create Application Load Balancer page, in the Basic configuration section,
configure the following option:
These options configure the load balancer to operate across multiple Availability
Zones.
In the Security groups section, choose the X for the default security group to
remove it.
The HTTPAccess security group has already been created for you, which permits HTTP
access.
In the Listeners and routing section, choose the Create target group link.
Note: This link opens a new browser tab with the Create target group configuration
options.
On the Specify group details page, in the Basic configuration section, configure
the following options:
In the Health checks section, for Health check path, enter /index.php
Once the target group has been created successfully, close the Target groups
browser tab.
Return to the Load balancers browser tab, and locate the Listeners and routing
section. For Default action, choose Refresh to the right of the Forward to
dropdown list.
To view the WebServerELB load balancer that you created, choose View load balancer.
To copy the DNS name of the load balancer, use the copy option , and paste the DNS
name into a text editor.
On the EC2 Management Console, in the left navigation pane, locate the Instances
section, and choose Launch Templates.
On the Create launch template page, in the Launch template name and description
section, configure the following options:
For Template version description, enter A web server for the load test app
For Auto Scaling guidance, select Provide guidance to help me set up a template
that I can use with EC2 Auto Scaling.
In the Application and OS Images (Amazon Machine Image) - required section, choose
the My AMIs tab.
In the Instance type section, choose the Instance type dropdown list, and choose
t3.micro.
In the Key pair (login) section, confirm that the Key pair name dropdown list is
set to Don't include in launch template.
Amazon EC2 uses public key cryptography to encrypt and decrypt login information.
To log in to your instance, you must create a key pair, specify the name of the key
pair when you launch the instance, and provide the private key when you connect to
the instance.
In the Network settings section, choose the Security groups dropdown list, and
choose HTTPAccess.
When you launch an instance, you can pass user data to the instance. The data can
be used to run configuration tasks and scripts.
Choose web-app-launch-template, and then from the Actions dropdown list, choose
Create Auto Scaling group.
On the Choose launch template or configuration page, in the Name section, for Auto
Scaling group name, enter Web App Auto Scaling Group
Choose Next.
On the Choose instance launch options page, in the Network section, configure the
following options:
From the Availability Zones and subnets dropdown list, choose Private Subnet 1
(10.0.2.0/24) and Private Subnet 2 (10.0.4.0/24).
Choose Next.
On the Configure advanced options – optional page, configure the following options:
From the Existing load balancer target groups dropdown list, choose webserver-app |
HTTP.
In the Health checks section, under Additional health check types, select Turn on
Elastic Load Balancing health checks.
Choose Next.
On the Configure group size and scaling policies – optional page, configure the
following options:
Desired capacity:2
Minimum capacity: 2
Maximum capacity: 4
This change tells auto scaling to maintain an average CPU utilization across all
instances of 50 percent. Auto scaling automatically adds or removes capacity as
required to keep the metric at or close to the specified target value. It adjusts
to fluctuations in the metric due to a fluctuating load pattern.
Choose Next.
On the Add tags – optional page, choose Add tag and configure the following
options:
Choose Next.
These options launch EC2 instances in private subnets across both Availability
Zones.
Your Auto Scaling group initially shows an Instances count of zero, but new
instances will be launched to reach the desired count of two instances.
Note: If you experience an error related to the t3.micro instance type not being
available, then rerun this task by choosing the t2.micro instance type instead.
Two new instances named WebApp are being created as part of your Auto Scaling
group. While these instances are being created, the Status check for these two
instances is Initializing.
Observe the Status check field for the instances until the status is 2/2 checks
passed. Wait for the two new instances to complete initialization before you
proceed to the next step.
On the Targets tab, verify that two instances are being created. Refresh this list
until the Health status of these instances changes to healthy.
You can now test the web application by accessing it through the load balancer.
This step calls the application stress in the background, which causes the CPU
utilization on the instance that serviced this request to spike to 100 percent.
On the EC2 Management console, in the left navigation pane in the Auto Scaling
section, choose Auto Scaling Groups.
After a few minutes, you should see your Auto Scaling group add a new instance.
This occurs because Amazon CloudWatch detected that the average CPU utilization of
your Auto Scaling group exceeded 50 percent, and your scale-up policy has been
invoked in response.
You can also check the new instances being launched on the EC2 Dashboard.
Conclusion
Congratulations! You now have successfully done the following:
Configured scaling policies and created an Auto Scaling group to scale in and scale
out the number of servers based on variable load