Cloud VPC Subnet Design Patterns

Why Cloud Subnetting Differs from On-Premises

In a traditional data centre, subnetting mistakes are expensive to fix — you may need to renumber servers, update firewall rules, and reconfigure routing. In cloud environments, the stakes are even higher because VPCs may need to peer with partners, connect to on-premises networks via VPN or Direct Connect, and scale to accommodate services not yet imagined at design time.

Cloud VPC design has a few unique constraints:

• Reserved addresses per subnet: Each cloud provider reserves several IP addresses within every subnet
• Immutable CIDR (partially): You cannot change the primary CIDR of a subnet after creation (though you can add secondary CIDRs in AWS)
• Peering overlap restriction: Two VPCs with overlapping CIDRs cannot be peered
• Future expansion: Cloud networks often grow faster than planned; always leave room

Foundational CIDR Planning Principles

Before choosing any specific ranges, establish these principles:

1. Use RFC 1918 Private Space

Stick to these three ranges for all cloud VPC addressing:

10.0.0.0/8      — 16,777,216 addresses (recommended for large deployments)
172.16.0.0/12   — 1,048,576 addresses
192.168.0.0/16  — 65,536 addresses

The 10.0.0.0/8 range is the best choice for cloud environments because it provides the most room and is least likely to conflict with partner networks.

2. Allocate VPC CIDRs from a Master Plan

Maintain a central IP address management (IPAM) plan — even a spreadsheet — that records every VPC CIDR across all accounts, regions, and cloud providers. Before creating any new VPC, check the plan for conflicts.

# Example master IPAM plan
10.0.0.0/8 ← Total pool

  10.0.0.0/12  ← AWS us-east-1 (Production)
  10.16.0.0/12 ← AWS us-east-1 (Development)
  10.32.0.0/12 ← AWS us-west-2 (Production)
  10.48.0.0/12 ← AWS eu-west-1 (Production)
  10.64.0.0/12 ← GCP us-central1 (Production)
  10.80.0.0/12 ← Azure East US (Production)
  10.96.0.0/12 ← On-premises (Corporate)
  10.112.0.0/12 ← Reserved for future

3. Never Use 172.31.0.0/16

AWS uses 172.31.0.0/16 as the default VPC CIDR. If you use it for your custom VPCs too, you will eventually have conflicts with default VPCs in other accounts. Avoid it entirely.

AWS VPC Subnet Design

Reserved Addresses per AWS Subnet

AWS reserves 5 IP addresses in every subnet:

A /24 subnet has 256 addresses but only 251 usable. A /28 has 16 addresses but only 11 usable. For very small subnets, the 5-address overhead is significant.

Three-Tier Subnet Architecture

The industry-standard pattern for AWS VPC design separates resources into three tiers across multiple Availability Zones:

VPC: 10.0.0.0/16

┌─────────────────┬──────────────────┬─────────────────┐
│    AZ-1 (a)     │    AZ-2 (b)      │    AZ-3 (c)     │
├─────────────────┼──────────────────┼─────────────────┤
│ Public:         │ Public:          │ Public:         │
│ 10.0.1.0/24     │ 10.0.2.0/24      │ 10.0.3.0/24     │
│ (251 IPs)       │ (251 IPs)        │ (251 IPs)       │
├─────────────────┼──────────────────┼─────────────────┤
│ Private App:    │ Private App:     │ Private App:    │
│ 10.0.11.0/24    │ 10.0.12.0/24     │ 10.0.13.0/24    │
│ (251 IPs)       │ (251 IPs)        │ (251 IPs)       │
├─────────────────┼──────────────────┼─────────────────┤
│ Private Data:   │ Private Data:    │ Private Data:   │
│ 10.0.21.0/24    │ 10.0.22.0/24     │ 10.0.23.0/24    │
│ (251 IPs)       │ (251 IPs)        │ (251 IPs)       │
└─────────────────┴──────────────────┴─────────────────┘

Route Table Configuration

Public subnets have a route to an Internet Gateway:

0.0.0.0/0 → igw-xxxxxxxx

Private App subnets route internet traffic through NAT Gateway (in public subnet):

0.0.0.0/0 → nat-xxxxxxxx (NAT Gateway in AZ-1 public subnet)

Private Data subnets typically have no internet route — they only communicate with the app tier within the VPC.

Sizing Recommendation

For most applications, start with /24 subnets (251 usable IPs). If you are running Kubernetes or EKS with many pods per node, consider /22 subnets (1,019 usable IPs) for the private app tier.

# EKS-focused design: larger private subnets
Public:       10.0.1.0/24,  10.0.2.0/24,  10.0.3.0/24   (251 each)
Private App:  10.0.4.0/22,  10.0.8.0/22,  10.0.12.0/22  (1019 each)
Private Data: 10.0.16.0/24, 10.0.17.0/24, 10.0.18.0/24  (251 each)

VPC Peering and CIDR Planning

VPC peering allows two VPCs to route traffic between each other using private IP addresses. The critical constraint: peered VPCs cannot have overlapping CIDRs.

Planning for Future Peering

When you design your first VPC, you do not know which future VPCs you will need to peer with. The solution is to allocate VPC CIDRs from non-overlapping blocks upfront:

# Environment segregation with non-overlapping /16 blocks
Production:   10.0.0.0/16   (10.0.0.0 – 10.0.255.255)
Staging:      10.1.0.0/16   (10.1.0.0 – 10.1.255.255)
Development:  10.2.0.0/16   (10.2.0.0 – 10.2.255.255)
Security:     10.3.0.0/16   (10.3.0.0 – 10.3.255.255)
Shared Svcs:  10.4.0.0/16   (10.4.0.0 – 10.4.255.255)

Each environment gets its own /16 with no overlap. Any VPC can peer with any other.

Peering vs Transit Gateway

For more than a handful of VPCs, individual peering becomes unmaintainable (N*(N-1)/2 peering connections). AWS Transit Gateway solves this with a hub-and-spoke model:

All VPCs → Transit Gateway ← On-premises (via Direct Connect or VPN)

With Transit Gateway, you still need non-overlapping CIDRs across all attached VPCs, but you only manage one set of route tables.

AWS Subnet Design for Specific Services

Load Balancer Subnets

AWS Application Load Balancers and Network Load Balancers require at least 8 free IPs per subnet for internal use. Ensure your public subnets have capacity.

Minimum recommended: /27 (27 usable IPs after reserves and ALB internal use).

Lambda VPC Subnets

Lambda functions inside a VPC create Elastic Network Interfaces (ENIs). Under heavy concurrency, Lambda can exhaust a small subnet rapidly. Use /24 or larger for Lambda subnets, and consider dedicated Lambda subnets separate from EC2 subnets.

RDS Multi-AZ Subnets

RDS requires a DB Subnet Group with subnets in at least two AZs. Use your private data tier subnets. The primary and standby instances each occupy one IP address in separate AZs.

GCP VPC Subnet Design

GCP VPCs work differently from AWS. A GCP VPC is global — a single VPC spans all regions, and subnets are regional (not availability-zone-specific).

GCP Reserved Addresses per Subnet

GCP reserves 4 addresses per subnet: - Network address (first) - Default gateway (second) - Second-to-last address - Broadcast (last)

A /24 has 252 usable addresses in GCP (versus 251 in AWS).

GCP Subnet Design Pattern

VPC: my-global-vpc (no CIDR at VPC level — assigned per subnet)

us-central1 region:
  prod-us-central:   10.64.0.0/20   (4,092 usable)
  dev-us-central:    10.64.16.0/20

europe-west1 region:
  prod-eu-west:      10.64.32.0/20
  dev-eu-west:       10.64.48.0/20

asia-southeast1 region:
  prod-ap-se:        10.64.64.0/20
  dev-ap-se:         10.64.80.0/20

GCP Secondary Ranges for GKE

Google Kubernetes Engine requires secondary IP ranges for Pod and Service CIDRs. Plan these separately:

Subnet: 10.64.0.0/20 (primary — nodes)
  Secondary range "pods": 10.128.0.0/14    (262,144 IPs for pods)
  Secondary range "services": 10.0.0.0/20  (4,096 service IPs)

Secondary ranges must not overlap with each other or the primary range.

Azure VNet Subnet Design

Azure Virtual Networks have their own conventions and reserved addresses.

Azure Reserved Addresses per Subnet

Azure reserves 5 addresses per subnet (same count as AWS, but slightly different addresses): - x.x.x.0 — Network address - x.x.x.1 — Default gateway - x.x.x.2 and x.x.x.3 — Azure DNS IP mapping - Last address — Broadcast

Azure Subnet Naming Conventions

Azure requires specific subnet names for certain services:

These reserved subnet names must match exactly — a misconfigured name will cause deployment failures.

Azure Hub-Spoke Design

Hub VNet: 10.80.0.0/16
  GatewaySubnet:          10.80.0.0/24
  AzureFirewallSubnet:    10.80.1.0/26
  AzureBastionSubnet:     10.80.2.0/27
  Management:             10.80.3.0/24

Spoke VNet — Production: 10.81.0.0/16
  app-subnet:             10.81.1.0/24
  data-subnet:            10.81.2.0/24
  aks-subnet:             10.81.4.0/22

Spoke VNet — Development: 10.82.0.0/16
  app-subnet:             10.82.1.0/24
  data-subnet:            10.82.2.0/24

Hub VNet uses VNet Peering to connect to each Spoke. Traffic between spokes routes through the Azure Firewall in the Hub for inspection.

Avoiding Common Cloud Subnet Mistakes

Mistake 1: Using /16 for Everything

Starting every VPC with 10.0.0.0/16 and every subnet with /24 is common but creates peering conflicts when the second or third VPC is also 10.0.0.0/16.

Fix: Assign distinct /16 blocks from a master IPAM table before creating any VPC.

Mistake 2: Subnets Too Small for Kubernetes

Kubernetes Pods are ephemeral and can be numerous. A /24 node subnet may seem fine until EKS starts assigning secondary ENIs and you run out of IPs.

Fix: Use /22 or /21 for private subnets that will host EKS node groups or GKE nodes.

Mistake 3: Forgetting On-Premises Overlap

If you have an on-premises network using 10.0.0.0/8 and your cloud VPCs also use that space, VPN or Direct Connect routing will have conflicts.

Fix: Get a full inventory of on-premises address space before allocating cloud CIDRs. Reserve a separate /8 or /12 block for cloud that does not appear on-premises.

Mistake 4: Not Planning for Multi-Region

If you deploy in multiple cloud regions and later want to route between them (VPN, peering, Transit Gateway), you need non-overlapping CIDRs per region.

Fix: Allocate separate /12 or /16 blocks per region from day one.

Summary

Cloud VPC subnet design is primarily a planning and documentation discipline. The technical rules are straightforward, but the consequences of getting CIDR allocation wrong — peering conflicts, address exhaustion, renumbering — are severe and sometimes require significant rebuilding.

Use a master IPAM document, allocate distinct non-overlapping CIDRs per environment and per region, plan for growth (use /22 or larger for subnets that will host Kubernetes), and know the cloud-specific reserved address counts. A well-designed VPC CIDR scheme takes an hour to build and saves days of remediation work later.