Presigned URLs vs. Spaces CDN — can I get both private access and edge caching?

Question

Hi all,

I’m building an image gallery app backed by DigitalOcean Spaces (bucket in fra1, CDN enabled). Public images work great through the CDN endpoint, but now I need to serve private images too.

My current approach is generating presigned URLs with the AWS SDK (v3, S3-compatible client) with a 15-minute expiry. That works, but two things bother me:

Presigned URLs only work against the origin endpoint (<bucket>.fra1.digitaloceanspaces.com), not the CDN endpoint (<bucket>.fra1.cdn.digitaloceanspaces.com) — so every request for a private image skips the CDN entirely. Is that expected, or is there a way to have the CDN honor presigned requests?
Since each presigned URL has a unique query string, even if caching did work, wouldn’t every URL be a cache miss anyway?

What are people actually doing for this? Options I’m considering:

Keep objects private and just eat the origin latency for authenticated users
Proxy images through my backend and cache there (feels like I’m rebuilding a CDN)
Make objects public with obfuscated/unguessable keys and rely on the CDN (uneasy about security-by-obscurity)

App is a Node.js backend on a basic Droplet, images are 200 KB–2 MB, maybe 50k requests/day. Any patterns or gotchas would be appreciated. Thanks!

KFSys · Answer

Heya, this is expected behavior, and your two problems are actually the same problem. Presigned URLs are SigV4, and the signature covers the Host header. You signed for bucket.fra1.digitaloceanspaces.com , so when the request comes through the CDN hostname the signature doesn’t match. The CDN edge doesn’t validate signatures at all — only origin does. There’s no way around this on Spaces currently, the CDN has basically zero config (no custom cache keys, no edge auth). And even if it did work, you answered your own question #2 — unique query string per user means every request is a cache miss. Presigned + CDN just don’t compose. That said, 50k req/day is under 1 req/sec. You’re overthinking the origin latency part. If you go with presigned URLs, one trick makes them way better: don’t sign for “now + 15min”, sign for expiry rounded up to the next 15-minute clock boundary. That way everyone asking for the same image inside a window gets the same URL, and browser caching suddenly works. Set Cache-Control on the objects with a max-age shorter than the window and you’ve recovered most of what the CDN was giving you. The unguessable-key option isn’t security by obscurity, for what it’s worth. A 128-bit random key in the path is exactly as hard to guess as a presigned URL signature — it’s the same entropy, just without an expiry. Slack served attachments this way for years. The actual tradeoffs are: leaked links work forever (until you delete/move the object), and anyone the user forwards a link to can see the image. Also make double sure listing is off on the bucket or the random keys are pointless. If your “private” just means “strangers shouldn’t stumble into these”, this is the easy answer and you keep the CDN. If “private” means revocable, per-user access — proxy it. But don’t write the caching in Node, just put nginx in front with proxy_cache pointed at Spaces and auth_request to your app for the permission check. At your volume a basic droplet will be bored.

Bobby · Answer

Hi there, Your understanding is correct on both points. Presigned URLs only work against the origin endpoint, not the CDN, and unique query strings mean every request is a cache miss anyway. This is not a DigitalOcean-specific limitation, it is just how presigned URLs and CDN caching fundamentally conflict with each other. For your scale and use case, here is how I would think about the options: Proxying through your backend is not as bad as it sounds for 50k requests/day at 200KB-2MB. You can cache aggressively on your end using something like node-cache or Redis with a short TTL tied to your auth session, serve the image with proper cache headers, and the Droplet handles it fine. The downside is egress cost since traffic goes through your server rather than the CDN. The obfuscated key approach is more legitimate than it might feel. If your threat model is “prevent casual unauthorized access” rather than “protect truly sensitive content”, UUIDs as keys plus CDN caching is a reasonable tradeoff that a lot of image gallery apps use in practice. The CDN edge caching works properly and latency is good. Just be honest with yourself about whether your images are truly private or just not publicly listed. For genuinely private content where latency matters, the proxy approach with server-side caching is the most correct architecture. Your backend validates the session once, fetches from Spaces, caches the response for the session duration, and subsequent requests hit your cache rather than Spaces. At 50k requests/day the Droplet will handle proxying without breaking a sweat, and the egress cost through Spaces is predictable. I would start there before over-engineering it.

alexdo · Answer

Heya, SigV4 signs the Host header, so a signature made for the origin bucket hostname can’t validate through the CDN hostname, and the proxy-based fix. The one thing worth adding is where this actually stands on DigitalOcean’s side: there’s an open feature request for signed URLs on the Spaces CDN that’s been sitting at “under review” since 2018, with 81 votes and no staff commitment to a timeline. Worth knowing before you sink time into a workaround, this isn’t a config you’re missing, it’s a gap DigitalOcean hasn’t committed to closing, so the proxy approach is the durable answer rather than a stopgap. On the proxy itself, one refinement worth considering over routing bytes through Node and Redis: have your backend do only the auth check and presigned URL generation, then return an X-Accel-Redirect header pointing nginx at an internal location that proxies to the Spaces origin with proxy_cache enabled. nginx handles the actual byte-shoveling and caching from there, so your Node process stays a lightweight auth decision instead of streaming 200KB-2MB files through itself and a cache layer on every request. At 50k requests a day that’s not going to break anything either way, but it keeps your app process doing less work per request as you scale past that.

Become a contributor for community

DigitalOcean Documentation

Resources for startups and AI-native businesses

The developer cloud

Start building today

Report this

Presigned URLs vs. Spaces CDN — can I get both private access and edge caching?

Related questions

How Can I Improve the Speed of an E-commerce Website?

How can I improve the speed of an e-commerce website?

How to setup ssl for Spaces CDN

CDN Bandwidth Usage for Cache Hits on Spaces (S3-Compatible Storage)

CDN Bandwidth Usage for Cache Hits on Spaces

Intermittent 500/502 from CDN while origin returns 200 on mp3 requests

Intermittent 500/502 from CDN while origin returns 200 on mp3 requests

How to improve CDN ingress latency?

How to setup CDN on Digital Ocean?

How to Optimize Ghost CMS Performance on DigitalOcean Droplets?

Is there really no way to track CDN egress for my app platform app?

Best Practice to Upload SSL Certificates to DigitalOcean Spaces Custom Subdomain Using Certbot Hook

Report this

Presigned URLs vs. Spaces CDN — can I get both private access and edge caching?

Related questions

How Can I Improve the Speed of an E-commerce Website?

How can I improve the speed of an e-commerce website?

How to setup ssl for Spaces CDN

CDN Bandwidth Usage for Cache Hits on Spaces (S3-Compatible Storage)

CDN Bandwidth Usage for Cache Hits on Spaces

Intermittent 500/502 from CDN while origin returns 200 on mp3 requests

Intermittent 500/502 from CDN while origin returns 200 on mp3 requests

How to improve CDN ingress latency?

How to setup CDN on Digital Ocean?

How to Optimize Ghost CMS Performance on DigitalOcean Droplets?

Is there really no way to track CDN egress for my app platform app?

Best Practice to Upload SSL Certificates to DigitalOcean Spaces Custom Subdomain Using Certbot Hook