Summary

  • DigitalOcean says Spaces CDN does not cache presigned requests: each is forwarded to origin, including requests using a CDN or custom domain.
  • This is a documented cache bypass, not merely a poor hit rate caused by changing query strings. Ordinary cache-duration controls do not overturn it.
  • The CDN’s inclusion in the subscription does not make transfer unlimited. Cost and resilience claims need the actual request path, eligible content and measured traffic—not a hostname alone.

One name, different dependencies

A delivery domain is an attractive architectural shorthand. It gives an application one recognisable address for its files and allows an organisation to present its own name rather than a storage provider’s endpoint. The shorthand becomes expensive when it is also treated as proof that every download is served from a cached edge copy.

DigitalOcean’s Spaces CDN guide, verified on 3 September, separates the two functions. A presigned download can use the CDN or a custom hostname. Nevertheless, the company says every such request is forwarded to the Spaces origin and is not cached by its CDN. The stated purpose is hostname consistency rather than the cache hits or latency reduction associated with ordinary cached delivery.

This is not evidence of an incident, a security flaw or an undisclosed service failure. It is a product rule with implications for purchasing and design. A working private-download link proves that the request can reach an object under the chosen access arrangement. It does not prove that a nearby edge has absorbed the work of delivering that object independently of origin.

The distinction matters most when an application’s visible address survives an access-policy change. Publicly cacheable promotional material and access-controlled customer files may look like neighbours under one domain. That shared presentation does not establish a shared cache benefit. A buyer who measures the former and budgets the latter from the same result may be measuring the wrong delivery population.

Bypass is not fragmentation

There is a familiar diagnosis for disappointing CDN results: a URL changes so often that requests seldom reuse the same cached entry. DigitalOcean’s features documentation says ordinary Spaces CDN caching treats each unique URL, including its query string, as a separate asset. That rule makes cache-key fragmentation a legitimate question for eligible requests.

The presigned case is narrower and more decisive. The CDN guide does not say that a signed request is cached under an inconveniently unique key. It says the request is not cached. Reusing an identical signed URL therefore cannot be credited with creating a Spaces CDN hit contrary to that documented behaviour.

Nor is a longer edge cache lifetime a demonstrated remedy. The ordinary TTL setting governs how long eligible cached content remains at the edge before refresh. It does not turn an explicitly bypassed request into an eligible one. Confusing these cases can send an operator through repeated cache tuning while leaving the actual request class unchanged.

That does not establish a universal prohibition on caching anywhere. The evidence concerns the Spaces CDN. It does not describe every browser, intermediary or alternative service, and it must not be promoted into a rule for all S3-compatible storage. Any separate delivery design would need its own access, correctness and invalidation assessment.

A supported endpoint is not a performance promise

The guide describes a specific integration sequence: generate a presigned GetObject URL against the non-CDN endpoint, then substitute the CDN or custom hostname. It limits this arrangement to virtual-hosted-style URLs; path-style URLs, including those generated with forcePathStyle enabled, cannot use the CDN hostname in this way.

Those conditions establish the documented compatibility boundary. They do not imply that a supported endpoint offers cached delivery for the signed request. A successful integration test should therefore keep “download accepted” and “served from Spaces CDN cache” as separate outcomes. The first can pass while the second is excluded by the product rule.

The boundary also includes storage class. Spaces Cold Storage does not support CDN integration or custom CDN endpoints. The analysis here concerns the supported Standard Storage arrangement. It is not a proposal to obtain cached delivery by moving the same signed URL to a cheaper storage class.

None of this requires publishing a live signature or experimenting with customer files. An architectural review can start by identifying the request class and reading its documented treatment. Controlled measurements, if commissioned, should use authorised test material and keep credential-bearing links out of reports and shared diagnostic records.

Included does not mean unmetered

DigitalOcean’s pricing page lists a US$5 monthly Standard Storage subscription with 250 GiB of storage and a 1,024 GiB outbound allowance shared across buckets. Additional outbound transfer costs US$0.01 per GiB. It also says CDN and origin bandwidth share the allowance, including transfer from origin to edge.

The absence of an additional CDN fee is therefore different from the absence of transfer accounting. For a signed delivery workload, a budget cannot assume that repeat demand will be satisfied by Spaces CDN hits. The material inputs are bytes delivered, the relevant metered routes and the remaining shared allowance.

The documentation does not support a universal claim that each signed download doubles its bill. It supplies accounting rules, not the bill for a measured customer workload. Object sizes, delivered traffic and allowance use are needed before converting a delivery pattern into money. A conceptual comparison with cached delivery is not a licence to count every possible leg twice without evidence.

The pricing page separately describes private Spaces traffic using a VPC-local DNS resolver. That is a network-routing condition, not a synonym for an object being private or a URL being signed. Treating access control as proof of an internal, unmetered route would collapse two different decisions into one misleading word.

Resilience needs an eligible copy

For ordinary cached content, the features page says an edge can continue serving a cached asset when origin is temporarily unavailable. The qualification is essential: there must be content available in that cache. It is not a blanket guarantee that every request under the CDN name survives an origin problem.

A signed request that the CDN forwards to origin has no documented Spaces CDN cache-hit fallback to borrow from that description. This does not prove an outage, predict a failure rate or reduce a stated SLA. It establishes that the cached-copy argument has not been demonstrated for this request class.

Buyers consequently need to match delivery promises to the files that matter in their application. Fast public images do not establish equivalent behaviour for protected downloads. A domain and a successful HTTP response are useful observations, but neither is a complete account of where the work occurs or which dependency remains on the critical path.

The practical conclusion is modest and demanding. Keep the access requirement intact; identify the executed delivery path; and evaluate cost and continuity against that path. Hostname consistency is a real feature. Calling it cached insulation would buy a benefit the documented signed-request arrangement does not provide.

Sources