Object Storage & Blob Storage • Presigned URLs & Access ControlMedium⏱️ ~3 min
Trade-offs: When NOT to Use Presigned URLs
Presigned URLs are a powerful pattern but not a universal solution. Understanding when to choose alternatives is as important as knowing when to use them. The decision hinges on revocation requirements, security posture, authorization complexity, and scale characteristics.
Avoid presigned URLs when you need immediate, fine grained revocation. Because presigned URLs are bearer tokens with no server side session state, you cannot revoke individual URLs; your only options are rotating signing keys (affects all URLs) or deleting the object. For use cases like enterprise document sharing where access must be revoked instantly upon employee termination or policy change, use token validating proxies or Security Token Service (STS) federated credentials with short lived sessions and policy enforcement at request time. This trades the performance and cost benefits of direct to storage for the security benefit of centralized, sub second revocation.
For highly sensitive data requiring per request re authorization or complex, dynamic policies (time of day restrictions, multi factor authentication requirements, audit logging of every access), presigned URLs lack expressiveness. Consider API Gateway patterns where every request validates current user state and logs to Security Information and Event Management (SIEM) systems. The added latency (50 to 200 milliseconds per request for policy evaluation) and cost (per request API Gateway charges, typically $3.50 per million requests) are acceptable trade-offs when compliance or security demands it.
Presigned URLs also complicate scenarios requiring real time progress tracking or bandwidth throttling. Because the client talks directly to storage, your backend cannot easily meter bytes transferred or throttle upload speed to enforce fair use. If you need to limit each user to 10 megabits per second upload rate or track progress for user interface updates, proxying through your backend with chunked transfer encoding gives you that control, at the cost of the bandwidth and Central Processing Unit (CPU) overhead you were trying to avoid.
Finally, for internal or trusted server to server integrations, Identity and Access Management (IAM) roles or service account credentials are often simpler and more appropriate than presigned URLs. If your backend service needs to write logs to storage every second, using the service's IAM role is cleaner than generating thousands of presigned URLs. Reserve presigned URLs for external callers (users, partners, untrusted clients) where you cannot distribute long lived credentials.
💡 Key Takeaways
•Immediate revocation requirements: If you must revoke access within seconds (employee termination, detected breach, policy change), presigned URLs fail. Use token validating proxies or Security Token Service (STS) credentials that check live policy on every request. Trade-off: added latency (50 to 200 milliseconds) and operational complexity for fine grained control.
•Complex authorization and audit: Presigned URLs encode authorization at generation time. For dynamic policies (time of day, location, multi factor authentication enforcement, detailed per request logging), use API Gateway or proxy patterns that evaluate current state on each access. Trade-off: approximately $3.50 per million requests API Gateway cost plus 100 to 200 milliseconds latency versus free and <10 milliseconds direct storage access.
•Bandwidth control and progress tracking: Direct to storage uploads bypass your backend, preventing real time progress updates or per user bandwidth throttling. If you need to enforce 10 megabits per second upload limits or show live progress bars, proxy through your backend with chunked transfer. Trade-off: lose bandwidth cost savings and add server load, but gain user experience control.
•Server to server versus client to storage: For trusted backend services writing to storage (logs, backups, internal data pipelines), use Identity and Access Management (IAM) roles or service account credentials, not presigned URLs. Presigned URLs add unnecessary complexity and query per second (QPS) load on signing service when caller is already trusted. Reserve presigned URLs for external, untrusted callers who cannot hold long lived credentials.
📌 Examples
Enterprise document sharing: Law firm needs to share case documents with external consultants but must instantly revoke access if consultant contract ends. Presigned URLs would remain valid until expiration (minutes to hours). Instead, use token validating proxy: consultant requests document with JWT, proxy validates token with live user directory (100 ms), then streams from storage. On termination, directory disables consultant instantly; next request fails.
Compliance logging: Healthcare app must log every access to patient records with user identity, timestamp, and reason for Security Information and Event Management (SIEM) audit. Presigned URLs give no per request visibility to backend. Instead, API Gateway validates session, logs access to CloudWatch, then proxies to storage. Added 150 ms latency and $0.0000035 per request acceptable for compliance.
Live upload progress: Mobile app uploading 1 GB video needs to show progress bar and allow cancellation mid upload. Direct to storage presigned URL gives no backend visibility. Instead, client uploads chunks to backend endpoint; backend streams to storage and reports progress via WebSocket. Trade-off: backend handles 1 GB of traffic (bandwidth cost) but user experience is smooth.
Internal logs to storage: Backend service writes 100,000 log lines per minute to S3 for analysis. Using presigned URLs would require generating 100,000 URLs per minute (1,667 queries per second QPS to signing service). Instead, service uses IAM role with PutObject permission, writes directly. Simpler, faster, no signing overhead for trusted service.