Session 2 | EC2, VPC, and Load Balancing
This Session's Setup
Open up the AWS Mangement Console and login to your AWS account using the admin user you created in the setup. Do not log into your root account.
At the top of your Management Console next to your username, you'll see "Ohio" listed as your region. Go ahead and change that to US East (N. Virginia).
Logistics and Expectations
- This session will give us the foundational knowledge on EC2 instances, VPCs, subnets, security groups, and SSH that we will need in order to deploy a full application using Elastic Beanstalk in the Session 3.
- In this session, we will create a few EC2 instances and set them up to be served behind a load balancer.
- Because we are cramming a lot of information into a small amount of time, we will not always have time to deeply explore all questions. Links to related concepts are embedded within the curriculum. We strongly recommend being present during the instruction and postponing your link-exploration of the "Additional Resources" sections until after class.
Agenda and Goals
- Understand the purpose and function of the EC2 service
- Explore the relationship between VPCs, subnets, and security groups
- SSH into a running EC2 instance
- Set up an EC2 instance with an Apache server
- Configure a load balancer with multiple EC2 instances
EC2 Overview
From AWS:
"Amazon Elastic Compute Cloud (Amazon EC2) provides scalable computing capacity in the AWS cloud. Using Amazon EC2 eliminates your need to invest in hardware up front, so you can develop and deploy applications faster. You can use Amazon EC2 to launch as many or as few virtual servers as you need, configure security and networking, and manage storage."
You can think of an EC2 instance as a computer that you might buy. You can customize the storage, memory, and CPU. You could install programming languages and software on this computer or set it up to serve a web application.
AWS provides Amazon Machine Images, or AMIs that are preconfigured templates for your EC2 instances so that you can quickly set up Linux or Windows environment. AWS also hosts AMIs that other users have uploaded in addition to proprietary/license-bound AMIs through the AWS Marketplace.
There are currently 19 AMIs that are eligible for Free Tier usage. In this course, we'll default to using the Amazon Linux 2 AMI.
EC2 Instance Types
Once you've selected your machine image, you'll be asked to choose an instance type. Different instance types provide different combinations of CPU, memory, storage, and networking capacity. You can see how instance types are optimized for specific purposes on the EC2 Instance Types documentation page or the ec2instances.info site. Luckily for us, there is only instance type that is available under free tier, so we don't need to dive in to the specifics of what each instance type can do for now. 😅
EC2 Storage
In addition to a root volume (which contains the image used to boot the machine), you can optionally attach additional storage volumes to your EC2 instance. We will not do this today, but you might choose to do this if you need a file system for your EC2 instance, or you want a database for your EC2 instance to interact with.
Together: Creating an EC2 Instance
Throughout this session, we'll be building up to creating a simple web server that can serve up a web page. The server will be hosted on an EC2 instance.
Let's open up the EC2 Dashboard in our admin account. There's quite a bit of stuff on the page, but we'll focus just on launching a new instance for now. We'll stop when we get to networks, security groups, and roles in order to talk more in depth.
- Click on the blue "Launch Instance" button, then select the Amazon Linux 2 AMI.
- For our purpose, we'll select the only instance type eligible under Free Tier, t2.micro.
Additional Resources
VPCs, Subnets, and Security Groups
From AWS:
"A virtual private cloud (VPC) is a virtual network dedicated to your AWS account. It is logically isolated from other virtual networks in the AWS Cloud. You can launch your AWS resources, such as Amazon EC2 instances, into your VPC."
VPCs, Subnets, and Security Groups are somewhat complicated to understand without a networking background. Although are not the focus of today's session, understanding what they do at a high level will help you conceptualize how all of the pieces work together in addition to helping you troubleshoot when something isn't working. NOTE: It is not necessary to memorize or even fully understand the terminology below in order to deploy an EC2 instance.
As we dive into vocabulary, we'll draw a diagram to see how all of these pieces connect.
AWS Networking Vocabulary
- Region: A region is a geographical area comprised of multiple availability zones (generally three). Each region has a corresponding code. For example, Northern Virginia is
us-east-1, whereas Paris iseu-west-3. - Availability Zone: An availability zone is a physical structure containing the computing resources necessary for AWS services. You can picture an availability zone as a giant warehouse filled with computing resources.
- VPC: Virtual Private Cloud. Each region that you use in your AWS account has one default VPC (although you can have up to 5 per region by default) which is where you'll launch and provision your AWS resources. Each default VPC has a range of private IP addresses that can be used by devices in the VPC. Think of a VPC as a locked building.
- CIDR Block: Classless Inter-Domain Routing Block. That "range of IP addresses" that I mentioned above? That's a CIDR block. The notation can be confusing, but here's an example of a CIDR block: 10.0.0.0/16. Each number between the periods represents 8 bits, for a total of 32 bits in an IPv4 address. The "/16" portion, called the netmask, means "lock down the first 16 bits (10.0) and allow the remaining bits to change for this range." In this case, this CIDR block would have the IP addresses of 10.0.0.1, 10.0.0.2, 10.0.0.3... etc. up to 10.0.255.255
- Subnet: A subnet is a logical grouping of IP addresses within your VPC. AWS creates one default subnet in each availability zone within a region. A subnet has its own CIDR block that is cut from the VPC's original CIDR block. So, if a VPC has a CIDR block of 10.0.0.0/16, then Subnet A might have a CIDR block of 10.0.0.0/24 and Subnet B might have a CIDR block of 10.0.1.0/24. Think of a subnet as a specific section of a building (VPC), just like the Stack sandwich shop, the lobby, Turing School, and the Guaranty Bank are all sections of the 1331 17th St. building.
- Internet Gateway: An internet gateway is a device that allows communication between your VPC and the outside internet. Think of an internet gateway as a door. Anyone inside a building (VPC) without a door (internet gateway) cannot have contact with the outside world.
- Route Table: This is a table that defines the rules of how network traffic should be routed. For example, what group of IP address should be routed internally, and what group of IP addresses should be routed to the outer internet? Think of the route table as one of those office directories. The difference in our example here is that the "office directory" in our VPC would have another row that says "all other locations: go outside" which would correspond to our internet gateway.
- Router: The router is a device that is responsible for taking all of the rules in your route table(s) and making sure that traffic is routed correctly throughout your VPC and to the world outside your VPC.
Together: Exploring VPC in the AWS Management Console
Let's open the VPC panel in our AWS management console and take a look at the default VPC, it's subnets, and the CIDR block ranges.
Try It: Network Diagram
Right now, your diagram should look something like the one below from AWS's VPC Documentation. In your breakout rooms, talk through each of the network components that you see in the diagram below, explaining what you know about their purpose or function. Remember, it's not important to fully understand how this all works. Instead, use the visual to help you build a mental model for how to organize the vocabulary words from above.
Together: VPC and Subnet for EC2
Now that we understand a bit more about VPCs, subnets, and CIDR blocks, we'll go back to our EC2 console and walk through the VPC and subnet for our EC2 instance. We'll also talk briefly about Elastic Block Store (EBS) for storage.
Security Groups
A security group sounds like a physical entity, but really it's just a set of rules that governs how traffic can flow in and out of your EC2 instance (and other AWS resources we'll get to later). In continuing our building metaphor, a security group would be the card reader that sits outside the door to each suite.
Each card reader allows traffic from certain groups of people. At Turing, keycards belonging to Turing students and staff work, but keycards belonging to employees of Stack sandwiches would not work.
In these cases, we're restricting who is allowed to enter. We probably would not restrict who is allowed to leave, and the same is true with security groups. By default, all inbound traffic is blocked and all outbound traffic is allowed. At Turing, a guest would need to be escorted in by someone with a keycard, but we would not prevent that guest from leaving the space.
When you configure a security group, you will specify what kind of traffic you want to be able to get past the keycard reader.
Together: Configuring a Security Group
Let's head back over to the AWS Management Console and create a new security group for our EC2 instance.
Since we want this EC2 instance to be able to serve up a web page through an Apache server, we'll need to allow two types of inbound traffic:
- HTTP on port 80 from 0.0.0.0/0 (this is the CIDR block that represents "anywhere")
- SSH on port 22 from 0.0.0.0/0. NOTE: This is fine for learning and testing purposes, but in production, you would want to lock the source down to a specific IP address (or a range of IP addresses).
The image below from AWS shows where Security Groups come into play:
Additional Resources
SSH Access to EC2
SSH, or Secure Shell, is a protocol that allows people to remotely login to one computer from a different computer. This is how we will access the EC2 instance that we're creating.
First, create a new key pair. This will allow you to log into your EC2 instance. A naming convention that helps keep track of key pairs is including the region in the name of the key pair. For example: MyVirginiaKeyPair or MyOhioKeyPair. Download this key pair.
In June 2019, AWS launched EC2 Instance Connect which allows for a browser-based SSH connection in addition to using IAM identities to login as opposed to key pairs. We'll SSH into our instance in the traditional method today, but you are encouraged to try Instance Connect on your own.
Together: SSH-ing Into EC2 Instance
- Open your terminal and get to the directory where your key pair was downloaded.
- In your terminal, type
chmod 400 <nameofkeypair.pem>.
For example:chmod 400 MyKeyPair.pem - Back in your EC2 console, copy the public IP address of your EC2 instance.
- In your terminal, type
ssh -i <nameofkeypair.pem> ec2-user@<publicIPaddress>.
For example:ssh -i MyKeyPair.pem ec2-user@18.216.158.31 - We'll upgrade our privileges to root user with
sudo su. - Once you're logged in, type
sudo yum updatewhich will use the yum, a package manager for Linux, to update any currently installed packages that you got from the AMI.
Additional Resources
Using Apache to Serve a Webpage
Now that we're connected via SSH to our EC2 instance, we'll set up an Apache web server and configure it to serve up an HTML file.
Together: Install Apache
- If you didn't do this already, upgrade your privileges by typing
sudo su - Install Apache with
yum -y install httpd - Start Apache with
service httpd start - Configure the server to start with each reboot:
chkconfig httpd on - Open a new tab and paste in the public IP address of your EC2 instance. You should see Apache instructions.
- Back in your SSH session, move into the directory where Apache will serve its files:
cd /var/www/html - Type
echo "<h1>Welcome to my page</h1><p>This content was served from $(hostname -i)</p>" > index.html. This will evaluate the private IP address of the host (your EC2 instance) and put the output into the index.html file. - Refresh the browser page that you opened earlier. Tada!
Additional Resources
- Apache HTTP Server Project
- EC2 Instance User Data (scroll down the page)
Configuring a Load Balancer
From AWS:
"A load balancer serves as the single point of contact for clients. The load balancer distributes incoming application traffic across multiple targets, such as EC2 instances, in multiple Availability Zones. This increases the availability of your application."
If you serve your application from one server, and that server goes down, then your users won't be able to access your content. In addition, if your server is overwhelmed by traffic, not all requests will be able to be served.
A Load Balancer receives requests and forwards those requests to EC2 instances. The load balancer can also prevent traffic from being routed to unhealthy EC2 instances. The diagram below from AWS shows how a load balancer works:

Together: Multiple EC2 Instances
Before we make a load balancer, we'll provision one more EC2 instance with the following user data so that we can load balance between the two EC2 instances. User Data can be used to automate bootstrapping configuration and run scripts when an instance is first launched. It is run as the root user.
#!/bin/bash sudo su yum update -y yum install -y httpd service httpd start chkconfig httpd on echo "This content was served from $(hostname -i)" > /var/www/html/index.html
Together: Setting up a Load Balancer
- From the left-hand side of your EC2 dashboard, select "Target Groups" under "LOAD BALANCING"
- Click "Create Target Group" and give your group a name (ie. DemoApacheServers)
- Keep all default settings, and click the blue "Create" button
- Select the target group you just created and click on the "Targets" tab
- Click the blue "Edit" button, then select both of your EC2 instances and click "Add to Registered", then save.
- From the left-hand side of your EC2 dashboard, select "Load Balancers" under "LOAD BALANCING"
- Click "Create Load Balancer" and select "Application Load Balancer"
- Give your load balancer a name. This name will become part of your URL.
- Select all of your availability zones at the bottom and click Next.
- For now, we'll ignore the HTTPS warning since this would require us to purchase an SSL certificate which is beyond the scope of this course.
- Create a new security group that allows incoming HTTP traffic from everywhere (0.0.0.0/0). Click Next.
- Select "Existing Target Group" and find the group you created in step 2.
- Click Next and create your load balancer. It is normal for the load balancer to take a few minutes to provision.
- Once provisioning is done, find the DNS name for your load balancer. Open this up and try refreshing a few times (soft refresh, not hard). You'll see the IP address of the host change!
As of right now, our EC2 instances are accessible either by the load balancer URL or by their IP address. We only want them to be available through the load balancer URL. To learn how to fix this, make sure to do the recommended self study at the bottom :)
Additional Resources
Cleanup
All of our tear down will happen from the EC2 service dashboard. It's important that you complete these steps in the order that they are listed due to dependencies.
- Click on "Load Balancers" from the left-hand panel and delete your load balancer.
- Click on "Target Groups" from the left-hand panel and delete your target group.
- Click on "Instances" from the left-hand panel. Select both instances, then click "Actions" and select "Terminate" from "Instance State"
- Click on "Security Groups" from the left-hand panel. Select the security groups you created for the load balancer and the web servers and select "Delete Security Group" from the "Actions" drop down.
- It might be a smart idea to move your key pair (which is probably in your downloads folder) into a better place. Consider creating a folder for AWS resources on your computer.
Recommended Self-Study: Practice Makes Better
Exercises
The self-study for this session is a repeat of what we did in class. If you're feeling up for a challenge, use the AWS CLI EC2 commands and AWS CLI Load Balancer commands to provision the resources below.
- Create two EC2 instances that use User Data to set up an Apache web server and an index page.
- Create a target group and add both of your instances to that target group.
- Create a load balancer that uses the target group.
- Use the DNS name of the load balancer to check if requests are balanced between your two instances.
Security alert: Right now, our EC2 instances are in a security group that allows incomming HTTP traffic from anywhere. Since we've put a load balancer in front of the target group, we should restrict the HTTP traffic to only come from the load balancer. Otherwise, it's kind of pointless to have a load balancer if users can pick the EC2 instance directly.
(One other thing to note: Because we originally wanted our EC2 instances to be publicly accessible, we didn't change the setting for "Auto-assign Public IP" when first creating them. However, if we are always planning to use the EC2 instances behind a load balancer, we don't need to assign Public IP addresses. Although you can't remove a public IP address after creating an EC2 instance, you could terminiate it and create a new one without a public IP. We won't do this now, but keep it in mind for the future.)
- From the EC2 dashboard, select "Security Groups" on the left hand side.
- Select the security group for your Web Servers.
- Click on the "Inbound" tab and select "Edit"
- Right now, HTTP traffic source is 0.0.0.0/0. Delete that, then start typing "sg" and you should see all of your security groups pop up.
- Select the security group of your load balancer. This means that your load balancer will be able to send traffic to the instances instead of the whole world.
Make sure to tear down all of the resources that you created in the practice section so that you aren't charged if you exceed your free tier limits.