Understanding cidrsubnets Subnet Allocation in Terraform

When working with subnetting, especially using Terraform's cidrsubnets function, understanding how bits are allocated and how subnets interact is crucial. This guide will walk you through the process of calculating subnet sizes, ensuring no overlaps, and optimizing your allocation.


The Basics of Subnetting

let's jump into it as the best way to understand it is to test it.
Key Concepts

subnets = cidrsubnets(local.cidr,

    2, 2, 2,

    6, 6, 6,

    8, 8, 8,

    8, 8, 8,

  )

Explanation of Subnet Allocation

Starting with 10.0.0.0/16, this block provides a total of 65,536 IP addresses (2^16). The /16 means the first 16 bits are reserved for the network, leaving 16 bits for hosts or further subnetting.

Here is how the cidrsubnets function divides the space:

  1. 2, 2, 2:

    • Each 2 represents allocating 2 additional bits, creating /18 subnets.

    • A /18 has 2^(16-18) = 2^2 = 4 subnets.

    • Reserved ranges:

      • 10.0.0.0/18: 00001010.00000000.00000000.00000000

      • 10.0.64.0/18: 00001010.00000000.01000000.00000000

      • 10.0.128.0/18: 00001010.00000000.10000000.00000000

      • 10.0.192.0/18: 00001010.00000000.11000000.00000000

    • In AWS, we typically have 3 Availability Zones (AZs), so we allocate 3 subnets per AZ. After allocating 2, 2, 2, the last subnet leaves the range 11000000 as the third octet in binary, which corresponds to 10.0.192.0/18.

    • Each 2 represents allocating 2 additional bits, creating /18 subnets.

    • A /18 has 2^(16-18) = 2^2 = 4 subnets.

  2. Using Remaining Bits:

    • Without allocating 4, 4, 4, the unused 11XX0000 provides flexibility to create more subnets. For example:

      • Additional 6, 6, 6 allocations can use these bits to split into /22 subnets.

      • The remaining 2 bits allow for more /22 or /24 subnets, ensuring efficient usage of the space. this will be explained in the 6, 6, 6 and 8, 8, 8

  3. 6, 6, 6:

    • Each 6 represents allocating 6 additional bits, creating /22 subnets.

    • Reserved ranges:

      • 10.0.192.0/22: 00001010.00000000.11000000.00000000

      • 10.0.196.0/22: 00001010.00000000.11000100.00000000

      • 10.0.200.0/22: 00001010.00000000.11001000.00000000

      • 10.0.204.0/22: 00001010.00000000.11001100.00000000

    • again in aws we will use only 3 and the last one will be for the lower subnets.

    • however we can also create more /22 subnets and this is because we can make use of the bits number 18 and 19 since there was no /20 subnets so the 2 bits are free to use. so we can use them to generate more /22 subnets and that can be 2^4 permutation.

    • but we need to be careful cause we need to leave at least 1 subnets range for the lower ranges

  4. 8, 8, 8, 8, 8, 8:

    • Each 8 represents allocating 8 additional bits, creating /24 subnets.

    • Reserved ranges:

      • 10.0.204.0/24: 00001010.00000000.11001100.00000000

      • 10.0.205.0/24: 00001010.00000000.11001101.00000000

      • 10.0.206.0/24: 00001010.00000000.11001110.00000000

      • 10.0.207.0/24: 00001010.00000000.11001111.00000000

    • A /24 has 2^(16-24) = 2^8 = 256 IP addresses per subnet.

    • Each 8 represents allocating 8 additional bits, creating /24 subnets.

    • A /24 has 2^(16-24) = 2^8 = 256 IP addresses per subnet.

    • so it we have more subnets left from the previous subnets then we will have available subnets for more /24 subnets

Summary

Choosing a /16 CIDR block for our private VPC, such as 10.0.0.0/16, provides a large number of potential subnets. Specifically, it allows for 256 smaller VPCs, which is often more than sufficient for most AWS accounts. This setup is ideal for accounts hosting multiple websites and a small number of databases, ensuring plenty of IP addresses and subnets for flexibility.

If fewer VPCs are needed, or if there is no intention to interconnect these VPCs, the subnet size can be reduced to allocate more IPs and subnets within a smaller range. However, in most cases, a /16 block provides the right balance for scalability and simplicity in AWS environments.