VPC Design Best Practices: Network Architecture Guide

VPC design decisions made early in a project are difficult to change later. Getting CIDR planning, subnet strategy, and security architecture right from the start prevents painful migrations. This guide covers best practices for VPC design at scale.

CIDR Planning

Non-Overlapping Ranges

The most critical rule: Plan for connectivity from day one.

• Never overlap: VPCs that need to connect cannot share IP ranges
• Reserve for on-premise: Account for existing data center CIDRs
• Plan for mergers: Leave room for acquired companies

CIDR Size Recommendations

IP Address Management (IPAM)

Use AWS VPC IPAM or similar for centralized control:

• Allocate CIDRs from managed pools
• Prevent overlaps automatically
• Track usage across regions and accounts

# Example CIDR allocation scheme
10.0.0.0/8 (Corporate supernet)
├── 10.0.0.0/12  (Production)
│   ├── 10.0.0.0/16  (us-east-1 prod)
│   ├── 10.1.0.0/16  (eu-west-1 prod)
│   └── 10.2.0.0/16  (Reserved)
├── 10.16.0.0/12 (Development)
│   ├── 10.16.0.0/16 (us-east-1 dev)
│   └── 10.17.0.0/16 (Reserved)
└── 10.32.0.0/12 (On-premise)

Subnet Strategy

Subnet Types

VPC: 10.0.0.0/16
├── Public Subnets (internet-facing)
│   ├── 10.0.0.0/24  (AZ-a) - ALB, NAT Gateway
│   ├── 10.0.1.0/24  (AZ-b)
│   └── 10.0.2.0/24  (AZ-c)
├── Private Subnets (application tier)
│   ├── 10.0.10.0/24 (AZ-a) - Containers, EC2
│   ├── 10.0.11.0/24 (AZ-b)
│   └── 10.0.12.0/24 (AZ-c)
├── Data Subnets (database tier)
│   ├── 10.0.20.0/24 (AZ-a) - RDS, ElastiCache
│   ├── 10.0.21.0/24 (AZ-b)
│   └── 10.0.22.0/24 (AZ-c)
└── Transit Subnets (TGW attachment)
    ├── 10.0.100.0/28 (AZ-a)
    ├── 10.0.100.16/28 (AZ-b)
    └── 10.0.100.32/28 (AZ-c)

Subnet Sizing

• Account for AWS reservations: 5 IPs per subnet (first 4 + last)
• Lambda ENIs: Each concurrent Lambda uses an IP
• EKS pods: Secondary IPs for pod networking
• Future growth: Easier to have unused IPs than to resize

Multi-AZ Design

Always Deploy Across AZs

• Minimum: 2 AZs for any production workload
• Recommended: 3 AZs for critical applications
• Consider: AZ-specific services may require specific AZs

AZ-Independent Design

# Each AZ should be independently functional
AZ-a                    AZ-b                    AZ-c
├── ALB node           ├── ALB node           ├── ALB node
├── NAT Gateway        ├── NAT Gateway        ├── NAT Gateway
├── App instances      ├── App instances      ├── App instances
└── Cache replica      └── Cache replica      └── Cache primary

Security Architecture

Security Group Design

• Per-role/function: Not per-instance
• Reference other SGs: Instead of CIDRs where possible
• Least privilege: Only required ports

# Good: Reference security groups
alb-sg → app-sg (port 8080)
app-sg → db-sg (port 5432)
app-sg → cache-sg (port 6379)

# Avoid: CIDR-based rules
10.0.0.0/16 → 10.0.0.0/16 (all ports)

Network ACLs

• Use for subnet-level blocklisting
• Remember: stateless (allow return traffic)
• Keep simple; complex logic goes in security groups

Connectivity Patterns

Internet Access

Public Subnet:
└── Route: 0.0.0.0/0 → Internet Gateway

Private Subnet:
└── Route: 0.0.0.0/0 → NAT Gateway (in public subnet)

Isolated Subnet:
└── No internet route (VPC endpoints for AWS services)

VPC Endpoints

• Interface endpoints: Most AWS services (PrivateLink)
• Gateway endpoints: S3 and DynamoDB (free, route-based)

Priority endpoints to deploy:

• S3 Gateway (cost savings, performance)
• DynamoDB Gateway (if used)
• ECR, Secrets Manager, SSM for container workloads

Multi-Account Strategy

Account per Environment

Networking Account
├── Transit Gateway
├── Direct Connect
└── Shared Services VPC

Production Account
└── Prod VPC → TGW attachment

Staging Account
└── Staging VPC → TGW attachment

Development Account
└── Dev VPC → TGW attachment

Benefits

• Blast radius: Limit impact of security issues
• Billing: Clear cost allocation
• Quotas: Separate limits per account
• Access control: IAM boundaries per account

Naming and Tagging

Consistent Naming Convention

# Pattern: {app}-{env}-{region}-{resource}-{az}
vpc:        myapp-prod-use1-vpc
subnet:     myapp-prod-use1-private-a
rt:         myapp-prod-use1-private-rt
sg:         myapp-prod-use1-app-sg
natgw:      myapp-prod-use1-natgw-a

Required Tags

• Environment: production, staging, development
• Application: Application name
• Owner: Team or individual responsible
• CostCenter: For billing allocation

Documentation Checklist

• ☐ Network diagram with all VPCs and connectivity
• ☐ CIDR allocation spreadsheet
• ☐ Security group matrix (what talks to what)
• ☐ Runbooks for common operations
• ☐ Disaster recovery procedures

Key Takeaways

• Plan CIDRs for current AND future connectivity needs
• Use consistent subnet tiers across all VPCs
• Deploy across multiple AZs for high availability
• Reference security groups, not CIDRs
• Use multi-account for blast radius and cost clarity