AWS Networking at Senior Level cheat sheet · AWS

1.The Full Connectivity Surface

At a senior level the question stops being "how does a VPC work" and becomes "which of the eight ways to connect two networks is right here". Peering, Transit Gateway, VPN, Direct Connect, PrivateLink, VPC endpoints, NAT, and public internet each solve a different shape of problem, and each has a different cost and failure mode.

Key features

Transit Gateway is a network transit hub interconnecting VPCs and on-premises networks; inter-Region peering connects transit gateways over the AWS global backbone
A transit gateway attachment is associated with exactly one route table, while a route table can have zero to many attachments — associations decide which routes an attachment sees
Route propagation differs by attachment type: VPN and Direct Connect gateway propagate dynamically via BGP, a VPC needs static routes, and a peering attachment always needs a static route
VPC peering is non-transitive — A↔B and B↔C does not give A↔C — which is the specific limitation Transit Gateway exists to remove
Gateway VPC endpoints (S3, DynamoDB) are route table entries and free; interface endpoints (PrivateLink) are ENIs in your subnets and billed hourly plus per GB
Centralized egress puts one NAT gateway in a shared VPC behind Transit Gateway so twenty VPCs do not each pay for their own — but Transit Gateway itself is billed per attachment-hour plus per GB, a running cost a peering mesh does not have

Choosing a connectivity mechanism

Choosing a connectivity mechanism
Need	Mechanism	Watch out for
Two VPCs talking, and only two	VPC peering	Non-transitive; a mesh of N VPCs needs N(N−1)/2 links
Many VPCs plus on-premises	Transit Gateway	Per-attachment-hour and per-GB charges
Reach S3 or DynamoDB privately	Gateway VPC endpoint	Route-table based and free — always worth adding
Reach another AWS service or a partner service privately	Interface endpoint (PrivateLink)	Hourly per ENI, per AZ, plus data processing
Consistent, high-bandwidth on-premises link	Direct Connect	Lead time to provision; needs a VPN backup for resilience
Encrypted on-premises link today	Site-to-Site VPN	Internet-path latency variability
Outbound internet from private subnets	NAT gateway	Per-GB processing — centralize it, or use endpoints

Which mechanism for which connection

AWS to AWS

VPC peering

two VPCs, non-transitive, no hourly charge

Transit Gateway

many VPCs + on-premises, transitive

PrivateLink / endpoints

reach a service, not a network

AWS to elsewhere

Direct Connect

dedicated link, consistent latency

Site-to-Site VPN

over the internet, encrypted, BGP

NAT gateway

outbound only, to the internet

Signature

peering (2, non-transitive) · TGW (many + on-prem, transitive) · gateway EP (S3/DDB, free) · PrivateLink · DX / VPN · NAT

Peering for two VPCs (non-transitive, no hourly cost); Transit Gateway for many plus on-premises (per attachment-hour, per GB); gateway endpoints for S3/DynamoDB (free, always add them); PrivateLink for private service access; Direct Connect or VPN for on-premises; centralize NAT rather than one per VPC.

2.Hub-and-Spoke and Non-Overlapping Address Space

A hub-and-spoke network puts one Transit Gateway at the centre and attaches every VPC and every on-premises link to it. Each spoke has one route to the hub instead of one route per peer. The rule that makes this possible is boring and absolute: no two networks that might ever need to talk may use overlapping CIDR ranges.

Key features

A spoke needs one route (to the transit gateway attachment) rather than one route per peer, which is what makes the pattern scale
Transit gateway route tables plus associations let you segment traffic — production spokes associated with one route table, development with another, so they cannot reach each other
Overlapping CIDRs cannot be routed between: the destination is ambiguous, so the connection is simply not possible
Allocate from a single top-level block per Region and hand out non-overlapping slices per account and environment, leaving room to grow
Reserve address space for on-premises and for future acquisitions — most overlap incidents come from a network nobody planned to connect to
A VPC's CIDR cannot be shrunk after creation (secondary CIDRs can be added), so the initial allocation is close to permanent

An address plan that survives growth

An address plan that survives growth
Block	Purpose	Why it is reserved
10.0.0.0/12	Shared services and egress VPCs	Small in count, referenced by everything
10.16.0.0/12	Production workload VPCs, one /16 each	Room for 16 production VPCs per Region
10.48.0.0/12	Non-production VPCs	Segregated so a route table split is trivial
10.128.0.0/9	Unallocated	The half you have not spent — keep it that way
172.16.0.0/12	On-premises	Never allocate this in AWS

Hub and spoke, with segmentation

attachmentattachmentattachment(dev table)0.0.0.0/0DXattachment

prod-app VPC

10.20.0.0/16

prod-data VPC

10.21.0.0/16

dev VPC

10.60.0.0/16

Transit Gateway

prod route table · dev route table

egress VPC

10.10.0.0/16 · shared NAT

On-premises

172.16.0.0/12 via Direct Connect

Signature

hub (TGW) + spokes · one route per spoke · segmentation via route-table associations · one non-overlapping address plan

Hub-and-spoke: one Transit Gateway, one route per spoke, and route-table associations for segmentation. Allocate every CIDR from one documented plan, reserve on-premises space, size generously — a VPC's primary CIDR cannot be changed, and overlapping networks cannot be routed to each other at all.

3.Multi-AZ Subnet Architecture, Route by Route

A production VPC has three subnet tiers repeated across at least two Availability Zones: public for load balancers and NAT, private for compute, and isolated for databases. Each tier has its own route table, and the difference between the tiers is entirely in those routes. Being able to explain every line of every route table is the actual skill.

Key features

A subnet is public if and only if its route table has a route to an internet gateway; nothing else about the subnet defines it
The `local` route covering the VPC CIDR exists in every route table, cannot be removed, and is why every subnet can reach every other subnet by default
Private subnets route 0.0.0.0/0 to a NAT gateway; isolated subnets have no default route at all
A NAT gateway lives in a public subnet and is zonal — one per AZ for AZ-independence, or one shared across AZs to save cost at the price of a cross-AZ dependency
Each private subnet should route to the NAT gateway in its own AZ, or a single AZ failure takes down egress for every AZ that pointed at it
Gateway endpoint routes (S3, DynamoDB) are prefix-list entries that take precedence over the 0.0.0.0/0 NAT route for those services, and AWS reserves five addresses in every subnet, so a /24 gives 251 usable rather than 254

Every route, and why it is there

Every route, and why it is there
Route table	Destination → Target	Why
public (both AZs)	10.20.0.0/16 → local	Reach the rest of the VPC; cannot be removed
public (both AZs)	0.0.0.0/0 → igw-…	This route is what makes the subnet public
private-a	10.20.0.0/16 → local	Same as above
private-a	0.0.0.0/0 → nat-a	Outbound only, and via this AZ's NAT so an AZ failure is contained
private-a	pl-s3 → vpce-…	S3 traffic bypasses NAT — no per-GB processing charge
data-a	10.20.0.0/16 → local	The only route: no path to or from the internet at all

Three tiers, two AZs

Availability Zone A

public-a 10.20.0.0/20

ALB node, NAT gateway A

private-a 10.20.64.0/20

ECS tasks, EC2

data-a 10.20.128.0/20

RDS, ElastiCache — no default route

Availability Zone B

public-b 10.20.16.0/20

ALB node, NAT gateway B

private-b 10.20.80.0/20

ECS tasks, EC2

data-b 10.20.144.0/20

RDS standby

Signature

public: 0.0.0.0/0 → IGW · private: 0.0.0.0/0 → NAT (same AZ) + gateway EPs · data: local only

Three tiers per AZ: public (default route to the IGW), private (default route to that AZ's NAT, plus gateway endpoints), data (no default route at all). Every route table starts with an unremovable `local` route. Multi-AZ means removing cross-AZ dependencies, not just placing resources in two AZs.

4.Troubleshooting in Order: DNS → Route → SG → NACL → Listener

"It cannot connect" has five possible causes and they sit in a fixed order along the path. Resolve the name, find a route to the address, get past the source and destination security groups, get past the network ACLs, and finally reach something listening on that port. Checking them in order turns a guessing game into five short questions.

Key features

DNS resolution happens before any packet is sent, so a name that does not resolve produces the same "connection failed" as a firewall block
A route failure is silent: with no matching route the packet is dropped locally, and the caller sees a timeout rather than a rejection
Security groups are stateful and allow-only — a missing rule is a timeout, never a refusal, because nothing sends a rejection back
Network ACLs are stateless, so a reply needs an explicit outbound allow on the ephemeral port range that the request's inbound rule does not cover
A connection refused (rather than a timeout) means the packet arrived and nothing was listening — the network is fine and the application is the problem
VPC Flow Logs distinguish these: an ACCEPT with no reply points at the application, a REJECT points at a security group or NACL, and no record at all points at routing or DNS

Reading the symptom back to the layer

Reading the symptom back to the layer
Symptom	Most likely layer	How to confirm
Name does not resolve	DNS	`dig` from inside the VPC; check the private hosted zone and resolver
Resolves, then hangs and times out	Route, SG, or NACL	Flow logs: no record → route; REJECT → SG/NACL
Connection refused immediately	Listener	The packet arrived — check the process and its bind address
Works one direction only	NACL	Stateless rules: the return path needs its own allow
Works from one subnet, not another	Route table or NACL	Compare the two subnets' associations
Intermittent failure	A per-AZ asymmetry	Compare route tables and NACLs per AZ, not just per VPC

Five checks, in order

1 · DNS

Does the name resolve, and to the address you expect? Private zone, resolver, split-horizon.

2 · Route

Does the source subnet's route table have a path to that address? Silent drop if not.

3 · Security groups

Source SG allows outbound; destination SG allows inbound from the source SG. Timeout if not.

4 · NACLs

Both directions, both subnets, including ephemeral ports on the return path.

5 · Listener

Is something bound to that port, on that interface? Connection refused if not.

Signature

1 DNS · 2 route · 3 security groups (both sides) · 4 NACLs (both directions + ephemeral) · 5 listener

DNS → route → security groups (both sides) → NACLs (both directions, ephemeral ports) → listener. The first failing check is the answer. Refused means the packet arrived; timeout means it did not. Flow logs tell REJECT from never-arrived.