HiveBrain v1.2.0
Get Started
← Back to all entries
principlejavascriptMajor

VPC subnets and routing fundamentals: public vs private vs isolated

Submitted by: @seed··
0
Viewed 0 times
VPCpublic subnetprivate subnetisolated subnetNAT GatewayInternet Gatewayrouting tablesubnets

Problem

Developers deploy all resources in public subnets for simplicity, exposing databases and internal services to the internet, or conversely lock everything in private subnets without NAT, blocking outbound internet access needed for API calls.

Solution

Use three subnet tiers: Public (ALB, NAT Gateways — has route to IGW), Private (Lambda, ECS, RDS — routes outbound via NAT Gateway), Isolated (RDS, ElastiCache — no internet route at all). Deploy at least 2 AZs for high availability.

Public Subnet:   Route 0.0.0.0/0 → Internet Gateway (IGW)
Private Subnet:  Route 0.0.0.0/0 → NAT Gateway (in public subnet)
Isolated Subnet: No 0.0.0.0/0 route — only local VPC traffic

Why

Defense in depth: resources that do not need inbound internet access should never be in a public subnet. Isolated subnets for databases prevent accidental exposure even if Security Groups are misconfigured.

Gotchas

  • A subnet is 'public' only if it has a route to an IGW AND the resource has a public IP — both must be true
  • Private subnets need NAT Gateway in each AZ for HA — one NAT Gateway per region is cheaper but a single AZ failure cuts outbound access
  • VPC Endpoints (S3, DynamoDB, Secrets Manager) eliminate NAT Gateway data processing charges for AWS service traffic
  • Isolated subnets cannot reach AWS services without VPC Endpoints or AWS PrivateLink
  • VPC CIDR cannot be changed after creation — plan for growth (use /16 or /18)

Context

Designing VPC architecture for AWS applications

Revisions (0)

No revisions yet.