Lesson 31 / 33
Cloud Networking Cheat Sheet
Recall the core building blocks, their scope and their defaults on one page before an exam or interview.
By Rahul Agarwal · 15 years in web development
Everything on one page
CIDR: addresses = 2^(32 - prefix); /16 = 65,536, /24 = 256. Private ranges: 10/8, 172.16/12, 192.168/16. VPC: isolated, regional in AWS and Azure, global in Google Cloud; primary CIDR fixed after creation in AWS. Subnet: AZ-scoped in AWS, regional in Google Cloud and Azure; AWS and Azure reserve 5 addresses, Google Cloud 4. Public subnet: route table has 0.0.0.0/0 -> IGW. NAT gateway: outbound only, zonal, sits in a public subnet. IPv6: globally routable; use an egress-only IGW for outbound-only. Route selection: longest prefix wins; local route cannot be removed. Security group: stateful, allow-only, attached to interfaces, can reference other SGs. NACL: stateless, allow and deny, ordered by rule number, subnet-wide. Peering: non-transitive, no overlapping CIDRs, routes on both sides. Transit gateway: hub-and-spoke with route tables for segmentation. Endpoints: gateway (S3, DynamoDB) or interface (PrivateLink).
The revision path
Revise in three passes: rebuild the mental model, practise explaining designs aloud, then test yourself with mixed questions.
Draw before you answer
In interviews, sketch the VPC, subnets per AZ, gateways and arrows for traffic before speaking. Most follow-up questions ('what if this AZ fails?', 'how does the reply get back?') become obvious on the drawing.
Quick check: Which pair correctly contrasts security groups and NACLs?
- SGs are stateless; NACLs are stateful
- SGs are stateful and allow-only; NACLs are stateless with allow and deny rules
- Both are stateful and allow-only
- SGs apply per subnet; NACLs apply per interface
Answer
SGs are stateful and allow-only; NACLs are stateless with allow and deny rules — Security groups track connections and only allow. NACLs evaluate each packet independently and support explicit denies.