Understanding dynamic origin modification in Amazon CloudFront – Part 1

In the modern digital landscape, our lives are inescapably dominated by screens and browsers. From global product launches to flash sales and virtual concerts, events that once drew crowds to physical venues now drive millions of users to digital platforms simultaneously. The rapid rise of digital-first experiences has made the need to dynamically adjust content delivery across globally distributed origins a critical capability for organizations. Enabling dynamic origin modification allows organizations to provide reliable, high-performance access to online resources, even during periods of high traffic or rapid changes in usage patterns.

Amazon CloudFront enables organizations to deliver content globally with low latency and high transfer speeds through its extensive network of edge locations. Each CloudFront distribution can be configured to fetch content from one or more origins, such as Amazon S3 buckets, Application Load Balancers (ALBs), or custom origins. CloudFront provides support for default origins and path-based routing, but for more sophisticated routing needs, it offers powerful edge computing capabilities through Lambda@Edge and CloudFront Functions. Organizations can intercept and dynamically modify origin requests at the edge to implement dynamic origin selection directly within the CloudFront edge network, which removes the need for a traditional proxy at the origin.

This is part one of a two-part series. In this post, we review the options provided by CloudFront to implement dynamic origin selection, using examples, reference architectures, and implementation considerations. Part two of this series focuses on how to implement these solutions with code references.

Use cases

The edge-based origin modification pattern is highly scalable and capable of supporting millions of requests per second. In this section we cover a few use-cases where dynamic origin modification would be beneficial.

Geo-based routing

Global businesses can use CloudFront Functions to route users to the origin server closest to their location. This reduces latency and improves the user experience. However, it can also shift traffic between those endpoints to manage regional loads, or direct traffic away from overloaded or failing deployments.

User context-based routing

Retail and Media & Entertainment platforms can use CloudFront Functions to route requests based on user profiles or subscription tiers. They can then serve personalized experiences or prioritize the experience of customers on their paid tiers over freemium users. For example, a live sports streaming platform can route premium subscribers to their nearest optimal origin, but during periods of congestion can route free or advertisement supported viewing tiers to less congested regions.

Cell-based routing

Globally distributed, cell-based architectures can use the CloudFront Functions dynamic origin routing to intelligently direct traffic to the appropriate regional endpoints and resources based the information contained in the HTTP request. In turn, users can maintain autonomous, high-performing “cells” while still providing a seamless experience for their customers, regardless of their location.

Strangler-fig routing

Users with a mix of on-premises and cloud-hosted infrastructure can use CloudFront Functions to dynamically route requests between these different origin types during the migration journey following a strangler-fig pattern. They can use the performance and scalability of the cloud while still using existing on-premises investments, creating a hybrid architecture that is optimized for their specific needs.

Microservices routing

Users with multi-tenant architectures looking to route across microservices from the same domain name can now use CloudFront Functions to dynamically select the origin without having to rely on pre-configured cache behaviors and avoid CORS issues.

Implementation options

CloudFront provides two options for implementing custom code at edge: Lambda@Edge and CloudFront Functions. Each has its own strengths, which makes the choice dependent on your specific use case. This document compares the two options in detail across varying features. Specific to dynamic origin selection, the following are some of the defining features that help you decide which option would work best for your use-case.

Reference architectures

The following two scenarios describe potential reference architectures.

Sample scenario 1:

Consider a scenario where a major global e-commerce platform needs to implement dynamic origin routing of client requests based on the customer’s subscription tier or membership type—parameters that would be available as a header or cookie.

The following architecture showcases how this can be achieved by using CloudFront Functions and KeyValueStore.

Figure 1: Edge Routing using Amazon CloudFront Functions

Solution overview:

1. The client sends an incoming request to www.example.com with a cookie param subscription:basic
2. The request is routed through DNS to the nearest CloudFront POP (edge location) that can best serve the request.
3. The request is routed to the nearest CloudFront edge location.
4. The CloudFront Function attached to the distribution looks up the subscription in CloudFront KeyValueStore.
5. CloudFront KeyValueStore has a mapping of subscription=basic to origin (us-west-2-api-origin in this case).
6. CloudFront Function updates the origin based on the correct client region and forwards the request.

Sample scenario 2:

Consider a scenario of a multi-tenant software as a service (SaaS) application that needs to route its users to different customer-specific backends based on account information stored in DynamoDB. The account information is a complex key of varying parameters in the request payload.

The following architecture showcases how this can be achieved by using Lambda@Edge and DynamoDB.

Figure 2: Edge Routing using Lambda@Edge

Solution overview:

1. The client sends an incoming request to www.example.com with account information in payload.
2. The request is routed through DNS to the nearest CloudFront POP (edge location) that can best serve the request.
3. The edge forwards the request to a regional edge cache (REC). The regional edge cache triggers Lambda@Edge at the origin request event in case of cache miss.
4. The Lambda@Edge function dynamically selects the appropriate origin based on customer payload and Dynamo DB lookup call.
5. Lambda@Edge forwards the request to the selected origin.

Use CloudFront Saas Manager to implement multi-tenant architectures with a single CloudFront distribution across multiple users/organizations.

Summary

AWS is continuing to enhance Amazon CloudFront by providing clearer and more flexible solutions for users looking to implement dynamic routing at edge. You can use the options discussed in this post with CloudFront Functions and Lambda@Edge to implement custom routing rules at the edge in a latency-sensitive and high-performance way and using the AWS global network of edge locations.

Start using the new CloudFront capabilities to build sophisticated, context-aware request routing that adapts to your evolving business and technical requirements today. The Part 2 of this series focuses on how to implement these solutions with code references.

About the authors