A simple explanation of VPCs for the AWS Cloud Practitioner

If you are looking for a simple introductory explanation of Amazon VPCs (Virtual Private Clouds), or if you are studying for the AWS Cloud Practitioner exam, this article is for you.

Networking has never been my strong suit, so when I first got started with AWS years ago, Amazon VPC was very intimidating. "Why can't I just use the Default VPC that AWS gives us? Seems to work fine..."

Fast-forward to today, and I now see many others struggle with the same concepts I struggled with. Since I am running an AWS Cloud Practitioner study group to help individuals pass the certification exam, I felt it was important to spend some time on Amazon VPC concepts, and this article is a result of that study group session.

Amazon VPCs: what are they?

A VPC is a private section of AWS that you control, into which you can place AWS resources (such as EC2 instances and databases). You have full control over who can access those resources that you place inside of your VPC.

Let's use a neighborhood analogy that I'm borrowing from this AWS Cloud Practitioner prep course.

You've got a neighborhood with houses, streets, and cars.

• Each house is a computer on the network (ie: an EC2 instance)
• Streets represent the network itself which connects houses and other neighborhoods together
• You hop on main streets to get from neighborhood to neighborhood (representing the open internet or private connections between your on-prem and AWS VPC)
• Some neighborhoods are gated, while others are open for anyone to drive through

So in our very high-level example, the VPC would be an entire neighborhood, and this VPC can have any number of resources inside of it. The neighborhood can also be subdivided even further with subnets and could have gates blocking traffic from entering certain parts of the neighborhood unless the vehicle has proper access.

Subnets

VPCs also have something called Subnets. Subnets are subsections of a network (“subnetwork”) which you can create to subdivide VPCs.

So after creating a VPC, you structure that VPC with subnets, and you'll typically want to create both:

• Public subnets (accessible from the internet)
• Private subnets

We'll explain the difference between public and private subnets in just a moment.

Although each subnet must reside in a single AWS Availability Zone (AZ), you can create multiple subnets in the same VPC and have them span across multiple AZs in the same region, which:

• Increases High Availability
• Creates Fault Tolerance

If you have 2 subnets across 2 AZs and one AZ goes down, you still have access to resources in the other AZ/subnet instead of your application being completely unresponsive.

Going back to our neighborhood example, we could decide how we want to segment our VPC into subnets.

Just like with street numbers and addresses (ie: 123 AWS Street, Seattle), each of our instances inside of VPCs have IP addresses that tell the network where to route traffic (ie: 192.168.1.1). The subnets dictate a range of IP addresses that can be allocated to your resources within those subnets.

What makes subnets public, and why does that matter?

We briefly mentioned public versus private subnets, but what's the difference and why does it matter?

The only difference between public and private subnets is that public subnets have a route to an Internet Gateway (IGW). The Internet Gateway then makes it possible for traffic to flow to, and from, the open internet (ie: from your home computer, or from another country).

By default, when creating a new VPC, all subnets will be private subnets.

However, when you create a new AWS account, by default, they provide you with a Default VPC, and that Default VPC has multiple subnets -- all of which are public subnets. This makes it much easier for beginners to start practicing using resources such as EC2 resources, because they'll be able to connect to those instances right away. Otherwise, if they had private subnets, they'd have to do more work before they could connect to those resources since they wouldn't be accessible from the open internet.

The problem with Default VPCs is that they are very restrictive and are really only designed to help you get started with using AWS, not to run production environments.

As a general rule of thumb, you want to keep as many resources in private subnets as possible, and only put resources in public subnets to help you get to private resources or to help you protect those private resources.

Let's take a quick look at an example:

In this diagram from https://aws.amazon.com/, we have the open Internet on the right, going to an Internet Gateway, routing traffic to the "VPC Public Subnet." They are hosting "Web App Firewalls" to protect their web apps in the public subnet, while the web apps and databases are hosted in the "VPC Private Subnet." So when it comes to requests coming from the open internet, those requests will have to get routed through the public subnet(s) in order to even access private resources in the private subnets.

VPC Security

While private subnets help protect your resources by making them harder to access, this is not enough security. We also have to use other tools such as Security Groups, Network Access Control Lists (NACLs), and Flow Logs.

Security Groups and NACLs act as firewalls and extra security layers, giving you complete control over what traffic is allowed in and out of your VPC and within your VPC.

Flow Logs allow you to capture information about IP traffic flowing between your network interfaces, which you can then analyze to detect anomalies.

Important information about NACLs

NACLs:

• Are at the subnet level - you assign one NACL to one or more subnets
• Have inbound and outbound rules - ie: allow this traffic to come in, but it can't go back out or vice-versa
• Allow everything by default
• Are stateless - traffic allowed one way has to also be allowed the other way

Important information about Security Groups

Security Groups:

• Are at the instance level (get evaluated after NACL) - you assign a Security Group when you create an instance, so each instance can have a different SG
• Deny everything by default, you can only specify allow rules
• Are stateful: traffic allowed one way is also allowed the other way

For example, in order to log into an EC2 instance that you've launched, you’d use something called SSH. In order to be able to SSH, though, you could create a Security Group that only allows SSH access from a specific IP or range of IPs. So, I could tell AWS to only allow SSH connections from my office network. If I go home and try to SSH, it would block my connection.

Helpful chart comparing SGs and NACLs

Source: AWS

Why use both Security Groups and NACLs?

Here's an example analogy of why you'd use both NACLs and SGs:

If you attend a conference like AWS re:invent. Different badges will give you different access…so if you’re just an exhibitor, you can get inside of the conference but you can’t get inside of speeches. In this case, as an exhibitor, the NACL access lets you inside of the conference but the SGs block you from getting inside of speeches.

Gateways & More

We went over what VPCs are, what subnets are, and what can be done to secure resources within VPCs.

One topic we didn't cover but that is important to understand for the Cloud Practitioner exam is the difference between Gateways (like Internet Gateways, Customer Gateway, Virtual Private Gateways, etc...). We cover all of the above concepts plus gateways and more in one of our live study groups. You can replay it here.