Networking & Content Delivery

Using latency-based routing with Amazon CloudFront for a multi-Region active-active architecture

This post guides you through setting up the networking layer for a multi-Region active-active application architecture on AWS using latency-based routing in Amazon Route 53 with Amazon CloudFront to deliver a low-latency, reliable experience for your users.

Building active-active architectures using AWS networking services improves your application resiliency and performance. However, there can be cost and complexity trade-offs, so we also provide guidance for thinking through architectural considerations and their impact on the functionality, resilience, and performance of your applications.

What are the advantages of a multi-Region active-active architecture?

Multi-Region active-active architectures are deployments of applications that run in two or more AWS Regions that are geographically separate. Both (or all) Regions have all the required components and data for your application, and actively serve requests, based on end-user proximity. If one Region fails, the other Region can automatically take over user traffic from the failed Region, without any downtime for your global users.

When should you consider adopting a multi-Region active-active architecture?

You should consider a multi-Region active-active architecture only if your application’s unit of failure is at an AWS Regional level. With an active-active architecture, carefully weigh the potential for higher costs and increased complexity. For stateful applications that require cross-Region data replication, you should also factor in some data inconsistency, higher latency, and slower performance.

·      Business requirements

Stringent recovery time objectives (RTO)/ recovery point objectives (RPO) requirements: One reason that you might choose to use an active-active architecture is to meet stringent SLA requirements that can’t be addressed by using other disaster recovery (DR) strategies, such as active-passive, warm-standby, or pilot-light configurations. You might also consider an active-active architecture when your business needs the unit of failure to be at a Regional level, with RTO measured in seconds or minutes.

Legal and compliance reasons: Data sovereignty laws and regulations enforced by local governments might require that your data be physically housed in close proximity to end-users. To meet data sovereignty requirements, you might choose to deploy your applications across multiple AWS Regions, based on the geographical locations of your users.

·      Improving latency and performance

If you serve dynamic content with a geographically-distributed user base, you might choose to adopt an active-active architecture to improve performance. In this scenario, active-active can reduce latency by enabling you to process and serve non-static data without the overhead of long network hops.

AWS networking services used in a multi-Region active-active architectures

In active-active architectures, we can use Amazon CloudFront and AWS Global Accelerator to improve the latency when we deploy an application in a multi-Region architecture setup. Global Accelerator is a networking service that improves your internet user performance and availability by using the AWS global network infrastructure. Global Accelerator is a good fit for use cases that require static anycast IP addresses or instant AWS Regional failover, but it doesn’t support content caching or edge processing. So, depending on your application, you might want to use CloudFront in your architecture instead, as described in this blog post.

CloudFront improves performance for both cacheable content (such as images and videos) and dynamic content (such as API acceleration and dynamic site delivery). CloudFront has additional benefits as well, including:

·      Security

Access control: By using CloudFront’s geo-restriction capability, you can restrict users in specific geographic locations from accessing content that is distributed through CloudFront.

·      Edge computing

CloudFront offers programmable and secure edge CDN computing capabilities with it’s AWS Lambda@Edge and CloudFront Functions offerings.

Lambda@Edge: AWS Lambda@Edge is a general-purpose serverless compute feature that supports a wide range of computing needs and customizations performed at the edge.

CloudFront Functions: CloudFront Functions is ideal for sub-millisecond compute operations at scale, such as HTTP header manipulations, URL rewrites/redirects, and cache-key normalizations.

Solution overview

request flow - region is selected based on unique custom domain

Figure 1: User flow from client browser to origin service in an AWS Region

The diagram shown in Figure 1 outlines how an end user API call flows in an active-active architecture. The user request arrives at the closest AWS edge location [1], and flows through CloudFront [2] to Amazon API Gateway [3]. You can also use CloudFront with other origins, such as Elastic Load Balancing load balancers, Amazon Elastic Compute Cloud (Amazon EC2) servers, or Amazon Simple Storage Service (Amazon S3) buckets.

If you were using Global Accelerator in this flow instead of CloudFront, it would look for the optimal pathway from the edge location to your application, including automatically failing over AWS Regions, if needed. CloudFront doesn’t currently provide an out-of-the-box solution to fail over to another AWS Region with an active-active multi-Region architecture. In the following sections of this blog post, we’ll explain how you can architect and implement failover functionality that’s similar to Global Accelerator’s. We’ll use an active-active setup with Route 53 latency-based routing to drive this Regional failover capability.

How it all works

When implementing the multi-Region active-active setup, there are two key areas that need closer attention:

  • Secure Sockets Layer/Transport Layer Security (SSL/TLS) certificates for your custom domains that are used by your clients to access your application.
  • The latency-based routing logic to route client requests to an AWS Region.

We’ll first step you through how to configure your SSL/TLS certificates. Then we’ll walk through the logic for routing client traffic to an AWS Region.

About SSL/TLS certificates to protect your AWS websites and applications

In order for the traffic to be encrypted in transit in a multi-Region setup, matching SSL/TLS certificates must be available in each Region where you deploy your application. In this section, we’ll discuss how this can be achieved on AWS.

You must create matching SSL/TLS certificates in each Region where you deploy your application. Certificates ensure that traffic can be encrypted in transit in your multi-Region setup, to protect your AWS websites and applications. You can create certificates with AWS using AWS Certificate Manager (ACM).

ACM is a service that lets you easily provision, manage, and deploy public and private SSL/TLS certificates to use with AWS services and your internal connected resources. SSL/TLS certificates are used to secure network communications and establish the identity of websites over the Internet, as well as resources on private networks.

In order for ACM to help you protect your AWS websites and applications, the certificates must be in each Region where AWS services use them to encrypt the traffic in transit. For example, if API Gateway is deployed in both the US East (Ohio) and US West (Oregon) Regions while using the custom domain name Regional endpoint type, the certificate must be created or imported into ACM in both Regions. To learn more about ACM, see What Is AWS Certificate Manager.

Note that CloudFront is a global service – not a Regional service. Therefore, the certificate must be issued in ACM in the US East (N. Virginia) Region.

Route 53 is a highly available and scalable Domain Name System (DNS) web service. You can use Route 53 to perform three main functions in any combination: domain registration, DNS routing, and health checking. Route 53 Traffic Flow lets you manage traffic globally through a variety of routing types. For the purpose of this post, we’ll focus on the Latency routing policy. To learn more about all of the supported routing types, see Choosing a routing policy.

DNS resolution and request flow using custom domains

Figure 2: DNS resolution and request flow using custom domains

Let’s look at how the user request flow works, as illustrated in the diagram in the above Figure 2.

  1. Create a Route 53 alias record with a custom domain that points to the default CloudFront domain name for the distribution. To learn more about Route 53 alias record and CNAMEs, see values for alias records.
  2. Configure alternate domain names (CNAMEs) in CloudFront and import the certificate from ACM in the US East (N. Virginia) Region. To learn more about Route 53 alias record and CNAMEs, see using custom URLs by adding alternate domain names.
  3. Configure Route 53 record sets for the Regional AWS services. You create two records with the same domain name, in this example, and set the routing policy to latency. In a multi-Region active-active setup, latency-based routes the traffic to each Region that contains the best latency with a lower round-trip time. To learn more about latency routing policy, see latency-based routing.
  4. Request a public certificate in ACM for each Region where you have a publicly facing AWS service. From this example, a certificate in ACM in Region 1 and Region 2.

The routing logic to route a client request to an AWS Region

In the proposed flow, there are two points of DNS resolution before the request is served by API Gateway:

  • At the client’s browser, resolving the domain name to the CloudFront IP address.
  • At the CloudFront edge location, resolving the custom domain name of the API Gateway.

The following diagram in Figure 3 illustrates multi-Region active-active latency-based routing using CloudFront and Route 53.

multi-region-active-active Latency Based Routing flow

Figure 3: Multi-Region active-active latency-based routing using CloudFront and Route 53

Let’s look at the DNS resolution flow as illustrated in the figure above.

  1. Client makes an HTTPS request to the domain. Route 53 resolves the domain.
  2. Client makes the request to the closest CloudFront Points of Presence (PoP) location to the client.
  3. CloudFront speeds up the distribution of your content by routing each request through the AWS global network to the edge location that can best serve your content. Typically, this is a CloudFront edge server that provides the fastest delivery to the viewer.
  4. CloudFront PoP location makes a DNS request to Route 53 to resolve the origin domain name Since this domain name has the latency-based routing policy configured in Route 53, the IP addresses are returned of the API Gateway in the closest Region to the CloudFront PoP location.
  5. CloudFront PoP location makes HTTP request to the API Gateway in the closest Region.

Testing latency-based routing

To simulate clients from different geographic locations, we’ve launched an Amazon EC2 instance in two AWS Regions (us-east-1 and us-west-2) that correspond to the Regions used to deploy our sample application. From each of the instances, we can execute curl against the domain name that’s used to access the application. For this exercise, we’ll execute the following command from each Linux EC2 instance, where 172-31-56-168 represents the instance in us-east-1 Region and 172-31-16-193 in us-west-2 Region.

Client request are served from the closest Region

Figure 5: Client request are served from the closest Region

As both Regions are healthy and accepting the traffic, each of the client requests were served from the nearby Region.

Testing Regional failover

Now, let’s simulate that the application in us-east-1 needed to go into maintenance mode and is operating at reduced capacity. For testing purposes, to direct the usual traffic away from this Region, we updated the health check status to indicate the maintenance window. Although executing the curl request from 172-31-16-193 will yield same results, doing so from the 172-31-56-168 instance in the us-east-1 Region will give the following results:

Client request forwarded to next closest Region when the closest Region is unavailable

Figure 6: Client request forwarded to next closest Region when the closest Region is unavailable

Because the us-east-1 Region is not available to serve the request, the request is forwarded to the next closest Region.

In our example, the sample application is only deployed in two Regions, and the request is served in the second Region. In a setup of three or more Regions, the traffic from the unavailable Region will be forwarded to the Regions that is the next closest to the end-user.

For the Regional failover to work, it’s essential for the health checks to work. That is, only a reliable health check at the application layer ensures that the application works as expected and can serve the client requests. We recommend to design your failover mechanisms to leverage data plane functions for the greatest reliability and fault tolerance. For example, choose mechanisms that use Route 53 health checks (data plane functions) rather than updating DNS records in hosted zones or health check configurations (control plane functions). For detailed information about how to use Route 53 health checks to handle failover scenarios, see Creating Disaster Recovery Mechanisms Using Amazon Route 53.


In this post, you learned about designing a multi-Region active-active architecture by using CloudFront and Route 53. CloudFront is used for fast content delivery by leveraging the AWS global network and other benefits, such as security, edge capabilities, and availability. Route 53 is used to configure latency-based routing from the end-user’s location to the closest Region in which your application is deployed. By combining these services in your multi-Region active-active architecture, they help provide a low latency experience for your end-users.

To get started, visit the Creating records using Route 53 console and Creating a CloudFront distribution.

About the authors

Artem Lovan

Artem Lovan is a Technologist and Solutions Architect at AWS. Artem helps guide AWS customers build scalable and sustainable products in the cloud. He has been involved in IT at many levels, including infrastructure, networking, security, DevOps, and software development.

Mohan Pasappulatti

Mohan Pasappulatti is a Technologist and Architect at AWS, based in San Francisco, USA. Mohan helps high profile disruptive startups and strategic customers architect and deploy distributed applications, and other business critical workloads in production on AWS. He has over 20 years of experience leading engineering and architecture teams in several verticals like health care, manufacturing, ecommerce, FinTech, etc. In his spare time, Mohan loves to cheer his college football team (LSU Tigers!), play poker, ski, watch the financial markets, play volleyball and spend time outdoors.