Scaling AWS VPCs: Architecture Patterns for Multi-Account Environments

AWS VPC design for multi-project multi-account setups: patterns that scale

Engineer Yash outlines a scalable AWS VPC framework using non-overlapping CIDRs across management, production, and development accounts. The architecture utilizes /20 subnetting to provide exactly 4,096 IPs per project, preventing IP exhaustion without wasting address space.

Why This Matters

In complex AWS organizations, early VPC decisions often become technical debt that is nearly impossible to reverse without significant downtime. While a single /16 VPC might seem simple, multi-project environments require precise CIDR planning and tiered security groups to ensure isolation and connectivity. Using /20 blocks provides a middle ground between the restrictive /24 and the overly broad /16, while multi-AZ NAT gateways prevent single points of failure that could take down entire private subnet tiers costing approximately $100 per month.

Key Insights

• Non-overlapping CIDR strategy: Management uses 10.0.0.0/16 while production accounts start at 10.1.0.0/16 to enable seamless VPC peering (Source: Yash, 2026).
• Right-sized subnetting: Allocating /20 per project provides 4,096 IPs, avoiding the waste of /16 blocks and the congestion of /24 blocks.
• Tiered Security Access: Chained security group patterns (ALB to App to RDS) ensure that database layers are only reachable by application tiers.
• Availability vs. Cost: Multi-AZ NAT gateways in production prevent single points of failure that would otherwise disable all private subnets.
• Automated Allocation: Step2Dev uses Terraform to allocate non-overlapping CIDRs across all accounts automatically to maintain network hygiene.

Working Examples

Terraform logic for calculating subnets and VPC creation.

locals { private_cidrs = [for i in [0,1,2]: cidrsubnet(var.vpc_cidr, 3, i)] public_cidrs = [for i in [4,5,6]: cidrsubnet(var.vpc_cidr, 3, i)] } resource "aws_vpc" "main" { cidr_block = var.vpc_cidr; enable_dns_hostnames = true; tags = { Name = "${var.project_name}-${var.environment}" } }

Tiered security group pattern for ALB, Application, and RDS access.

resource "aws_security_group" "app" { ingress { from_port = 8080; to_port = 8080; protocol = "tcp"; security_groups = [aws_security_group.alb.id] } } resource "aws_security_group" "rds" { ingress { from_port = 5432; to_port = 5432; protocol = "tcp"; security_groups = [aws_security_group.app.id] } }

Practical Applications

• Use case: High-availability production workloads using Multi-AZ NAT Gateways. Pitfall: Single NAT Gateway deployments leading to complete private subnet failure during AZ outages.
• Use case: Multi-project account isolation using non-overlapping 10.x.x.x/16 ranges. Pitfall: Overlapping CIDRs preventing future network integration via Transit Gateway.
• Use case: Private-only compute deployments for ECS and Lambda. Pitfall: Placing compute resources in public subnets with public IPs, increasing the attack surface.

References:

• https://dev.to/yash_step2dev/aws-vpc-design-for-multi-project-multi-account-setups-patterns-that-scale-1nph