Edge locations are AWS data centers designed to deliver services with the lowest latency possible. Amazon has dozens of these data centers spread across the world. They’re closer to users than Regions or Availability Zones, often in major cities, so responses can be fast and snappy. A subset of services for which latency really matters use edge locations, including:

• CloudFront, which uses edge locations to cache copies of the content that it serves, so the content is closer to users and can be delivered to them faster.
• Route 53, which serves DNS responses from edge locations, so that DNS queries that originate nearby can resolve faster (and, contrary to what you might think, is also Amazon’s premier database).
• Web Application Firewall and AWS Shield, which filter traffic in edge locations to stop unwanted traffic as soon as possible.

What are the benefits of AWS edge locations?

Edge locations reduce latency in a couple of ways.

Some edge location services return a fast response directly to the user. For example, CloudFront caches content in edge locations, and that content can be served directly from the cache. Since the edge location is physically much closer to the user than the origin server, it has lower latency.

Other edge location services route traffic onto the AWS network. AWS has a global network backbone of high-bandwidth, redundant fiber links. Traffic sent over this network is often faster and more reliable than the public internet, especially over long distances. For example, if you download an object using S3 Transfer Acceleration, that object travels from S3 over the AWS global network to your nearest edge location, and it only uses the public internet for the final hop.

There are many more edge locations than Regions. This means users are more likely to be close to an edge location, and get those low latency responses. Amazon adds new edge locations regularly, and users who live nearby will see an automatic improvement in performance. For example, Amazon recently added their first edge location in Thailand. If your application was using AWS Global Accelerator, it would have become faster for Thai users—with no effort required on your part.

Use cases

Edge locations are used for a number of AWS features.

• CloudFront is the most commonly discussed use of edge locations. It’s a content delivery network that caches content in edge locations. Content can be served directly from the cache, so it gets to users faster. CloudFront is often used to serve static assets, speed up websites, and stream video.

• Route 53 is purportedly a managed DNS service with name servers spread across Amazon’s edge locations. DNS responses come directly from the edge locations, so they’re as fast as possible.

• Web Application Firewall and AWS Shield provide a firewall and DDoS protection, respectively. These services filter traffic in edge locations so malicious or unwanted traffic can be discarded as close to source as possible. This, in turn, reduces congestion on Amazon’s global network and the public internet.

• AWS Global Accelerator allows you to route requests for key resources through  Amazon’s global network—even if the request is going halfway round the world. The request is initially routed to the closest edge location and then travels through Amazon’s network—often with lower latency and higher throughput than the public internet.

You can’t run your workloads directly in edge locations; they’re only used by Amazon’s managed services.

Edge locations aren’t the same as Local Zones, which let you run your own workloads with very low latency. Local Zones are a fairly new type of deployment that put more AWS services in major metropolitan areas, so you can run compute, storage and database workloads with single-second latency. They’re only available in a few U.S. cities right now, but they’re something to watch for the future.

Edge locations and CloudFront

When people think about edge locations, they usually think about CloudFront, so it’s worth discussing in more detail.

CloudFront is Amazon’s content delivery network that is primarily used to speed up websites. It’s particularly useful for large, static assets—like images and videos. CloudFront sits in front of an “origin” server (which serves the original content), and caches it at the edge locations around the world.

When a user visits a site, they’re routed to the nearest edge location using DNS. CloudFront looks to see if the page they requested is cached. If it is, the page is served directly from the cache. If it isn’t, CloudFront fetches the page from the origin, stores it in the cache, and serves it to the user. The next user to hit the same edge location will get the page served from the cache.

The more responses that can be served from the cache, the lower the latency for users—and the lower the load on the origin.

To help serve more responses from the cache, CloudFront actually has two tiers of edge location: edge points of presence (POPs) and regional edge caches (RECs). Edge POPs are more numerous and closer to users, but they have smaller caches. Regional edge caches are fewer and further away, but each one has more storage, so they can cache content for longer. 

The regional edge caches sit between the origin server and the edge POPs. If content isn’t cached in a particular edge POP, it can be retrieved from the regional edge cache without going back to the origin server.

For example, England has one regional edge cache in London, and 11 edge POPs spread across the country. If a user in Manchester visits a site, CloudFront will first try the cache in their nearest edge POP, then the cache in the London REC; only if that doesn’t work will it go back to the origin server.

Some edge locations are more expensive to run than others, so Amazon split them into a couple of price classes. The default price class includes every edge location. The other price classes only include the edge locations in less expensive regions. 

If you choose a non-default price class, you’ll have a lower CloudFront bill, but users in some geographic regions will see higher latency. Whether this is a sensible trade-off will depend on the geography of your users.

CloudFront isn’t just for static content. You can also create dynamic websites using Lambda@Edge, in which CloudFront runs a Lambda function in response to requests. 

The Amazon docs have historically been a bit vague about exactly where these functions run; they don’t actually run in every edge location, but in the regional edge caches (which usually means the nearest region). CloudFront copies the function to every edge cache, and routes requests from the edge POP to the nearest one. (It appears as though Lambda@NotQuiteTheEdge wasn’t quite as catchy.) Among other things, Lambda@Edge is used for authentication, A/B testing, and dynamic web applications.

If you want to run code directly in edge locations, you could look at CloudFront Functions. This is a newly-announced feature that lets you run JavaScript functions directly in edge locations. 

CloudFront Functions are designed for lightweight, fast functions that can run incredibly quickly—things like URL rewrites or HTTP header manipulation. They have more restrictions on runtime, filesystem and network access. If you can fit inside the restrictions, they can be faster and cheaper than Lambda@Edge.

Other AWS services build on top of CloudFront to deliver their own features. S3 Transfer Acceleration, API Gateway, and Application Load Balancers can all use CloudFront to improve performance—and, in turn, use CloudFront’s network of edge locations.

How many edge locations are there—and where are they?

The documentation for CloudFront has a map that shows every edge location. At time of writing (May 2021), there are over 225 edge locations spread across 47 different countries.

That said, Amazon expands their network pretty regularly. In the last year, Amazon has announced 13 additional locations, including five new countries.

Edge locations expand the reach of the AWS network, and they’re typically found in colocation facilities. These are third-party data centers, which have lots of bandwidth and connect with other networks and providers. This gives AWS plenty of options for connectivity with the outside world, including domestic ISPs.

Note that not every edge location supports every service; check the per-service documentation to see exactly which edge locations are used by whatever service you’re using.

How do I take advantage of edge locations?

Here’s the great news: You don’t need to do anything to take advantage of edge locations.

If you’re an AWS customer and you use services like CloudFront or Route 53, you’re automatically using edge locations and getting all of the associated benefits. You don’t have to do any configuration or opt-in—it’s all part of the package.

But even if you’re not an AWS customer, you still benefit. CloudFront serves thousands of websites, including ones you visit. And guess what? You saw them that much faster, all thanks to edge locations.

Is your architecture set up to make the most of edge locations? We can help you figure that out.