TestForge Blog
← All Posts
#cloud #aws #vpc #network #architecture

AWS VPC Design Basics — Subnets, Routing, NAT, and Security Groups

A practical guide to designing AWS VPCs. Covers public and private subnets, route tables, NAT Gateways, Internet Gateways, security groups, and the common mistakes teams make early on.

TestForge Team ·

Why VPC Design Matters

VPC design shapes every later cloud decision.

A weak foundation leads to:

  • poor isolation between workloads
  • expensive NAT patterns
  • confusing security group sprawl
  • painful multi-AZ expansion

VPCs are not a one-time setup. They become the networking foundation of the platform.

Questions to Answer First

  • single region or multi-region?
  • what must be internet-facing?
  • should DB and internal APIs be fully private?
  • do you expect VPC peering or Transit Gateway later?
  • are you planning around EC2, ECS, or EKS?

The answer changes your CIDR and subnet layout.

VPC (10.0.0.0/16)
├─ Public Subnet A
├─ Public Subnet B
├─ Private App A
├─ Private App B
├─ Private Data A
└─ Private Data B

Typical roles:

  • Public: ALB, bastion, NAT
  • Private App: APIs, workers, EKS nodes
  • Private Data: RDS, Redis, internal data services

Public vs Private Subnets

Public subnet:

  • route to Internet Gateway
  • internet-facing resources can live here

Private subnet:

  • no direct internet route
  • optional outbound via NAT
  • no direct external inbound access

Production application and database tiers should usually live in private subnets.

Route Table Design

A common pattern is:

  • one route table for public subnets
  • one for private app subnets
  • one for private data subnets

The key is to keep routing simple and role-based.

NAT Gateway Placement

The classic tradeoff is:

  • one NAT for lower cost
  • one NAT per AZ for higher availability

For important production services, AZ-level NAT is often safer.

Also remember:

  • cross-AZ NAT traffic can add cost
  • S3 and DynamoDB often benefit from VPC Endpoints instead of NAT

Security Groups and NACLs

A practical rule:

  • Security Groups = primary access control
  • NACLs = optional additional boundary rules

Security Groups are usually enough for most service-layer traffic.

VPC Endpoints Are Worth Considering Early

Without them, a lot of AWS traffic flows through NAT unnecessarily.

Common useful endpoints:

  • S3
  • DynamoDB
  • ECR
  • Secrets Manager
  • CloudWatch Logs
  • STS

These can improve both cost and security.

Common Mistakes

  • choosing VPC CIDR ranges that are too small
  • making databases public
  • using overly broad inbound rules
  • underestimating NAT cost

These problems show up repeatedly in real AWS environments.

A Good Design Sequence

  1. choose VPC CIDR
  2. decide AZ count
  3. split subnet roles
  4. design routing
  5. design security groups
  6. evaluate NAT and endpoint cost
  7. define operational access paths

Closing Thoughts

Good AWS VPC design starts with boundaries:

  • what is public
  • what is private
  • what is allowed to talk to what

If those boundaries are clear, later work on EKS, databases, security, and CI/CD becomes much easier.