In this tutorial you will learn how to create a VPC in AWS.
Configuring a New VPC
There are a number of components (or building blocks) that we will need to use when creating a new VPC. These include a defined CIDR block for the VPC (this defines the private IP address space for everything that is created within the VPC), subnets, internet and NAT gateways, route tables, network access control lists and security groups. With these ‘building blocks’ we can build a secure virtual network to host our EC2 instances and other resources. In this post, I’ll cover the following tasks:
- Create a new VPC
- Create 4 new subnets (two ‘public’ and two ‘private’ split across separate availability zones)
- Create an internet gateway to allow EC2 instances launched in the public subnets internet connectivity
- Create a NAT gateway to allow EC2 instances launched in the private subnets to access the internet
- Create Route Tables to direct traffic to Internet/NAT gateways
This will be a fairly long post as there is quite a bit to get through, starting with creating the new VPC. I won’t be covering all the options available at each stage, but will go through getting a basic VPC set up.
To get started, once logged into the AWS console, Click Services then VPC. Then click the Create VPC button. In the window, enter the IPv4 CIDR block to be used for the new VPC:
Once done, click Yes, Create. It will only take a few seconds to create. Once done it will show up in the VPC Dashboard:
Next we need to create some subnets within the VPC.
Creating VPC Subnets
In this example I will create 4 subnets. One public and one private subnet in two separate availability zones. I’ll use the following scheme:
[table id=4 /]
To create a subnet, go to the subnets page and click ‘Create Subnet’:
I will go ahead and repeat for the remaining subnets, ensuring that I select a different AZ where appropriate. Once complete there are now 4 subnets associated with the new VPC:
Unlike the default VPC, by default, instances launched into the public subnets will not automatically receive a public IP address. To enable this functionality, select the subnet, then select ‘Modify auto-assign IP settings’ from the ‘Subnet Actions’ menu:
I will make this change for the two Public subnets I have created. With that done, the next step is to create an internet gateway, which will allow us to make instances in the public subnets accessible over the internet. Before they can be reached however, we need to create an internet gateway and attach it to the VPC.
Creating an Internet Gateway
We have set the public subnets up to allow any instances launched into them to receive a public IP address, however, they will not be accessible as we don’t currently have an internet gateway IGW provisioned. To create one, select ‘Internet Gateways’ , then click ‘Create Internet Gateway’:
After creation it will be detached, we need to click attach to VPC and select the new VPC:
Now that we have a IGW attached to the new VPC we need to create a route table to ensure that any traffic from the EC2 instances launched into the public subnets, destined for anywhere outside of the VPC is directed to the internet gateway. To do so, I need to create a route table to direct traffic destined for the internet to the IGW, and attach it to the public subnets. Click route tables, then Create Route Table. Enter a name for the route table, and select the new VPC that it will belong to. There will be a route populated already, covering the address space used for the VPC. We need to add a new route to catch traffic destined for addresses outside of the scope of the VPC. To do so, enter a route for 0.0.0.0/0, and use the newly created internet gateway as the target:
With the route added, the next step is to associate the route table with the ‘public’ subnets. To do so, click the ‘Subnet Associations’ tab, then select the subnets to associate with the table. At this point we have a new VPC, some subnets and an internet gateway configured. We can test what has been done so far by launching an EC2 instance into one of the ‘public’ subnets. If all is working as expected, the instance should be accessible over the internet. When launching the instance select the new VPC and one of the public subnets. Ensure that appropriate security group settings are configured when deploying the instance. I allowed SSH inbound so that I can test connectivity, but everything else will be blocked.
Once the instance has launched we can test connectivity to it by establishing an SSH session to its public IP address. If all has gone well then it should connect, and you will see the console of the new instance, and should see that it has been assigned an IP address from the range defined for the subnet it was launched into. In this case 172.16.1.189.
At this point there is an instance deployed into a ‘public’ subnet, which is accessible via SSH over the internet. All good so far. The last step that I want to carry out is to create a NAT instance and attach it to the two ‘private’ subnets. This will allow any instances launched into the private subnets outbound access to the internet, however they won’t have a public IP address assigned, and will be otherwise only accessible to other instances launched within the VPC.
To create a NAT instance, click ‘NAT Gateways’ on the VPC dashboard, then Create NAT Gateway. Select the subnet to deploy the NAT instance into (I am deploying it into one of the public subnets I created earlier), and select (or create) an elastic IP address to attach to the NAT instance:
Once the gateway has been created, the next step is to create a route table. This is very similar to the one created earlier directing traffic to the internet gateway. However, this time the target for the 0.0.0.0/0 route should be the NAT gateway:
With the route added, the route table can then be associated with the private subnets, enabling outbound internet access for any EC2 instances launched into those subnets.
As stated at the top, this article has turned into a long one! At this point, I now have two EC2 instances in different subnets that can communicate with each other (think Web and DB server), whilst making the ‘web’ server accessible over the internet, and granting the ‘DB’ server internet access via a NAT gateway. Whilst I haven’t gone into a great deal of detail, hopefully this has given an overview of the components used when creating a VPC and how they fit together. I’ll look to build on the concepts discussed here in future articles.