A user in Sydney loads your homepage and waits 600 ms while a 2 MB hero image crosses the Pacific from your origin server in Virginia. Multiply that by every static asset, every product photo, every video thumbnail — and your origin spends most of its CPU budget pushing bytes that haven't changed in weeks. This is what CDNs and object storage exist to fix. Object storage gives you a virtually infinite, durable place to put files. A CDN puts copies of those files close to your users so the request never reaches your origin in the first place.

They are different tools that almost always work together. Object storage (S3, GCS, Azure Blob) is the durable source of truth: cheap per GB, eleven nines of durability, accessed by HTTP. CDN (CloudFront, Cloudflare, Fastly, Akamai) is a global cache layer: hundreds of edge locations near users, designed to absorb traffic before it reaches your origin. The CDN talks to object storage; users talk to the CDN; object storage rarely sees direct user traffic.

The geography matters more than people expect. Edge locations (also called PoPs — points of presence) are small caching servers placed in major metros. CloudFront has 600+ PoPs; Cloudflare has 300+; Akamai has 4,200+. The architecture is hierarchical: a user hits the nearest edge, which on cache miss may consult a regional “mid-tier” cache, which on miss queries your origin. The further upstream the request goes, the slower it gets and the more it costs you.

The analogy: object storage is your central warehouse. The CDN is the network of corner stores that hold the products people actually buy. Customers walk to the corner store; the corner store re-orders from the warehouse weekly. The warehouse barely sees an end customer.

A CDN supports two ways of getting your files into its caches. Pull (lazy) is the default and the right answer for almost everything: you point the CDN at your origin; on the first request to any URL, the edge fetches from origin, caches it, and serves it. Subsequent requests within the TTL are served from edge. New files are discovered automatically. Push (eager) is the rarer model: you upload directly to the CDN's storage; you control which files exist and when they update. Push made sense for video distribution in the early 2000s; pull dominates modern web because it's self-managing and works equally well for content you didn't know you needed.

The metric that matters is cache hit ratio at the edge. A well-tuned static site CDN runs 95–99% hit ratio — the origin sees only the long-tail traffic. A poorly-tuned one drops to 50–70%, which often means too-short TTLs, varying cache keys (e.g. including useless query parameters), or content that should be cacheable but isn't marked as such. Hit ratio is a direct line to your origin egress bill.

Object storage looks simple from the outside — a key, a value, an HTTP API — but the engineering behind “eleven nines of durability” is substantial. A PUT to S3 doesn't complete until the object has been written to multiple devices across multiple availability zones. Reads pull from any of those copies. Background processes constantly scan for bit-rot and repair lost replicas. The flat key namespace is an illusion implemented over a partitioned, distributed key-value store; what looks like “folders” in your S3 console is just keys with slashes in them.

Not all data deserves the same storage cost. Object storage providers tier their offerings based on access frequency and retrieval latency. Hot data (regularly accessed): standard storage, ~$0.023/GB-month. Infrequent access: 60% cheaper but with retrieval fees. Archive (Glacier / Archive Tier): ~$0.001/GB-month but minutes-to-hours to retrieve. Lifecycle policies move objects through these tiers automatically — e.g. logs go to standard for 30 days, infrequent for 60 days, glacier for 7 years, deleted after.

For nearly any web application serving public, cacheable assets, the CDN-on default is correct. The cost is small, the operational complexity is low, and the latency win is unambiguous. The cases where a CDN doesn't help are narrower than people imagine: heavily personalised per-request content, internal-only APIs, and content that changes on every request. Even then, edge compute (Cloudflare Workers, Lambda @ Edge) lets you push some logic out so personalisation doesn't mean “always hit origin.”

Three storage paradigms exist, and they are not interchangeable. Object storage (S3): HTTP API, immutable objects, infinite scale, eventual-then-strong consistency, no random updates. Block storage (EBS, GCP Persistent Disk): raw block device attached to one VM, supports filesystems, low latency, fixed capacity. File storage (EFS, NFS, FSx): network filesystem accessible by many VMs, supports POSIX semantics, expensive but compatible with legacy software. Object storage wins for “files served by my web application” in nearly every case. Block storage is what your databases and VMs run on. File storage is for legacy workloads that genuinely require a shared POSIX filesystem.

CDN cache invalidation is the second of the “two hard things in computer science.” You have three real strategies. Versioned URLs (the right answer most of the time): when a file changes, change its URL — app.a3f9b2.js instead of app.js. The new URL is uncached; the old URL keeps serving until natural TTL expiry. Zero invalidation calls, zero coordination. TTL expiry: set a short TTL (e.g. 60 s) and let staleness self-heal. Simple, but every request fetches from origin once per TTL window. Explicit purge: call the CDN API to invalidate a URL or pattern. Slow (propagation across edges takes seconds to minutes), often rate-limited, and historically the most common source of “why is the old version still showing?” bugs.

S3 used to be eventually consistent for new objects in some regions; it became strongly read-after-write consistent globally in December 2020. PUT then immediate GET now reliably returns the new object. List operations are also strongly consistent. The implication: a lot of legacy code defensively retries or sleeps after writes — that defensive code is no longer necessary on S3 specifically, though it's still required on most other object stores. Don't assume strong consistency on every object store; check the docs for whichever you use.

Two patterns turn up in nearly every production system that gets static content right. Presigned URLs: generate a short-lived signed URL that grants temporary access to an object — clients upload directly to S3 without the bytes ever flowing through your application servers. Critical for video uploads, large file uploads, anything that would otherwise saturate your app tier. CDN for API acceleration: even dynamic API responses benefit from edge proximity — the CDN handles TLS termination, request collapsing, and geographic routing even when nothing is cached. The TTFB win is real even at zero cache hit ratio.