Strengthen the resiliency of your data delivery with multi-CDN

Usually companies use Content Delivery Networks (CDN) to ensure fast and reliable delivery of its website, data, videos, etc. globally. There is plenty of information online about how a CDN works as well as what its advantages, disadvantages and limitations are, for example on Wikipedia.

We are looking beyond that to see what happens if a CDN fails to deliver content and how companies can be prepared for such cases. The effect of a failing CDN can be indeed, dependent on the business, quite pricey. Whilst an online retailer like Amazon can lose millions of missed revenue in the process, social news aggregator sites like Reddit will mainly struggle with user complaints. Nonetheless, the outage of just one CDN can have serious implications.

It gets worse when it is part of a critical infrastructure that is needed in times of crisis, as during a catastrophe when a government needs to deliver urgent information to its citizens. If foreign forces, that try to disrupt the flow of information, are causing it, then an outage could potentially also last days.

Multi-CDN to the rescue

Enough about the possible implications of a CDN outage. Let’s make sure that an outage does not have negative implications for us.

Though we need to mention, one caveat before: We will not look at the resiliency of the actual content that a CDN delivers. There is an abundance of articles regarding storage, backup, and recovery of data.

We look at CDN resiliency itself, namely multi-CDN. Multi-CDN comes in mainly two flavors:

Fully managed as a single vendor solution
Self-managed (which does not mean self-hosted) leaving the customer the choice of which CDNs to combine

It depends a lot on how the fully managed multi-CDN solution is implemented on a technical and organizational level. To fulfill our requirements of true resiliency, a multi-CDN has to consist of at least two complete separate infrastructures with different patch cycles and different organizational procedures. This quickly becomes very cost-inefficient for a single vendor. Although some vendors, offer a turnkey multi-CDN solution, we doubt that this solves the problem of a resilient CDN - but maybe we are wrong.

It is simply not in any vendor’s financial interest to promote the additional use of another vendor. For example, AWS mentions challenges with a multi-CDN architectures and promotes to only use CloudFront, whilst still being aware of additional scrutiny in that case: “Another multi-CDN approach to address the aforementioned challenges is using CloudFront as an origin to your other CDNs. However, this approach requires additional scrutiny over the redundancy of the architecture.”

On the other hand, a self-managed multi-CDN is very simple to implement, and therefore is, in our opinion, the go-to choice - which we will discuss in the next section.

Load balanced multi-CDN

To implement a load balanced multi-CDN, we need some kind of load balancer in front of our CDN. Luckily, by now virtually all major cloud vendors offer load balanced DNS records. That means we don’t need to use and pay for another separate load balancer but use the load balancing feature of our DNS zone.

Load balancing can happen on several parameters. A classic one is the failover load balancing: We define a primary and a secondary CDN record based on a health check:

If cdn-a.com is healthy, then send the user there
If cdn-a.com is unhealthy, then send the user to cdn-b.com

Healthy in this context means that the CDN is returning an HTTP status code 200.

Done, plain and simple - two CDNs serving the same URL and taking over automatically if one of them fails. In this case, resiliency is achieved by redundancy plus a simple failover mechanism.

Though, we can push things one step further and even throw GDPR in the mix with resiliency by combining failover with geolocation load balancing.

How is GDPR related to CDNs, you might ask? Unfortunately, CDNs are often ignored or not seen as relevant when your data protection officer asks about vendors that are being used. Since CDNs process your visitor’s IP address, they matter. This even already climaxed in a court order.

Geolocation load balancing means, that we can set a dedicated CDN DNS record for each origin location of the request (usually grouped by country). For example, we can define DNS records with the following rules:

If the request of a user originates from Europe, then send the user to cdn-eu.com
If the request of a user originates from North America, then send the user to cdn-usa.com

Let’s assume cdn-eu.com is a European based CDN vendor and cdn-usa.com is a US based CDN vendor. Therefore, this setup sends European based customers to European servers that are controlled by a European based CDN which is in accordance with the GDPR - even without using the unsound Standard Contractual Clauses.

This solution has two downsides:

If the EU based CDN fails, the user will be routed to the US based CDN, which then would not be in compliance with the GDPR. To solve this, we would need to include a second EU based CDN.
If the US based CDN fails, the user will be routed to the EU based CDN, which will result in longer loading times for the US based user. This, too, could be solved with another US based CDN.

The mitigation for those cases depend on your resiliency and compliance needs.

Choice of CDN

CDN vendors are plenty and are often offered not only within general cloud offerings but also as specialized service offering.

A general overview of the major CDN vendors can be found here: https://almanac.httparchive.org/en/2024/cdn#cdn-providers

A general overview of EU based CDN vendors can be found here: https://european-alternatives.eu/category/cdn-content-delivery-network

Make sure that the chosen CDN vendors offer the same set of features for the core functionalities that you want to offer to your users. For example, you will probably want to always serve content via HTTPS. If you rely on your CDN for handling the SSL certificates, then both CDNs need to provide this feature.

However, there are more exotic features, like the creation of AI images based on a string in your URL. Your core business processes are probably fine without that feature for a few hours.

Costs

The previously linked resources of AWS claims that “with this approach origin costs are multiplied by the number of CDNs”, which is simply not true. In modern cloud stacks, you only pay for what you use. In the described scenario, you will only use the second CDN, in a case of a failover or based on the geolocation of the user.

Therefore, you will only pay for one CDN at any given moment. There might be some CDN vendors that charge a minimum fee per month, for the availability of their services, but this is usually below 10 Euros per month. This is one of those rare cases where you have an active-active configuration with almost no additional cost - use it!

Additional resources

We found the following resources helpful, though, we didn’t use their data since the methods of the survey as well as the survey size was not published:

Strengthen the resiliency of your data delivery with multi-CDN