principlejavascriptMajor
VPC subnets and routing fundamentals: public vs private vs isolated
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 trafficWhy
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.