Terraform cidrsubnet Calculator

Resolve cidrsubnet, cidrhost and cidrnetmask to exact addresses, with the overlaps and the out-of-range arguments named before plan finds them.

Paste below, or drop a file anywhere on this panel

Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.

The answer appears here

Paste on the left and press Calculate. Nothing leaves this tab.

Examples

Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.

newbits read as the target prefix

16 plus 24 is 40, so the plan fails and the error is about the extension rather than the argument

cidrsubnet("10.0.0.0/16", 24, 1)

A netnum past the end

Two newbits gives four subnets, so netnum 4 does not exist

cidrsubnet("10.0.0.0/16", 2, 4)

Two calls that overlap

Different newbits off one prefix, so netnum means a different step in each

cidrsubnet("10.0.0.0/16", 8, 1)
cidrsubnet("10.0.0.0/16", 4, 0)

Common mistakes

These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.

  1. Passing the wanted prefix length as newbits

    newbits is added to the prefix you gave. From a /16, newbits 24 asks for a /40 and the error is about the extension being too large rather than about the argument meaning.

    Instead:Subtract: for a /24 out of a /16, newbits is 8.

  2. Using different newbits for subnets off the same prefix

    netnum steps by a different size for each newbits value, so two calls that look unrelated produce overlapping ranges and the create fails.

    Instead:Pick one newbits for the whole prefix and give each subnet a distinct netnum.

  3. Sizing subnets from the RFC address count

    AWS reserves five addresses in every subnet regardless of size, so a /28 gives 11 usable rather than 16.

    Instead:Subtract five when planning, and remember /28 is the smallest subnet AWS will create.

The second argument is how many bits to add, not the prefix you want

cidrsubnet(prefix, newbits, netnum). Almost every problem with this function comes from reading newbits as the target prefix length, and the resulting error does not say so.

newbits is relative

Asking for a /24 out of a /16 means newbits 8, because 16 + 8 is 24. Writing newbits 24 asks for a /40, and Terraform errors about a prefix extension being too large, which is accurate and does not mention that the argument means something else.

netnum is bounded by newbits

newbits 8 gives 256 subnets, numbered 0 to 255. This fails when a list of availability zones or a count grows past what the newbits allow, so a configuration that worked for months breaks when somebody adds a region, and the error is about the netnum rather than about the list.

Mixing newbits against one prefix produces overlaps

cidrsubnet(prefix, 8, 1) and cidrsubnet(prefix, 4, 0) both come off the same /16 and both cover 10.0.1.0. Because netnum means a differently sized step for each, two calls that look independent collide, and AWS rejects the second subnet at create time.

AWS reserves five addresses in every subnet

The network address, the VPC router, the DNS server, one reserved for future use, and the broadcast address. So a /24 has 251 usable, not 254, and a /28, which is the smallest AWS accepts, has 11. Capacity planning that assumes the RFC numbers comes out short.

Host bits below the prefix are ignored

10.0.5.0/16 is treated as 10.0.0.0/16, so the calculation is correct on a network that is not the one written down. Nothing errors, and the subnets come out where the /16 says rather than where the typed address suggests.

cidrhost takes an index, and a negative one counts back

cidrhost("10.0.1.0/24", 5) is 10.0.1.5. Minus one is 10.0.1.255, which is how the broadcast address gets written. Either way it is bounded by the size of the prefix and errors rather than wrapping.