What is the recommended CIDR when creating VPC on AWS?

Solution 1:

I would recommend the following considerations:

If you creating an IPSEC connection between your corporate LAN and your VPC, use a CIDR that is different than that on your corporate LAN. This will prevent routing overlaps and create an identity distinction for reference.

For very large networks, use at least different 16-bit masks in different regions eg

eu-west-1 10.1.0.0/16
us-east-1 10.2.0.0/16
us-west-1 10.3.0.0/16

For smaller networks, use a 24-bit mask in different regions eg

eu-west-1 10.0.1.0/24
us-east-1 10.0.2.0/24
us-west-1 10.0.3.0/24

Consider making a distinction between private and public subnets, eg

private 10.0.1.0/24 (3rd byte < 129)
public 10.0.129.0/24 (3rd byte > 128)

Don't over-allocate address space to subnets, eg

eu-west-1 10.0.1.0/26
eu-west-1 10.0.1.64/26
eu-west-1 10.0.1.128/26
eu-west-1 10.0.1.192/26

(62 hosts per subnet)

Don't under-allocate either. If you use a load of Elastic Load Balancers, remember that they will also consume available ip addresses on your subnets. This is a particularly true if you use ElasticBeanstalk.

Solution 2:

Some things I considered the last time I created a new VPC:

1. Make sure the IP ranges from different regions don't overlap. You shouldn't have a 172.31.0.0/16 in us-west eu-ireland, for example. It will make VPN between those two regions a problem requiring double-NAT to solve. No thanks.
2. Make sure the IP range is large enough to hold all the instances you think you'll need x.x.x.x/24 will accommodate 254 different addresses. There are probably hundreds of CIDR calculators out there to help you figure this out.
3. I create a lot of different subnets in a single VPC, rather than creating multiple VPCs. The subnets can talk to each other - I can have private vs. public subnets to keeps some instances shielded from the open internet. Use a NAT instance so that the private subnet can talk to the public subnet. Use security groups to isolate groups of instances from one another.

---

Solution 3:

Amazon doesn't appear to recommend any particular network size for your VPC (see the VPC network administrator's guide and note the use of /16s), but in general there are two reasons to consider the performance effects of CIDR:

1. Routing. A smaller prefix (larger network) is frequently used for route aggregation and can actually improve performance.
2. Broadcast and multicast traffic, which is more relevant to your situation and can result in decreased performance on smaller prefixes. You can mitigate the effects of this traffic by further subnetting the VPC as shown in the network admin guide.

Consider the initial number of nodes in your VPC and projected growth for the anticipated project lifetime and you should have a good starting point for prefix size. Remember that there is no harm in starting with a small prefix such as /16 because you can always create subnets.