AWS Networking — Core Model

What we're doing: See the difference between a default VPC (ready to use) and a newly created custom VPC (empty boundary).

aws ec2 describe-vpcs --filters Name=is-default,Values=true \
  --query "Vpcs[].{Id:VpcId,Cidr:CidrBlock}"

aws ec2 create-vpc --cidr-block 10.0.0.0/16 --query "Vpc.{Id:VpcId,Cidr:CidrBlock}"

1

The default VPC already has subnets, an internet gateway, and DNS settings ready — an instance launched into it can reach the internet immediately.

4

A freshly created custom VPC has only its IP range — no subnets, no gateway, nothing else exists inside it yet.

Why this works: The default VPC exists so a new account can launch something immediately, but production workloads almost always use a deliberately designed custom VPC instead, built up piece by piece from an empty boundary.

What we're doing: See how the pieces compose: one subnet, one route table association, one gateway route.

aws ec2 create-subnet --vpc-id vpc-0abc123 --cidr-block 10.0.1.0/24 \
  --availability-zone eu-west-1a

aws ec2 create-route --route-table-id rtb-0def456 \
  --destination-cidr-block 0.0.0.0/0 --gateway-id igw-0ghi789

aws ec2 associate-route-table --route-table-id rtb-0def456 --subnet-id subnet-0jkl012

1

The subnet claims a slice of the VPC's CIDR range, pinned to one specific AZ.

4

The route table gets a rule sending anything not otherwise matched (0.0.0.0/0) to the internet gateway.

7

Associating the route table with the subnet is what actually makes that subnet public — without this step the subnet has no route to the gateway at all.

Why this works: None of these three commands alone makes a subnet public — a subnet is public only once all three pieces (the subnet, a route to an internet gateway, and the association between them) are in place together.

What we're doing: Confirm whether a subnet is public by reading its route table directly, rather than trusting its name.

aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0jkl012 \
  --query "RouteTables[].Routes[].{Dest:DestinationCidrBlock,Target:GatewayId}"

1

This asks for the specific route table associated with one subnet — not the VPC's route tables in general.

3

A row with Dest 0.0.0.0/0 and Target starting igw- confirms the subnet is public; a nat- target confirms private with outbound-only access.

Why this works: A subnet named "subnet-private-1" with a misconfigured route table is public in every way that matters — the name is documentation, the route table is the actual behavior.

What we're doing: Compare a CIDR plan that allows future peering against one that silently blocks it.

# Plan A — distinct ranges, peerable later
prod-vpc:    10.0.0.0/16
staging-vpc: 10.1.0.0/16

# Plan B — both teams picked the "obvious" default independently
team-a-vpc:  10.0.0.0/16
team-b-vpc:  10.0.0.0/16   # identical to team-a — cannot be peered as-is

2

prod and staging can be peered directly whenever needed — their ranges never collide.

3

No coordination was needed between these two teams because the ranges were planned together from one shared allocation.

6

Both teams independently picked the same common default range.

7

This VPC cannot be peered with team-a's without re-addressing one of them — a disruptive change with production resources already using those IPs.

Why this works: The cost of overlap is deferred, not avoided — it surfaces only when someone actually tries to connect the two networks, often much later and under time pressure, when re-addressing is far more expensive than it would have been at design time.