14.1 The Edge Blueprint

Advanced

What you will learn

1. The canonical tiers and what each one owns.

2. The three NGINX deployments that cover 90% of real shops.

3. The trust-boundary consequences: TLS, headers, client IPs, and blast radius.

4. The questions that pick the right topology for a given system.

1. The canonical tiers

Strip away vendor names and every web-serving stack has the same tiers — the discipline is knowing what each tier owns (and refusing to let ownership blur):

Module 10 already gave you the L4 option ( stream{} as your own L3/L4 tier); this lesson is about the L7 placements.

2. The three deployments you'll actually meet

Shape A — the single front door. One NGINX tier faces the world; apps sit behind it directly.

internet -> [NGINX L7 edge] -> app1 app2 app3

Everything you've learned lives in one config: TLS (Module 6), routing (2–3), protection (7), caching (8), observability (12). The shape's virtue is one place to reason; its vice is one place to reason about during incidents — and one blast radius for a bad reload. It's the right answer up to surprising scale (one box, 10k+ rps, everything you learned in Module 9).

Shape B — tiered edge. An outer tier (often the cloud LB or a first NGINX layer) handles coarse concerns; an inner tier owns per-service policy.

internet -> [cloud L4 / first NGINX] -> [per-team NGINX tiers] -> apps

Now PROXY protocol (Lesson 10.3) becomes load-bearing — the client address must survive the extra hop — and TLS has a decision to make at every boundary: terminate at the edge and re-encrypt inward (inspection + internal mTLS from Module 6), or pass through at L4 and let inner tiers own certs (Lesson 10.5). Real shops usually terminate at the outermost tier and run mTLS inside — the "TLS everywhere, plaintext nowhere" pattern, with the certificate chain (edge cert from public CA, internal certs from the private CA) as two separate PKI stories.

Shape C — per-cluster ingress (Kubernetes-shaped). NGINX (or a controller driving it) is the cluster's front door; the unit of deployment becomes Ingress resources, not config files. Lessons 14.3–14.5 build this one in full.

3. Trust-boundary consequences

Every tier boundary is a trust boundary, and three things change when you cross one:

Client identity. Each hop that terminates TCP resets the peer address to the proxy's. The fixes, in order of preference: PROXY protocol (L4, Lesson 10.3), X-Forwarded-For + real_ip (L7, Module 4) — and the rule that makes them safe: only trust forwarding headers from known addresses ( set_real_ip_from). An X-Forwarded-For accepted from the public internet is a spoofing vulnerability with a standards body's blessing.

TLS and payload visibility. Where TLS terminates is where inspection is possible — WAF rules (Module 7), cache keys (Module 8), golden-signal logs (Module 12). Terminate later (pass-through), and every one of those tools goes dark at that tier. The "where do we decrypt?" question is simultaneously a security question, a features question, and an observability question — architect it deliberately, in writing.

Blast radius. Shape A's single tier means a config error is a global outage (your nginx -t in CI is the mitigation); tiered shapes contain failures but multiply the places they can happen. The operational answer is the same discipline Module 12 gave you: every tier logs in the same shapes, so the investigation crosses tiers without translating.

4. The questions that pick the shape

Ask in order; stop at the first "no":

1. One team or many? One team owning all routing → Shape A is honest and fast. Many teams → tiering (or per-cluster ingress) prevents config-commit collisions.

2. Does the platform own the front door? If you're on a cloud LB anyway (you almost always are), treat it as the L4 tier and plan PROXY protocol from day one.

3. Compliance zones? PCI/scoped data often requires a boundary — a dedicated tier whose blast radius (and audit trail, Lesson 12.5) is separately reviewable.

4. East-west traffic volume? Service-to-service traffic dwarfs north-south in mature systems — internal gateways (Shape B's right side) become their own project with their own capacity planning (Module 9) and their own PKI.

Try it yourself

• Your own single-tier install IS Shape A run honestly: isolated prefix, nginx -t before every start/reload — the discipline that keeps a single-tier edge safe.

• Rehearse Shape B's trust problem: point Module 4's XFF receipts at this lesson — then send a forged X-Forwarded-For from "outside" (a curl that isn't in set_real_ip_from) and watch NGINX ignore it.

Q&A

Q: Should the outer tier be NGINX or the cloud LB? A: The cloud LB if you want managed DDoS absorption and no boxes to patch; NGINX (yours) when you need L7 smarts at the very edge or must run on-prem. Both are correct; mixing their responsibilities is what isn't.

Q: Is a service mesh "just" more tiers? A: For our purposes: yes — sidecars are per-pod L7 tiers whose boundaries face other sidecars. Same rules: forwarding headers, mTLS between hops, logs that cross-correlate (the request_id from Lesson 12.2 becomes the mesh-wide join key).

Q: How many tiers is too many? A: When the average request crosses more proxies than the debugging team can enumerate from memory, latency budget and incident response both degrade. Three L7 hops is a common ceiling; four needs a written justification.

Takeaways

• Tiers have owners: L4 absorbs, L7 routes and protects, services think, internal gateways segment. Blur ownership and you blur blame.

• Three shapes cover reality: single front door, tiered edge, per-cluster ingress — pick by team count, platform, compliance zones, and east-west volume, in that order.

• Every boundary resets client identity and decides payload visibility: PROXY protocol / XFF with trusted sources only, and a deliberate terminate-vs-passthrough decision per hop.

• Blast radius trades against coordination cost — contain it with nginx -t in CI and uniform logging shapes, not with hope.