One of the important first stages of adopting cloud is looking at how the network will function. Cloud-based applications are always accessed over a network. Network design and planning is critical. The networking in AWS is designed as one or more Virtual Private Cloud (VPC). A VPC is a collection of subnets in a region. Regions are geographically spread, today there are 14 AWS regions spread around the globe. Each region is made up of two or more Availability Zones (AZs), which you can think of as data centers. Each subnet lives inside a single AZ, routing is used between the subnets. Every AWS tenant has a default VPC in every region, with the same subnets in each VPC. Usually, we build our own VPC to suit our needs. Sometimes we have additional VPCs for different business units or for separating production from development. I will create a very basic VPC. It will allow me to have applications spread across multiple AZs, to survive AZ failure. It will also use a DMZ to provide Internet connectivity and have a separate internal network.
The nearest AWS region to my home in New Zealand is the “Asia Pacific (Sydney) zone”. This zone is based in the city of Sydney and has three AZs (data centers). This is where I am going to deploy a VPC because network latency, and therefore performance, is related to the distance to the VPC. The Create VPC wizard only needs a name and the overall subnet range (CIDR block) for the VPC. The subnets in each AZ must fit within this block. The “Tenancy” option is a trap for new players. Choosing “Dedicated” will provide you dedicated physical servers for your VMs. This will make your costs skyrocket.
Once the VPC is created, we need to create some subnets for our EC2 instances (VMs). The default VPC for Sydney has three subnets, one for each AZ. I will also create at least one subnet for each AZ. I am creating DMZ and internal subnets in each AZ for a total of six subnets. Each subnet is named and then associated with a VPC and an AZ then assigned a CIDR (subnet) that fits inside the VPC.
Here is my built collection of subnets, each AZ has an Internal subnet and a DMZ subnet. I used the VPC name and subnet function in the names so the purpose of each subnet is clear. If I had application subnets I would include the application name.
Now that we have a set of subnets, we need to link them together and allow them access to the Internet. There is routing between the subnets within the VPC. We will need a Route Table to get outside the VPC, to the Internet for example. For the DMZ subnets, I am also going to allow access to the Internet through an Internet Gateway. My Internet Gateway is simply named for the VPC it serves.
Once the Internet Gateway is created I attach it to my VPC so that my subnets can have some Internet access.
I only want my DMZ subnets to have direct access to the Internet. Everything else is going to need to route its Internet traffic through something in one of the DMZ subnets. To do this I create a new routing table for the three DMZ subnets.
Then I associate the three subnets with the Route table by selecting the subnets on the “Subnet Association” tab.
Finally, I add a default route, for 0.0.0.0/0, via the Internet Gateway I just created. Notice that there is a dropdown with all the Internet Gateways in the VPC, so I don’t need to remember the name of the gateway.
I now have my DMZ and Internal network setup, each with a subnet in each AZ. I have only deployed a very simple VPC, enough to get started learning about AWS. As a final thought, AWS does not let you edit the CIDR on a VPC or subnet, if you need to change then you must delete and re-create. This is a common principle in AWS, parts should be disposable and easy to recreate.
Leave a Reply