How do I decide the CIDR blocks for public and private subnets and VPC?

Question

I would like to create a VPC in AWS with a private subnet and a public subnet. I am using Terraform.

Here is what I have so far:

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16" # <---

  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = {
    Name = "Main"
  }
}

resource "aws_subnet" "public" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.0.0/20" # <---

  tags = {
    Name = "Public"
  }
}

resource "aws_subnet" "private" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.16.0/20" # <---

  tags = {
    Name = "Private"
  }
}

The problem I am having is that I don't know how to choose appropriate CIDR blocks (3 to decide).

How do I determine what CIDR blocks to use?

---

A working combo might be:

• VPC: 10.16.0.0/16
• Public: 10.16.0.0/24
• Private: 10.16.128.0/24

Answer 1

Firstly there is nothing wrong with what you have done, each of the /20 subnets has half of the available IPs in the /16 VPC (4096 each less the 5 AWS reserved IPs).

In terms of how you decide, well this is a classic network design question that has been around for decades. An Internet search for "IP address range design best practice" will trawl-up several articles that might help.

Specifically for the AWS cloud then a few pointers:

• /16 and /20 are quite large subnets and unless you really expect to consume that many IPs I'd be tempted to make them smaller; you can add a 2nd CIDR to a VPC later on if necessary: link.
• When it comes to multiple VPC environments, then if you want to peer the VPCs so they can route traffic to each other then they can't have overlapping CIDRs; so that is another reason for not making the VPC CIDRs larger than they need to be so you don't run out of IPs by having VPCs with large unused CIDRs.
• The no overlapping IP address point also applies if you have a hybrid cloud environment where on premise and AWS resources are a part of the same network.
• A little trick of mine is to use 10.0.0.0/8 for production VPCs, 172.16.0.0/12 for Test, and 192.168.0.0/16 for development. That helps me remember what environment I'm dealing with.