While not classified as a traditional cybersecurity method, an origin shield can help mitigate the effects of both malicious and non-malicious traffic overloads and DDoS attacks. Origin protection can play an important role in the overall security picture without explicitly or exclusively being a security feature.
What is an origin shield?
An origin shield is an extra layer of caching placed in front of an origin server to shield it from overloads, such as the so-called “thundering herd” level of requests that come with events like Black Friday, a big game release day or a major sporting event. An origin shield is often the one thing standing between a massive traffic jam or a site crashing entirely.
Yes, it’s a bit more complex than this, but for the purposes of this article, we will keep it simple, focusing on a big side benefit of the origin shield: security.
How does an origin shield relate to security?
An origin shield should be part of your security-driven, DDoS-resistant architecture by design. Keeping your site running reliably and at consistent performance levels is key both to business and QoE, making the protection of your origin something you do at all costs, whether the threat is malicious or self-made.
Protect your backends from DDoS attacks
A DDoS attack is a deliberate attempt to render your website or application unavailable to users or incoming requests. By unleashing a flood of requests that eat up both network and system resources, your services are dead in the water for as long as it takes you to fix the problem.
Many solutions exist to help detect, prevent or mitigate DDoS attacks, but one that should be built-in from the beginning - both for the protection offered and for the performance boost it offers - is caching. An additional caching layer in front of your servers, i.e. an origin shield, manages and fetches content for incoming requests and guards against the onslaught of massive traffic spikes. Clearly this applies in situations with genuine traffic peaks, for example, when a major news event breaks or everyone tries to watch the same new on-demand video at the same time, but it also applies in cases when an attacker comes at you in an attempt to take your applications down.
Protect your origin from your own CDN
Your CDN can be something like an autoimmune disorder if you don’t introduce a sane origin shield solution to your setup. Without an origin shield in place, a CDN itself (or multiple CDNs, if you’re running a multi-CDN setup) can be your origin’s biggest vulnerability.
For example, different data centers don’t in most cases share caches, so each CDN has to fetch a copy of incoming requests individually. You can picture the result: if traffic is peaking, even a single CDN sending many requests to your backend can create a major slowdown or crash if the traffic reduction isn’t good enough. The whole reason you want an origin shield is to protect yourself from overloads, so you definitely don’t want your own CDN to become the source of your unintended DDoS attack.
These kinds of requests are usually cacheable, and they are often for the exact same content, which is why the origin shield, aided by request coalescing, is ideal for protecting yourself from being overrun by requests -- external or from your own CDNs.
Secure your origin shield to ensure:
- Reduction of risk from and protection against intentional DDoS and unintentional DDoS-like attacks; no downtime at origin
- Protection against traffic overloads: resilience and availability in all traffic conditions
- Improvements to cache-hit efficiency and faster, high-performance content delivery for both single and multi-CDN setups with the aid of request coalescing