Edge Locations, CloudFront, and the AWS Global Network

We've talked about AWS regions, clusters of data centers where our main infrastructure lives. But there's another critical part of AWS's global infrastructure we need to understand: edge locations and the global network.

What Are Edge Locations?

They're smaller than full AWS regions, there are a lot more of them, and they're spread out all over the world.

These locations sit at the "edge" of AWS's network, as close as possible to end users.

Regions

America Map

Global Edge Network

America Map

Region

Edge Location

Embedded POP

Regional Edge Cache

Regions
  • 36+ locations worldwide
  • Large clusters of data centers
  • Where you deploy most AWS resources (EC2, S3, etc.)
  • YOU choose which region to use
  • Designed for compute, storage, and databases
Edge Locations
  • 700+ locations worldwide
  • Smaller facilities, more widely distributed
  • Used primarily for content delivery and networking
  • AUTOMATICALLY used when you use edge services
  • Designed for low-latency content delivery

Edge locations come in a few different flavors - Edge Locations/Points of Presence (POPs), Regional Edge Caches, and Embedded POPs.

We really don't need to worry about the differences right now, and I'm just going to call them all "edge locations" from here on out.

The important take away here is that there are a lot of these edge locations and they are spread out all over the world.

Why do Edge Locations Matter?

So what can we do with all these edge locations? Can we deploy an EC2 instance in an edge location?

No, we can't.

Can we deploy an S3 bucket in an edge location?

Nope!

Databases? VPCs? Lambda functions?

No, No, and No (well kind of, but we'll get to that later).

We don't really deploy anything in an edge location. It's more about having a network of locations that make it faster and more reliable to deliver content to users all over the world. A Content Delivery Network.

The AWS Global Backbone Network

AWS has built their own global network of fibre optic that span the globe. They've literally wired up all their regions and edge location with their own private network. Oh, and they're working on tech like hollow-core cables to make it even faster.

Planet Scale Networking

This AWS backbone network gives us low latency, low packet loss, and high overall network quality and speed.

There's a whole bunch of amazing things that AWS has done here, and a lot of benefits that we get like enhanced security, and high availability. But one of the easiest things to notice is the speed.

Using the backbone network is usually much faster than using the public internet.

Let's say you have a web server hosted in Mumbai, India and I try to make an HTTP request to that web server from Vancouver, Canada.

World Map
1.52s

When I tested this out and it took 1.52 seconds to receive a basic 100 byte response. That's the time it takes for a single HTTP request to complete at this distance over the public internet.

But what happens if we use the backbone network instead?

World Map
564ms

Now when I try to access your web server in mumbai, AWS can connect me to my closest edge location, which is right here in Vancvouer. Then AWS directs my request to your web server in Mumbai over the AWS backbone network.

It takes only a third of the time for a round trip to the other side of the world and back. We've reduced the latency from ~1.5 seconds to ~0.5 seconds.

So how do we use this backbone network and all the edge locations?

CloudFront

We don't directly provision the edge locations or backbone network, instead we use services that automatically work on the edge infrastructure. The main one being CloudFront.

CloudFront is AWS's powerful content delivery network (CDN) service that uses all these edge locations to securely deliver static and dynamic content globally with low latency and high transfer speeds

For static content, cloudfront will cache the files at the edge. For dynamic content, it can route traffic effeciently over the backbone network. You can even run small amounts of code directly in the edge locations.

And you don't specify or think about individual edge locations. CloudFront works in all edge locations.

In the previous example, connecting to a server in Mumbai, we would simply add a CloudFront distribution with the EC2 isntance as it's origin. In a few minutes we would have 1/3 of the latency.

Static Content

Let's say you're serving static content, like a static website, from a bucket in Mumbai. No servers or dynamic content in this example, just static content that doesn't change.

Because it's static, it can be easily cached to improve speed even more. So if we put cloudfront in front of the S3 bucket, we can actually get something more like this:

Cache Miss

If the content has not been cached at the edge (like if no one has requested the static asset yet), the request will be forwarded to the origin bucket in the region through the AWS backbone network.

World Map
564ms
Cache Hit

If the content has been cached at the edge, the request will be served from the edge location. No request to the origin bucket in the region.

America Map
<100ms

CloudFront will cache the static content inside the edge locations so there's no need to go all the way to the origin in Mumbai every time. Now my request takes under 100ms to get a response.

Anything static, like images, videos, web pages, or other assets, can be cached at the edge locations.

Edge computing

It's not all about static content though. Cloudfront also allows you to run code at the edge locations, through CloudFront Functions and CloudFront Lambda@Edge.

These are smaller and more constrained environments than full servers or even full AWS Lambda functions. However, we can run some amount of logic at the edge, while keeping the main infrastructure like S3 storage, ec2 instances, and databases in a single region.

We'll touch on these a little bit more in the Serverless section.

Summary

In the next part, we will setup CloudFront to serve a static website from an S3 bucket. This is a simple use case, and as we've seen, CloudFront is capable of much more. However, this will give us a chance to see how CloudFront works in practice.

We won't be using CloudFront in many of other parts of this course because I want us to focus on other services directly.

But keep in mind that we can always integrate CloudFront into our AWS infrastructure if we want the edge benefits. Even a basic server running on an EC2 instance can use CloudFront with a VPC origin to utilize the backbone network for better networking.

Remember that CloudFront and the global edge network exists, even when we're not using them.

Show timestamps
00:00
We already talked about how, when we're deploying infrastructure to the cloud, we have to select a
00:04
region—a physical location in the world where our infrastructure is going to exist.
00:08
But there aren't just regions when we're dealing with AWS. We also
00:12
have this idea of edge locations and a global network.
00:15
So if you look here on the left, these are all the regions in North America. We've got things
00:20
like US East 1 and CA West 1. Then, on the right here,
00:24
is the AWS Global Network with all the different edge locations.
00:28
And there are just way more of these edge locations all around the world. For example, I'm in
00:33
Vancouver. I actually have some regions pretty close to me, but there's nothing directly in my city, right here in Vancouver.
00:39
But if I look at these edge locations, there's one right there, and they're all over North America—
00:43
they're all over the world. So there's way more of these kinds of edge locations. There are different
00:48
names for them: edge locations, embedded PoPs, regional edge caches. But I'm
00:52
just going to refer to them all as edge locations. There's a ton of them, way more than
00:56
regions. There are about 36+ regions—they're always adding more. AWS
01:00
currently has 700+ of these edge locations. All of these edge locations,
01:05
plus AWS's regions, are all linked up privately through AWS's backbone network.
01:12
So, essentially, if you're connecting from one AWS region to an edge location or another region,
01:17
you're using AWS's private backbone network, which is usually way faster and better than the public internet.
01:24
So Amazon has its own physical cables laid all around
01:27
the world to connect all their different regions and all their different edge locations.
01:31
And we can't deploy regular infrastructure to these edge locations. If I wanted to set up an S3
01:37
bucket or an EC2 instance, I still have to select a region. These edge locations are for a different purpose.
01:44
And let me show you a little example here. If I have a server set up in Mumbai, India,
01:49
and I try to connect to that from Vancouver—and I've done this test before—it takes about
01:53
1.52 seconds for a round trip request. And that's not really getting any data; that was
01:57
just a few bytes in an HTTPS request. But that was just the round trip time—really just network latency.
02:04
So, if I instead use AWS's edge locations and global network, what I can do is
02:11
instead of connecting directly from where I am in Vancouver and trying to connect to a server
02:14
all the way in Mumbai, I can actually connect to the closest edge location to me, which is in Vancouver.
02:20
So what that ends up looking like is, I'll directly connect to this edge location in Vancouver,
02:26
and then that will connect over AWS's private backbone network to the server in the region
02:33
somewhere. So I'm taking advantage of global networking by using AWS's private backbone network.
02:38
And that reduced the latency to about a third of the original time. So I'm getting way lower
02:44
latency just by using AWS's global backbone network. But we don't directly use these edge
02:49
locations. If I set up a server in Mumbai, I'm putting that specifically in the region.
02:54
I don't tell AWS that I want to use certain edge locations or certain backbone routes.
02:59
If I just use a service that leverages these edge locations, AWS will handle all of this automatically.
03:05
And the most popular service you'll use that
03:08
integrates with these edge locations is called CloudFront, and it's a CDN.
03:12
So if I set up CloudFront in front of my EC2 instance, no matter where someone is in the world
03:16
and they try to connect to my server, it's always going to go through an edge location first and
03:20
have a faster and better connection to my server.
03:23
Because CloudFront is a CDN, it works really well with static content. So let's say instead
03:30
of having a server in Mumbai, I have an S3 bucket. If I'm in Vancouver and I try to request
03:35
that static content, if that content hasn't yet been cached in CloudFront, I'll still do that
03:40
same request. It'll be way quicker than going over the public internet, but it'll still take
03:44
about half a second. Then CloudFront will cache
03:48
that static asset in one of the edge locations—in Vancouver, in this case.
03:53
And instead of having to go all the way around the world just to get my static assets, it's going to
03:56
exist in this location here. So you can imagine, when you're trying to grab static assets like
04:01
images, or if you're trying to set up a video streaming service or something, this is generally
04:05
how those services work. Instead of having to grab data from the origin region, that data is
04:11
copied and cached all over the world. So I'm just going to get that data from my closest edge
04:16
location. And you can also run tiny bits of code in these edge locations and do some dynamic things.
04:22
But really, they're much less powerful than a region. You can't deploy databases, you can't
04:26
just deploy full servers, but they really shine in caching static assets and allowing us to
04:31
connect over that private backbone network to other pieces of infrastructure in regions within
04:37
AWS. We're going to take a look at how to use CloudFront to serve a static website, just like we
04:42
did with the S3 bucket, but instead with CloudFront so it'll be globally distributed. And
04:46
then we're not really going to touch CloudFront too much in the course, but I want you to know
04:50
that you have access to all of these different edge locations within AWS.
04:54
And all you really have to do is design your infrastructure with CloudFront integrated into it
04:59
to be able to benefit from using this backbone network and all of these edge locations. So it's
05:04
always there and available, even when we're not focusing on it, because we're going to focus specifically on different things throughout the course.