In this exercise, let's image you are a Cloud Support Engineer at XYZ. During your shift, a customer asks for help - they have a networking issue in their AWS infrastructure! Below is their email and an attachment of their architecture.
Email from the customer:
Hello Cloud Support!
I thought I had all the necessary resources in place for internet access, but I'm not getting pings* outside my VPC.
I'm trying to achieve successful pings. Could you please check if my VPC is correctly set up for network connectivity? You'll find the architectural details below.
Thank you,
Nigel
*Note:Ping is a tool used to test the reachability of a device or resource in a network. When someone says they are "unable to ping outside the VPC," it means they can't seem to receive responses from resources or servers outside their VPC.
Objectives:
By the end of this hands-on exercise, you should be able to do the following:
Create a VPC, Internet Gateway, Route Table, Security Group, Network Access List, and EC2 instance to create a routable network within the VPC
Familiarise yourself with the console
Develop a solution to the customer's issue found within this lab.
Task 1: Investigate and create the networking resources based on the customer's needs
In this task, you will investigate the customer's request and build a VPC that has network connectivity. You will complete this lab when you can successfully ping from your EC2 instance to the internet showing that the VPC has network connectivity.
In the scenario, Nigel has asked for help in creating resources for her VPC to be routable to the internet. Keep the VPC CIDR* at 192.168.0.0/18 and the public subnet CIDR at 192.168.1.0/28.
*CIDR, short for Classless Inter-Domain Routing, is a method for assigning and organising IP addresses in your VPC and its subnets. "VPC CIDR at 192.168.0.0/18," means that the VPC's address range goes from 192.168.0.0 to 192.168.63.255, allowing for 16,384 unique IP addresses within it! The "/18" part tells you how big the VPC is. It means the first 18 numbers in the IP address are fixed, and the rest can change.
So, when we "keep the VPC CIDR at 192.168.0.0/18 and the public subnet CIDR at 192.168.1.0/28," the public subnet is still part of our VPC, but it's configured in a way that allows resources in that subnet to have internet connectivity, while other subnets in the same VPC might be configured differently for private, internal use. In detail:
VPC CIDR (192.168.0.0/18): This defines the IP address range for your entire Virtual Private Cloud (VPC). It covers a larger range of IP addresses, allowing for a huge number of resources within your VPC.
Public subnet CIDR (192.168.1.0/28): This specifies a smaller, more limited address range within the VPC that will be our public subnet. The "/28" indicates a smaller pool of addresses, suitable for a smaller number of resources. The IP address range includes all IP addresses from 192.168.1.0 to 192.168.1.15 (only 14 usable IP addresses, compared to the VPC's pool of 16,384)!
The differentiation helps in structuring your VPC to allocate IP addresses efficiently, separating resources that need public internet access from those that don't.
Before you start, let's review VPC and its components to make it network-compatible.
A Virtual Private Cloud (VPC) is like a data centre but in the cloud. A logically isolated section of the AWS Cloud where you can launch AWS resources in a virtual network that you define.
An Internet Gateway (IGW) is a gateway that you attach to your VPC to allow communication between your VPC and the Internet. It has two jobs: perform network address translation (NAT) and be the target to route traffic to the internet for the VPC. An IGW's route on a route table is always 0.0.0.0/0.
A route table is a set of rules that dictate where network traffic is directed. It's like a map for your network traffic. If an IGW was on a route table, the destination would be 0.0.0.0/0 and the target would be IGW.
Private Internet Protocol (IP) addresses are how resources within the VPC communicate with each other. An instance needs a public IP address for it to communicate outside the VPC. The VPC will need networking resources such as an Internet Gateway (IGW) and a route table in order for the instance to reach the Internet.
A subnet is a range of IP addresses in your VPC. You can choose to launch resources into a specific subnet. There are two types of subnets: public (if it's connected to the internet) and private (if it's not).
Security groups and Network Access Control Lists (NACLs) work as the firewall within your VPC. As a recap:
Default Security groups by default allow no inbound traffic coming from outside the VPC. They still allow inbound traffic from instances in the same security group.
Default Security groups allow all outbound traffic by default.
Default NACLs allow all inbound/outbound traffic by default.
Custom NACLs deny all inbound/outbound traffic by default.
NACLs work on the network level and are stateless, which means you have to set up rules to explicitly allow (or deny) both inbound and outbound rules.
Security groups work on the instance level and are are stateful, which means that return traffic from an allowed inbound connection is automatically allowed to leave the instance. You do not have to define outbound rules to allow it.
Create the VPC
Once in the AWS console, click VPC under Recently visited services. If it is not there, navigate to the top left corner, and select VPC under Networking and Content Delivery in the Services navigation pane
Start at the top of the left navigation pane at Your VPCs and work your way down. Select Your VPCs, navigate to the top right corner, and select Create VPC.
On the Create VPC page, you will notice on the Resource to create there are two options. Let's see what they mean:
VPC only - in this resource, you will create your Amazon VPC and its components manually.
5. VPC and more - in this resource, you will create your Amazon VPC and its components using the VPC Wizard. This would launch your VPC and all its components in just a one-pager setup. Pretty cool!
Note: It is important to know how the manually set up your Amazon VPC and its components before you go straight through the simpler one.
In this hands-on exercise, you will use the VPC only (manual creation) to create your VPC and its components.
6. Name the VPC: My Test VPC
IPv4 CIDR block: 192.168.0.0/18
7. Leave everything else as default, and select Create VPC.
Creating a subnets
Now that the VPC has been created, look at the left navigation pane and select Subnets. In the top-right corner, select Create subnet
Configure the following settings:
VPC ID: Choose the custom VPC that you've created (i.e. My Test VPC). You might find that the name 'My Test VPC' doesn't come up in the results. If that's the case, choose whichever VPC has the right IP address address underneath (i.e. 192.168.1.0/28)
Subnet settings:
Subnet name: Enter Public subnet
Availability Zone: Leave the default (No preference)
IPv4 subnet CIDR block: 192.168.1.0/28
Choose Create subnet
Woah! You just created a subnet, that's awesome. 😎
Creating Route Table
Navigate to the left navigation pane, and select Route tables. In the top right corner select Create route table
Configure the following settings:
Name - optional: Public route table
VPC: Choose the custom VPC that you've created which is the My Test VPC
Choose Create route table
Nice one, that's the route table created!
Creating an Internet Gateway and attach to the VPC
From the left navigation pane, select Internet gateways. Create an IGW by selecting Create internet gateway at the top right corner
Configure the following settings:
Name tag: IGW Test-VPC
Choose Create Internet gateway
6. Once created, notice the state of the Internet Gateway that is still Detached. Attach the Internet Gateway to the VPC by selecting Actions at the top right corner and clicking Attach to VPC.
Available VPCs: Choose the custom VPC that you've created i.e. My Test VPC.
Choose Attach internet gateway
Add route to route table and associate the subnet to route table
In this step, you will associate the subnet to the route table.
Creating a subnet association sets the route table for a VPC subnet, controlling how its traffic is directed.
This is crucial for ensuring proper internal and internet connectivity. Without the proper subnet association to a route table, resources in that subnet won't know how to send their network traffic to the right destinations. This can lead to connectivity issues, like not being able to connect to the internet, or not being able to send data to other resources in the VPC.
This means every subnet in a VPC must be associated with a route table, to dictate the routing of IP traffic leaving the instances in that subnet.
Navigate back to the Route tables section on the left navigation area. Select (check the box next to) the Public route table, scroll to the bottom, and select the Routes tab. Select the Edit routes button located in the routes box.
On the Edit routes page, the first IP address you see is the local route and cannot be changed.
Select Add route.
In the Destination section, type 0.0.0.0/0 in the search box. This is the route to the IGW. You are telling the route table that any traffic that needs an internet connection will use 0.0.0.0/0 to reach the IGW therefore it can reach the internet.
Click in the Target section and select Internet Gateway since you are targeting any traffic that needs to go to the internet to the IGW. Once you select the IGW, click the box with the text igw-, and you will see your IGW Test-VPC appear. Select that IGW. Select Save changes.
Now your traffic has a route to the internet via the IGW. You will see you've successfully updated your Public route table.
2. From the route table dashboard (the page you're automatically on), select the Subnet associations tab. Select the Edit subnet associations button.
Select the Public subnet and choose Save association.
*In AWS, every route table must be connected to a specific subnet. We use consistent names for clarity, making it easier to manage as your network grows. Clear naming helps prevent confusion as you accumulate similar resources, ensuring you know where each resource belongs.
Creating a Network ACL (NACL)
In this section, you will see the difference between default NACLs and custom NACLs
From the left navigation pane, select Network ACLs. You might need to scroll on the left hand pane to see it. Navigate to the top right corner and select Create network ACL. Exciting, we're about to create a custom NACL!
On the Create network ACL page, configure the following settings:
Name - optional: Specify a name for your Network ACL. For example if you're creating a public NACL enter Public-NACL or PubNACL
VPC: Select the VPC that you've created.
Choose Create network ACL.
Recap: There are two types of NACLS, the default NACL and custom NACLs. For the default NACL, the inbound/outbound rule is already allowed by default. If you create custom NACLs they are blocked/denied by default. See the difference below.
Default NACL:
Inbound - Take a look at the example snapshot below. We've selected the default NACL (which has no name). Under the Inbound rules section, there is only one rule number, which is 100, that says that all traffic, protocols, and port ranges from any source (0.0.0.0/0) are allowed to enter (inbound) the subnet. The rule with the asterisk (*) says that anything else that does not match the above rule is denied.
Outbound - outbound rules in an NACL decide which kind of traffic (specified by protocol, port, and destination) is allowed to exit the subnets in your VPC. Just like inbound rules, outbound rules allow all traffic by default.
Custom NACL:
Unlike default NACLs, custom NACLs deny all traffic in/out of your VPC's subnets. You will have to customise this to allow any traffic. Denying all traffic first is an added layer of network security helps in protecting AWS resources from unwanted traffic or malicious attacks.
Creating a Security Group
Note: Why are we setting up this inbound security group? We set up inbound security groups to control who can access our servers or applications securely. We have three main rules for different kinds of traffic:
SSH (Secure Shell Protocol):
SSH is like a special key to securely enter our server. SSH uses port 22.
To keep it safe, we only let specific trusted IP addresses access the server.
Usually, we don't leave it wide open for anyone (0.0.0.0/0), but we'll make an exception for this activity. Usually, you choose My IP so only your local machine/laptop can access the EC2 instance
HTTP (Hypertext Transfer Protocol):
HTTP is used for regular web pages, where data exchanged between the web browser and server is not encrypted. It's on port 80.
Be cautious with sensitive info when allowing HTTP as an inbound port. While it's okay for many types of information, it's not suitable for sensitive data like passwords, credit card numbers, or personal information. For regular content that doesn't involve sensitive data, HTTP still works great
HTTPS (Hypertext Transfer Protocol Secure):
HTTPS, using port 443, enhances security for sensitive data transfer.
Security groups need rules allowing inbound HTTPS to protect information, especially for platforms handling personal details, making it a safer alternative to HTTP.
From the left navigation pane, select Security groups. Navigate to the top right corner and select Create security group to create a security group.
Configure the following settings to create a security group.
Security group name:Public security group
Description:Allows public access
VPC: Ensure you've selected your custom VPC (My Test VPC)
Inbound rules: Click Add rules 3 times to add three protocol* types. Now let's set up these rules differently
In the first rule under Type, choose SSH. For the Source/Source type, choose Anywhere IPv4.
In the second rule under Type, choose HTTP. For the Source, choose Anywhere IPv4
In the third rule under Type, choose HTTPS. For the Source, choose Anywhere IPv4
Choose Create security group.
For Outbound rules, you are allowing all traffic from outside your instance.
Task 2: Launch an EC2 instance, and SSH into an instance
In this task, you will launch an EC2 instance within your Public subnet and you will test the connectivity by running the command ping.
This will validate that your infrastructure is correct, such as security groups and network ACLs, to ensure that they are not blocking any traffic from your instance to the internet and vice versa.
This will also validate that you have a route to the IGW via the route table and that the IGW is attached.
Navigate to Services at the top left, and select EC2. From the EC2 dashboard, select Instances. Select Launch instances.
2. Configure the following settings:
3. Name: MyLinuxTest-Instance
4. AMI: Choose Amazon Linux 2023 AMI
5. Instance type: t2.micro
6. Key pair: Select Create new key pair
7. Key pair name: PubKP
Note: PubKP means Public Key Pair. You can enter any key pair name as long as you remember it before you use it. For example, if you create a private key pair, you would use a key pair name such as PrivKP.
Key pair type: RSA
Private key file format: For the private key file format you have two options, either .pem or .ppk
.pem - use this if you're a macOS/Linux user
.ppk - use this if you're a Microsoft Windows user.
Select Create key pair.
Note: If you're a Microsoft Windows user and you forgot to select .ppk (i.e. you accidentally selected the .pem file format), you will have to convert your .pem into a .ppk file. Here's how :
Download and install PuTTY software here. Click Download PuTTY and you'll be directed to a similar page as below. Click the link that has a 64-bit x86 installer (this is commonly used for most Windows users)
To install, run the .msi file that you've downloaded and choose Next > Next > Install.
As simple as that, you have now installed the PuTTY software.
The PuTTY installer is a package file. It has three pieces of software. The software is Pageant, PuTTYgen, and PuTTY. To convert the .pem file into a .ppk file format you will use the PuTTYgen software.
Open the PuTTYgen software, choose File > Load private key
Choose the .pem file that you've downloaded. If you don't see the .pem file, modify the file type (see image below) change it into All files (*.*) and select the .pem file. Click Open
You will see a notice that you've imported a foreign key. Click OK
Choose Save private key. Ensure that you selected the RSA.
Click Yes on the PuTTYgen Warning. Save the converted file.
Scroll to the Network settings panel below. Choose Edit and configure the following settings:
VPC - required: Choose the custom VPC that you've created from the previous task which is the My Test VPC
Subnet: Ensure you selected the Public subnet (this is where you will launch your EC2 instance)
Auto-assign public IP: Choose Enable
Firewall (security groups): Select existing security group. From the Common security groups drop-down, and select Public security group. This is the security group we've created in the previous step.
Choose Launch instance.
Use SSH to connect to an Amazon Linux EC2 instance
In this task, you will connect to an Amazon Linux EC2 instance. You will use an SSH utility to perform all of these operations.
For Windows Users:
These instructions are specifically for Windows users. If you are using macOS or Linux, skip to the next section
Open the PuTTY software. Configure the following settings:
Host Name (or IP addresses):ec2-user@<public_IPv4 address> (see below to locate the public IPv4 address)
Note: Copy only the public IPv4 address or click the copy icon to copy the public IPv4 address.
4. It should be similar to the image below except for the public IPv4 (it may assign you a different public IPv4 address when you launch your EC2 instance)
5. Connection type: SSH
6. On the left-side Category under Connection, expand the SSH (click the plus sign icon before the word SSH)
7. Expand the Auth, and select Credentials. On the Private key file to authentication, click Browse. Select the .ppk file that you saved earlier from .pem file. Choose Open
8. On the PuTTY Security Alert window, just click Accept.
9. You have now successfully SSH into your Amazon EC2 Linux instance.
For macOS and Linux Users:
These instructions are specifically for Mac/Linux users. If you are a Windows user, skip ahead to the next task.
Open a terminal window, and change the directory by using the cd command to get to the folder where the PubKP.pem file was downloaded. For example, if the PubKP.pem file was saved to your Downloads folder, run this command:
2. Change the permissions on the key to be read-only, by running this command:
3. Run the below command (replace <Public IPv4-address> with the EC2 instance server's address you copied earlier):
4. You should see a similar setup from the image below.
5. Type yes when prompted to allow the first connection to this remote SSH server. Because you are using a key pair for authentication, you will not be prompted for a password.
You successfully remotely access the EC2 instance server.
Task 3: Use ping to test internet connectivity
Run the ping command to test the internet connectivity:
You should get the following result. Successful ping:
If you are getting replies back, that means that you have connectivity.
After a few seconds, exit ping by holding CTRL+C on Windows or CMD+Q on Macs to exit.
Task 4: Delete the networking resources
Go back to the EC2 console, and terminate the Amazon EC2 Linux instance.
2. Next, go back to the VPC console. Let's delete the internet gateway.
3. Go to Internet gateways (you can jump straight to here by searching 'internet gateways' in the search bar at the top of your AWS Console), select the custom Internet gateway that you've created, and choose Detach from VPC
4. Finally, you can now delete the internet gateway. Choose Delete internet gateway, and type delete to confirm the deletion. Choose Delete internet gateway.
5. You will now delete your custom VPC. Let's head to Your VPC from the left side bar.
6. To delete the custom VPC, select the checkbox next to My Test VPC, and choose Delete VPC.
To confirm the deletion, type delete, and choose Delete.
The other VPC components (subnet, route table, and security group) that you've created and attached to the custom VPC earlier will be deleted once you delete the custom VPC.
You have successfully deleted your custom VPC. Phew - all done!
Congratulations! You have completed the hands-on exercise!You have successfully:
Created a VPC, Internet Gateway, Route Table, Security Group, Network Access List, and EC2 instance to create a routable network within the VPC
Familiarised yourself with the console
Developed a solution to the customer's issue found within this lab.
