6 Key AWS VPC Fundamentals

What is a VPC?

If your role is to design or deploy Cloud infrastructure on AWS, then one of the most fundamental concepts to be familiar with is the Virtual Private Cloud (VPC).

It’s not easy to find a direct correlation of this idea in the legacy network world. In some respects, we could compare it to a Virtual Routing Function (VRF), but considering the multi-route table flexibility in a VPC that analogy doesn’t hold true.

I like to explain it as a container for workloads that meet certain grouping criteria. These criteria may be organizational (departments), logical (application dependency), or any other criteria that would allow you to apply policy (routing, security, access control, administration) in a way that meets your requirements.

1. Scope and IP Addressing

The first thing to be aware of is that VPC is a regional concept. This means that the created VPC is deployed in the region, across all Availability Zones in the region. It does not extend beyond the region.

The second key concept is the CIDR assigned to the VPC. This is the aggregate-address of the subnets that will be deployed in the VPC. This does require some planning.

Acceptable VPC subnetting include:

2. Subnets

This brings us to the second most critical concept concerning VPCs – subnets.

A workload (EC2 instance, ENI, etc.) does not live in a VPC, but rather lives in a subnet in the VPC.

Subnets are generally classified as either Public or Private. This only has an impact in so far as workloads in a public subnet will be accessible from the internet by default and workloads in a private subnet will not be accessible (or have access) by default. We’ll address that further below.

Continuing to build out our VPC, we now add 2 subnets with both CIDRs clearly within the range of the VPC CIDR and not overlapping.

When designing this subnet allocation, the below constraints must be kept in mind:

• AWS reserves 5 IP addresses in the subnet range for internal use
• As is typical, the .0 and .255 addresses are reserved
• .1 is reserved for the default gateway
• .2 is reserved for DNS
• .3 is reserved for future use

3. Route Tables

So now we have subnets, how do we communicate between them? Well, just like in real life, with the help of route tables and a router:

You can get away with one route table, but assigning a route table to each subnet will offer more granular routing policy control going forward.

It’s also necessary to have a separation of public routing tables and private routing tables in order to control internet access. We’ll see that later with the IGW and NAT GW.

For now, the routing configuration offers communication between the subnets (considering there are no security policies in place (NACLS or SGs).

The “router” function that I have depicted above is not an explicit service, but rather an implicit service. There is no “router” function to deploy or configure – it is implicitly managed by AWS in the VPC.

4. Internet Access

There are two types of access to take into consideration.

1. Public subnet workloads inbound and outbound internet access
2. Private subnet workloads outbount internet access

Public Subnets

Let’s start with the Public subets:

Internet access is managed using an Internet Gateway or IGW.

If you manually create the IGW, you need to assign it to the VPC after creation. You will also have to ensure that the route tables associated with the Public subnets have a default route pointing to the IGW (this must be done manually).

When EC2 instances require an elastic public IPv4 address, one is assigned to the instance (whether elastic or sticky). This is not actually assigned to the EC2 instance, but rather as a destination NAT entry in the IGW pointing to the private IP address of the host in question.

The IGW is a service provided by AWS – you do not need to configure NAT or anything else on it or manage capacity or redundancy. It is a VPC wide concept and spans AZs.

Private Subnets

What about the private subnets? Do workloads here require internet access? Most likely, yes for software installations, updates, etc.

This is handled by a NAT gateway.

The NAT gateway is deployed in a Public subnet and requires a default route in the Private subnet pointing to it. It receives an Elastic IP address to allow it to access the internet.

It is managed by AWS and you do not need to configure the SNAT or anything else on it or worry about capacity.

However, this instance is specific to an AZ (IGW is not), so redundancy may be required for multi-AZ deployments.

5. Securing the VPC

At a very basic level, we will be using the Network Access Control Lists to secure the VPC.

These are deployed at the subnet level and control access to the subnet at an IP level

NACLs, are not the be-all and end-all of security. They are quite basic and static, but very effective at enforcing some high level IP access to the subnet. Coupled with out security approaches, they are very effective.

6. Availability Zones

A quick note on how all the above fit into the concept of Availability Zones (AZs).

As a reminder, an AZ is a fully redundant, independent, physical data centre in a Region. A region is therefore made up of 2 or more (likely 3 or more) physical AZs.

VPC is a regional concept. A VPC spans the AZs in a region.

All the concepts we discussed above can now be seen in the context of Availability Zones:

As we can see above, some elements are local to the AZ and some are at the VPC level.

For example, IGW is not concerned with AZs. The NAT GW on the other hand is associated with a subnet which is in turn associated with an AZ and redundancy must therefore be designed for.

Conclusion

So, after reading this post, I hope you feel more comfortable with the high-level concepts around VPC. There are many more complexities to add to the configuration, but for now, we have a base to build on.