OSI Model for Cloud Engineers

Why this matters

Cloud load balancers, firewalls, and proxies are sold by layer — an L4 NLB behaves nothing like an L7 ALB, and pricing reflects it. If you can't articulate which layer a problem lives at, you'll reach for the wrong service and pay for headers you never inspect.

Demo

Inspect how AWS exposes layer-3 routing, layer-4 NLB, and layer-7 ALB as distinct primitives.

Try it yourself

1. Run the L3 route-table command and identify which destination CIDR routes to your internet gateway vs a NAT.
2. List both NLBs and ALBs in your account and note which ones have listeners on port 443 with TLS termination (L7 only).
3. Pick one ALB rule and trace which OSI layer the rule's match condition operates at (host header = L7, source IP = L3/L4).

Prompt your AI

Use these three in order. Each builds on the one before.

1. Basics & terminology

In one paragraph, explain the OSI model layers 3, 4, and 7 like I'm new to cloud — what each layer can and cannot see about a packet.

2. Why it works (the mechanism)

Walk me through how a request from a browser to a cloud-hosted API traverses the OSI stack, naming the cloud component at each layer it passes through.

3. Advanced — application & what's next

Given a service that needs both mTLS termination and IP allow-listing, would you put the IP filter at L3, L4, or L7 — and why does that choice affect cost and latency?

References

• AWS — Choosing between ALB and NLB
• RFC 1122 — Internet host requirements (layer model)