We are happy to announce the immediate availability of Warpshield, our multi-CDN origin shield. This addition to our turn-key multi-CDN platform is free of additional charge, fully transparent, protects you from overloading your origin, and saves origin network egress costs.
What’s an origin shield?
In the context of CDNs, an origin shield is a group of servers between the edge servers of a CDN provider acting as an additional caching layer to protect your origin from a sudden influx of traffic caused by for instance purging a large number of files or the expiry of popular files.
Why you need an origin shield
Without an origin shield configured, each of those groups of edge servers, called a Point of Presence (PoP), will request the files from the origin. In order to provide fast response times, CDN providers often deploy upwards of 15 PoPs in strategic locations. If you have a global audience, all those PoPs will request the file from the origin and store it locally until it has expired and will then fetch the file again upon the next request. In the most optimistic case, that would mean 15 origin hits for one file. However, there are CDNs that only cache a file once it has been requested 3 times within a certain timeframe. This means that the number of requests goes up to 45 already.
If you have a properly configured origin shield, often a single PoP, all other PoPs will request the files from the origin shield. In turn, the origin shield will contact the origin, retrieve the file, cache it locally and then serve it to any requesting PoP. In this case your origin receives only one request. If the files are large and being hosted on an expensive platform like Amazon’s S3 or Google Cloud Storage, the amount of cost savings will add up quickly.
Origin shield and multi-CDN
The issue described above compounds if you have a multi-CDN setup. Such a setup consists of two or more CDNs but behaves like one big CDN. Reusing the case above but adding another similarly behaving CDN to the mix, you’d have 90 requests for a single file.
As a multi-CDN provider this issue has been bothering us. To solve it we had 2 options:
- Enable CDN specific origin shields for the CDN providers we work with
- Setup our own origin shield solving all issues at once
The first option would leave you with 4 requests in case you have 4 CDNs in your mix (our default). But more important, the process of setting up an origin shield is a time consuming, complex, and expensive process. Which then also needs to be repeated multiple times with different procedures.
Setting up our own shield was clearly a no-brainer: regardless of the efficiency or inefficiency of a CDN, we always maximise the origin offload, we can integrate it easily into the deployment workflow, and it allows for some additional features that we’ll announce later.
Since the shield has been fully integrated into our platform, you don’t have to do anything when setting up a property as you can see in the video of the registration and property setup process below.
Share this Post