VPC and subnets: CIDR, routing, and the NAT egress trap

CIDR, subnets, and the per-AZ rule

By the end of this section you will know exactly which two things make a subnet “public,” and why the wrong answer costs money every hour.

A VPC (Virtual Private Cloud) is a logically isolated virtual network you carve out inside an AWS Region. You define its address space with a CIDR block, for example 10.0.0.0/16 — that gives you 65,536 private IPv4 addresses to hand out. Nothing inside one VPC can reach another VPC or the internet unless you explicitly wire a path; isolation is the default.

You don’t put resources directly in a VPC — you put them in subnets, which carve the VPC CIDR into smaller ranges like 10.0.1.0/24. The single most important structural fact: a subnet lives entirely in one Availability Zone and cannot span AZs. An AZ is an isolated datacenter cluster, so if you place every subnet in one AZ and that AZ has an outage, your whole tier goes dark. High availability is therefore non-negotiable: spread subnets across at least two AZs and run a copy of each tier in each.

VPC CIDR        10.0.0.0/16          (65,536 IPs, one Region)
  AZ us-east-1a
    public      10.0.0.0/24          web / load balancer / NAT
    private     10.0.1.0/24          app servers, databases
  AZ us-east-1b
    public      10.0.2.0/24
    private     10.0.3.0/24

A subnet’s CIDR must be a subset of the VPC CIDR, and the two cannot overlap each other. AWS also reserves the first four and last IP in every subnet, so a /24 gives you 251 usable addresses, not 256 — a detail that bites when you size subnets too tight for an autoscaling fleet. When you plan your CIDR layout, always leave headroom: a /24 looks generous until you have 200 Lambda ENIs or an EKS node pool expanding under load.

”Public” and “private” are routing, not a flag

There is no checkbox that makes a subnet public. A subnet is public only if two things are true: its associated route table sends 0.0.0.0/0 (all internet-bound traffic) to an Internet Gateway (IGW), and the instances in it have public IP addresses. Remove either and the same subnet is effectively private. The IGW is a horizontally-scaled, redundant VPC component that provides bidirectional internet connectivity; AWS does not charge an hourly fee for the gateway itself (you pay normal data-transfer rates).

Every subnet is associated with exactly one route table, a list of destination → target rules evaluated by longest-prefix match. Every route table has an immutable local route for the VPC CIDR, which is what lets any subnet talk to any other subnet inside the VPC with no extra configuration.

# Public subnet route table
Destination     Target
10.0.0.0/16     local              # intra-VPC, always present
0.0.0.0/0       igw-0abc123        # internet, both directions

# Private subnet route table
Destination     Target
10.0.0.0/16     local
0.0.0.0/0       nat-0def456        # egress only, via NAT in a public subnet

A NAT Gateway is how private instances reach out to the internet — for OS updates, package registries, third-party APIs — without being reachable from the internet. Per AWS docs, instances in a private subnet connect outbound through a NAT Gateway, but external services cannot initiate a connection back. A public NAT Gateway must live in a public subnet and have an Elastic IP, and its route ultimately sends traffic to the IGW. It is a managed, zonal resource: it exists in one AZ.

The egress-cost trap and how endpoints kill it

Here is the trap that produces five-figure surprises. A NAT Gateway bills on two axes: an hourly charge for each gateway, plus a per-GB data-processing charge on every byte that flows through it (prices are illustrative and region-dependent — see the Amazon VPC pricing page for current rates). When a private instance talks to S3, DynamoDB, or another high-volume service through the default 0.0.0.0/0 to NAT route, every gigabyte is taxed by that data-processing fee — and at terabyte scale it dwarfs the actual compute cost.

The fix is a VPC Gateway Endpoint. Per AWS docs, gateway endpoints provide connectivity to S3 and DynamoDB “without requiring an internet gateway or a NAT device,” and there is no additional charge for using them. You enable one by selecting your private subnets’ route tables; AWS auto-adds a route whose destination is an AWS-managed prefix list for the service and whose target is the endpoint. Because routing uses longest-prefix match, S3-bound traffic now takes the free endpoint route instead of the NAT default — and stays entirely on the AWS network.

For services without a gateway endpoint, Interface Endpoints (PrivateLink) put an ENI in your subnet so traffic to that service stays off the public internet (these carry their own hourly + per-GB charge, but avoid NAT data-processing and the internet path).