the number “2” in the call, "cidr_block = “${cidrsubnet(aws_vpc.environment-example-two.cidr_block, 2, 2)}” is supposed to add bits to the CIDR block of the VPC, but “2” doesn’t make sense to me, because the VPC has a CIDR range of 10.0.0.0/16, and the subnet CIDR block ends up 10.0.0.0/24 … this is defiantly more than 2 bits of additional network.
I am wondering if AWS is taking that argument, and interpreting it as IT wants to, for some reason.
newbits is the number of additional bits with which to extend the prefix. For example, if given a prefix ending in /16 and a newbits value of 4, the resulting subnet address will have length /20.
see the 2 is “newbits” in the line from the man page, or user guide /16 + 4 newbits == 20. In the above example /16 + 2 != /24
Hi @rhino007US,
In terraform console I evaluated the following expression:
cidrsubnet("10.0.0.0/16", 2, 2)
This produced the result I expected: 10.0.128.0/18.
This suggests to me that the issue in your case is that aws_vpc.environment-example-two.cidr_block is different than you expected. In the terraform plan output, can you see what value Terraform is reporting for cidr_block inside the resource "aws_vpc" "environment-example-two" block?
The other strange thing about the behavior you are seeing is that you said you are passing a network number of 2, but you reported that the result was 10.0.0.0/24. Even if that had the expected prefix length, 10.0.0.0/18, that is still incorrect because it includes network number zero rather than network number 2.
Unfortunately I can’t offer any further ideas without seeing some real examples from your configuration to see how things are connected. It seems like something unusual is happening here but I can’t tell what that is from the information you’ve shared so far.