Cloud Networking 101: How to make a VPC within AWS

I hope you all are having a wonderful day, evening, night….depending on your timezone. :) In the last blog we covered the fundamentals of Virtual Private Clouds.

I broke down the differences between traditional networking and VPCs, subnets, route tables, Internet Gateways, and NAT Gateways.

Cloud Networking 101: What is a VPC? Hi, everyone welcome back to my Cloud Networking 101 series.

If some of those terms sound unfamiliar, I highly recommend you read this blog first. All these blogs are a part of my Cloud Networking 101 series.

Last time I covered the what, this time I'll be demonstrating the how. Usually my blogs would be a bit more analogy based with breakdowns.

This will have some of those, but there will be a lot more clean and concise steps because it's a step-by-step tutorial, and it builds on knowledge covered in previous articles.

Step 1: Create the VPC

The first thing you will do is navigate to 'VPC' within AWS. You can do it within the search bar.

Then select Create VPC.

I gave it the name 'VPC-Blog-Demo'

Assign it an IPv4 CIDR block. This is the total number of IP addresses allotted to your VPC.

Once you create your VPC, it'll look like this.

Now, it exists.

Great job guys, we can…stop there?

No :)

Why? Because we need to allow traffic to go into it, send traffic out from it, and do it in a way that keeps us secure and isolated from the rest of the public AWS infrastructure.

These next steps are all about 3 things

• secure segmentation of public vs private portions of your network
• specific gateways in and out
• hosting infrastructure within the VPC such as EC2 instances (AWS specific Virtual Machines)

Step 2: Public and Private Subnets

Quick Overview:

• Public subnet → hosts internet-facing resources
• Private subnet → hosts internal resources
• IGW → allows internet connectivity
• NAT → allows private resources outbound internet access
• Route table → tells packets where to go

Let's get into subnet creation. 😁

First, the public subnet.

You navigate to subnets and then you click Create subnet.

You then give it a name, *availability zone, choose the VPC's IPv4 block, and then give the subnet a specific IPv4 block within the VPC.

• An availability zone is an isolated physical location designed to house AWS data. I selected us-east-1a, which is one of the Availability Zones within the US East (N. Virginia) region.

By the way, you choose an IPv4 subnet range within the VPC's CIDR block the same way you take a slice of pizza from a larger pie.

/24 is a smaller pool of IP addresses within a larger /20 pool.

Now, the private subnet. This is going to house infrastructure that we want to keep safe. People on the internet will not be able to access this.

• In an organization, this can be all your employee credentials, medical records, trade secrets, R&D related data, you name it.

With this one I gave it 10.0.1.0/24 because 10.0.0.0/24 is being used by our public subnet. So this is one subnet over in terms of IP addressing.

Step 3: Build the Doors — NAT Gateway + Internet Gateway

Now you may ask, Aryan, how does the VPC talk to the internet? And how does the private subnet especially communicate externally while staying secure?

Great questions.

Let me explain.

Instances in the private subnet send traffic → to the NAT Gateway.

The NAT Gateway uses its public IP and Internet Gateway to communicate with the internet on behalf of those private instances.

By the way, the NAT gateway must be deployed in the public subnet and assigned an elastic IP address so it can communicate with the internet.

Elastic IPs simply are IP addresses that stay even when the device gets shut down. If you don't have one, then everytime you start up your instance or device again, a new IP is assigned.

Here is a breakdown of the flow itself:

• private subnet →
• translate private IP to NAT gateway's public IP →
• public subnet → internet gateway
• internet gateway → internet
• (now on the way back)
• internet → internet gateway (reentering the VPC's public subnet)
• internet gateway → public subnet
• public subnet → NAT gateway (translate public address back to private address)
• NAT gateway routes traffic to the specific private IP address within the private subnet

So, lets make it.

• Create NAT Gateway
• Name
• Select your VPC
• Create

Now it exists. 😅

Now, for the Internet Gateway.

Same steps, you give it a name, assign it to the VPC, and create it.

Now you have the VPC itself, the public and private subnets, the NAT gateway, and the IGW all created. Now we need to create the lanes to drive traffic between these components.

This is where we handle routing. How do I get something from here to there? 🤔

We use route tables.

Step 4: Routing — Tables + Routes

Same fundamentals, you give it a name, VPC assignment and hit create.

You're going to create a public route table and a private route table.

In AWS, you must explicitly associate your subnets to the route tables because otherwise the route tables will bind to the VPC's Main Route Table by default.

The public route table, as displayed in the Routes below is going to allow traffic from anywhere 0.0.0.0/0 to be routed to your public subnet via the Internet Gateway.

You set the IGW as your target.

For the private route table, you point all outbound traffic to the NAT gateway.

Once your routes are setup, your traffic can flow between your gateways and subnets. Now that we have the infrastructure set up, we deploy an EC2 instance to verify that it works.

🛑 Wait! A Quick Security Check

Before we do launch our EC2 instance (virtual machine), we need to discuss firewalls within AWS.

There are 2 types: Security Groups and Network Access Control Lists (NACLs).

What is the difference? Security Groups are implemented at the instance level and NACLs are implemented at the subnet level.

I will give a much more thorough explanation in a future blog and how you use both in tandem to keep your VPC secure, but at the moment, we are going to create a Security Group specifically for the EC2 instance we will deploy.

You first go to VPC, and select security groups.

You then click Create security group.

As usual, you give it a name. I called mine vpc-demo-sec-group.

You also need to associate your security group with the VPC.

Like this. Then you set your rules.

Set one inbound rule for port 22 — SSH, and one for port 80 — HTTP.

For SSH, set your source type to My IP. AWS will autofill your public IP address in to ensure only you can remotely connect to the instance.

For HTTP, I set it to everyone to allow anyone to access any web server I setup on there. You do that by setting the source type to Anywhere-IPv4.

Now you can see the rules below. Why? Because it tells AWS which private network the firewall applies to.

If I want to deploy an NGinx webpage of sorts, anyone can do http:// and connect to it via the internet.

Now that we have the instance rules created via the SG, we are going to create the actual instance and verify connectivity for our final steps.

Step 5: Create an EC2 Instance

Before we make the instance, there is one thing I want to mention.

Every single EC2 instance is given an ENI (Elastic Network Interface). This is your virtual NIC. It is essentially your instance's badge to connect to a VPC.

It's a logical entity and it consists of an IPv4 address, a virtual MAC address, and more.

I'll go into ENIs more in a future blog and some of the different use cases of them.

So, let's make the instance.

You first navigate to EC2.

You then select Launch an instance under instances.

You then give it a name, I called mine ec2-vpc-demo, and you select an AMI.

AMIs are Amazon's catalog of virtual machines that you can select from.

If you want macOS, Windows, you name it, you select it here.

You then select your instance type. That's something I'll cover in a future blog too but the differences are around memory, pricing, and generally how much processing you want your instance to have.

If you look above you'll see t3.small have 2 GiB of memory whereas t3.large has 8 GiB.

You then select a key-pair to be able to securely connect to your instance.

Now, you do your Network settings.

You first associate the EC2 instance with the VPC you created.

You then specify the private subnet as the place the instance will exist.

Under security groups, select the one you just created.

Under advanced network configuration I like to set Auto-assign public IP to enable.

I also like to set Delete on termination to yes that way the ENI is also deleted alongside the EC2 instance.

You don't have to worry about the other advanced network configurations. You can, but generally once you have the main network settings specified you're good to go.

Under Configure storage I set it to 8 GiB and the file system type to None. I'll talk about the various file systems within AWS in a future blog as well and why you'd choose one over another.

You then hit launch instance and you're good to go. You can create more than one instance if you want but I made one for now.

Then you create your key-pair. Secure your key in a private place because you'll need it to connect to your instance.

And now it is made! We created our instance, and the final step is to connect to it. :)

We're almost there guys. If you stuck around this long, well done.

Step 6: Testing EC2 Connectivity

Once you launch the instance, open up your terminal on your local device.

You then connect using SSH with the following syntax:

ssh -i "mykey.pem" ec2-user@<public_ip>

ssh -i "mykey.pem" ec2-user@<public_ip>

mykey.pem is the key you created earlier when defining the instance

So um….it didn't work.

But why do I show you this? Because I'm going to fix it and make it work. :)

And this is a big part of tech and anything you do….it's not always going to work. And that's okay. So time to troubleshoot this and I'll show you guys what the error was.

In the mean time, here is a photo of food. If it makes you hungry, that's a sign to eat. We will resume soon. :)

Step 7: Troubleshooting Connectivity

Step 8: Successful Connection Established

🟢 I figured it out!

The issue was within the security group.

My IP address had changed so the IPv4 assigned under My IPv4 address went stale, causing the connection to drop.

So here we are with a successful SSH connection into the EC2 instance. We did it. If you made it this far, well done.

Seriously well done.

Key Takeaways

Now that we are done, I want to list a few key take aways as you build this:

1. It is not meant to be easy. There is a learning curve, and you will break things along the way.
2. If something doesn't work, trace your steps as you troubleshoot. You'll know what you looked at and you can save the steps for future use cases.
3. You can build this in steps. It doesn't have to all be done at once. I built it over 3 different sessions.

And most importantly, attempting to do it is nothing to be afraid of. Trying will always make you better.

So just try. :)