When you hand your car to a valet, you don't give them your full keychain. Many cars come with a valet key that starts the engine and unlocks the doors but won't open the glovebox or trunk. It grants exactly the access the valet needs — and nothing more.
The Valet Key pattern applies that idea to cloud storage. Instead of routing every file upload and download through your application, you hand the client a narrow, short-lived token that lets it talk to storage directly — but only to one specific resource, only for a moment.
The problem
Suppose users upload videos to your app. The naive flow has every byte travel from the user to your application server, which then forwards it on to storage. Your servers become a pointless relay — paying for the bandwidth twice, tying up worker threads for the duration of a slow upload, and turning into a bottleneck the moment traffic spikes.
The obvious fix is to let clients hit storage directly. But you can't just publish your storage credentials — that would hand every client the keys to everything. You need a way to grant access that's both direct and tightly limited.
App server (relay)Every upload and download flows through here on its way to storage. It pays for the bandwidth twice and ties up a worker thread for the whole of each slow transfer.
StorageWhere the files actually belong — but clients can't reach it directly without being handed the keys to everything, so the app stays stuck in the middle.
How it works
The client first asks your application for permission to access a resource. Your app authenticates the request, decides what the client is allowed to do, and then mints a valet key — a token (such as a signed URL or SAS token) scoped to a single object, a single operation like upload or download, and a short expiry. It returns that token to the client and steps out of the way.
Armed with the token, the client talks directly to storage, bypassing your application entirely. The big payload never touches your servers; they only handled the tiny permission check. Because the token is so narrow, a leaked one is nearly worthless — it grants one operation on one object for a few minutes. The diagram below shows the client getting a scoped token from the app, then uploading straight to storage.
- AppAuthenticates the client and mints a scoped, short-lived token for one object and one operation — then steps out of the data path.
- StorageAccepts the client's upload or download directly, authorized by the valet key; big payloads never pass through the app.
Keep the token as narrow as it can possibly be. Scope it to one object, the single operation it needs, and the shortest expiry the workflow tolerates. The whole security argument rests on the token being nearly useless if intercepted — a broad, long-lived key undermines the entire pattern and is barely safer than sharing your real credentials.
When to use it
Reach for the Valet Key whenever clients move large amounts of data to or from storage — media uploads, document downloads, data exports. Taking your servers out of the data path saves bandwidth, frees up capacity, and usually makes transfers faster for the user too. It pairs well with federated identity: the user proves who they are, then your app grants a scoped key for exactly what they're allowed to touch.
It's less suitable when you need to inspect, transform, or validate the content as it passes through — a job for a gatekeeper or an API gateway in the request path instead. And it depends on your storage supporting scoped, time-limited access tokens, which the major cloud providers all do. When those conditions hold, it's one of the cleanest ways to scale data transfer.