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

An update was made on April 11th, 2024, outlining deployment procedure.

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. When your application is impaired in one Region, the other Region can automatically take over user traffic, 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

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.

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 example.com 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, api.example.com 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.
5. Alternatively, you may use Application Load Balancer as the origin as well. The above steps are applicable for all AWS origins except S3.

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 or an Application Load Balancer (depending on your origin type).

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

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 example.com 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 example.com. 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. In this example, we have used API Gateway as an origin. Even if you use other origin types (except Amazon Simple Storage Service), the data flow remains the same.
5. CloudFront PoP location makes HTTP request to the API Gateway to the appropriate origin (APIGW/ALB) in the closest Region.

Deployment Procedure

The deployment procedure will follow a four-step approach: Part 1 will focus on Origin and DNS registrar setup; Part 2 will showcase Route 53 public hosted zone and AWS ACM configuration; Part 3 will focus on adding a custom domain to the Route53 public hosted zone; and finally, Part 4 will focus on the CloudFront distribution setup.

Part 1 – Deploying APIGW/EC2 instances, registering a domain with a registrar and configuring Route 53 records:

Configure your backend servers in each region that will host the website www.example.com.

1. Follow the steps to create two API Gateways in above two regions. Refer to the blog on ways to setup AWS edge services to boost performance and security of dynamic websites.
2. Or if you plan on using Application Load Balancer as your origin, follow the steps to create two Application Load Balancers (ALBs) in above two regions.

Part 2 – Creating a public hosted zone for the custom domain in Route 53 and adding a public certificate.

1. Create a public hosted zone using Route 53 for the domain name (e.g. example.com) you want to route traffic on the internet. To register a domain name, you can either use Route 53 or any other domain registrars. Just make sure, you update the DNS servers on the 3P registrar’s website if you are using Route 53 for DNS management.
2. For the registered domain name, request a public certificate via AWS Certificate Manager in N. Virginia Region (us-east-1). NOTE: It is critical to request the public certificate in us-east-1 region irrespective of your resource regions as ACM’s control plane resides in us-east-1.

Part 3 – Adding A records for the custom origin domain in the same public hosted zone.

As an active-active architecture consists of custom domain names, make sure to add A records for the custom origin domain in the public hosted zone. Following the above example, you would need two A records for a custom origin domain (e.g.: api.example.com), which would act as an origin for the CloudFront distribution.

Create two A records for the two load balancers with latency-based routing:

1. 1. Under the public hosted zone example.com, Select Create record.
   2. Add Record name as api and select A record under Record type.
   3. Toggle on Alias and select the appropriate origin you are using under Route traffic to.
   4. Choose Region us-east-1 (as per the current example) and select the configured origin.
   5. Under Routing policy, select Latency.
   6. Add another record and repeat the above steps for the second region us-west-2 (as per the current example).
   7. Once done, select Create Records.

Part 4 – Setting up CloudFront distribution with APIGW/ALB as the origin.

Once the custom domain name A record is added to the public hosted zone, configure it as an origin with the CloudFront distribution.

1. Go to Amazon CloudFront navigation pane via AWS console and choose Create distribution.
2. Follow the steps to create CloudFront distribution.
3. For Origin domain, add the custom subdomain api.example.com.
4. For Viewer protocol policy, select Redirect HTTP to HTTPS (or any other available policy applicable to you)
5. Under Cache key and origin requests, select Cache policy and origin request policy (recommended), and then select one of the appropriate Cache policies under Cache policy as per your design requirements.
6. Under the Settings section, select Alternate domain name (CNAME), and then add the domain name configured in Part 2 (www.example.com) under Add item.
7. For Custom SSL certificate, select the ACM certificate for the domain created in Part 2.2.
8. Select Create distribution.
9. Once the distribution is deployed, go to the Origins tab under the distribution, then select the origin and click edit. Verify if the Protocol selected is HTTPS Only. (AWS recommends HTTPS. However, you may choose the best option for your design).

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.

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:

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.

Conclusion

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