23 - Gatekeeper and Valet Key Patterns - Secure your APIs and Resources
Continuing the ‘Architecting for the Cloud, one pattern at a time’ series, Chris and Peter Piper explore two closely related cloud design patterns that address a core challenge in distributed systems: how do you give clients access to exactly what they need — and nothing more?
The Gatekeeper Pattern
The Gatekeeper acts as a dedicated intermediary between untrusted clients (the public internet) and trusted backend services. Rather than exposing internal services directly, all traffic flows through the Gatekeeper, which can enforce:
- Authentication and authorization
- Input validation and sanitization
- Protocol translation (e.g., REST to SOAP)
- Rate limiting and subscription tier enforcement (free tier vs. paid tiers)
- Logging and monitoring
The Valet Key Pattern
Where the Gatekeeper controls who can access a service, the Valet Key pattern controls what a client can access and for how long. A client requests a time-bound, scope-restricted token (such as an Azure SAS token) from a trusted service, then uses that token to access a resource — like Azure Blob Storage — directly, without routing every request through a central host. This improves performance and reduces operational load while maintaining security through expiry and minimal-permission scoping.
Azure Implementation Options
The episode covers practical implementation options on Azure including Azure API Management (for gatekeeper scenarios), Azure Key Vault, and Azure App Configuration — along with design considerations around token caching, key rotation cost implications, and the tradeoffs of different approaches.
This episode is part of an ongoing series on cloud design patterns. Previous episodes covered the API Economy, Backends for Frontends, Strangler Pattern, Anti-Corruption Layer, and Gateway Aggregation and Routing patterns.
Related Content
5 - The API Economy
APIs are the connective tissue of modern cloud architectures — but poor API design compounds into technical debt that is expensive to unwind. In this episode, Chris Reddington and Peter Piper explore the full lifecycle of API design: defining versioning contracts up front, modernising legacy APIs using the Strangler and Façade patterns, and securing APIs with JWT tokens, OAuth 2.0, and OIDC. They also cover Azure API Management patterns, circuit breakers, throttling, key rotation with Azure Key Vault, and the DevSecOps practices that keep an API estate healthy at scale.
19 - The Event Sourcing, Materialized View and CQRS Patterns
What if you stored not just the current state of your data, but every event that produced it? The Event Sourcing pattern captures the full history of changes as an append-only log — enabling audit trails, temporal queries, and history replay. Combined with Materialized Views for efficient read-side querying and CQRS for command/query separation, these three patterns form a cornerstone of modern event-driven architecture. Chris and Steph explore all three in this episode of Architecting for the Cloud.
16 - The Backends for Frontends and Strangler Pattern with Peter Piper
Managing APIs across web, mobile, and multiple consumer types creates tight coupling that slows modernisation and makes versioning painful. In this episode, Chris Reddington is joined by Peter Piper to explore the Backend for Frontends (BFF) pattern — creating dedicated backends tailored to each consumer — alongside the Strangler Fig pattern for incrementally migrating legacy monoliths without disrupting existing clients. The Façade pattern also features as a key decoupling mechanism for smooth API migrations. Part of the "Architecting for the Cloud, One Pattern at a Time" series.