Under what circumstances would offloading assets to object storage plus a CDN actually be the wrong call, and what would you use instead?

## The bet the pattern makes Static content hosting via object storage plus a CDN is a bet that a large fraction of requests for a given resource can be served identically to many different users, and that the resource is requested often enough that caching it pays back the fixed overhead of the pattern — extra infrastructure, cache-key discipline, versioning strategy. When either half of that bet fails, the pattern stops being a clear win and can become a net negative. ## Content that is not shareable The first and most common failure of the bet is content that is not actually shareable across requesters — genuinely personalized responses, like a user's dashboard HTML rendered server-side with their own data embedded, or an API response scoped to an authenticated user's account. Even if you technically ran such a response through object storage and a CDN, the effective cache hit ratio would be close to zero, because no two users' requests should ever return the same cached bytes; you'd be paying the operational and latency overhead of an extra hop with essentially none of the caching upside. The correct approach for this content is to keep it dynamic — served from the app tier with normal request-scoped logic — and reserve static hosting for the genuinely shared, non-personalized pieces of the page, which is exactly the split most modern web apps already make. ## Traffic too thin to warm anything up The second failure mode is scale mismatch in the other direction: very low-traffic content, such as an internal admin tool used by a handful of engineers, or a low-traffic B2B portal. Here the argument for CDN offload is weak on both dimensions the pattern needs: - request volume is too low for edge caching to meaningfully warm up, and - the absolute bandwidth/compute savings from offloading are small in dollar terms relative to the fixed complexity cost of standing up and maintaining a separate storage bucket, CDN distribution, cache-invalidation discipline, and additional access-control surface area. For this kind of workload, serving assets directly from the app tier is often genuinely simpler and cheaper to operate, even though it's 'less scalable' in the abstract — scalability that will never be exercised isn't worth its operational tax. ## Where the law constrains the copies A third, sharper failure mode is regulatory: data residency and compliance requirements — certain financial or healthcare data, or jurisdictions with strict data-localization law — can make broad CDN edge replication a liability rather than a benefit. A CDN's value proposition is caching content at PoPs physically close to users worldwide, but that means copies of the content may transiently or persistently exist in countries whose legal regimes the data isn't supposed to touch. Some CDNs offer region-restricted distribution to address this, but that's a constrained, more expensive configuration that partially forfeits the pattern's core benefit, and for the most sensitive content it may be simpler and safer to serve from a region-pinned private store with no broad CDN caching at all, accepting the latency cost as the price of compliance certainty. ## Cost-structure mismatch A fourth, more subtle failure mode is cost structure mismatch for specific traffic shapes: object storage and CDN pricing typically has both a per-GB transfer component and a per-request component. Workloads dominated by an enormous number of very small, mostly-uncacheable requests — think per-user generated fragments requested once each by a huge number of distinct, rarely-repeating keys — can end up paying more in aggregate request-count charges and cold-miss origin fetches than they would have paid simply serving that traffic from compute, especially if the content's uncacheability means the CDN is mostly acting as an expensive, request-charged pass-through rather than actually absorbing traffic at the edge. ## The diagnostic questions Recognizing these cases requires reasoning about the pattern's actual mechanism rather than applying it as a default. The diagnostic questions worth asking before committing to static hosting are: 1. Is this content identical across the users who will request it, or can it be made so by stripping personalization into a client-side fetch layered on top of a cached shell? 2. Is request volume high enough, and traffic geographically distributed enough, that edge caching will actually warm up rather than mostly missing? 3. Are there legal constraints on where copies of this data may physically reside? 4. And does the request/byte cost profile of the actual traffic favor CDN economics, or would it be cheaper served directly? ## Where teams opt out A concrete real-world instance where teams have deliberately opted out of broad CDN caching is authenticated, per-tenant SaaS dashboards where the HTML and API responses are inherently personalized — those systems typically use CDN/object storage only for the genuinely static shell assets (JS/CSS/fonts) while keeping all tenant-specific data on directly-served, non-cached paths behind normal auth, precisely because attempting to cache the personalized parts would offer no benefit and would risk accidentally leaking one tenant's cached response to another if cache-key discipline ever slipped.