vpc-network-design

name	vpc-network-design
description	Step-by-step playbook for designing an AWS VPC — CIDR allocation, subnet layout, routing, security groups vs NACLs, egress control, and PrivateLink/VPC endpoint placement. Covers single-VPC through multi-account Transit Gateway topologies.

AWS VPC Network Design

1. CIDR Allocation

Pick a non-overlapping RFC 1918 range before you create anything — overlapping CIDRs block VPC peering and Transit Gateway routes permanently.

Scope	Recommended range	Why
VPC	/16 per environment	65 k addresses; room to add AZs
Public subnet	/24 per AZ	~250 public IPs; load balancers, NAT GWs
Private (app) subnet	/22 per AZ	~1 000 IPs; ECS tasks, EC2, Lambda ENIs
Private (data) subnet	/24 per AZ	~250 IPs; RDS, ElastiCache

Reserve at least one /24 per AZ for future use — subnets cannot be resized.

2. Subnet Tiers and Routing

Internet Gateway
    └── Public subnet (route: 0.0.0.0/0 → IGW)
            └── NAT Gateway (one per AZ for HA)
App (private) subnet (route: 0.0.0.0/0 → NAT GW in same AZ)
Data (private) subnet  (no default route — data layer stays dark)

Rules:

1. Only load balancers, bastion hosts, and NAT GWs belong in public subnets.
2. Cross-AZ NAT GW traffic incurs data-transfer cost — always route to the NAT GW in the same AZ.
3. Data subnets have no internet route; app code reaches them through the private tier only.

3. Security Groups vs NACLs

Control	When to use	Key behaviour
Security group	Default — almost always	Stateful; only allow rules; attach to ENI
NACL	Subnet-wide deny (e.g., block a known bad CIDR)	Stateless; explicit allow + deny; evaluated in rule-number order

Avoid redundant NACL rules. NACLs are stateless — a DENY is not matched by the return traffic; denying an ephemeral-port range silently breaks connections.

4. Egress Control Decision

Traffic type	Control	Rationale
Internet-bound (app → external API)	NAT Gateway + security group	No per-byte NAT cost for AWS-to-AWS; use VPC endpoints instead
AWS service APIs (S3, DynamoDB, SQS, STS…)	VPC Gateway or Interface endpoint	Keeps traffic on the AWS backbone; removes NAT GW dependency and cost
Cross-account internal traffic	Transit Gateway or VPC Peering	TGW for hub-and-spoke; peering for point-to-point (no transitive routing in peering)
On-premises	Direct Connect + VGW or TGW attachment	Site-to-Site VPN for non-critical; DX for production

5. VPC Endpoint Checklist

At minimum, create endpoints for:

• com.amazonaws.<region>.s3 (Gateway — free)
• com.amazonaws.<region>.dynamodb (Gateway — free)
• com.amazonaws.<region>.ecr.api + ecr.dkr (Interface — costs apply, saves NAT GW per-byte)
• com.amazonaws.<region>.sqs, ssm, secretsmanager (Interface — eliminates NAT GW for these APIs)

6. Multi-Account Transit Gateway

Central networking account owns the TGW.
Each spoke account creates a TGW attachment (VPC attachment).
Route tables:
  - Shared-services attachment: can reach all spokes
  - Prod spokes:  can reach shared-services + inspection; not each other
  - Non-prod spokes: same isolation from prod
  - Inspection attachment: default route 0.0.0.0/0 for egress firewall (optional)

Enable resource sharing via RAM so spoke accounts can attach without cross-account peering invitations.

Pitfalls

• Allocating /24 VPCs — you'll run out of IPs when ECS and Lambda ENIs proliferate.
• A single NAT GW across AZs — AZ failure kills all outbound traffic.
• Forgetting the ephemeral port range (1024–65535) in NACL return rules.
• Overlapping CIDRs discovered after peering — no fix except re-IP or abandon.
• Security groups that reference 0.0.0.0/0 on port 22/3389 — always a finding; use SSM Session Manager instead.
• Skipping VPC endpoints for S3/DynamoDB — 100% of that traffic transits the NAT GW and incurs per-byte charges.