40

I have been creating AWS VPCs and I am wondering if there is a recommended CIDR value when creating VPCs. What are the factors that I must consider when choosing a CIDR and does the CIDR value affect the performance of the network?

34

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.

8

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.
2

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.

  • 1
    I just want to point out for future readers that AWS VPC does not support broadcast or multicast, so the second bullet point isn't relevant. aws.amazon.com/vpc/faqs – jready Sep 30 '18 at 19:32
1

Another consideration is whether you will need to use AWS ClassicLink to allow access to the VPC from EC2 instances outside of the VPC. From the AWS documentation:

VPCs with routes that conflict with the EC2-Classic private IP address range of 10/8 cannot be enabled for ClassicLink. This does not include VPCs with 10.0.0.0/16 and 10.1.0.0/16 IP address ranges that already have local routes in their route tables. For more information, see Routing for ClassicLink.

from http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/vpc-classiclink.html#classiclink-routing

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.