AWS VPC Resource Usage and Specifications

NYU VPC Resource Usage and Specifications VPCs primarily allow for grouping of services within AWS for various use cases, such as: common service classification, auditing, routine operations, administrative access control, and billing. The use of AWS features such as IAM (Identity and Access Management) and resource tagging facilitate regulating access to a VPC and identification […]

NYU VPC Resource Usage and Specifications

VPCs primarily allow for grouping of services within AWS for various use cases, such as: common service classification, auditing, routine operations, administrative access control, and billing. The use of AWS features such as IAM (Identity and Access Management) and resource tagging facilitate regulating access to a VPC and identification of its resources, respectively.  It should be noted that VPCs are not a security boundary; that is the role of Security Groups, NACLs or perimeter firewalls. When used for common classification of services, VPCs can be built to host the compute resources of an individual school or department, or to group services having a particular common compliance requirement such as PCI or HIPAA.

AWS recommends the allocation of a /16 IPv4 CIDR Block per VPC, dividing that block equally among the Availability Zones (AZs) used by the VPC.  (All IPv4 addresses used internally within a VPC are RFC1918 Private IP Addresses.) As AWS’ recommendation is to use three AZs within a Region, and as a /16 is equally divisible by four, they also recommend dividing the /16 CIDR block into four equal /18 sub-blocks: one for use within each of the three AZs and the fourth /18 held in reserve as a spare for future VPC growth.  That /18, in turn, is split in half per-AZ: one /19 to be used for Private Subnets (subnets which cannot access the Internet) and the other /19 used for Public Subnets (subnets which can access the Internet) within each AZ. This yields a total of 8,192 public and 8,192 private IP addresses available within each AZ. IP subnets of a variety of sizes for hosting EC2 instances can then be chosen from these /19s, including: 2x /20s, 4x /21s, 8x /22s, 16x /23s, 32x /24s, or some combination thereof.

Diagrammatically, this IP allocation plan has the following appearance for use within the us-east-1 Region, when selecting the Availability Zones us-east-1a, us-east-1b, and us-east-1c.  The choice of Region and Availability Zones does not alter the IP allocation scheme.

Figure 1: VPC Example Region

VPC Example Region: AWS recommends the allocation of a /16 IPv4 CIDR Block per VPC, dividing that block equally among the Availability Zones (AZs) used by the VPC. (All IPv4 addresses used internally within a VPC are RFC1918 Private IP Addresses.) As AWS’ recommendation is to use three AZs within a Region, and as a /16 is equally divisible by four, they also recommend dividing the /16 CIDR block into four equal /18 sub-blocks: one for use within each of the three AZs and the fourth /18 held in reserve as a spare for future VPC growth. That /18, in turn, is split in half per-AZ: one /19 to be used for Private Subnets (subnets which cannot access the Internet) and the other /19 used for Public Subnets (subnets which can access the Internet) within each AZ. This yields a total of 8,192 public and 8,192 private IP addresses available within each AZ. IP subnets of a variety of sizes for hosting EC2 instances can then be chosen from these /19s, including: 2x /20s, 4x /21s, 8x /22s, 16x /23s, 32x /24s, or some combination thereof.
VPC Example Region

EC2 subnets can be arbitrarily large or small.  The physical network constraints about subnet scaling such as multicast or broadcast traffic or router interface throughput do not apply in AWS.  Our AWS Account Team recommends against sizing subnets too small (down to an individual application) because the quantity of subnets could lead to exceeding VPC limits.