What is the recommended CIDR when creating VPC on AWS?

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.

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.

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.

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

In case someone may find this question and would be interested in setting a CIDR-based specification of just a single ip address (such as if you are setting the RDP IP allowed in a new AWS stack), you would do that with the ip address and then /32 (which means "one ip address), so if your address were 66.12.34.567 you'd specify: 66.12.34.567/32

The recommended CIDR for VPC depends on requirement. The largest block size for VPC Ipv4 CIDR is a /16 netmask with 65,536 IP addresses and Smallest is a /28 netmask with 16 IP addresses.