Origin Shield

An origin shield is an extra cache tier. A CDN places it between its edge servers and your origin. Cache misses from the whole network then converge on one designated node before any request leaves for the origin. Fastly describes the effect plainly: "When Shielding is enabled, visitor requests from across the global network funnel through a single, designated shield POP instead." AWS describes its own version the same way: "CloudFront Origin Shield is an additional layer in the CloudFront caching infrastructure that helps to minimize your origin's load, improve its availability, and reduce its operating costs." The point of the tier is arithmetic, not security. A popular object that expires can be fetched from the origin once for the entire network, instead of once per point of presence.

It is not a security product, and not a web application firewall. It does not inspect, authenticate or filter requests. Fastly's own guidance puts "security filtering (e.g., WAF or bot detection)" at the POP connected to the client, not at the shield. By absorbing misses, though, it does help keep the origin available under load. That is why Fastly lists origin shielding among the features that "help protect the availability of your content from DDoS threats". It is also not a second origin, not a failover target, and not free. On every CDN that offers it, it is a setting you switch on per origin. It bills as an extra layer of traffic, and it adds a hop for the misses it handles. Nor does it abolish origin fetches. The object still has to be fetched once. CloudFront's promise is "as few as one request going to your origin", not zero.

How it works

Without a shield, each point of presence works alone. Fastly: "Because each POP acts independently, any time it doesn't have a cached version of the requested resource, it will make a request directly to your origin, even if another POP may be in the process of making the same request." Enabling a shield changes this. It inserts one node in front of the origin, and re-points every other POP at it.

1. The request lands at the nearest POP. It serves the request from its own cache when it can. Shielding is never involved in that case. It "is only applicable to requests that are forwarded to a backend".
2. On a miss, the edge POP forwards to the shield, not to the origin. "If the resource had been previously cached on the shield POP, then it would be returned to the regional POP where it is then cached and returned to the user." The origin is never contacted.
3. If the shield misses too, the shield fetches once. "Otherwise, the shield POP would make a request to the origin server for the resource, cache the response and return it to the regional POP where it is also cached before being returned to the user." One object now exists in two tiers. The next POP to miss is served by the shield.

The two paths look like this:

Without origin shield:
  Edge-AMS ──miss──> Origin
  Edge-FRA ──miss──> Origin    (3 origin hits for same content)
  Edge-NRT ──miss──> Origin

With origin shield (IAD):
  Edge-AMS ──miss──> Shield-IAD ──miss──> Origin  (1 origin hit)
  Edge-FRA ──miss──> Shield-IAD ──HIT──>          (served from shield)
  Edge-NRT ──miss──> Shield-IAD ──HIT──>          (served from shield)

What the tier physically is differs by vendor. On Fastly it is an ordinary POP you nominate per backend by its shield code, such as iad-va-us for Ashburn. On CloudFront it is a regional edge cache in an AWS Region you choose: "Origin Shield leverages the CloudFront regional edge caches feature". So the shield sits below both the edge locations and the regional edge caches, rather than directly below the edge.

Two details keep this from being literally "every miss through one node". The first is what happens if the visitor's nearest POP already is the shield: there is no second hop. On Fastly, "the request lands directly at the shield from the start", and on CloudFront "requests that are made in the same region as your origin will bypass Origin Shield". The second is that the funnel is best-effort, not guaranteed. On Fastly, "if a specified shield POP is inaccessible for a request (e.g., because of intervening network issues), that request will go directly from the edge node to your origin server, bypassing the shield". CloudFront instead uses "active error tracking for each request to automatically route the request to a secondary Origin Shield location if the primary Origin Shield location is unavailable".

Shielding is opt-in everywhere. It is configured on the origin, not on the service as a whole. Fastly is explicit that "origin shielding is not enabled by default. To use it, you must specifically enable it", and that in CDN services "shielding may be enabled when adding or editing an origin server, and may be selected per-origin". On CloudFront, Origin Shield is a property of the origin, and "when you enable CloudFront Origin Shield, you must specify the AWS Region for Origin Shield". Multiple backends therefore mean multiple shields, each chosen for its own origin's location.

Why it matters for a CDN

The shield decouples the number of requests your origin receives from the number of POPs serving your traffic. That is the whole value. It shows up in four measurable ways.

• Concurrent misses collapse. On CloudFront, "requests for content that is not in Origin Shield's cache are consolidated with other requests for the same object, resulting in as few as one request going to your origin". This is request coalescing applied to the whole network. It is what turns a cache stampede after an expiry into a single fetch.
• Spikes stay absorbed. AWS: "handling fewer requests at your origin can preserve your origin's availability during peak loads or unexpected traffic spikes, and can reduce costs for things like just-in-time packaging, image transformations, and data transfer out (DTO)." Fastly makes the same claim with the same hedge, "potentially protecting your origin servers from unexpected spikes in requests for content".
• Long-tail content gets a bigger, shared cache. One node aggregates the whole network's misses. It sees far more traffic per object than any single POP does, so unpopular objects survive in it. Fastly's advice follows directly: "choose a POP that offers the largest cache storage for a better cache hit ratio at the shield, and therefore reduced origin traffic."
• Origin connections concentrate. Cloudflare notes that tiering "concentrates connections to origin servers so they come from a small number of data centers rather than the full set of network locations", which "results in fewer open connections using server resources". Fastly adds a counter-intuitive latency win. All its POPs hold pools of open connections to one another, so routing a miss through the shield can be faster than a fresh origin handshake.

The effect is largest where duplicate origin work is expensive. Examples include just-in-time packaging for live streaming, on-the-fly image processing, on-premises origins with bandwidth limits, and multi-CDN setups. There, AWS points out that an origin otherwise "might receive many duplicate requests for the same content, each coming from different CDNs".

What CDNs do

• Fastly: Shielding. You designate one POP per backend as the shield. It is off by default. It cannot be used with backends declared in VCL: "you cannot apply shielding to backends that you define in VCL." Choosing a shield POP that has a private network interconnect with your origin's cloud can also cut egress cost. The saving, though, depends entirely on the provider. Fastly's table lists free egress for Backblaze B2 and for Azure (at AMS, BFI, CHI, DFW, IAD and PAO only). It lists discounted egress for Google Cloud, and none for AWS.
• Amazon CloudFront: Origin Shield. This is a per-origin flag plus a Region. It is available only in the Regions where CloudFront runs a regional edge cache. Shield hits are visible in logs as OriginShieldHit. Origin Shield also composes with origin groups: "for a given request, CloudFront routes the request to the primary origin in the origin group through the primary origin's Origin Shield." Lambda@Edge origin-facing triggers move to the shield's Region.
• Cloudflare: Tiered Cache. Data centres are split into lower and upper tiers, and "if the upper-tier does not have the content, only the upper-tier can ask the origin for content". Placement can be automatic: Smart Tiered Cache "dynamically selects the single closest upper tier for each of your website's origins with no configuration required". Watch the plan table rather than assuming parity. Tiered Cache and Smart topology are available on all plans, while Generic Global, Regional Tiered Cache and Custom topologies are Enterprise-only.
• Akamai: Tiered Distribution. Servers near your origin are "designated as parents, who will cache your content and serve it to other servers on our platform". It is auto-enabled in the default rule for Adaptive Media Delivery, Download Delivery and Object Delivery. It applies only to cacheable content. Akamai also documents the tradeoff a shield always faces. A Global parent map lowers latency but spreads misses over many parents, so fewer of them hit. A Local map near the origin instead uses "a smaller set of parent servers which increases the likelihood that the object a user requested is in cache".

Watch out for

• Your edge logic runs twice. With shielding on, Fastly says your code "typically executes twice": once at the edge POP and again at the shield. Unconditional rewrites therefore duplicate themselves. Changes made at the shield "are viewed by downstream edge POPs as part of the official payload from your origin servers", so a mistake there is cached network-wide. Split the work. Make origin-facing changes at the shield, and client-facing changes only at the POP talking to the client.
• Hit ratio accounting shifts, and the numbers look worse. An edge miss served by the shield records both events: "we will record both the miss and the hit for the purpose of calculating your cache hit ratio". A request that does reach the origin "will be counted as two misses, one at the edge, and one at the shield". Debug headers gain a token per POP, so X-Cache reads MISS, MISS or HIT, MISS. Where the second token is HIT, the first describes when the object was originally fetched, not this request.
• It costs money on both platforms. Fastly: "traffic from one Fastly POP to another will count towards your request count and billable bandwidth". In the extreme case of a service that PASSes everything, "your request count and delivery bandwidth will almost double". AWS: "you incur additional charges for using Origin Shield". This is billed on requests for which the shield is an incremental layer, and for dynamic requests it always is. AWS counts PUT, POST, PATCH and DELETE as dynamic. It also counts "GET and HEAD requests that have a time to live (TTL) setting of less than 3600 seconds".
• Not every workload benefits. AWS is direct about it: "Origin Shield may not be a good fit in other cases, such as dynamic content that is proxied to the origin, content with low cacheability, or content that is infrequently requested." Akamai likewise uses Tiered Distribution "only for cacheable content". Shielding an uncacheable path buys an extra hop and an extra bill.
• Rewriting the Host header breaks the funnel. The shield uses Host to work out which service a forwarded request belongs to. Changing it at the outer edge means "the shield POP won't recognize the request and will immediately drop it with an HTTP 500 Internal Server Error". Use the backend's override_host instead, or gate the rewrite on the origin-bound hop. The same collision splits objects across services, and forces you to purge both.
• The client's IP is no longer the connecting IP. At the shield, Fastly's client.ip "reflects the IP address of the immediate downstream connection", meaning the edge POP. Read Fastly-Client-IP instead. Reset client.identity too, if you use sticky load balancing.
• Vary and TTL rewrites behave differently once there are two tiers. Fastly's documented pitfall is VCL that swaps a custom header for Cookie in the response. With shielding on, "edge POPs will have Cookie in the Vary header, and thus will have a terrible hit rate". Guard it with a Fastly-FF check. Likewise, unsetting and resetting Cache-Control leaves the object with one TTL on the shield and another at the edge. Use Surrogate-Control for the tier-only value instead. Keep the cache key and the Vary header identical at both tiers. Otherwise one logical object becomes several entries, and the shield stops absorbing anything.

Best practice

• Put the shield close to the origin. Fastly: "generally, we recommend selecting a data center close to your backend." AWS: choose the Region "that has the lowest latency to your origin". If your origin is in a Region that offers Origin Shield, use that same Region.
• If offload is the goal, prefer the smaller set of parents. Akamai's Local map exists for exactly that reason. A global spread of parents lowers latency, but it dilutes the consolidation you enabled the tier for.
• Enable it per origin. Pick a different shield for each origin that lives in a different place. Where the CDN can choose for you, let it. Cloudflare's Smart topology probes latency to the origin continuously.
• For a cloud origin, check whether an interconnect shield location exists for that provider before choosing on geography alone.
• Exclude paths that cannot be cached, rather than shielding everything. Fastly exposes a per-request switch for this. AWS bills dynamic requests as an incremental layer regardless.
• Measure the shield's hit ratio separately from the headline figure. A shield hit is recorded as a miss and a hit, so the headline ratio understates reality. Fastly suggests pulling raw numbers from its historical stats API, and calculating your own.
• Confirm the shield is actually in the path before trusting it. Two tokens in X-Cache, and OriginShieldHit in CloudFront logs, are the evidence. A single token means the request never used the tier.