Configuring subnets and VPCs can be confusing when you’re setting up AWS infrastructure. There’s plenty of documentation about what subnets are, and how to create them, but not necessarily when and why you’d create them. In this article you’ll learn why you’d want to create multiple subnets in the first place.

First off though, here’s a quick recap of all the network related infrastructure that lives in a VPC. If you’re familiar with this, just skip to the main section of the article.

What are subnets?

A subnet, or sub-network, is the result of splitting up an IP network by IP address.

An IP address, of course, consists of 4 numbers between 0 and 255, such as:

255.255.255.255

This allows up to 4,294,967,296 different addresses, at least with IPv4, which is what we’re concentrating on in this article. Since an IP address consists of 32 bits, you can also think of this as 2^32, which represents the same number.

When a network is split into subnets, each subnet is given its own range of IP addresses (or IPs) to use. Each IP in the subnet will have the same subnet prefix, and each IP in the network will have the same network prefix.

As an example, we could be working in a network that has a network identifier of 10.0. This network could have been split into a subnet with identifier 10.0.1. Within that subnet, then, we can use the IP range from 10.0.1.0 to 10.0.1.255 to assign to any host.

CIDR blocks

Typically though, rather than talking about networking identifiers or prefixes, we talk in terms of Classless Inter-Domain Routing (CIDR) blocks, or just CIDRs. This is just a way to express a range of IP addresses with a common prefix.

It consists of the first address in a network, followed by a slash, then the number of bits that make up the prefix. For example:

10.0.1.0/24

This CIDR block represents the range of IPs from 10.0.1.0 to 10.0.1.255, or 256 different IPs. The /24 signifies that the first 24 bits form the prefix.

This is easier to understand, if you remember that each section of the IP address (between the dots) represents 8 bits. Hence /24 represents the first 3 (24 / 8) sections of the IP address.

Here are some more examples:

  • 10.0.0.0/8 represents the IP range from 10.0.0.0 to 10.255.255.255

  • 192.168.0.0/16 represents the IP range from 192.168.0.0 to 192.168.255.255

Why use CIDR blocks?

The CIDR block notation starts making more sense when we talk about subnets. After all, as mentioned earlier, a subnet consists of a range of IPs with a common network prefix.

The diagram below shows how we have a network with a given range of IPs, and within that network have 2 separate subnets. Each of these components has been assigned a specific CIDR block, the CIDR block of the subnets falling within the CIDR block of the overall network.

Note that in a private network, the RFC 1918 standard allows us to use IP ranges from the following three CIDR blocks:

  • 10.0.0.0/8

  • 172.16.0.0/12

  • 192.168.0.0/16

Networks and subnets in AWS

VPCs

In AWS a Virtual Private Cloud (VPC) is a cloud network into which you can deploy resources, where your have complete control over the network environment.

When you create a VPC you have to assign a CIDR block to define the IP address range and how many addresses will be available. You can select a block size from /16 ( 65,536 IPs) to /28 (16 IPs).

Subnets

The subnet must use a CIDR block that falls within that of the VPC it’s assigned to. Once again you can use a block size from /16 to /28.

The subnet can span the entire IP range of the VPC, as below:

Alternatively, we could split the range of IP addresses in the VPC into multiple subnets, as below:

In the above scenario we’re not using the full IP range of the VPC, allowing ourselves the space to create more subnets in future (e.g. for 10.0.2.0/24). ✅

What situations warrant a different subnet?

Now that you have a good understanding of the fundamentals of networking, IP addresses, CIDR blocks, and VPCs, let’s dig into the scenarios in which you might want to consider using separate subnets in your AWS VPC.

1. Deploying to different AWS availability zones

An availability zone is a geographically and operationally separate AWS data centre within the same AWS region. This means that if one availability zone goes down there will be another available to take over.

To achieve high availability it’s always recommended to deploy services to at least two availability zones.

In AWS, though, a subnet can only span one availability zone. This means that to achieve high availability you must deploy services to multiple subnets.

Consider the example below, where we have a VPC in eu-west-1. In order to deploy services into multiple availability zones we can create two subnets, one in eu-west-1a and the other in eu-west-1b.

2. Securing your AWS resources within a private subnet

A private subnet is a subnet that doesn’t have a route to the internet, whereas a public subnet does. This can be useful to provide an additional layer of security for services that don’t need public access, such as databases or backend microservices.

Internet gateways and route tables

To provide internet access to a subnet we need an AWS Internet Gateway. A subnet can then be attached to a route table which contains a route to that internet gateway. That subnet then becomes a public subnet.

If, on the other hand, another subnet is attached to a route table that doesn’t contain a route via the internet gateway, it’s a private subnet.

This setup is shown in the diagram below:

Note that we have:

  • an EC2 instance in a public subnet with a route to the internet. It must also have a public IP, which you can set when you create the instance.

  • an EC2 instance in a private subnet without a route to the internet. It’s route table still has a target of local, meaning it can communicate with other EC2 instances in the VPC.

  • a router, which uses the route table to route traffic within our VPC. Note that the router is implicit i.e. it’s not actually a resource we can see in AWS, but we get one automatically with a VPC.

3. Using AWS Elastic Load Balancers

Elastic Load Balancers come in two flavours:

  • Network Load Balancers

  • Application Load Balancer

If you want to use the Application Load Balancer, which is a layer 7 HTTP load balancer, you’ll need to configure at least two subnets. Or more specifically, you need to specify subnets from at least two availability zones.

AWS don’t provide any clear reason why this is, and the Network Load Balancer doesn’t have such a constraint. It’s probably a good thing though, as it forces us to consider high availability of whatever services are being exposed by the load balancer.

Resources

AWS AWS provide some excellent documentation, and I would recommend in particular: