VPC Introduction – Part 1

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:

VPC Resource

The “VPC” resource itself. At its most simple, a VPC is:

  1. A VPC Resource defines a CIDR block of addresses. For example, vpc-c057aaaa5 uses the IP range
  2. 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:
    1. a DHCP options set
    2. a route table
    3. a network ACL.
  3. 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:

  1. 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, I can create two subnets comprised of IP ranges and
  2. 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.
  3. A subnet must be associated with:
    1. a Route Table (providing one or more “target” for outbound packets – a “target” is Amazon’s terminology for “next hop.”)
    2. a Network ACL (providing control of inbound and outbound traffic)
  4. 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 and two subnets: and

VPC - VPC and Subnet

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 – 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

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, Amazon creates the following route automatically:
    • Destination:
    • 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:
    • 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 is “local”) and to the Internet (route is igw-3547bf50), sharing a route table with multiple subnets makes sense.
Network ACLs

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)
  • Network ACLs only allow filtering based on IP address and port – for instance, I can allow traffic in from IP addresses 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 and an Outbound rule allowing traffic to destination The Route Table contains a rule directory all traffic to to be delivered to an Internet Gateway.

VPC - Route Table and Network ACL

More Information

One thought on “VPC Introduction – Part 1

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s