VPC subnets

VPC and Subnets

There are many networking concepts associated with a AWS Virtual Private Cloud. These concepts are key to architect and build your VPC for a variety of different workloads and use cases. The following are the concepts associated with VPC:

  • Virtual Private Clouds (VPCs)
  • Subnets
  • Route Tables
  • Network Access Control Lists (NACLs)
  • Security Groups
  • NAT Gateways
  • Bastion Hosts
  • VPN and Direct Connection
  • VPC Peering
  • AWS Transit Gateway

In this post, I will focus on what are VPCs and dive into Subnets.

What is a VPC?

A VPC is an isolated segment of the AWS Cloud itself.

Now to understand what a VPC is, let’s just take a look at the AWS infrastructure. So, here is the AWS Cloud. Quite simply a VPC resides inside of the AWS Cloud and it’s essentially your own isolated segment of the AWS Cloud itself, so here is your VPC sitting inside the AWS Cloud.

Now by default when you create your VPC, the only person that has access to this is your own AWS account, just you. It is totally isolated and no one else can gain access to your VPC other than your own AWS account.

Now obviously there are millions upon millions of other VPCs within the AWS network created by other customers all across the world. So, there are millions of customer VPCs. However, they do not have access to your VPC and likewise, you do not have access to their VPC.

Now what do you use a VPC for?

Well, essentially it allows you to start deploying resources within your VPC, for example, different compute resources or storage or database and other network infrastructure among others and this allows you to start building and deploying your solutions within the Cloud.

Now by default from a limitation perspective, you are allowed up to five VPCs per region per AWS account and it’s very simple to create a VPC. All you need to do is to give it a name, when you create your VPC and also define an IP address range that the VPC can use and this is done in the form of a CIDR block which stands for Classless Inter-Domain Routing.

So, at a high level, simply put, a VPC is an isolated segment of the AWS public cloud that allows you to provision and deploy resources in a safe and secure manner. Next I want to dive deeper into the VPC architecture and start talking about subnets and how you can segment your VPC out into different areas across multiple availability zones for resiliency and high availability.

Subnets

So now we know what a VPC is, let’s take a look at subnets. Now, subnets reside inside your VPC, and they allow you to segment your VPC infrastructure into multiple different networks. Now, you might want to do this to create better management for your resources, or to isolate certain resources from others, or even to create high-availability and resiliency within your infrastructure.

Firstly, then we’ll just draw our VPC quickly. So this is our VPC. And I mentioned when talking about VPCs that when you create your VPC, there’s two pieces of information that you need. You need to give it a name and also a CIDR block address. Now, the CIDR block address is a range of IP addresses. And this CIDR block range can have a subnet mask between a range of IP addresses from a /16 all the way through to a /28.

Now, for our example, let’s say we created our VPC with the following CIDR block. 10.0.0.0/16. Now, this is important because any subnets that we create within our VPC need to reside within this CIDR block range. So let’s take a look at a couple of subnets.

Public and Private Subnets

Now, in this section, I want to talk to you about public subnets and also private subnets. So let’s just create a public subnet and also a private subnet. The yellow one can be our public subnet and the green one can be our private subnet.

Now, similar to when we create a VPC, we need to give it a CIDR block range. We need to do the same with our subnets as well. So let’s say for example this is 10.0.1.0/24. Now, this range of addresses sits within this bigger CIDR block here, and then this private subnet can be 10.0.2.0/24. And again, this CIDR block sits within the bigger VPC CIDR block.

What makes a subnet public and what makes a subnet private?

Well, essentially a public subnet is accessible from outside of your VPC.

So essentially from the Internet. For any resources created within your public subnet, for example web servers, would be assessable from the Internet. Now, because we want these web service accessible from the Internet, I have two IP addresses. So they have their own internal IP address which will be within the range of the subnet, which, for this subnet, it’s 10.0.1.0/24. And then also we’re going to assign them a public IP address as well, because to be accessible from the Internet, the instance itself has to have a public IP address.

Any resources created within your private subnet, for example your backend databases, would be considered private and inaccessible by default from the Internet.

So how do you make a subnet public and how do you make one private?

When you create a subnet, you create them both exactly the same. It’s what you configure afterwards that will dictate if a subnet is public or private.

There’s two changes you need to make to your infrastructure to make a subnet public. The first is to add an Internet gateway. Now, an Internet gateway is a managed component by AWS that is attached to your VPC and acts as a gateway between your VPC and the outside world. So essentially the Internet.

So let’s just add in an Internet gateway here, IGW for Internet gateway. So now we have our Internet gateway attached to our VPC. And this Internet gateway then also connects out to the Internet. So we now have a bridge between our isolated VPC to the Internet by the Internet gateway which is managed by AWS.

Route table:

Now, you might think that a public subnet now has access to the Internet because there’s an Internet gateway. However, before the public subnet can access the Internet, we need to add a route to the public subnet’s route table.

The public subnet’s route table needs to have a route to the IGW

Now, associated with every subnet, when it’s created will also be an associated route table. Now, you can have the same route table associated to multiple subnets. That’s not a problem. However, you can’t associate more than one route table to a single subnet.

Need for a default route:

Now, by default, when your subnet’s created, it will have a default route in it, and this is a local route. Let’s take a look. Now, your route table will contain a destination field and also a target field. Now, the destination field is the destination address that you’re trying to get to. The target essentially specifies the route to that destination.

Now, within every route table that’s created, there will be this local route (underlined by blue). Now, what this enables your subnets to do is simply talk to each other. So any subnet within your VPC is able to communicate with each other without you having to configure any routes. It’s there by default. Every route table has this local route. It can’t be deleted, and it simply allows all subnets within your VPC to communicate with each other.

So what we need to do is we need to add a route to this route table that’s associated to the public subnet. Now, this new route here that’s been added to the route table has a destination of 0.0.0.0/0. Now, that essentially means that for any IP address that’s not known within the route table already, send it to this target. Now, this target is the Internet gateway as shown by the IGW followed by ID of the Internet gateway.

So by adding this route to the route table, this public subnet now knows exactly how to get to the Internet by going by the Internet gateway as shown in the route table. Now, those two components are essentially what makes a subnet public, the fact that we have an Internet gateway attached to the VPC and this subnet has a route pointing to the Internet gateway for any traffic that it doesn’t know how to get to.

What makes it a private subnet?

Now, if we compare the route table of the private subnet, we can see that it only has this local route, so it has no route to the Internet gateway. It’s not aware that an Internet gateway even exists, so it has no route out to the public Internet. So this is considered a private subnet. Now, if we go back to the public subnet, before we added this route here, so let’s just take that out.

This subnet is effectively a private subnet, because it doesn’t have a route to the Internet gateway. So with that in mind, every time you create a subnet, it is a private subnet to begin with and that is until you attach an Internet gateway to your VPC and then add this additional route.

Architecting for HA and Resilience

So now we’ve looked at public subnets and also private subnets. Let’s now look at architecting multiple subnets across your VPC for high availability and resilience.

So let’s consider we have three subnets this time. We’ll have a public subnet, and we’ll have two private subnets. The one in yellow can be our public subnet, and the remaining two will be our private subnets. Our public subnet will be our web layer. One of the private subnets be our application layer, and the other private subnet will be our database layer.

So in our public subnet, we will have some web servers. In our application layer, we’ll just have some EC2 instances. And in our database layer, we’ll just have some databases. So there we have our three tiers of our deployment. So as we know with any subnet, we have a local route, so each of these will all have a local, as you can’t remove that local route. And this enables all of these subnets to communicate with each other. The public subnet, as we know, will also have a route to the Internet gateway.

Create Subnets within an AZ

Now, when you create a subnet, you have to create it in one of the availability zones that are available within that region. Let’s say for example when we created the public subnet, we created it in availability zone one (AZ-1), and we’ve done the same for the remainder of our subnets as well, and placed them all in the same availability zone (AZ-1). And that’s all okay, we can deploy infrastructure all within the same availability zone and our solution would be operating fine.

However, should AWS have an issue with availability zone within this region, for example they might experience a flood or a fire or a natural disaster, and it took out the services to availability zone one, what would happen to our resources?

Well, effectively, these would also be taken down because they’re all running in availability zone one. So that’s not ideal. It’s not best practice to deploy all of your resources within the same availability zone, within a single region, simply because it doesn’t offer high-availability and resilience.

So what should you do in that situation?: Well, the best thing to do to ensure high-availability is to add additional subnets to allow for resiliency. So we’ll add an additional web tier and also additional application, and also a database.

So now we have six subnets, and again, we’d replicate our resources, so it’d have our web infrastructure in the public subnet, we’ll have our application service and our databases in the private subnets. Again, then we’ll have the routes and then Internet gateway route as well. All the subnets will have a local route, and as we know, this allows communication between all subnets. So now, every subnet can talk to every other subnet with a local route, and also the public subnet has a route to the Internet gateway as well. So now let’s look at the availability zones that we’ll deploy our infrastructure in this time. This is how it will look like:

Scenario 1: AZ-1 fails

Let’s imagine AZ-1 experienced a failure. So what would happen here? This public subnet would be out of action. This application subnet and that is it. So in this situation, we still have one subnet available in each layer of our infrastructure. So should we experience a failure with availability zone one, our services will remain up and running.

Scenario 2: AZ-2 fails

So let’s do the same with availability zone two. What would happen in this situation? Well, both of our public subnets would be okay, because everyone’s in AZ-1 and three. This application subnet would be down, and this database subnet would also be down. So again, at least one subnet in each of our layers is operational and available. So again, our services would still be up and running.

Scenario 3: AZ-3 fails

Now, finally, just for clarity, if we take down availability zone three, this web layer would go and also this database layer. So again, we still have at least one subnet in each tier or each layer of our infrastructure operational.

So this is a much better design. This allows you to ensure your resources stay up and running should a failure occur in one of the availability zones.

Subnet IP addressing

So I mentioned that when you create your subnet, you have to assign it a CIDR block range that fits within the VPC CIDR block. So say for example we created a subnet, and we give the subnet the address of 10.0.1.0/24. Now, with a slash 24 mask, this gives this subnet a total of 256 IP addresses. But you can only actually use 251 IP addresses. And I’ll explain why.

  • So the very first IP address in this subnet is 10.0.1.0 and this is known as the network address. Now, you’re not able to use this as an IP address to assign to your host addresses. This is reserved for networking.
  • Now, the next available IP address after the network address is 10.0.1.1. And this is reserved for AWS routing. So again, not a network address. You can’t use this address as a host network in your subnet.
  • Now, the next available IP address is 10.0.1.2. And again, this one is reserved by AWS, but this time for DNS. So you cannot use this IP address.
  • Now, the fourth IP address that you won’t be able to use in this subnet is 10.0.1.3. And this is actually reserved by AWS for future use.
  • Now, the fifth and final address that you can’t use in an AWS subnet is the last available address in the subnet. So in this case, it’d be 10.0.1.255, and the last address in any subnet is known as the broadcast address, and again, you cannot use this for host resources.

So when working with TCP/IP addresses within your subnet, first four addresses in any subnet are reserved and you cannot use for host addresses and also the very last address is reserved. So that’s why use only 251 IP addresses available to you that you can use to assign to your host resources.

Summary

So now we’ve covered what a VPC is. We’ve looked at subnets, both public and private, and also how it’s best to architect your subnets across multiple availability zones for high-availability.