I’ve been spending some time attempting get a more in-depth knowledge around Amazon Web Services. It is dead simple to start spinning up compute instances and S3 buckets. As I dive deeper in, however, I have started to uncover some of the more complicated topics that a person or an organization would run into while beginning a “journey to the cloud.”
One of those areas is networking. Maybe I gravitate towards that area first since my background involves a heavy dose of traditional on-premise networking. I would imagine anyone in my shoes would have no problem grasping the concepts of VPCs, NAT gateways, and Internet Gateways. Still, there are a certain amount of steps involved in customizing a VPC.
A Virtual Private Cloud (VPC) is a networking space in an AWS footprint. They are unique to regions, meaning you can’t span VPCs between Virginia and Ireland for example. The use cases for building your own customized VPCs include some or all of the following:
- The ability to pick your IP addressing scheme per data center (could be important in building VPNs from a local data center to a VPC, or VPC-to-VPC peering–larger topics for another time)
- The ability to separate networking space for different business units such as HR, Finance, IT (And the ability to apply separate, granular firewall controls through security groups and ACLs)
- The ability to separate dev/test/prod environments from one another
There is a default VPC, which contains default subnets, you can start deploying instances into this networking space right away. But you may want to take a more prescriptive approach to networking in AWS and build your own custom VPCs.
To create a new VPC
- Go to AWS Services, under “Networking and Content Delivery,” choose VPC
- Go to “Your VPCs,” click the big blue button that says “Create VPC”
- Give the VPC a name (I called mine Bob VPC) and a CIDR block (A /16 is the largest block you can create, you will create subnets from this block)
Next, we need to create subnets within our VPC
- Go to “Subnets,” click “Create Subnet”
- Give the subnet a friendly name (I chose the format of my VPC name and the network address)
- choose which VPC it goes in (my BobVPC)
- you can specify the availability zone in which you want it to reside
- specify the CIDR block for the subnet (I chose /24s for my example)
In the details pane, you can see how many IP addresses are left, VPC membership, network, and subnet-ID. AWS reserves the first three addresses in any network. I have created two new subnets, one for public instances and one for private instances.
By default, any subnet created in a custom VPC doesn’t assign a public IP to instances created within it. If you want instances in the subnet to automatically get a public IP, you can enable auto-assignment of those public IPs.
- choose which subnet ( I chose my Bob 10.10.1.0/24 subnet to be my public-facing subnet)
- from the dropdown on “Subnet Actions,” choose modify auto-assign IP settings
- Check the box for auto-assign
For the subnets with public IPs, we need to create a way for those instances to get to the internet. This is an Internet Gateway.
- Go to Internet Gateway
- click “Create Internet Gateway”
- Give the IGW a friendly name ( I chose BobVPC IGW in this case)
- We then need to associate the IGW with the VPC
- choose your new IGW and click “Attach to VPC,” select your VPC (Bob VPC)
OK, we have a VPC created, we have a subnet that auto-assigns public IPs to instances within it, we have an internet gateway. We now need to create a route for that subnet to get to the Internet Gateway.
- Go to “Route Tables”
- Click “Create Route Table,” lets name it “BobVPC Public Route,” make sure it is associated with the correct VPC
- Our route table is created, let’s create a route, choose our route table
- Click on the routes tab and add a new route, by clicking edit
- Click add another route, since this is default, we are going to do an all 0s destination (0.0.0.0/0)
- Click in the target box, and it should show you the options, choose the IGW you created, Click Save
- Lastly, we need to associate the subnets with this route table, click on the Subnet tab
- Click Edit, then choose the subnets you wish to route to the internet, Click Save
We can now create an EC2 instance. During the launch process, choose our new VPC and the subnet you want the instance to live in. Once that instance is launched into my “Bob VPC 10.10.1.0” subnet, it will get a public IP address and will be able to access the internet via our Internet Gateway.
What if we don’t want our EC2 instance to get a public IP? We have our old friend NAT.
Much like we created an Internet Gateway for our public instance, we create a NAT Gateway for our private instance. The key here is that when creating this NAT Gateway, it needs to be associated with a public subnet.
- Go to NAT Gateways, click “Create NAT Gateway”
- Choose a subnet in which to place the NAT GW (This is where we need to choose our public subnet, “Bob VPC 10.10.1.0”
- We can have AWS automatically assign our external IP, which is called an Elastic IP
Next we’ll need to add a route to the NAT GW for your private subnets. You can either edit the default route table within your VPC, or create a new route table. I am going to create a new route table.
- Go to “Route Tables”
- Click “Create Route Table,” lets name it “Bob VPC NAT,” make sure it is associated with the correct VPC
- Let’s add a default route, click on the Routes tab, choose Edit
- Add another route, and choose all 0s again (0.0.0.0/0)
- In the target, you should see the NAT gateway you created, choose that and click save
- Then we need to associate this route table with our private subnet, click on the Subnet tab
- Click Edit, then choose your private subnet (in my example it is “Bob VPC NAT”)
Any new EC2 instances created with this subnet will have NAT access to the internet, but will not have a public IP.
Like many of the services within AWS, there is a low barrier to entry for getting started, but once you get past the surface, there is a world of dragons. Beware.
Here is the link to the VPC user guide: