This post is part of a series of posts categorized as “Wiki” that contain basic how-to information. The intent is to create a reference repository for myself, but I’m not selfish so if anyone else can also benefit from it then I’m happy to share the knowledge!
What follows is a basic walkthrough of creating a simple VPC with public and private subnets. One public and one private subnet are in one availability zone. The second public and private subnets are in a different availability zone.
This VPC setup has several use cases. For example:
- The public subnets could be used as a sort of DMZ with more sensitive resources located within the private subnets.
- You can deploy webservers across the two private subnets with an AWS load balancer in the public subnets.
Creating a VPC
In the AWS VPC Dashboard click Create VPC.
You will want to give the VPC a name that reflects its purpose or function. You also need to assign it a CIDR block. For this example I’m using 10.0.0.0/16. You’ll want to make sure what you pick doesn’t conflict with other IP ranges, either in AWS or on-prem. [If I ever create a post about calculating IPs I’ll link to it from here. For now that is out of scope. Sorry!]
I’m also not assigning an IPv6 CIDR.
Creating and attaching an internet gateway
The VPC that you created cannot currently access the internet because it doesn’t have an internet gateway for that network traffic to pass through.
You can create an internet gateway from the VPC Dashboard by clicking on Internet Gateways.
I like to give the gateway a name that helps identify the VPC it is attached it to.
The newly created internet gateway is not yet attached to a VPC.
Select the internet gateway and then attach it to the VPC that you created.
You now need to create the two public and two private subnets for the VPC. This can be done from Subnets in the VPC Dashboard.
To make things easier on yourself, the name you give the subnets should clearly reflect if it is public or private, as well as public/private subnet one or public/private subnet two.
When you create it, make sure you place the subnet in the VPC you just created, not an other VPC, such as the default VPC.
You also want to make sure you explicitly assign it to an Availability Zone (AZ). Otherwise AWS will automatically assign it and you could end up with both subnets in the same AZ. In this example public/private subnet one will be AZ us-east-1a and public/private subnet two will be in us-east-1b.
The final consideration is the CIDR block for the subnet. In this example I’m just using /24 CIDRs.
- Public subnet one is 10.0.10.0/24
- Public subnet two is 10.0.20.0/24
- Private subnet one is 10.0.30.0/24
- Private subnet two is 10.0.40.0/24
Any resources you eventually stand up in your public subnets will have a public IP address that they can use for internet access via the internet gateway you attached to the VPC. However, we want to insulate our private subnet resources.
Rather than give them a publicly routable IP address you should create NAT gateways for outbound internet access.
From NAT Gateways in the VPC Dashboard we are going to create two NAT gateways, one in public subnet one and the other in public subnet two.
Unless you already have AWS elastic IPs available, select Create New EIP so that AWS assign a public IP address to the NAT gateway.
Again, put one NAT gateway in each of the public subnets.
To help you tell the NAT gateways apart you should give them a name identifying which subnet they are attached to.
Currently the subnets don’t know how to route network traffic because there are no route tables.
Previously it was noted that resources with public IPs in the public subnets would reach the internet via the internet gateway you created. You need to create route tables for those public subnets pointing that traffic to the internet gateway.
Similarly, you created NAT gateways in the public subnets that were to be used to route internet traffic from the private subnets. To do this the private subnets need route tables that point to the respective NAT gateways.
Create the route tables from Route Tables in the VPC Dashboard.
Give the route tables an appropriate name so you can identify which subnet it belongs to and then select the correct VPC.
You will have a total of four route tables.
For the first public route table, select it and then click the Routes tab and Edit Routes. Click Add route with a destination of 0.0.0.0/0 (i.e. all traffic) with a target of the internet gateway you created.
Then click the Subnet Associations for the first public route table and click Edit subnet associations.
Currently this route table is not associated with anything. This is where you associate the first public route table with the first public subnet that you created.
Public route table one will now show associated with the subnet ID that corresponds to public subnet one, which we assigned the IPv4 CIDR 10.0.10.0/24.
Repeat the same steps with public route table two so that the destination 0.0.0.0/0 targets the internet gateway. Then assign public route table two to public subnet two.
The private route tables will be very similar to the two public route tables you configured. The main difference is that instead of targeting the internet gateway for all traffic, you need to target the corresponding NAT gateways created.
You should now have:
- Public route table one associated with public subnet one, routing all traffic to the internet gateway
- Public route table two associated with public subnet two, routing all traffic to the internet gateway
- Private route table one associated with private subnet one, routing all traffic to the NAT gateway in public subnet one
- Private route table two associated with private subnet two, routing all traffic to the NAT gateway in public subnet two
This completes setting up the VPC.
[Next I plan to link to a post about creating an AWS Application Load Balancer. I’ll add that link here once it has been posted.]