Subnets, Routing, and Gateways

What we're doing: Compute how many usable addresses a planned subnet actually has, accounting for the 5 AWS reserves.

def usable_ips(prefix_len):
    total = 2 ** (32 - prefix_len)
    return total - 5  # AWS reserves 5 addresses in every subnet

print(usable_ips(24))  # 251
print(usable_ips(28))  # 11

1

The -5 applies uniformly regardless of subnet size — it is a fixed AWS reservation, not a percentage.

3

A /28 with only 16 total addresses loses nearly a third of its space to reserved addresses — the smaller the subnet, the bigger that proportion.

Why this works: Planning a subnet by total CIDR size alone (rather than usable IPs) is the single most common way teams run out of address space earlier than expected — 5 reserved addresses is a bigger bite out of a small subnet than a large one.

What we're doing: See a full route table with both the automatic local route and an added default route.

{
  "Routes": [
    { "DestinationCidrBlock": "10.0.0.0/16", "GatewayId": "local" },
    { "DestinationCidrBlock": "0.0.0.0/0", "NatGatewayId": "nat-0abc123" }
  ],
  "Associations": [
    { "SubnetId": "subnet-0priv1" }
  ]
}

4

The "local" route was never explicitly created — every route table gets it automatically and it cannot be deleted.

8

This route table is explicitly associated with one specific subnet, overriding whatever the VPC's main route table says.

Why this works: The local route guarantees resources within the VPC can always reach each other regardless of what the default route points at — losing internet access never means losing intra-VPC connectivity.

What we're doing: See why a private instance can call out to an API but can never be reached directly, even on an open port.

# Allowed — outbound, initiated from the private subnet
app-server (private) --request--> api.example.com:443
app-server (private) <--response-- api.example.com:443   # return traffic, same connection

# Blocked — inbound, initiated from outside
attacker --connect attempt--> app-server (private):443   # no path exists, NAT is outbound-only

2

The private-subnet instance is the one that opened this connection — NAT allows the response to come back on the same connection.

5

This is a brand-new, externally initiated connection attempt — there is no NAT mapping for it, so it has nowhere to go, security group settings aside.

Why this works: NAT's asymmetry is a structural property of the gateway itself, not a rule that can be misconfigured open — even a maximally permissive security group on the instance cannot make it reachable from the internet through a NAT gateway.

What we're doing: See how adding a gateway endpoint changes the route table, without touching the application code at all.

{
  "Routes": [
    { "DestinationCidrBlock": "10.0.0.0/16", "GatewayId": "local" },
    { "DestinationPrefixListId": "pl-0abc-s3", "GatewayId": "vpce-0def456" },
    { "DestinationCidrBlock": "0.0.0.0/0", "NatGatewayId": "nat-0abc123" }
  ]
}

4

Traffic to S3's IP ranges (the prefix list) now routes to the VPC endpoint instead of falling through to the NAT gateway default route.

Why this works: The application's S3 client code does not change at all — it still calls the same S3 API. The route table silently redirects that traffic onto a private path instead of out through the NAT gateway, which also stops that traffic from being billed as NAT data processing.

What we're doing: See the two independent NAT gateway cost drivers, and where a VPC endpoint removes one of them entirely.

# Without an S3 gateway endpoint
private-subnet → NAT gateway (hourly + per-GB) → internet gateway → S3

# With an S3 gateway endpoint
private-subnet → S3 directly (no NAT hourly or per-GB charge for this traffic)

2

Every byte of S3 traffic here is billed at the NAT gateway's per-GB rate, in addition to the gateway's standing hourly charge.

5

The same S3 traffic now bypasses the NAT gateway entirely — no per-GB NAT charge, and the gateway endpoint itself is free.

Why this works: The NAT gateway's per-GB charge applies to all traffic that flows through it, including traffic to AWS services that have a free, direct alternative — the architecture choice (adding an endpoint) directly changes the cost, not just efficiency.