Creating a VPC With Autoscaling in AWS CLI | by Michael Cassidy | Apr, 2022

[*]

Photograph by Jukan Tateisi on Unsplash

The objective of this challenge is to create a VPC with an autoscaling group. I shall be putting in apache on two cases, and a scaling coverage with CloudWatch to scale after CPU utilization surpasses 40%.

Conditions:

  • AWS Account with IAM person
  • Applicable IAM permissions

First, we’re going to create a VPC with cidr 10.10.0.0/16. Use the next command:

aws ec2 create-vpc --cidr-block 10.10.0.0/16

Your display screen ought to look one thing like this:

Be sure that to repeat down the VpcId. I personally use the Notepad utility on Home windows, and can retailer the ID there for later use. As you possibly can see, my VPC ID is vpc-081aa807895d15ecb

Subsequent, we are going to create subnets for our VPC.

I used the next web site to find out the subnet tackle:

Listed below are the outcomes for my cidr block, and 16 subnets, which might permit for 4091 IP addresses. The subnet masks /20 shall be enough for this.

I’ll use the primary 2 subnet IDs to create 2 public subnets. Use the next instructions to take action:

aws ec2 create-subnet --vpc-id vpc-081aa807895d15ecb --cidr-block 10.10.0.0/20

After you enter the above command, your display screen will look one thing like this:

Copy down your SubnetId. Repeat the command, however be sure you specify a unique availability zone. My first subnet is positioned in AZ us-east-1a, so for my subsequent subnet, I’ll place it in us-east-1b. Be aware that I’m utilizing the tackle from the 2nd subnet ID

aws ec2 create-subnet --vpc-id vpc-081aa807895d15ecb --cidr-block 10.10.16.0/20 --availability-zone us-east-1b

Upon getting carried out that, you possibly can listing the subnets by typing the next:

aws ec2 describe-subnets --filters "Identify=vpc-id,Values=vpc-081aa807895d15ecb"

It’s best to see details about each of the subnets you created. Be sure that to repeat down each subnet IDs.

We should modify the subnets attributes so that each one cases launched into our subnet are assigned a public IPv4 tackle. Use the next command for every subnet:

aws ec2 modify-subnet-attribute --subnet-id subnet-007be26e340495888 --map-public-ip-on-launch

As soon as, you will have carried out this for each subnets, you possibly can describe the subnets once more, and see that the output reveals “MapPublicIpOnLaunch”: true

Subsequent, let’s connect an web gateway to our VPC. First, we’ve to create an Web Gateway. Within the CLI, kind:

aws ec2 create-internet-gateway

The output ought to look one thing like this:

Copy down the InternetGatewayId, and use it within the subsequent command to connect the gateway to your VPC.

aws ec2 attach-internet-gateway --vpc-id vpc-081aa807895d15ecb --internet-gateway-id igw-0cfc4b3e94995400e

Your display screen should have no output, which might point out the Web Gateway has been efficiently hooked up to the VPC. To view the attachment, enter the next command utilizing your gateway ID:

aws ec2 describe-internet-gateways --internet-gateway-ids igw-0cfc4b3e94995400e

It’s best to see that your gateway is hooked up to your VPC

Hooked up

Once we created a subnet, AWS robotically associates it with the default route desk for the VPC. Let’s describe this route desk:

aws ec2 describe-route-tables --filters "Identify=vpc-id,Values=vpc-081aa807895d15ecb"

Be sure that to repeat down the RouteTableID:

The principle route desk doesn’t comprise a path to the web gateway. We have to create a customized route desk with a route that sends outbound visitors to the web gateway.

To create the customized route desk for IPv4 visitors, enter the next command:

aws ec2 create-route --route-table-id rtb-07ca16e6a996bd002 --destination-cidr-block 0.0.0.0/0 --gateway-id igw-0cfc4b3e94995400e

It’s best to obtain the next output:

Let’s describe the route desk once more to ensure our new route is related:

aws ec2 describe-route-tables --route-table-id rtb-07ca16e6a996bd002

Throughout the output, you will notice that your CreateRoute is energetic:

Every subnet have to be related to a route desk. A subnet is implicitly related to the principle route desk of your VPC. Each of the subnets we created are related to our route desk. To view this within the CLI, strive the next command:

aws ec2 associate-route-table --subnet-id subnet-007be26e340495888 --route-table-id rtb-07ca16e6a996bd002

I ran the above command twice, for every subnet, and the output I acquired appeared like this:

Subnets related to route desk

Now we are going to create a brand new safety group and add guidelines that permit inbound visitors from the web. You’ll be able to then affiliate the safety group with cases within the public subnet.

aws ec2 create-security-group --group-name vpc-sg-traffic --description "VPC SG Visitors" --vpc-id vpc-081aa807895d15ecb

Write down the GroupId you see from the output of the above command.

Subsequent, we have to add guidelines to our safety group to permit incoming visitors.

The next command will add a rule for HTTP (port 80) entry with the safety ID group sg-00d5f5f589f2a3bce. To permit entry for all:

aws ec2 authorize-security-group-ingress --group-id sg-00d5f5f589f2a3bce --protocol tcp --port 80 --cidr 0.0.0.0/0

To permit all inbound visitors on port 22, allow SSH to the occasion in the identical safety group:

aws ec2 authorize-security-group-ingress --group-id sg-00d5f5f589f2a3bce --protocol tcp --port 22 --cidr 0.0.0.0/0

To view the adjustments to your safety group within the CLI, you could run the next command:

aws ec2 describe-security-groups --group-ids sg-00d5f5f589f2a3bce

Since we shall be putting in apache on our cases, and an AWS stress device, we are going to create a script to bootstrap to our cases. Use the next textual content to enter into vim, or a textual content editor of your selecting. In Home windows, you should find the saved script file and duplicate the trail, to make use of later when launching the EC2 cases.

#!/bin/bash
sudo yum -y replace
sudo yum -y set up httpd
systemctl begin httpd
systemctl allow httpd
amazon-linux-extras set up epel -y
yum set up stress -y

Subsequent, we are going to create launch configurations for autoscaling:

aws autoscaling create-launch-configuration --image-id ami-0c02fb55956c7d316 --instance-type t2.micro --key-name keypairweek7 --security-groups sg-00d5f5f589f2a3bce --user-data file://"C:UsersmjcdyOneDriveDocumentsUser Dataapache_stress.sh" --launch-configuration-name lauchconfig

I used an current key-pair. I additionally used an AMI related to area us-east-1. To find an appropriate, free tier AMI, the next command could be typed:

aws ec2 describe-images --owners amazon --filters "Identify=title,Values=amzn2-ami-hvm-2.0.????????.?-x86_64-gp2" "Identify=state,Values=accessible" --query "reverse(sort_by(Photos, &Identify))[:1].ImageId" --region us-east-1 --output textual content

Upon getting created launch configurations, you possibly can view the outline:

aws autoscaling describe-launch-configurations

Subsequent, we will create an autoscaling group:

aws autoscaling create-auto-scaling-group --auto-scaling-group-name autoscaling --availability-zones us-east-1a us-east-1b --vpc-zone-identifier "subnet-007be26e340495888, subnet-05dd76f3530bd0a82" --launch-configuration-name lauchconfig --max-size 5 --min-size 2
  • Should you would possibly discover, I named my launch configuration, “lauchconfig.” Be sure that to make use of the identical spelling when creating the autoscaling group in any other case you’ll obtain an error.
  • Additionally, the primary time I ran this command, I didn’t use the vpc-zone-identifier. My cases wouldn’t launch, as a result of I didn’t specify which subnets to make the most of.

After you will have created the autoscaling group, you will want to allow metrics assortment so you should use CloudWatch to observe your cases. Use the next command:

aws autoscaling enable-metrics-collection --auto-scaling-group-name autoscaling --granularity "1Minute"

Subsequent, we have to apply a goal monitoring scaling coverage that tells Amazon EC2 Auto Scaling to alter the variety of operating EC2 cases within the group dynamically when the load on the appliance adjustments. The next JSON file is a goal monitoring configuration that units the common CPU utilization at 40 %. Save this file and ensure to repeat the trail, as we are going to use it in our subsequent command.


"TargetValue": 40.0,
"PredefinedMetricSpecification":

"PredefinedMetricType": "ASGAverageCPUUtilization"

The command it would be best to run so as to add the scaling coverage is:

aws autoscaling put-scaling-policy --auto-scaling-group-name autoscaling --policy-name cpu40-target-tracking-scaling-policy --policy-type TargetTrackingScaling --estimated-instance-warmup 60 --target-tracking-configuration file://"C:UsersmjcdyOneDriveDocumentscpuutilization.json"

The display screen you see will look one thing like this:

Alarm ARNs created

We will see if the cases have launched as properly with the next command:

aws autoscaling describe-auto-scaling-groups --auto-scaling-group-name autoscaling

Subsequent, you possibly can verify and see if the Apache webserver was put in and activated, copy your Public IPv4 tackle from every occasion, which could be discovered by typing the next:

aws ec2 describe-instances --query "Reservations[*].Cases[*].PublicIpAddress" --output=textual content

Subsequent, in an tackle bar, kind the next:

http://public_ip_address

Should you get a display screen like this, your Apache net server is up and operating:

Lastly…

We are going to enter the AWS console. Head over to CloudWatch and it’s best to discover the alarm we created earlier than with the autoscaling put-scaling-policy:

I ran some stress assessments earlier, then reinitialized the alarm
  • I had tried to run the scaling coverage with CloudWatch to scale after CPU utilization was above 80%. This didn’t work as a result of my autoscaling coverage applies to 2 cases. The CPU utilization might solely attain 50% per occasion.

SSH into one in all your cases:

ssh -i "C:UsersmjcdyOneDriveDocumentsKeyPairkeypairweek7.pem" ec2-user@public_ip_address

In Home windows, make certain to make use of your file path to your key pair.

Now let’s run a stress take a look at!

Within the EC2 occasion, enter the command:

sudo stress --cpu 1 --timeout 300

Within the AWS console, it’s best to see your CloudWatch alarm go off after a couple of minutes, a brand new EC2 occasion launching, and a rise in your cases in your autoscaling teams.

Threshold surpassed
Third Occasion Created because of this
3 cases as a substitute of two
Autoscaling executed

When you have gotten this far, congratulations. Bear in mind to terminate any sources which will incur additional charges! Thanks for studying.

More Posts