Subnets, CIDR & Route Tables

## "Public" is a convention, not an attribute When you create a subnet in an Amazon VPC you give it a CIDR block and an Availability Zone. There is no field, tag or checkbox on the subnet that says *public*. The distinction lives entirely in the **route table** that the subnet is associated with. Engineers say "public subnet" as shorthand for "its route table has a default route pointing at an internet gateway", and that shorthand is exactly what an interviewer is probing. ## Ingredient one: an internet gateway attached to the VPC An internet gateway (IGW) is a VPC-level object. You create it and attach it to the VPC, and a VPC can have at most one attached at a time. Attaching it changes nothing on its own — it is a door in the wall of the VPC that no subnet has been told to walk through yet. Candidates who stop here are the ones who later ask why their instance still cannot reach the internet. ## Ingredient two: a route to it Every route table starts with a `local` route covering the VPC's CIDR, which is what lets subnets in the same VPC talk to each other. To make a subnet public you add one more route: ``` Destination Target 10.0.0.0/16 local 0.0.0.0/0 igw-0abc123 ``` The subnet is then associated with that table. Traffic to an address inside the VPC matches the more specific `local` route; everything else matches `0.0.0.0/0` and is handed to the gateway. A private subnet is simply one whose table lacks that entry, or whose default route points at something that is not an IGW. Route lookup is longest-prefix-match, so `local` always wins for intra-VPC destinations. That is also why a route table cannot be used to firewall traffic between subnets of the same VPC — the local route always covers it. ## Ingredient three: a globally routable address The internet gateway does **not** hide your private addresses behind a shared address. It performs a one-to-one mapping between an instance's private IPv4 address and the public address associated with that instance's network interface. If the instance has no public IPv4 and no Elastic IP, the gateway has nothing to map, so outbound packets are dropped and no reply could ever find its way back. There are two ways to get that address. The subnet attribute `MapPublicIpOnLaunch` (set with `aws ec2 modify-subnet-attribute --map-public-ip-on-launch`) auto-assigns a public IPv4 to instances launched into it — this is on for subnets of the default VPC and off for subnets you create yourself. Or you allocate an Elastic IP and associate it with the interface, which gives a stable address that survives stop/start. Note that this attribute is a frequent source of confusion: enabling it on a subnet whose route table has no IGW route gives instances a public address that is completely unreachable, and the reverse — an IGW route with no public address — gives a subnet everyone calls public that nothing can leave. ## Ingredient four: the filters must agree Security groups and network ACLs still evaluate the traffic. They can block a perfectly routed packet, but they never *create* reachability, and no security-group rule turns a private subnet into a public one. ## What this buys you architecturally The pattern this enables is the one you will be asked to draw: per Availability Zone, a small public subnet holding only internet-facing entry points, and a larger private subnet holding application instances and databases. The public/private split is enforced purely by which of two route tables each subnet is associated with, which is why the split is cheap to get right and cheap to get catastrophically wrong — moving one association is all it takes to expose a tier that was meant to be internal. A useful diagnostic habit: when something in a VPC cannot reach the internet, check in this order — is an IGW attached, does the subnet's *associated* route table have `0.0.0.0/0` to it, does the instance have a public or Elastic IP, and only then look at security groups and NACLs.