Using CloudFront Origin Shield to protect your origin in a multi-CDN deployment

In most cases, customers use a single CDN such as Amazon CloudFront to deliver online video streaming to their viewers. However, in some cases, you may choose to use a multi-CDN deployment for specialized reasons such as requiring parallel redundancies on all parts of your media-delivery architecture, or using a specific CDN to cover a geography where they have unique coverage. While using a multi-CDN deployment can offer certain advantages, it can also introduce challenges such as incremental load on your origin that require additional thought or different solutions.

This blog details how Amazon CloudFront’s recently announced Origin Shield can enhance your multi-CDN media workload by minimizing the load on our your origin. This reduction in origin load can improve your origin’s availability, reduce its operating costs, and even improve general performance for your viewers. Some customers using CloudFront Origin Shield in production have reported origin load reductions and origin fetch p90 latency reductions as high as 57% and 67% respectively. Click here to learn more about edge networking with AWS.

Origin Shield fundamentals

Before diving deeper into the multi-CDN example, it is best to first establish a foundation for what CloudFront Origin Shield is and how it can even optimize workloads that are using CloudFront as its sole CDN for viewer delivery.

Not all origins are alike. For example, some are more sensitive than others to the number of requests they can handle. This is particularly true for origins running processes that require more compute per request, such as just-in-time packaging, or for origins on-premises that are not able to scale as easily as those in the cloud. Since 2016, CloudFront has helped protect origins from excessive origin load by providing regionalized mid-tier caching at no additional cost to everyone by default. These Regional Edge Caches automatically protect your origins and collapse requests within the region they cover (Figure 1).

For workloads that span across multiple regions or geographic areas covered by more than one Regional Edge Cache, you may want to further optimize the load on your origin. Now, with just two clicks you can configure one of CloudFront’s Regional Edge Caches to become your CloudFront Origin Shield. Origin Shield works with any HTTP-accessible origin, such as AWS Elemental MediaPackage, AWS Elemental MediaStore, Amazon S3, Amazon EC2, or any other third-party or on-premises streaming origins.

CloudFront Origin Shield provides a centralized caching layer that sits in front of your origin to help increase CloudFront’s cache hit ratio and collapse simultaneous requests for the same object coming across multiple regions. As a general best practice, you should always choose the Origin Shield Region that is closest to your origin.

When enabled, all origin fetches coming from any CloudFront Point of Presence or Regional Edge Cache will now be routed through the Origin Shield location for a final cache check. Any content not already held in the Origin Shield location will then benefit from central request consolidation so that as little as one request goes to the origin. In contrast to our previous diagram, now the origin fetch that originated from the Regional Edge Cache in Portland will no longer go directly to the origin but will instead go to the Origin Shield Regional Edge Cache location in N. Virginia (Figure 2).

By leveraging CloudFront’s existing Regional Edge Caches, Origin Shield does not introduce an extra layer of caching in all cases. As shown above, Points of Presence assigned to the Regional Edge Cache in the US East (N. Virginia) Region will continue to use that Regional Edge Cache in its regular capacity even when it is designated as the Origin Shield Region. However, requests coming from Regional Edge Caches in other Regions will benefit from the additional caching layer because they now make the additional cache check at the Origin Shield Region to provide the origin offload benefits.

Use-cases ideal for Origin Shield

Origin Shield can be easily incorporated into any CloudFront workload. However, the most notable benefits are seen among workloads that have viewers spread across multiple regions, involve on-demand processes such as just-in-time packaging or on-the-fly image transformations, or on-premises origins with scaling or bandwidth constraints.

Bedrock Streaming, a subsidiary of M6 Group in France, stated, “We enabled Origin Shield on our live linear channels served by CloudFront and immediately saw our origin’s load from those channels reduce by more than 26% without having to do any architectural changes. The additional origin protection we’re getting, plus the origin cost savings, is well worth Origin Shield’s low-cost pricing.” – Yann Verry, Head of Operations.

While Origin Shield can optimize your origin load when using CloudFront to deliver content directly to your viewers, Origin Shield can also be useful in serving content to other CDNs in a multi-CDN deployment such as a large live event.

Understanding and managing multi-CDN trade-offs

Over-the-top (OTT) video delivery for live events such as the NFL Super Bowl continually grow in size each year. Content providers for events of this scale sometimes use multi-CDN strategies to deliver these mission-critical events. Reasons for using a multi-CDN architecture vary between providers but are generally rooted in establishing extra redundancy or enhancing performance in a geographic region where one CDN might have specialized coverage. Recently, one of our colleagues, Achraf Souk, wrote a multi-part blog series about the benefits and trade-offs of using multi-CDN for video streaming. We encourage anyone reading this blog to also check out his posts on how to use multi-CDN for video streaming and how to score and balance traffic between multi-CDNs.

For our purposes here, let’s assume you are using a multi-CDN strategy including three CDNs – Amazon CloudFront and two others which we will refer to as CDN 2 and CDN 3. With multiple CDNs involved, we often see each one pulling content directly from the media origin server (Figure 3).

As mentioned before, while there may be specific reasons to use a multi-CDN architecture, there are several trade-offs to consider when compared to a single CDN approach such as increasing origin load, increased origin cost, operational overhead, and lack of feature parity across CDNs. These trade-offs are explained below:

1. Increased origin load: As viewers request segments identified in the manifest, each request for the same segment of video is replicated across CDNS as each one fills their own cache independently. This places unnecessary load on the media origin and has a higher likelihood of impacting its availability.
2. Increased origin cost: Directly correlated to your origin load is the operational cost of your origin. Each request handled by the origin incurs costs such as just-in-time packaging as well as egress to the CDNs. Handling multiple CDNs directly from your origin can increase these costs.
3. Operational overhead: Each CDN will require its own configuration which takes time and expertise to understand the nuances of each CDN. You likely want to have uniformity in your content delivery which means repeatedly configuring capabilities such as origin failover across each CDN independently.
4. Lack of feature parity: Not all CDNs have equivalent functionality such as serverless edge computing capabilities. Like before, to maintain uniformity in your content delivery, you may be arbitrarily constrained from using one CDN’s advanced capabilities due to another CDN’s lack of a comparable feature.

If you are using or considering a multi-CDN architecture, CloudFront Origin Shield can help minimize these trade-offs by using a single CloudFront distribution to deliver content to both your viewers and downstream CDNs. This is achieved by configuring your other CDNs to use CloudFront as their origin and send their origin fetches to CloudFront’s Points of Presence (Figure 4).

Just like previously described, now all requests will be handled by CloudFront’s Points of Presence which will naturally use CloudFront’s Regional Edge Caches and then be routed through the Origin Shield location before going to your origin. This arrangement provides a number of advantages that helps minimize the trade-offs of using a multi-CDN architecture:

1. Minimized origin load: All requests, both direct viewer and non-CloudFront CDN origin fetches, going to CloudFront’s Points of Presence will benefit from a common cache key which will help maximize your cache efficiency at the edge giving you faster viewer responses. In addition, any requests for content not already in the Origin Shield cache will be consolidated before going to the origin and reduce its load.
2. Minimized origin cost: With only CloudFront Origin Shield pulling content from your origin, the volume of requests your origin is handling will be reduced. This will help you decrease your costs of operating your origin for expenses like egress and just-in-time packaging.
3. Central point of configuration: Origin Shield gives you a point of central configuration that applies to your entire CDN architecture. Now you can leverage CloudFront’s Origin Group for origin failover without having to replicate and maintain similar functionality across each CDN. Likewise, you can also use CloudFront’s Lambda@Edge capabilities deploy serverless logic for advanced capabilities like dynamic load balancing across origins.
4. Improved network performance: All of CloudFront’s Points of Presence are connected to the AWS network which is the largest global infrastructure footprint of any cloud provider with consistent high performance. By using CloudFront as the origin for other CDNs, you are now able to bring their requests onto the AWS backbone faster by connecting to a nearby CloudFront Point of Presence.

Customers using CloudFront Origin Shield in production have seen notable improvements in their overall cache-hit ratio, origin load, and network performance for origin fetches. For example, users have seen as much as:

• A 57% reduction in origin load after enabling Origin Shield
• A 56% reduction in first-byte latency (p90) for cross-region origin fetches now going over the AWS backbone
• A 67% reduction in last-byte latency (p90) for cross-region origin fetches now going over the AWS backbone

How to set up Origin Shield in your multi-CDN deployment

CloudFront Origin Shield is incorporated into the configuration of a CloudFront distribution’s Origin settings. It is straightforward to set up and can be easily introduced into your multi-CDN architecture with minimal changes.

Step 1 – Enable Origin Shield: By default, Origin Shield is not enabled for origins. You enable it on a per-origin basis within your CloudFront distribution by going into the Create or Edit Distribution screen and clicking the ‘Yes’ option next to ‘Enable Origin Shield’.

Step 2 – Choose location: Next, you choose the Origin Shield Region. Click the dropdown menu to choose the Origin Shield Region.

Note to readers: When choosing your Origin Shield Region, ALWAYS choose the Region that is closest to your origin for the most optimal performance.

At the time of this blog, CloudFront offers Origin Shield in twelve AWS Regions but more locations may be added in the future. If your origin is located in one of the AWS Regions shown in the drop down selection, choose the same Region for Origin Shield. If your origin is located in an AWS Region not shown in the drop down selection, refer to CloudFront’s Developer Guide for recommendations on which Origin Shield location to use based on AWS and CloudFront’s network topology.

For origins located outside of AWS Regions such as an on-premises origin within your own datacenter, choose the Origin Shield Region with the lowest latency connection to your origin. You can base your selection on our recommendations depending on which AWS Region is closest to your origin. Or, you could setup EC2 instances in a few different AWS Regions that are close to your origin and run some tests using ping to measure the typical network latencies between those Regions and your origin.

Step 3 – Update DNS: Multi-CDN architectures often use a DNS load balancer to distribute viewer traffic across CDNs each with its own unique CNAME to receive the awarded traffic. In a multi-CDN architecture with CloudFront Origin Shield, you would use CloudFront’s endpoint as the origin to the other CDNs. For an added level of visibility you might want to consider using a custom CNAME for each CDN’s CloudFront endpoint.

To do this in our example of three CDNs, you would have three CNAMEs on your CloudFront distribution – Cloudfront.example.com to receive viewer traffic sent directly from the DNS load balancer to CloudFront and fetch.CDN2.example.com and fetch.CDN3.example.com to receive and distinguish traffic coming from the other CDNs to CloudFront (Figure 5).

Note to readers: Even though traffic may arrive to your CloudFront distribution under different CNAMEs, they will still share the same cache key. When CloudFront constructs the cache key for your distribution, it uses the default domain name of your distribution (i.e. d123.cloudfront.net) as the host and not the specific CNAME that directed the traffic to the distribution.

The reason to use different CNAMEs to distinguish traffic between its downstream source is to give you additional visibility and reporting into the performance of each CDN in your multi-CDN architecture.

Step 4 – Test, confirm, and monitor: As with any workload, it’s important to test your architecture in a pre-production environment before switching your production traffic to the new architecture. As part of monitoring best practices for a multi-CDN architecture, we recommend using CloudFront’s additional logging & reporting capabilities for maximum visibility. CloudFront provides several options to gain transparency into the performance of your multi-CDN architecture by way of access logs, real-time logs, and AWS CloudWatch metrics.

CloudFront provides access logs free* of charge and can be enabled in just a few clicks (*standard Amazon S3 storage charges do apply). If you set up unique CNAMEs for each CDN origin endpoint as described in Step 3, your access logs will show you which domain the request resolved to on your CloudFront distribution in field 16 ‘x-host-header’.

With Origin Shield enabled, field 14 ‘x-edge-result-type’ will display a new possible value – OriginShieldHit – that indicates that the object originated from outside the Origin Shield Region and was served from the Origin Shield cache. If a request is routed from a CloudFront Point of Presence to the Regional Edge Cache that is also acting as the Origin Shield, it is reported as a Hit in the logs, not as an OriginShieldHit.

Additionally, you might consider using CloudFront real-time logs and CloudFront’s eight additional, real-time AWS CloudWatch metrics to create active dashboarding, monitoring, and alarms for the operational health and performance of your CDN infrastructure such as overall Cache-Hit Ratio and 4xx and 5xx Error Rates.

Removing Origin Shield

If you no longer need to use a multi-CDN architecture, consider continuing to use Origin Shield even for your CloudFront-only viewer delivery as it can still provide valuable optimizations on origin load and cross-region request collapsing. If you no longer need to use Origin Shield, you can easily disable the feature by going back to your Origin Settings and selecting ‘No’ next to ‘Enable Origin Shield’ and then saving your configuration.

Notes regarding high-availability and stacking CDNs

Using a CDN as an origin to other downstream CDNs requires additional scrutiny over the availability track record, redundancy, and scalability of the CDN providing the origin shield service. CloudFront and its Origin Shield feature are built according to AWS’ high-availability best practices and are fault tolerant and redundant.

CloudFront as a service is able to handle massive volumes of traffic and balance the load across its hundreds of Points of Presence. As a best practice to better ensure the availability of you application to your end viewers, we do not recommend enabling a third-party’s origin shield or centralized dedicated cache when using CloudFront as their origin. Doing so may consolidate all third-party CDN requests made to CloudFront on a single CloudFront Point of Presence. By naturally allowing another CDNs resolvers to distribute the load to its nearest CloudFront Point of Presence (POP) you better safeguard your workload from being potentially impacted by a single-POP availability event.

As for Origin Shield, all Origin Shield Regions leverage CloudFront’s Regional Edge Caches which are built within AWS Regions using at least three Availability Zones. This gives Origin Shield the ability to quickly and dynamically scale to handle workloads of any size. For redundancy, Origin Shield uses per-request error tracking across multiple KPIs to trigger automatic failover to one of two secondary Origin Shield Regions. If your traffic naturally involves multiple regions, the secondary Origin Shield Regions are already likely to have their caches warmed with your content and will seamlessly continue shielding your origin.

Summary

We’re very excited about the release of Origin Shield and the incremental origin protection, origin offload, and reduced origin costs it can provide you whether using CloudFront as your sole CDN or as part of a multi-CDN setup. Please refer to CloudFront’s webpage for Origin Shield Pricing and our Developer Guide for more information on how to estimate the monthly cost of Origin Shield.

If you are interested in using Origin Shield for a multi-CDN architecture, and have discounted pricing, contact us or your AWS sales representative for more information. Additional charges may apply.