Valet Key Pattern
Grant clients direct but scoped access to resources: pre-signed URLs, SAS tokens, temporary credentials, and minimizing proxy bottlenecks.
The Valet Key Pattern
Imagine handing your car to a valet. You give them a special key that only starts the ignition and unlocks the driver's door — it cannot open the glove compartment or trunk where valuables are stored. The Valet Key pattern applies the same idea to distributed systems: instead of routing large data transfers through your application server (a bottleneck), you issue clients a temporary, scoped credential that allows direct access to a specific resource in storage.
The most common implementations are AWS S3 Pre-Signed URLs, Azure Blob Storage Shared Access Signature (SAS) tokens, Google Cloud Storage signed URLs, and AWS STS temporary credentials. These credentials are time-limited, scope-limited, and carry no standing privileges.
Why Use the Valet Key Pattern?
Without the Valet Key pattern, clients must upload or download large files through your application server. This creates a bandwidth bottleneck, increases server CPU/memory load, and concentrates risk — your application server holds long-term storage credentials. The Valet Key pattern eliminates the proxy:
| Aspect | Without Valet Key (Proxy) | With Valet Key (Direct) |
|---|---|---|
| Data path | Client → App Server → Storage | Client → Storage (direct) |
| Server load | App server handles all I/O | App server only issues tokens |
| Bandwidth cost | Double egress (storage → app → client) | Single egress (storage → client) |
| Credential exposure | App server holds long-term storage keys | Client gets short-lived, scoped token only |
| Scalability | App server is the bottleneck | Storage scales independently |
Sequence: S3 Pre-Signed Upload URL
Scoping and Security Controls
A Valet Key should be minimally scoped — grant the exact access needed and nothing more. The following controls should be applied when issuing a valet key:
- Short TTL: Expire within minutes (5–30 min for uploads, seconds for downloads of sensitive content). Never issue non-expiring URLs.
- Single resource scope: The URL/token should target a specific object key, not an entire bucket or container.
- HTTP method restriction: A PUT pre-signed URL cannot be used for GET, and vice versa.
- IP allowlisting: Where supported, restrict token use to the requesting client's IP range.
- Content-type enforcement: Use S3 pre-signed URL conditions to enforce expected content-type and max file size at the storage level.
- Audit trail: Log all token issuances in your application, including who requested them and for what resource.
Pre-Signed URL Leakage
A pre-signed URL is a bearer credential — anyone who has it can use it until it expires. Avoid logging full pre-signed URLs in application logs, sending them over unencrypted channels, or embedding them in client-side code. Treat them like short-lived passwords.
Real-World Implementations
| Platform | Mechanism | Key Feature |
|---|---|---|
| AWS S3 | Pre-Signed URLs (GET/PUT) | HMAC-signed query params, configurable TTL, condition keys |
| Azure Blob Storage | Shared Access Signature (SAS) | Service, Container, or Account level; IP restrictions, permission flags |
| Google Cloud Storage | Signed URLs (V4 signing) | Service account signature, URL-scoped permissions |
| AWS STS | Assume Role / GetFederationToken | Temporary IAM credentials with policy boundaries, session tags |
Interview Tip
The Valet Key pattern is a perfect answer for 'how would you handle large file uploads in your system?' It demonstrates you understand both performance (no proxy bottleneck) and security (short-lived, scoped tokens). Always mention the TTL, scope restrictions, and the notify-on-complete pattern for triggering downstream processing after the upload. Bonus: mention server-side encryption at rest and how S3 can enforce it via bucket policy, independent of the upload credential.