Let me start by talking about what is meant by subnetting. Subnetting is the process of splitting a CIDR block into smaller CIDR blocks within the same range by using different subnet masks.
Subnetting enables you to create smaller networks using a smaller CIDR range from your larger network IP address space. For example let's say you had a CIDR block range of 10.0.0.0/16. Which as itself gives you the following network details.
This is a large IP range to have as a single network as it allows for up to 65,534 hosts. To make better use of this range and to create smaller networks allowing segmentation within your network you could subnet the CIDR block into smaller CIDR ranges using a different subnet mask, such as /17 for each subnet.
This would provide you with two different subnets with CIDR block ranges of 10.0.0.0/17 and black 10.0.128.0/17 providing the same range of host addresses minus the network and broadcast addresses for each subnet of course. You can see this by comparing the HostMin and HostMax entries between the three CIDR blocks.
Should you require more than just the two subnets which is likely than you can obviously split the original CIDR block further giving you more than just the two subnets I listed. For example, if I wanted 16 different subnets than I could subnet the CIDR block 10.0.0.0/16 by using a subnet mask of /20 for each subnet which would provide me with the following subnets.
Again this will provide the same range of host addresses minus the network and broadcast addresses for each subnet. Let's now look at how the subnetting relates to your AWS VPC. When you create a VPC you are required to enter your VPC CIDR block range. This CIDR block range will encompass the entire IP address space that you can use within that VPC.
So you need to be sure that you set the correct mask allowing you to subnet the RP space into different networks should it be required. Whilst at the same time ensuring there are enough host IP addresses for your instances available within each subnet. As a result consideration must be put to your VPC CIDR block.
At this point it's important to point out that the maximum and minimum masks for your VPC CIDR block are /16 to /28. A /16 can provide you with 65,531 usable host addresses as one single subnet. A /28 will provide you with just 11 host addresses as one single subnet. In addition to the network and broadcast address of the subnet which can't be used for host addresses AWS reserves the first three host IP addresses of each subnet for internal AWS usage.
The first host address used is for the VPC router. The second address is reserved for AWS DNS and the third address is reserved for future use. Let's look at this as an example. Sticking with the AWS VPC CIDR block of 10.0.0.0/16 let's imagine we want to create 16 subnets. We would use a /20 mask for each subnet as previously mentioned.
In this scenario one of the 16 subnets would be detailed as follows. For this subnet the AWS reservations would be reserved as 10.0.32.1. And this would be for the VPC router as this is the first host address available in the subnet. 10.0.32.2 would be for the AWS DNS being the second available address. And thirdly 10.0.32.3 which would be reserved for any future use service or feature that may be used by AWS.
Which means your available host addresses for any instances would be from 10.0.32.4 through to 10.0.47.254 giving you a total of 4,091 usable host addresses. When allocating your VPC CIDR block range for your VPC it is mandatory to specify an IPv4 range, but you also choose to associate an IPv6 range to your VPC as well.
However when selecting an IPv6 you are not able to specify the range yourself but AWS will provide a /56 IPv6 CIDR block for you from their pool of IPv6 addresses. Once you have allocated a CIDR block range for your VPC you are then ready to begin creating different subnets within your VPC. If you need help with your IP addressing and subnet calculations there are a number of free IP and subnet calculators available on the internet that will quickly help you define your requirements.
Creating multiple Subnets allows you to create logical network divisions between your resources. By doing so, you could have a Subnet for database instances, another for application servers, and another for web infrastructure.
By splitting up your Subnets this way, helps to enforce a greater level of security. Logical grouping of similar resources also helps you to maintain an ease of management across your infrastructure.
Think of these as Subnets. The space in your house, your CIDR block, has been divided into smaller more manageable purpose specific rooms rather than one large room in which you can cook, clean and sleep in, which would soon become very disjointed."
By having multiple Subnets with similar resources grouped together, as per the previous point, it allows for greater security management. By implementing network level virtual firewalls, called network access control lists, or NACLs, it's possible to filter traffic on specific ports from both an ingress and egress point at the Subnet level.
For example, if you had a Subnet that only held my SQL RTS databases within it, you could allow communication between your application service Subnet to talk to your database Subnet on port 1443 for my SQL. And then block and drop all other packets that do not meet this criteria. If you had web servers and application servers within the same Subnet as your RTS instances, you would have to open up a lot of other ports, reducing the level of security within that Subnet.
Having multiple Subnets allows you to create both private and public Subnets. Public Subnets allows the resources within it to access and connect to the internet, and the outside world to connect to those resources, depending on certain security controls. Private Subnets are not directly accessible from the internet. And so private Subnets are protected from the outside world, providing a greater level of security by its very nature.
You may want some of your Subnets to route out to the internet, some to remain private, and some to communicate back to your corporate on premise network over a VPN link. Through the use of routing tables associated to each specific Subnet, you can route traffic as required to cater for these communication paths.
A Subnet can only belong to one route table at any time. Therefore, by creating multiple Subnets, you can restrict some resources in those Subnets to specific routes. If your solution requires a level of high availability, and it most likely will, then it's best practice to deploy services across multiple availability zones within a region.
Here becomes a restriction of VPC Subnets in that a single Subnet cannot span across two availability zones. As a result, this best practice forces you to create an additional Subnet in the second availability zone. So if you want high availability within your environment, you'll need Subnets in at least two availability zones in any region.
As you can see, there are many advantages over creating multiple Subnets within your VPC. And as you design, architect and secure your infrastructure, you will quickly see how multiple Subnets enables ease of network management, rooting and security.
Top comments (0)