AWS VPC Subnet Guide

Why VPC CIDR Planning Matters

The CIDR block you choose for your VPC is one of the first architectural decisions you make in AWS, and one of the hardest to change later. Once a VPC is created with a primary CIDR, you cannot modify it -- you can only add secondary CIDRs. If you run out of addresses, the fix often involves creating a new VPC and migrating workloads, which is exactly as painful as it sounds.

Good CIDR planning prevents three problems: IP address exhaustion (running out of addresses within a VPC), routing conflicts (overlapping CIDRs between VPCs that need to communicate), and subnet fragmentation (address space that is allocated but unusable because subnets were sized inconsistently).

Choosing Your VPC CIDR Block

AWS VPCs must use RFC 1918 private IP ranges. The three options are:

The 10.x.x.x Range: The Enterprise Standard

Most organizations use the 10.0.0.0/8 range for VPCs because it provides the largest address space and the most flexibility. A common pattern is to allocate a /16 to each VPC (e.g., 10.0.0.0/16, 10.1.0.0/16, 10.2.0.0/16), which gives you up to 256 VPCs with 65,534 usable hosts each. This is enough for most architectures.

Avoid 172.31.0.0/16

AWS creates a default VPC in every region using the 172.31.0.0/16 range. If you are building production infrastructure, avoid this range to prevent conflicts with the default VPC. Many organizations delete the default VPC entirely to keep their address space clean.

VPC CIDR Sizing Rules

AWS enforces specific CIDR constraints:

• The primary VPC CIDR must be between /16 and /28.
• You can add up to 4 secondary CIDRs to expand a VPC.
• Secondary CIDRs cannot overlap with the primary or with each other.
• AWS reserves 5 IP addresses in each subnet: the first four and the last one.

That last point is important: AWS reserves more addresses than standard networking. In a /24 subnet (256 addresses), AWS gives you 251 usable hosts, not the usual 254. In a /28 (the minimum subnet size), you get only 11 usable hosts out of 16 total.

The 3-Tier Architecture Pattern

The most common VPC design separates workloads into three tiers, each in its own set of subnets:

VPC: 10.0.0.0/16 (65,536 addresses)
|
+-- Public Subnets (Internet-facing)
|   +-- 10.0.0.0/24   (AZ-a)  -- ALBs, NAT gateways, bastion hosts
|   +-- 10.0.1.0/24   (AZ-b)
|   +-- 10.0.2.0/24   (AZ-c)
|
+-- Private Subnets (Application tier)
|   +-- 10.0.16.0/20  (AZ-a)  -- ECS tasks, EC2 instances, Lambda
|   +-- 10.0.32.0/20  (AZ-b)
|   +-- 10.0.48.0/20  (AZ-c)
|
+-- Data Subnets (Database tier)
    +-- 10.0.64.0/24  (AZ-a)  -- RDS, ElastiCache, OpenSearch
    +-- 10.0.65.0/24  (AZ-b)
    +-- 10.0.66.0/24  (AZ-c)

Public Subnets

Public subnets have a route to an Internet Gateway and are for resources that need direct internet access: Application Load Balancers, NAT Gateways, and bastion hosts. These subnets are typically small (/24 is sufficient) because they hold relatively few resources. The key requirement is that every public subnet must have a route table entry pointing 0.0.0.0/0 to the Internet Gateway.

Private Subnets

Private subnets hold your application workloads -- ECS tasks, EC2 instances, Lambda functions in VPC mode. These are the largest subnets in the VPC because they host the most resources. A /20 provides 4,091 usable hosts (after AWS reservations), which is generous for most workloads. Outbound internet access goes through NAT Gateways in the public subnets.

Data Subnets

Data subnets are the most restricted tier. They have no route to the internet (not even through a NAT Gateway) and are accessible only from the private subnets. RDS instances, ElastiCache clusters, and OpenSearch domains live here. These subnets are typically small (/24) because managed services use fewer IP addresses.

Multi-AZ Subnet Strategy

AWS best practice is to deploy across at least 2 availability zones, with 3 being the recommended standard for production workloads. This means every tier needs multiple subnets -- one per AZ. The math is straightforward:

• 3 tiers x 3 AZs = 9 subnets for a standard production VPC
• 3 tiers x 2 AZs = 6 subnets for a cost-optimized setup

When planning addresses across AZs, use consistent sizing. If your private subnets are /20 in AZ-a, make them /20 in AZ-b and AZ-c as well. Inconsistent sizing makes troubleshooting harder and wastes the mental model advantage of a structured layout.

Common Sizing Patterns

Small Application (/21 VPC)

For a small application or development environment, a /21 VPC (2,048 addresses) is sufficient. Use /24 for each tier across 2 AZs: 6 subnets of 256 addresses each, consuming 1,536 addresses with 512 left for future use. This works well for startups and individual projects.

Standard Production (/16 VPC)

The most common production pattern. A /16 gives you 65,536 addresses -- enough for the 3-tier layout shown above with plenty of room for future expansion. You can add subnets for VPN connections, AWS Transit Gateway attachments, or new application tiers without re-architecting.

Large Enterprise (/16 VPC per Environment)

Enterprise organizations typically create separate VPCs for each environment (dev, staging, production) and sometimes per team or product line. Each gets its own /16, and they communicate through VPC peering or Transit Gateway. The 10.0.0.0/8 range supports up to 256 of these /16 VPCs.

Avoiding Common Mistakes

• Starting too small: A /24 VPC (254 addresses) fills up fast when you add multiple subnets across AZs. Always start with at least a /20 for production, preferably a /16.
• Overlapping CIDRs: If VPCs need to communicate via peering or Transit Gateway, their CIDRs must not overlap. Maintain a central CIDR registry. Use our overlap detection tool to check before deploying.
• Forgetting AWS reservations: AWS reserves 5 IPs per subnet, not 2. A /28 gives you 11 usable hosts, not 14. Plan for this when sizing small subnets.
• Non-contiguous allocations: Allocate subnets in contiguous blocks (10.0.0.0/24, 10.0.1.0/24, 10.0.2.0/24) rather than scattered addresses. This makes route table management simpler and enables supernetting for route aggregation.

Infrastructure as Code

Never create VPCs and subnets manually through the AWS Console. Use Terraform, CloudFormation, or CDK to define your network infrastructure as code. This ensures repeatability across environments and regions, and it creates documentation that stays in sync with reality.

Our Subnet Calculator includes a VPC Planner tab that generates Terraform and CloudFormation snippets for common VPC patterns. Choose a template, customize the CIDR, and export the code directly into your IaC repository.

Planning Checklist

Before creating a new VPC, walk through these questions:

• What is the maximum number of hosts you expect in each tier over the next 2-3 years?
• How many availability zones will you deploy across?
• Does this VPC need to peer with other VPCs or connect to on-premises networks? If so, do the CIDRs overlap?
• Are you using any AWS services that require their own subnets (e.g., EKS pod networking, AWS Managed Blockchain)?
• Have you accounted for the 5 reserved IPs per subnet in your sizing calculations?