The Amazon Virtual Private Cloud (VPC) is a logical, networking construct that provides the network layer for EC2 instances and other AWS services. Basically, it’s a software-defined networking solution that gives you the flexibility to bring your own IP addresses to the cloud, create subnets, configure routing, and implement security and access policies. While there’s much we could do with VPCs, I want to keep this post brief and simply explain VPC concepts. I do plan to build on this post so stay tuned for multi-part guides on how to create VPCs and connect them to your on-prem or cloud environments.
VPCs and Subnets
When you implement a VPC, you are creating the private networking layer for a specific region with primary subnet range. This means that you will assign a specific CIDR block that spans all availability zones within a region. This specific CIDR block is known as the primary subnet. You then assign subsets of primary CIDR block to specific availability zones within the VPC. For example, if the primary subnet for the VPC is 10.0.0.0/16, you can assign 10.0.0.0/24 to a single availability zone. Note that subnet blocks (i.e., the subset of the primary subnet) cannot span availability zones. Additionally, you may only specify block sizes that fall between a /16 and /28 (inclusive) netmask. For more detailed information, please visit the AWS User Guide for VPCs and Subnets.
There is an implicit router within a VPC that performs all routing functions. To properly route between subnets, the router contains at least one route table called the main route table. AWS automatically creates the main route table; subnets that are not explicitly associated with other route tables are implicitly associated with this table. Note that you cannot delete the main route table but can replace it with a custom table.
A custom route table is simply a table you create that complements the main route table. For simplicity, I like to leave the main route table in its original state (i.e., default) and explicitly associate each new subnet I create with new or existing custom route table. This gives me the ability to control routing at a more granular level than using the main routing table.
An internet gateway is a component within a VPC that allows instances within a VPC to initiate and receive communication from the internet via a 1-to-1 NAT. Note that addresses must be globally unique and be either a public IPv4 address, Elastic IP address, or IPv6 address. For communication to traverse the internet gateway, you must create an entry in your route table to direct internet communication to the gateway.
A NAT Gateway is another component available in a VPC that allows instances assigned a private IP to connect to the internet. The NAT gateway is useful for instances that simply need to access the internet for package updates or downloads. While this device sounds similar in function to the internet gateway, they are different with respect to redundancy, IP addresses, and NAT functions. Specifically:
- There is redundancy only within a single availability zone
- The NAT gateway supports a single Elastic IP address
- The NAT gateway performs a many-to-one NAT
Note that you must deploy a NAT gateway in a VPC that contains an internet gateway. Additionally, you must update your route table to handle instance traffic you wish to traverse the NAT gateway.
There are two features that you can utilize to further secure your VPC. The first feature is security groups. Security groups are rules that control the inbound and outbound traffic for instances within your VPC. These rules are stateful in nature and support “allow” rules only. Additionally, you assign and apply a security group to a particular instance. This can occur during deployment time or later once the instance is functional. Also note that all rules within a security group are evaluated before traffic is allowed to pass to/from an instance in a VPC.
The second security feature is the network access control list (ACL). This feature is different than a security groups because it operates at a subnet level. This means that all instances deployed onto a particular subnet get assigned an ACL (if one is defined). A network ACL is also stateless meaning that you must specify allow rules for both outbound and inbound traffic. In addition to “allow” rules, network ACL supports “deny” rules and processes rules in specific order to determine whether to allow traffic.