Low Latency Performance With AWS Local Zones | by Tate Galbraith | Feb, 2022

Ultra-low latency in the places where you need it most

Tate Galbraith
Photo by Lars Kienle on Unsplash

Imagine this: you just finished setting up a brand new EC2 instance. Everything was going fine until you started testing out the network. There staring you right in the face was one big problem: latency.

Historically, AWS only offered a handful of Regions and Availability Zones to deploy into. If you or your customers were stuck somewhere in between zones, then you were out of luck when it came to latency.

Most of the time, this isn’t really an issue if you’re hosting some data or serving a basic website. However, things start to get serious if you’re trying to deliver streaming data like video or audio. For sensitive applications like these you need much faster delivery times and a more stable network.

This is where AWS Local Zones come into play. These are a set of newly minted edge locations that AWS provides in different metropolitan areas. Using these zones you can achieve lower latency and more granular control over where you deploy.

Before we dive into the new zones, let’s refresh our memory on some AWS fundamentals.

The largest geographic unit of measurement in the AWS world is the Region. A Region is a large area containing multiple data centers. Inside of each Region, the data center is considered an Availability Zone. There are multiple AZs spread out for fault tolerance across a region.

When you spin up a new instance you can select the Availability Zone you’d like then you’re pretty much done. Although Amazon provides a list of edge locations, each AZ wasn’t explicitly tied to a particular location (at least not that you could quickly discern). For example, you couldn’t explicitly deploy into a particular city like Los Angeles.

When you deploy into these zones you, its pretty much up to you to estimate which one has the best latency for your application.

With the introduction of Local Zones, AWS now provides specific Availability Zones in major cities. The best part is, each zone is explicitly labeled according to the city it resides in. Now you can actually deploy an instance into a particular city at will.

Below are the currently available Local Zones for the US East Region:

AWS Local Zones for the us-east-1 region. Source.

There are also several Local Zones available in the US West Region as well:

AWS Local Zones for the us-west-2 region. Source.

As you can see, this opens up a whole new world of possibilities for deploying instances as close as possible to the cities they’ll be serving. If you’re providing video to customers in Portland or Denver then creating an endpoint in those Local Zones will likely be much quicker than a normal AZ.

Of course, there are a few limitations with Local Zones.

Local Zones do not support the entire AWS service catalog yet. They also don’t support all EC2 instance types (this could be a huge catch for some). In order to check on the service catalog, reference the following page:

Although instance type support is listed on that page, there are still some specific instances that aren’t allowed in some zones. In order to find out what instances are permitted in a local zone, use the following aws-cli command (replacing the <zone> and <region> with your own):

aws ec2 describe-instance-type-offerings --location-type "availability-zone" --filters Name=location,Values=<zone> --region <region>

This should output the available instance types for that particular zone.

This is all good and fun, but what about the latency numbers? How much better is it?

Well, this question isn’t simple to answer because the real answer is: it depends. Measuring latency isn’t a static thing. Links change and the values ‚Äč‚Äčaren’t always the same. Another critical variable is where the client accesses the server from. If you spin up a new instance in NYC and they’re reaching it via a degraded path or far outside of the city, you may not see much improvement at all.

According to Amazon if you’re located in the same city as an instance into a local zone, then you can expect “single-digit millisecond latency.”

Local and normal AZ ping response times.

In the benchmarks I performed against a Local Zone instance in New York City (us-east-1-nyc-1a) I saw an average response time of 3.5ms from a server located in the same geographic area (northern New Jersey). For a cloud hosted instance this is an excellent response time.

For the same test performed against an instance located in a standard US East zone (us-east-1c), the results were around 8.5ms. Using a Local Zone cuts the latency by more than half.

Using these new Local Zones seems like one of the quickest, easiest ways to move services closer to major metropolitan areas and serve applications faster than ever before.

Always keep in mind that your mileage may vary when deploying into new Local Zones depending on their location and the current status of the links. It is always a good idea to perform your own latency tests to determine the best zone for deployment.

Leave a Comment