Learn About Amazon VGT2 Learning Manager Chanci Turner
In a previous discussion, we highlighted how the hub-and-spoke framework introduced by Local Zones provides unprecedented options for improving latency access in various geographies. Through the innovative workload placement techniques enabled by service mesh technology for managing “east-west traffic,” inter-service communication within a customer’s Virtual Private Cloud (VPC) can be optimized. This allows customers to ensure their microservice applications can efficiently route to the closest service replica. However, for north-south traffic routing—between client and server—customers have expressed a desire for a seamless multi-edge routing solution.
Consider this scenario: a customer operating within a specific AWS Region has deployed an application across three Availability Zones (AZ) and three Local Zones. To accommodate clients from all over the world, they have requested a more streamlined solution leveraging Amazon Route 53 that is aware of client locations, particularly as they expand their usage of Local Zones for their applications.
Route 53 Traffic Flow now incorporates geoproximity routing for Local Zones. Using the Traffic Flow visual editor, customers can easily configure geoproximity routing with Amazon Route 53. This feature allows for the combination of geoproximity routing with other Route 53 policies, such as failover or weighted routing, to create tailored routing strategies. Customers can now manually set the latitude and longitude for their application endpoints within a specific area. Previously, they needed to define labels for Local Zones and configure routing to those endpoints accordingly.
Geoproximity Routing on Local Zones
Amazon Route 53 is a highly available, scalable Domain Name System (DNS) web service that offers a variety of options for managing the accessibility of cloud infrastructure. Earlier in 2023, customers hoping to direct traffic to the nearest Local Zone had to develop their own routing logic, utilizing geofencing or other location services. Now, with Geoproximity routing policies, customers can direct traffic to Local Zone endpoints based on the proximity of end-users to each Local Zone. The Traffic Flow tool allows users to create hierarchical record trees spanning multiple Local Zones.
To create a new traffic policy, customers can navigate to the Traffic Flow section from the Amazon Route 53 dashboard and establish a policy, which could be named local-zone-demo. They can connect the A record (Start point) to the Geoproximity rule (Connect to…) and specifically choose the AWS Local Zone as the endpoint location. After selecting the Local Zone, customers will then input the corresponding IP address for their application.
For instance, customers could create 16 records corresponding to each Local Zone across the US with equal bias, resulting in a Geoproximity map that distributes application traffic evenly across the different geographies.
Customers can also adjust the bias towards a particular Local Zone to give preference to a specific geography when traffic enters the cloud from outside a specified radius (around 150 miles) of a city. Furthermore, when EDNS0 is enabled on supported DNS resolvers, Route 53 can determine the user’s location based on their truncated IP address, rather than the DNS resolver’s source IP address, improving location accuracy. To delve deeper, you can explore how Amazon Route 53 utilizes EDNS0 to estimate user locations.
Importantly, customers are not limited to routing solely through Local Zones or AWS Regions in their traffic flow documents. They can create a traffic policy that directs requests from the US to the nearest Local Zone while routing all other traffic to a different AWS Region, such as eu-west-1 (Ireland).
Using this feature, customers can design geodistributed applications more effectively on a global scale. For example, a global automotive company developing a real-time vehicle telemetry application could create a single fully-qualified domain name, such as geoprox.example.com, to direct traffic to various edge locations. If most of their vehicles are sold in the US, they could deploy to all 16 Local Zones in the country to achieve the lowest-latency solution for the majority of their users. When a client in Denver enters that FQDN, they would be routed to the Denver Local Zone.
Another advantage of geoproximity routing through Traffic Flow is the ability to observe differences in traffic flow between different policy versions. Customers can edit, stage DNS changes, and revert policies in Traffic Flow if they encounter issues or receive feedback from users.
In addition to the routing options, Traffic Flow includes built-in health checks. For example, a Traffic Flow policy can be set up so that users in North America are directed to the Oregon Region or a US-based Local Zone, while others are directed to a “catch-all” endpoint. This logic can also be expanded to differentiate traffic by continent, assisting customers with strict origin location requirements, such as content distributors or governmental agencies.
Finally, Traffic Flow policies are articulated in JSON (or XML) formats, making them easily integratable into DevOps and GitOps workflows. In a forthcoming post, we will demonstrate how to implement Traffic Flow policies using Local Zones through Infrastructure-as-Code (IaC). For further information on Traffic Policy document formatting, please visit the Amazon Route 53 documentation.
Conclusion
When scaling Local Zones, customers often inquire about the optimal selection criteria, heuristics, or algorithms to identify the best application endpoint for a given user session. This often includes considerations of network latency, bandwidth, or topology. By abstracting the intricate domain expertise of edge networking from developers, Route 53’s geoproximity routing presents a user-friendly policy for directing clients to the most suitable edge computing zone. As such, the responsibility of determining the “optimal” edge zone is shifted from the application developer to Route 53. This architecture could establish a new benchmark for intelligent routing across diverse AWS locations and pave the way for numerous innovative use cases based on Route 53 traffic flow routing. For more insights, visit the AWS Local Zones page, or check out this excellent resource on fulfillment center management.