VPC Introduction – Part 1
My 3 part VPC introduction will provide an understanding of each resource that makes up a VPC, how the resources relate and how to stand a VPC up using AWS’s CloudFormation. The content of each part is as follows:
- part 1: covers the VPC resource itself, subnets, Network ACLs and Route Tables
- part 2: covers Internet Gateway, EC2-VPC Security Groups, Auto Scaling Groups and Launch Configurations
- part 3: the CloudFormation template itself and each resource that makes up a CloudFormation Stack that creates a VPC
VPC Resources and Subnets:
The “VPC” resource itself. At its most simple, a VPC is:
- A VPC Resource defines a CIDR block of addresses. For example, vpc-c057aaaa5 uses the IP range 10.0.0.0/24.
- A VPC Resource must be associated with three additional resources that Amazon will automatically create when you build a VPC. The three required resources are:
- a DHCP options set
- a route table
- a network ACL.
- A VPC resource should contain one or more subnet resources – the subnet resources are required for hosting Amazon resources require an IP address.
Subnets are logical divisions of the VPC resource into smaller networks. You can build a VPC that contains only one subnet, but best practice dictates that you have at least two subnets per VPC, with each of these to subnets in a different availability zone. Subnet resources are described below:
- A subnet must contain an CIDR IP range that is within the VPC and does not overlap with another subnet. For instance, in the VPC with IP address range 10.0.0.0/24, I can create two subnets comprised of IP ranges 10.0.0.0/25 and 10.0.0.128/25.
- A subnet may only be in one Availability Zone but may not span Availability Zones. For instance, subnet-09b5e321 may be in us-east-1e or us-east-1b both not both us-east-1e and us-east-1b.
- A subnet must be associated with:
- a Route Table (providing one or more “target” for outbound packets – a “target” is Amazon’s terminology for “next hop.”)
- a Network ACL (providing control of inbound and outbound traffic)
- A subnet can automatically assign public IP addresses to instances when they are brought into service. As of July 4, 2014 the public assignment of IP addresses can not be done within an “EC2::Subnet” type of resource from within CloudFormation, but rather must be applied on either the Auto Scaling Group or EC2 Instance types.
The image below describes a VPC that contains the CIDR IP Range 10.0.0.0/24 and two subnets: 10.0.0.0/25 and 10.0.0.128/25.
A quick notes regarding VPC IP addressing:
VPCs can use the same IP address range. For instance, vpc-6e558a0b and vpc-00548b65 can both use IP ranges 10.0.0.0/16 – as they are both separate private clouds the addresses will not conflict. I would recommend against this practice – routing traffic to two different VPCs that use the same IP address scheme is technically possible (NAT) but would be difficult.
Route Tables and Network ACLS:
As mentioned earlier, a VPC requires three additional resources that Amazon will create for you. These three resources are a Route Table, a Network ACL and a DHCP Options Set. The Route Table and Network ACL resources are described in further detail below.
Route tables determine where network traffic is directed.
- A Route Table contains one or more routes that are responsible for determining the “target” of packets sent to a particular destination
- A Route Table always contains a “local” route that directs traffic within the subnet. Assuming a VPC with CIDR IP Range 10.0.0.0/24, Amazon creates the following route automatically:
- Destination: 10.0.0.0/24
- Target: local
- A Route Table will may contain more than the local routes that directs traffic within a subnet – these routes will allow instances to send traffic beyond the VPC where they are located. The rout described below will route traffic to the Public Internet:
- Destination: 0.0.0.0/0
- Target: igw-3547bf50 (igw-3547bf50 is an Internet Gateway)
- Each subnet can be associated with only one route table. However, a route table may be used by more than one subnet.
- Allowing only one route table per subnet makes sense: merging two route tables would be complex and might even result in conflict in where to send traffic.
- Allowing a route table to be used by multiple subnets makes sense: a common case might be two subnets that are allowed to send data within the VPC and also to the Internet – given that they share identical routes within the VPC (route 10.0.0.0/24 is “local”) and to the Internet (route 0.0.0.0/0 is igw-3547bf50), sharing a route table with multiple subnets makes sense.
Network ACLs determine if traffic can be passed.
- Network ACLs are required for inbound and outbound traffic.
- inbound rules match on source IP of packet
- outbound rules match on destination IP of packet
- Network ACLs are stateless (as opposed to stateful)
- the fact that Network ACLs are stateful means that both inbound and outbound rules must be defined. For instance, a request bound for http://www.google.com on port 80 would be best allowed by using an outbound rule 0.0.0.0/0 for port 80 – but accepting return traffic from google would require an additional inbound rule allowing 0.0.0.0 on ports 1024-65535 – or, more realistically, 0.0.0.0 on any port. A good discussion on ephemeral ports is here: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_ACLs.html#VPC_ACLs_Ephemeral_Ports.
- Network ACLs only allow filtering based on IP address and port – for instance, I can allow traffic in from IP addresses 10.0.0.128/25 on port 80. Note that a Network ACL does not understand the concept of a security group, so I can not allow traffic in from sg-6482490e on port 80.
The image below describes a VPC that allows traffic flow between within subnets as and also allows traffic to flow to and from the Public Internet. Notice the Network ACL has an “Inbound” rule allowing traffic from source 0.0.0.0/0 and an Outbound rule allowing traffic to destination 0.0.0.0/0. The Route Table contains a rule directory all traffic to 0.0.0.0/0 to be delivered to an Internet Gateway.
- For a comparison of Network ACLs and Security Groups: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Security.html