← Concepts

阅读中文版本

Origin Shield

An origin shield is an additional CDN caching tier — one shield region in front of the origin — collapsing N edge POPs into one shield, multiplying effective cache depth and cutting origin load.

performance

Definition

Origin shielding inserts a designated parent cache layer between CDN edge POPs and the origin. Edges fetch from the shield; only the shield fetches from the origin. Total cache capacity becomes edge count times edge hit rate plus shield retention, sharply reducing origin request volume and improving byte hit ratio for long-tail content.

Context and scope

Configured on CDNs for origins with strict rate limits or high per-request cost. Also a resilience layer absorbing origin outages via extended stale serving.

Common misconceptions

  • Shields add latency to every request — shields add a hop only on edge misses; hits at the edge are unaffected
  • Every region should be a shield — the point is exactly one shield point per origin; multiple shields re-fragment the fan-in
  • Shielding is only for traffic reduction — it also isolates the origin from edge retries and lets stale serving persist longer in one place

Anti-patterns

  • Configuring shields per continent and recreating the fan-in the shield was meant to collapse
  • Forgetting the shield cache size when sizing origin capacity, since shield eviction policy now governs origin load
  • Routing non-cacheable dynamic traffic through the shield and serializing all requests through one region

Related concepts

Related examples

Authoritative source

https://docs.fastly.com/en/guides/shielding-your-origin

What it is

CDN edges cache independently: the same long-tail object misses at each POP. A shield sits between them all and the origin, so the object is fetched once and served to every POP from the shield. The origin sees one client instead of dozens.

How it works

Edges are configured with the shield as their fetch origin. The shield maintains a large cache with its own TTLs and stale policies, and typically applies request coalescing at its fetch point. Choose the shield region near the origin, not near users, because all edge fill traffic transits it.

When to use it

Origins with rate limits or costly computation, long-tail catalogs where per-POP caches miss heavily, and DR scenarios wanting a single choke point for origin protection. The shield also concentrates stale-serving policy in one place during origin outages.

Pitfalls

The shield is a new single point of failure: its outage routes edge fill traffic straight to origin or fails requests, depending on configuration. Shield capacity sizing needs the same rigor as origin sizing. Dynamic, non-cacheable traffic must bypass the shield or the one-region hop serializes everything.