To set the stage for explaining Amazon Web Services Virtual Private Clouds, I previously walked through AWS Regions and Availability Zones in another blog post. With that as the foundation, we can start taking a look at the concept of a Virtual Private Cloud and how it enables advanced networking capabilities for your AWS resources.

Virtual Private Cloud, aka VPC, is a logically isolated virtual network, spanning an entire AWS Region, where your EC2 instances are launched. A VPC is primarily concerned with enabling the following capabilities:

• Isolating your AWS resources from other accounts
• Routing network traffic to to and from your instances
• Protecting your instances from network intrusion

There are 6 core components which are fundamental to being able to launch AWS resources, such as EC2 instances, into a VPC. These 6 components are:

• VPC CIDR Block
• Subnet
• Gateways
• Route Table
• Network Access Control Lists (ACLs)
• Security Group

Every AWS account created after 2013-12-04 supports VPCs and these accounts are assigned a default VPC in every Region. These default VPCs are designed to make it easy for AWS users to get started with setting up networking for their EC2 instances.  In the whiteboard video below, I will explain how the basic components of a VPC fit together and walk though how they are configured in a default VPC. For the rest of this post, I will walk you through what a default VPC looks like in the AWS Console and highlight important default settings.

The place to begin looking in your AWS Console is with the VPC Dashboard where you can get an overall view of what components are available as part of your VPC footprint. Note that the basic components I mentioned earlier will already be provisioned as part of the default VPC that is assigned to every AWS account for every region.

VPC CIDR Block

Select “Your VPCs” in the left sidebar and the dashboard will display all your VPCs in a particular Region, including the default VPC. A region can only have one default VPC. Although you can have up 5 VPCs in a region, only the initial VPC that AWS creates for you can be the default VPC.

Every VPC is associated with an IP address range that is part of a Classless Inter-Domain Routing (CIDR) block which will be used to allocated private IP addresses to EC2 instances. AWS recommends that VPCs use private ranges that are defined in RFC 1918. All default VPCs will be be associated with an IPv4 CIDR block with a 172.31.0.0/16 address range. This will give you 65,536 possible IP addresses.

Subnet

Next, if you go to the “Subnets” screen, you will see that multiple default subnets have already been assigned to your default VPC, one subnet for each Availability Zone in a Region.

A subnet is always associated with a single Availability Zone and cannot span multiple AZs. However, an AZ can host multiple subnets. Each subnet in a VPC is associated with an IPv4 CIDR block that is a subset of the /16 CIDR block of its VPC. In a default VPC, each default subnet is associated with /20 CIDR block address range which will have 4091 possible IP addresses minus the 5 addresses that AWS always reserves. Note that 2 subnets cannot have overlapping address ranges.

When you launch an EC2 instance into a default VPC without specifying a specific subnet, it is automatically launched in one of the default subnets. Every instance in a default subnet receives a private IP address from the pool of addresses associated with that subnet and also a private DNS hostname. In a default subnet, an instance will also receive a public IP address from the pool of addresses owned by AWS along with a public DNS hostname, which will facilitate Internet access for your instances.

Gateways

Frequently, your EC2 instances will require connectivity outside of AWS to the Internet or to a user’s corporate network via the use of gateways. For communication with the Internet,  a VPC must be attached to an internet gateway. An internet gateway is a fully manged AWS service that performs bi-direction source and destination Network Address Translation (NAT) for your EC2 instances. Optionally, a VPC may use a virtual private gateway to grant instances VPN access to a user’s corporate network.

A subnet that provides its instances a route to an internet gateway is considered a public subnet. A private subnet may be in a VPC with an attached internet gateway but will not have a route to that gateway. In a default VPC, all default subnets are public subnets and will have a route to a default internet gateway.

Route Table

I’ve mentioned routing several times while talking about the internet gateway. Every VPC is attached to an implicit router. This is a router that is not visible to the user and is fully managed and scaled by AWS. What is visible is the route table that is associated with each subnet and is used by the VPC router to determined the allowed routes for outbound network traffic leaving a subnet.

Note from the screenshot below that every route table contains a default local route to facilitate communication between instances in the same VPC, even across subnets. In the case of the main route table that is associated with a default subnet, there will also be a route out to the Internet via the default internet gateway for the VPC.

Also note that every subnet must be associated with a route table. If the association is not explicitly defined, then a subnet will be implicitly associated with the main route table.

Network ACLs

One concern you may rightly have is network security, particularly if all default subnets in a default VPC are public and open to Internet traffic. AWS provides security mechanisms for your instances in the form of network ACLs and security groups. These 2 mechanisms can work together to provide layered protection of your EC2 instances.

A network Access Control List (ACL) acts as firewall that controls network traffic in and out of a subnet. You create Network ACL rules for allowing or denying network traffic for specific protocols, through specific ports and for specific IP address ranges. A network ACL is stateless and has separate inbound and outbound rules. This means both inbound and outbound rules have to be created to allow certain network traffic to enter the subnet and for responses to go back through. For example, if you create an inbound rule allow SSH traffic into the subnet, you must also create an outbound rule to allow SSH related traffic out of the subnet.

A rule number is assigned to each rule and all rules are evaluated starting with the lowest numbered rule. When traffic hits the firewall, it is evaluated against the rules in ascending order. As soon as a rule is evaluated that matches the traffic being considered, it is applied regardless of what is indicated in a subsequent rule.

 

As indicated above, the default Network ACL in a default VPC is configured with lower-numbered rules for both inbound and outbound traffic which combine to explicitly allow bi-directional communication for any protocol, through any port and to and from any source or destination.

You can associate a Network ACL with multiple subnets but any single subnet can only be associated with one Network ACL. If you don’t specifically associate a Network ACL with a subnet, the subnet is automatically associated with the default Network ACL. This is the case with your default VPCs which have all subnets associated with the default Network ACL.

Security Groups

Security groups are considered the first line of defense and is a firewall that is applied at the instance level. This means that only instances explicitly associated with a security group will be subject to its rules while all instances in a subnet are impacted by the network ACL applied to that subnet.

Similar to network ACLs, you create inbound and outbound traffic rules based on protocol, port and source or destination IP. However there are some differences as well.

• You can specify rules to allow network traffic but cannot create rules to deny specific types of traffic. In essence, all traffic is denied except for traffic you explicitly allow.
• Security groups are stateful so if you create a rule to allow a certain type of traffic in, then outbound traffic in response is also allowed even if there is no explicit outbound rule to allow such traffic.

Every instance must be associated with a security group and if a security group is not specified at launch time, then that instance will be associated with a default security group.

You can see from the screenshot above that a default security group will have a rule that only allow inbound traffic from other instances that are associated with the same default security group. No other inbound traffic is allowed.

Looking at the outbound rules above, all network traffic out is allowed by the default security group. This includes traffic out to the Internet since a default VPC will have a route to a default internet gateway.

As you can imagine, while a default VPC may be suitable for a small non-critical single tier applications, it is not ideal for a robust production environment. That’s why it is recommended that after getting their feet wet, users modify the default VPC configurations or create custom VPCs for production use. In the next blog post, we will do just that and break down a common use case with a custom VPC that has a public subnet tier and a private subnet tier. Stay tuned.