Valet Key
The Valet Key pattern gives clients temporary, limited-scope credentials to access a storage system (typically object storage like S3) directly, bypassing the application server. Instead of streaming a 5 GB upload through your service, the service mints a presigned URL that lets the client write directly to S3 for the next 15 minutes, scoped to one bucket key. The pattern is named after hotel valet keys — limited-functionality keys that open doors and start the ignition but not the trunk or glovebox. The result: lower service bandwidth, lower latency, and the service stays stateless.
How it works
The Valet Key pattern takes its name from the valet key in older cars — a key that opens the doors and starts the ignition, but cannot open the trunk or glovebox. The valet can drive the car, but can't access your valuables.
In software, the pattern works as follows:
- The client wants to upload or download a large file (e.g., a 1 GB video).
- Instead of streaming the file through the application server, the client asks the service for a temporary URL.
- The service checks authorization (is this user allowed to upload? what's the size limit? what key should it have?) and mints a presigned URL — a URL with embedded credentials and an expiration.
- The service returns the presigned URL to the client.
- The client uploads/downloads the file directly to/from the storage service (S3, Azure Blob, GCS) using the presigned URL.
- The application server is not in the data path — it only authorized the transfer.
The presigned URL is scoped:
- Method: only PUT (for uploads) or GET (for downloads), not DELETE.
- Bucket/object: only one specific key, not the whole bucket.
- Expiration: typically 5 minutes to a few hours.
- Conditions: optional content-length, content-type, or other constraints.
Cloud implementations:
- AWS S3 presigned URLs — generated by the SDK using the signing key derived from the requester's IAM credentials; works for both upload (PUT) and download (GET).
- Azure SAS (Shared Access Signature) — a signed URI granting specific permissions for a specific resource and time window.
- GCP signed URLs — generated with a service account's private key.
All three implement the same pattern: temporary, scoped, signed credentials that let the client talk directly to storage.
Benefits of Valet Key:
- Lower service bandwidth cost — the app server doesn't move the file bytes. For 100 GB/day of uploads, this saves 100 GB of egress + ingress on the service tier. At cloud egress rates, this is real money.
- Lower service CPU/memory pressure — no streaming buffers, no multipart parsing, no proxying.
- Higher throughput — clients upload directly to S3, which is horizontally scalable to nearly unlimited concurrent transfers. The app server is not the bottleneck.
- Lower latency for clients — direct path to the storage region closest to them, no extra hop through the app server.
- Resumable uploads — S3 multipart uploads with presigned URLs let clients resume interrupted transfers without restarting.
- Stateless app server — the service doesn't hold the upload in memory; it just mints URLs.
- Decoupled scaling — storage scales independently of the service tier.
What the service still owns:
- Authorization — who is allowed to upload, to what key, with what size/content-type limits.
- Audit — record that a presigned URL was issued; correlate with the eventual upload event from S3.
- Post-upload processing — trigger transcoding, virus scanning, thumbnail generation via S3 event notifications.
- Cleanup — set lifecycle rules for abandoned uploads; delete objects never confirmed by the client.
A presigned URL is a bearer token — anyone who has it can use it until it expires. Treat it like a password: don't log it, don't put it in URLs that get shared, don't store it longer than necessary. Mitigations: (1) short expiry — 5-15 minutes for uploads, longer only for very large files; (2) scope tightly — one bucket, one key, one HTTP method; (3) constrain content-length and content-type via POST policy conditions (S3 POST with policy); (4) require HTTPS only; (5) verify the upload after completion (HEAD the object or listen for the s3:ObjectCreated event). If a presigned URL leaks, an attacker can use it for the duration of its expiry — but only for the scoped action.
Valet Key works for both uploads and downloads:
Uploads — the client asks for a presigned PUT URL and writes directly to S3. Use cases: profile pictures, document uploads, video uploads (with multipart for resumability), backups.
Downloads — the client asks for a presigned GET URL and reads directly from S3. Use cases: serving user-generated content (videos, images) without proxying through the app; generating download links for reports/exports; serving private files to authenticated users without streaming through the app.
For downloads, an alternative is to put a CDN in front (CloudFront, Cloudflare) and use signed URLs/cookies from the CDN. This combines Valet Key (signed URL) with edge caching — even lower latency for popular files.
For uploads, the modern pattern is S3 multipart upload with presigned URLs for each part: the client asks the service to initiate a multipart upload, gets back presigned URLs for each part, uploads parts in parallel, then asks the service to complete the multipart upload. This handles multi-GB uploads with resumability and parallelism, all without the service touching the file bytes.
A common variant: S3 POST with policy. Instead of a presigned PUT URL, the service returns a signed policy that the client uses to POST a form (with the file) to S3. The policy can constrain content-length, content-type, and key prefix. Useful for browser-based uploads where you want fine-grained constraints.
Why does the Valet Key pattern reduce application server costs for large file uploads?
Pick one answer.
A presigned URL generated for an S3 upload has leaked publicly. What's the worst an attacker can do, and what should you do?
Pick one answer.
Engineering mental model
Mental model. Think of Valet Key as a deliberate boundary in a system. The boundary exists because something becomes harder to manage when everything is done in one place: latency, scale, failure isolation, consistency, cost, or team ownership. The useful question is not “what does Valet Key mean?” but “what pressure makes this boundary worth introducing, and what new failure mode does it create?”
Before choosing Valet Key, name the workload, the critical user path, the dominant bottleneck, the failure you are trying to absorb, and the trade-off you are willing to accept. If you cannot name those five things, the design is probably premature.
// Pseudocode
request = receive()
result = valet_key(request)
return result
// Production questions:
// 1. What happens on timeout?
// 2. Can this operation be retried safely?
// 3. What is the bottleneck?Back-of-the-envelope reasoning
Numerical lens: write down traffic, payload size, read/write ratio, peak multiplier and durability target before choosing a component. The numbers should justify the architecture.
Interactive thought experiment: Valet Key
Change the variables below and predict what breaks first in Valet Key. The production lab can later reuse these same inputs.
Change one variable at a time. Predict the failure mode first, then move the slider and see whether your mental model matches the simplified system response.
If you are stuck on Valet Key, start by drawing the request path and marking every network hop, stateful component, queue, cache and failure boundary. Then estimate where the system will saturate.
You increase traffic by 10× in a system using Valet Key. What should you inspect first?
Pick one answer.
Which statement is the safest engineering habit when using Valet Key?
Pick one answer.
You have dashboards for traffic, latency, errors and saturation. You can change the architecture, but every change has operational cost.
Production scenario: your system uses Valet Key, traffic suddenly spikes, and p99 latency doubles. What is your first move?
Interview drill
Answer this without notes: When would you choose Valet Key, and when would you intentionally avoid it? Mention at least one bottleneck it addresses, one failure mode it introduces, and one alternative. Then quantify the workload you are designing for.
For Valet Key, define the trust boundary first. Identify who is allowed to perform each action, where credentials live, how they expire, and what a compromised credential can reach.
Numerical sanity check
A practical blast-radius question: if one credential is compromised, how many users, services, records or regions could it affect? Prefer designs where that number is deliberately bounded.
Do not optimize for a memorized definition. Reason from the workload and failure mode.
What is the smallest trust boundary you would enforce for Valet Key, and what would you log so a suspicious action can be investigated later?
Pick one answer.
What you gain, what you pay
- +Application server bandwidth cost drops dramatically — bytes don't flow through it.
- +Higher throughput — object storage scales horizontally to near-unlimited concurrent transfers.
- +Lower latency for clients — direct path to the nearest storage region.
- +Resumable uploads via multipart, parallelizable across parts.
- +App server stays stateless — no upload buffers in memory.
- +Decoupled scaling — storage scales independently of the service tier.
- −App server no longer sees the bytes — can't inspect content inline (e.g., virus scan, format validation must happen post-upload).
- −Presigned URLs are bearer tokens — leaks have consequences for the URL's lifetime.
- −Client must implement upload logic (multipart, retries) instead of just POSTing to the app.
- −Cloud-specific implementation — S3 presigned URLs differ from Azure SAS and GCP signed URLs.
- −CORS configuration needed for browser uploads directly to S3.
How this breaks in production
- Leaked presigned URL is used by an attacker within its expiry — mitigate with short expiries and tight scoping.
- Client uploads invalid/malicious content because the app server can't inspect it — mitigate with post-upload scanning triggered by S3 event notifications.
- Upload size exceeds what the client can handle in memory — use multipart upload with presigned URLs per part.
- CORS misconfiguration blocks browser uploads to S3 — must configure bucket CORS policy.
- Clock skew between client, app server, and S3 — presigned URL may be rejected as expired too early or accepted too late.
- Stale URLs in client code — URL embedded in a long-lived page is expired by the time the user clicks.
Don't fall into these traps
- •Using long-lived presigned URLs (e.g., 24 hours) — increases leak risk; use 5-15 minute expiries.
- •Scoping too broadly — generating URLs that allow access to the whole bucket or multiple methods.
- •Not using HTTPS — presigned URLs over HTTP can be intercepted.
- •Forgetting post-upload verification — the app should listen for s3:ObjectCreated and verify the upload met the constraints (size, type).
- •Not using multipart upload for large files — single PUT fails on network issues and can't resume.
- •Logging presigned URLs — they're bearer tokens; treat them as secrets.
Real systems using this
How real systems implement this
- AWS S3 presigned URLs — The canonical implementation. The SDK signs a URL with credentials derived from IAM; the URL grants PUT or GET on one object for a configurable expiration. Widely used for direct-to-S3 uploads from web and mobile clients.
- YouTube / Google Drive direct uploads — Large file uploads to YouTube and Google Drive use a resumable upload protocol that issues signed URLs for each chunk — clients upload chunks in parallel directly to storage, bypassing the application servers. This is Valet Key with resumability at scale.
- Azure SAS (Shared Access Signature) — Azure's equivalent of S3 presigned URLs. A signed URI grants specific permissions (read, write, list, delete) on a specific resource for a specific time window. Used for direct client access to Azure Blob Storage.
Practice saying it out loud
- Q1What is the Valet Key pattern? Where does the name come from?
- Q2Your app allows users to upload 1 GB videos. Walk me through the design with and without Valet Key.
- Q3A presigned URL has leaked. What's the worst case, and how do you mitigate it?
- Q4How would you handle very large (50 GB) uploads with resumability and parallelism using Valet Key?
- Q5What can't the app server do once it's removed from the data path? How do you recover that capability?
Further reading & references
Core explanations are original NO CAP material. External references are provided for deeper study and standards.
What next?
Mark as understood once the mental model clicks.
Next recommended
Gatekeeper Pattern