Managing global AWS Local Zones applications with Amazon Route 53 Geoproximity routing

In an earlier post, we discussed how the hub-and-spoke architecture introduced by Local Zones unlocks more choices than ever for geographies where lower latency access can be introduced. Through workload placement techniques offered by service mesh technology for “east-west traffic”, inter-service communication within a customer’s Virtual Private Cloud (VPC), customers can make sure that microservice applications can seamlessly route to the topologically closest replica of a service. For north-south traffic routing, or that between client and server, customers have asked for a seamless approach to multi-edge routing.

Consider the following scenario: a customer within a given AWS Region has deployed an application across three Availability Zones (AZ) and three Local Zones. To accommodate clients connecting from across the globe, customers have asked for a more seamless solution leveraging Amazon Route 53 that is client location-aware, even as customers choose to utilize an even larger number of Local Zones for their applications.

Figure 1: Sample application with VPC extended across three AZs and three Local Zones

Route 53 Traffic Flow now supports geoproximity routing for Local Zones. Using Traffic Flow policy documents formats within the Traffic Flow visual editor, customers can configure geoproximity routing using Amazon Route 53. In fact, customers can combine geoproximity routing with other Route 53 routing policies, such as failover or weighted, to create a customized routing policy specific to their needs. Using Traffic Flow, Local Zones customers can manually configure latitude and longitude for their application endpoints that exist within that area. Prior to this feature, customers had to configure labels corresponding to Local Zones and configure routing to those endpoints accordingly.

Geoproximity routing on Local Zones

Amazon Route 53 is a highly available and scalable Domain Name System (DNS) web service, providing a breadth of options for how customers can manage the reachability of their cloud infrastructure. Earlier in 2023, customers wishing to route traffic to the closest Local Zone would have to implement their own routing logic, either using geofencing or other location services. Today, customers can now use Geoproximity routing policies to route traffic to their Local Zone endpoints based on how close the end-users are to each Local Zone. Using Amazon Route 53 Traffic Flow, customers can utilize a visual editor to create hierarchical trees of records spanning across multiple Local Zones.

From the Amazon Route 53 dashboard, customers can visit Traffic flow by visiting Traffic policies, and creating a new traffic policy. After creating a traffic policy, local-zone-demo, they can connect the A record (Start point) to the Geoproximity rule (Connect to…) and specifically select AWS Local Zone as the endpoint location. Once selecting Local Zone, customers can select the Local Zone corresponding to their endpoint followed by the IP address corresponding to their application.

Figure 2: Creating traffic policy in Amazon Route 53 Traffic Flow

As an example, customers can create 16 records, corresponding to each Local Zone within the US, with an equal bias. The resulting Geoproximity map evenly distributes application traffic across each of the coordinated geographies.

Figure 3: Configuring traffic policy through Geoproximity map using Amazon Route 53 Traffic Flow

Customers can also manipulate the bias of a single Local Zone, to prioritize a specific geography when application traffic ingresses the cloud outside a defined radius (~150 miles) of a given city. Additionally, when EDNS0 is enabled on supported DNS resolvers, Route 53 determines the location of the user based on the truncated IP address rather than the source IP address of the DNS resolver, providing an even more accurate estimate of the user’s location. To learn more you can visit: How Amazon Route 53 uses EDNS0 to estimate the location of a user.

Figure 4: Adjusting bias for endpoint location using Local Zones in Amazon Route 53 Traffic Flow

Lastly, customers don’t need to choose whether to include only Local Zones or AWS Regions in their traffic flow documents. Customers could create a traffic policy routing US-based requests to the nearest Local Zone, but all other traffic to a different AWS Region, such as eu-west-1 (Ireland).

Figure 5: Configuring Amazon Route 53 Traffic Flow using Local Zones with AWS Region as default

Using this new feature, customers can more efficiently architect geodistributed applications across the globe. As an example, a global automotive company seeking to develop a real-time vehicle telemetry application can create a single fully-qualified domain name – such as geoprox.example.com – to direct traffic to an ephemeral set of edge locations. If most of their vehicles are sold within the US, then they could deploy to all 16 Local Zones within the US to realize the lowest-latency solution for the majority of their end-users. When entering that fully qualified domain name (FQDN) from a client in Denver, for example, it would route them to the Denver Local Zone.

Figure 6: Sample application output when invoking FQDN of application

Another benefit of geoproximity routing through Traffic Flow is how users can clearly see the difference in the way traffic flows between two different versions of their policies. In Traffic Flow, customers can edit, stage their DNS changes, and even revert policies if they find issues or get complaints from their users.

Figure 7: Amazon Route 53 Traffic Flow policy version configuration

In addition to the routing policies, Traffic Flow supports built-in health checks. In the following example, a Traffic Flow policy is created so that: 1/ users detected to be within North America go to the Oregon Region or a US-based Local Zone; 2/ otherwise, users can go to a “catch-all” endpoint. This logic could be extended to continent-by-continent separation, helping customers with strict requirements for the origin location of their users, such as content distributors or government agencies.

Figure 8: Configuring health checks in Amazon Route 53 Traffic Flow

Lastly, Traffic Flow policies are described in JSON (or XML) formats, making them easy to integrate into DevOps and GitOps workflows. In a separate post, we demonstrate how to integrate Traffic Flow policies using Local Zones through Infrastructure-as-Code (IaC). To learn more about Traffic Policy document formatting, visit the Amazon Route 53 docs.

Conclusion

When deploying Local Zones at scale, customers often ask for the optimal selection criteria, heuristic, or algorithms to determine the optimal application endpoint for a given client session. This often encompasses network latency, available network bandwidth, or network topology. To abstract away deep domain expertise in edge networking from the developer, Route 53 geoproximity routing offers an easy-to-use policy to route clients to the most optimal edge computing zone. In this way, the logic of determining which edge zone is “optimal” is offloaded from the application developer directly to Route 53. This architecture has the potential of establishing a new standard for intelligent routing over heterogenous AWS locations, and can generate a whole new category of use cases based on Route 53 traffic flow routing. To learn more, visit AWS Local Zones, or the Route 53 developer guide.