In the Gatekeeper cloud design pattern, what does the dedicated gatekeeper host do to a client's request before it reaches a backend service, and why does it run separately from that backend?

## The question it answers The Gatekeeper pattern addresses a simple but consequential question: when a client — especially an untrusted or lightly-trusted one, such as a public internet caller or a third-party integration — needs to reach a backend system that holds sensitive data or credentials, should that client's request ever touch the backend directly? **The pattern's answer is no.** Instead, every inbound request is routed first to a dedicated, deliberately minimal host called the **gatekeeper**. Its only job is to: - **validate the request's shape** — schema, field types, size limits; - **check** authentication/authorization tokens; - **sanitize input** against injection-style payloads; - and **reject** anything that fails those checks outright. Only requests that pass are forwarded onward — typically not straight to the backend either, but to a second, internal 'trusted host' that actually holds the credentials and does the real work (this two-tier split is covered in more depth elsewhere, but even a single-tier gatekeeper embodies the core idea). ## How the host is built Mechanically, the gatekeeper is built to be as small and boring as possible: - minimal OS image; - few installed packages; - no unnecessary services; - and critically, no direct credentials to the backend's data stores. It typically sits in a network segment (e.g., a DMZ or public subnet) that clients can reach, while the backend sits in a separate, more restricted segment the gatekeeper — not the client — is permitted to reach, and even then only through a narrow, well-defined channel. ## Why it exists Why does this exist? The core problem is **attack-surface concentration**. Any component that's reachable by an untrusted client is, by definition, the piece an attacker will probe first — for buffer overflows, injection, auth bypass, deserialization bugs, whatever the vulnerability class of the week is. If that reachable component is the same one holding database passwords, storage account keys, or admin APIs, then a single successful exploit against it is a full backend compromise. The Gatekeeper pattern breaks that coupling: the reachable component is intentionally 'sacrificial' — cheap to rebuild, holding no valuable secrets, and running enough logic to filter obvious garbage but not enough logic to be a rich target itself. Even if an attacker fully compromises the gatekeeper, the blast radius is capped at whatever narrow capability the gatekeeper itself was granted, not full backend access. ## The trade-off The trade-offs run in both directions. On the cost side: - every legitimate request now takes an extra network hop, adding **latency**; - you now operate and patch two classes of infrastructure instead of one; - and validation logic can drift out of sync between what the gatekeeper checks and what the backend actually expects, creating either **false rejections** (gatekeeper is stricter than backend, breaking valid use cases) or, worse, **false acceptances** (gatekeeper misses something the backend is vulnerable to). On the benefit side: - a compromised gatekeeper doesn't hand over the keys to the kingdom; - and the backend's attack surface toward the open internet effectively drops to zero, since the only party allowed to talk to it is the gatekeeper (or the internal trusted host) over an internal, restricted channel. ## Failure modes Failure modes show up in a few recognizable shapes. 1. **First, an under-scaled gatekeeper fleet** becomes a throughput bottleneck or a single point of failure — since all traffic funnels through it, a traffic spike or a bug that exhausts its connection pool can take down access to an otherwise-healthy backend. 2. **Second, 'privilege leakage':** teams under deadline pressure sometimes give the gatekeeper more than the minimum it needs (e.g., direct database credentials 'just to keep things simple'), which quietly defeats the pattern's whole purpose — a compromise of the gatekeeper is now a compromise of everything. 3. **Third, validation drift**, where the gatekeeper's sanitization rules go stale relative to a backend that has evolved its accepted input formats, producing subtle correctness bugs or security gaps that are hard to spot because two components now need to agree on one contract. ## Where it shows up A concrete real-world shape of this pattern: Microsoft's Azure Architecture Center documents Gatekeeper as a reference pattern for scenarios like a public web app that needs to write to Azure Storage or a database on behalf of untrusted users. A fleet of small, load-balanced gatekeeper VMs (or lightweight services) does authentication and payload validation, then hands off validated requests via an internal queue to a separate trusted-host tier that holds the actual storage/database credentials and performs the write. The gatekeeper VMs can be rebuilt from a minimal, hardened image on every deploy, so even a successful RCE against one buys an attacker almost nothing of lasting value.