AWS Edge Locations and CloudFront, Explained

An AWS edge location is a site where Amazon CloudFront keeps cached copies of your content and serves them to viewers from somewhere close to them. It is not a Region and not an Availability Zone: you don't deploy your application there, you deliver it from there. AWS's own documentation calls these sites points of presence, or POPs, and uses the two names for the same thing.

This guide explains what edge locations are and how they differ from Regions, follows a single request through CloudFront step by step, and covers the services that work alongside them. It then goes through the CloudFront features worth remembering and the traps the Cloud Practitioner (CLF-C02) and Solutions Architect Associate (SAA-C03) exams set around them. The same material is drawn on a whiteboard in the video linked at the end.

What is an AWS edge location?

An edge location is part of the CloudFront content delivery network. When a viewer asks for an image, a script or a video segment, CloudFront answers from the edge location that can serve that viewer best, usually the one with the lowest latency. If the edge already holds a copy, the viewer gets it without the request ever reaching your servers.

AWS currently says CloudFront has more than 750 POPs in over 100 cities across more than 50 countries, plus 15 regional edge caches. The same AWS global infrastructure page lists 39 Regions and 124 Availability Zones. Older figures you may see elsewhere are out of date; always check the CloudFront features page for the current figure, and on an exam, remember the ratio rather than the number: there are far more edge locations than Regions, and that is the point of them.

A useful way to hold the picture in your head:

The Region is the warehouse. It is big, it holds everything, and it is out of town.
The edge location is the corner shop. It is small, it stocks what people nearby keep buying, and it is on your street.
The regional edge cache is the neighbourhood depot. It sits between the two, holds more than any one shop, and restocks the shops around it so they rarely have to call the warehouse.

That is an analogy, not an AWS definition, but each part of it maps to a real layer of CloudFront, as the request path below shows.

Edge location vs Region vs Availability Zone

These three terms come up together in every AWS fundamentals course, and the Cloud Practitioner exam guide explicitly asks you to describe the relationships among them.

Region: a physical location where AWS clusters data centers. Each Region has at least three Availability Zones. This is where your workloads run: EC2 instances, databases, S3 buckets, Lambda functions. You choose a Region based on things like latency to your users, data sovereignty and compliance, and which services are available there.
Availability Zone: one or more discrete data centers inside a Region, with redundant power, networking and connectivity. You spread an application across several AZs so that losing one doesn't take it down. That is a resilience decision, not a distance decision.
Edge location: a CloudFront POP, sited close to viewers rather than close to your servers. It caches and delivers content, and it is also where some edge services meet your traffic. You don't launch servers in one or pick one when you deploy; CloudFront and the other edge services use the whole network for you.

So the question an edge location answers is different. A Region and its AZs answer "where does my application run, and how does it survive a failure?" An edge location answers "how does content reach a viewer on the other side of the world quickly?" Adding a second AZ makes your application more available, but it is still the same distance from a user in Singapore when your Region is in Virginia. That distinction is behind a Cloud Practitioner practice question on Availability Zones.

The Cloud Practitioner exam guide also lists AWS Local Zones and Wavelength Zones in the same task as edge locations, and they are easy to confuse. A Local Zone extends a Region into another metropolitan area so you can run compute, storage and databases near users. Wavelength puts AWS infrastructure inside telecommunications providers' data centers. AWS Outposts puts AWS hardware in your own facility. All three run your workloads; none of them is a CloudFront cache. If a scenario needs an application to *run* with very low latency near a city, think Local Zones; if it needs *content delivered* fast worldwide, think CloudFront. A practice question on low-latency compute near users tests exactly that line.

How a request travels through CloudFront edge locations

Here is what happens when a viewer requests an object, such as an image, from a site served by a CloudFront distribution. Every step comes from AWS's description of how CloudFront delivers content.

The viewer asks for the object. Their browser requests, say, images/logo.png from your domain.
DNS routes the request to a POP. CloudFront's DNS sends the viewer to the POP that can best serve the request, which is typically the nearest one in terms of latency, not necessarily the nearest one on a map.
The POP checks its cache. If the object is there and still fresh, that is a cache hit, and the POP returns it immediately.
On a miss, the POP asks a regional edge cache. Typically the nearest one. If the regional edge cache has the object, it hands it to the POP.
If the regional edge cache misses too, CloudFront goes to the origin. The origin is where the real content lives: an S3 bucket, a load balancer, or any HTTP server you run.
The object comes back and is cached on the way. CloudFront starts forwarding the object to the viewer as soon as the first byte arrives, and stores a copy at both the regional edge cache and the POP, so the next viewer nearby gets a hit.

CloudFront also keeps persistent connections open to your origins, so that fetches from the origin on a miss are as fast as possible.

Regional edge caches

The regional edge cache is the middle layer, the depot in the analogy. It has a larger cache than any single POP. POPs are numerous but small, so they evict objects that aren't requested often to make room for popular ones; the regional edge cache keeps those less popular objects for longer. Because every POP in an area shares the same regional edge cache, a file that one POP has evicted can usually be refilled from the regional layer instead of from your origin.

Regional edge caches are enabled by default and cost nothing extra. You don't configure them; Origin Shield, covered below, is the separate layer you choose to add.

Requests that skip the regional edge cache

Not every request takes the full path. AWS lists the exceptions:

Proxy methods go straight to the origin. PUT, POST, PATCH, OPTIONS and DELETE requests from viewers are not cached, so they pass from the POP directly to the origin.
Dynamic requests go straight to the origin. Content that is generated per request skips the regional layer.
Same-Region S3 origins skip it. If your origin is an S3 bucket and the best regional edge cache is in the same Region as the bucket, the POP goes directly to S3.

This matters for questions about caching behaviour: if a site's API traffic is mostly POSTs, those requests are not cached at all, so the regional edge cache does nothing for them.

Who uses CloudFront

AWS's published case studies give a sense of the scale edge locations are built for. Each claim here is what the case study itself says.

JioSaavn, the music streaming service, says it relies on CloudFront to deliver 15 petabytes of music and video to customers around the world every day.
PBS delivers nearly all of its streaming video through CloudFront and reports fifty percent fewer errors in its video streaming since the move. Its case study also mentions using invalidation to pull bad files out of the cache quickly while testing.
Amazon Prime Video uses CloudFront to deliver Thursday Night Football with low latency to a global audience.
Discovery serves its static assets from CloudFront's edge servers and reports cost savings of 20 to 25 percent.

The pattern is the same in each: a very large audience, spread far from where the content is produced, and content that many viewers request again and again.

Services that work with edge locations

An edge location never works alone. CloudFront needs an origin behind it, a DNS name in front of it, a certificate for HTTPS, and usually some protection. And two other AWS services use the same edge network for different jobs.

Origins: S3, load balancers and EC2

The most common origin is an S3 bucket. To keep the bucket private, so viewers must come through CloudFront and can't fetch objects straight from S3, you use origin access control (OAC). OAC works with a bucket policy that allows the CloudFront service principal, scoped to your distribution. AWS recommends OAC over the older origin access identity (OAI), which it now calls legacy; OAC supports all S3 Regions, server-side encryption with KMS keys, and PUT and DELETE requests. One limit: if the bucket is configured as a static website endpoint, it can't use OAC and must be set up as a custom origin. The SAA-C03 practice question on a private S3 origin turns on that OAC-versus-OAI choice. If you are weighing how to store the objects themselves, the guide to S3 storage classes and lifecycle rules covers that side.

For dynamic sites, the origin can be an Application Load Balancer, either internet-facing or internal through CloudFront VPC origins. EC2 instances can also act as a custom origin, and AWS recommends putting a load balancer in front of them so traffic is spread across instances.

Route 53 alias records

To point your domain at a distribution, you create a Route 53 alias record that targets it. An alias works at the root of a domain, such as example.com, where a CNAME record is not allowed. Route 53 also doesn't charge for alias queries to CloudFront distributions.

HTTPS, WAF and Shield

Certificates: an AWS Certificate Manager certificate used by CloudFront must be requested or imported in US East (N. Virginia), us-east-1, whatever Region your origin is in. This is one of the most reliable exam details in this area. The exception is the certificate between CloudFront and an Elastic Load Balancing origin, which can be in any Region.
AWS WAF: attach a web ACL to the distribution, and WAF inspects requests at CloudFront, blocking bad ones before they reach your servers.
AWS Shield: Shield Standard is applied automatically for all AWS customers at no extra charge. Shield Advanced is the optional paid tier.

If you are studying who is responsible for which layer of protection, the shared responsibility model guide puts these services in context.

Global Accelerator and S3 Transfer Acceleration

Two more services use the same edge network, and exams love to put them next to CloudFront.

AWS Global Accelerator gives you two static anycast IPv4 addresses (four if you use dual stack). Your users' traffic enters the AWS network at the closest edge location, where Global Accelerator terminates the TCP connection and opens a new one to your endpoint over the AWS global network. Its endpoints are Network Load Balancers, Application Load Balancers, EC2 instances and Elastic IP addresses. It does not cache anything. AWS positions it for non-HTTP traffic over TCP or UDP, such as gaming, IoT and voice, and for HTTP applications that need static IP addresses or fast failover between Regions.

Amazon S3 Transfer Acceleration uses CloudFront's edge locations to speed up transfers into and out of one S3 bucket. Data enters at the nearest edge location and then travels to the bucket over an optimized network path. You use a special endpoint, bucketname.s3-accelerate.amazonaws.com, and the bucket name must be DNS-compliant with no periods. It is about moving objects to and from a bucket, typically large uploads from far away, not about caching for viewers.

CloudFront features to remember

These are the settings that come up repeatedly in exam scenarios and in real troubleshooting.

TTLs and caching headers

How long an object stays cached is controlled by time to live (TTL) settings and by the caching headers your origin sends.

Default TTL: if the origin sends no Cache-Control or Expires header, CloudFront keeps the object for 24 hours (86,400 seconds) by default.
Maximum TTL: defaults to one year (31,536,000 seconds). With a minimum TTL of 0 and a Cache-Control: max-age header, CloudFront caches for the lesser of max-age and the maximum.
Minimum TTL above 0: CloudFront then caches objects even when the origin says no-cache, no-store or private. This is a common cause of "why is CloudFront serving stale content?"
Viewers can't force a refresh: CloudFront ignores Cache-Control and Pragma headers in a viewer's GET request.

Note that an object can leave a POP before its TTL ends: an edge may evict a rarely requested file to make room. TTL is the longest an object may stay, not a promise that it will.

Invalidation vs versioned file names

Invalidation removes files from CloudFront's caches before they expire, at the edge locations and the regional edge caches, so the next request goes back to the origin. Pricing details worth knowing:

The first 1,000 invalidation paths each month are free, counted across all distributions in your account.
A path with a wildcard, such as /images/*, counts as one path however many files it matches.
An invalidation can't be cancelled once it starts.

For files that change often, AWS recommends versioned file names instead, such as app.v42.js rather than overwriting app.js. A new name is a new object, so viewers get it immediately without any invalidation, and you avoid the cost entirely.

Origin Shield vs regional edge caches

Origin Shield is an optional extra caching layer in front of your origin. You enable it per origin and choose the Region with the lowest latency to that origin. Requests from the regional edge caches then go through that one layer (those made in the origin's own Region bypass it), so in the best case only one request per object reaches your origin. It is offered only in Regions where CloudFront has a regional edge cache.

The difference from regional edge caches is the exam point: regional edge caches are on by default and free; Origin Shield is optional, one more layer, and costs extra. You add it when your origin is expensive to hit or sensitive to load.

Origin failover

An origin group has a primary and a secondary origin. When the primary returns one of the status codes you choose (such as 500, 502, 503 or 504), CloudFront retries the request against the secondary. A failed connection counts as a 503 and a timeout as a 504, so select those codes if you want failover for them too. By default CloudFront tries the primary for up to 30 seconds (three attempts of 10 seconds) before failing over. Failover applies only to GET, HEAD and OPTIONS requests, so it protects reads, not writes.

Signed URLs, signed cookies and geo restriction

To serve private content only to authorized users:

Signed URLs: suit individual files, such as one download link, or clients that don't support cookies.
Signed cookies: suit access to many files at once, such as every segment of a video or a members' area, and leave your URLs unchanged.
Trusted key groups: AWS's recommended way to define which keys can create signed URLs and cookies.

Geo restriction allows or blocks viewers by country, for the whole distribution. Blocked viewers get HTTP 403. For anything finer than country level, AWS points to a third-party geolocation service.

You also choose a viewer protocol policy per cache behaviour: allow HTTP and HTTPS, redirect HTTP to HTTPS, or HTTPS only. "HTTPS only" answers an HTTP request with 403; "redirect" answers a GET or HEAD with a 301.

CloudFront Functions vs Lambda@Edge

Both run your code close to viewers, but they are built for different weights of work, as AWS's guide to choosing between them sets out.

CloudFront Functions: lightweight JavaScript that runs at the edge locations on viewer request and viewer response events only. Sub-millisecond execution, scale to millions of requests per second, a 10 KB code limit and 2 MB of memory, with no network, file system or request body access. Good for header changes, URL rewrites and redirects, and simple token checks.
Lambda@Edge: Node.js or Python, on viewer *and* origin request and response events, with network and request body access and up to 30 seconds of run time. You author it in us-east-1, and CloudFront replicates it to locations around the world. Good for work that needs to call another service or inspect the body.

The deciding question is simple: if the logic is small and needs no network call, use CloudFront Functions, which runs in under a millisecond. The SAA-C03 question on CloudFront Functions vs Lambda@Edge is built on that rule.

What the AWS exams ask about edge locations

Edge locations appear in several AWS exam guides:

Cloud Practitioner (CLF-C02): Domain 3, Task 3.2 lists Regions, Availability Zones and edge locations, the benefits of edge locations (with CloudFront and Global Accelerator as examples), and the relationships among them.
Solutions Architect Associate (SAA-C03): Task 3.4 covers edge networking services such as CloudFront and Global Accelerator and their use cases, and Task 2.1 covers using edge accelerators such as a CDN.
Others: the CloudOps Engineer Associate (SOA-C03) covers configuring CloudFront and fixing caching issues; Solutions Architect Professional and Advanced Networking Specialty test global edge services at design level.

You can practise all of it in the Cloud Practitioner practice tests and the Solutions Architect Associate practice tests, or browse every question in the CLF-C02 question list and the SAA-C03 question list. These are the traps they keep setting.

The three-way trap

Three services use the edge network, and a scenario usually fits exactly one:

CloudFront: viewers far from the origin need content (static or dynamic, over HTTP or HTTPS) delivered faster, with copies cached close to them.
Global Accelerator: the application needs static IP addresses, runs over TCP or UDP, or needs fast failover between Regions. Nothing is cached.
S3 Transfer Acceleration: large files need to move into or out of one S3 bucket faster over long distances.

The words to look for are "cache" (CloudFront), "static IP", "UDP" or "non-HTTP" (Global Accelerator) and "upload to a bucket" (Transfer Acceleration). The CLF-C02 question on global content delivery is the simplest form of the trap, and the one used in the video. Harder versions: a UDP game with instant Region failover, a Cloud Practitioner static IP scenario, and global uploads into one bucket, where CloudFront is the distractor.

Other traps

More edge locations won't fix a low cache hit ratio. If CloudFront keeps going back to the origin, look at the cache key: forwarding every header, cookie or query string splits one object into many cache entries. The cache hit ratio question tests this.
OAC, not OAI. For a private S3 origin, the current answer is origin access control. OAI is legacy, and a website endpoint can use neither.
us-east-1 for certificates and Lambda@Edge. Whatever Region your app is in, the ACM certificate for CloudFront and the Lambda@Edge function are created in N. Virginia.
An Availability Zone is not an edge location. A second AZ adds resilience, not proximity to far-away users.

Frequently asked questions

Is an edge location the same as a Region?

No. A Region is a cluster of data centers, with at least three Availability Zones, where your workloads run. An edge location is a CloudFront point of presence that caches and delivers content close to viewers. There are far more edge locations than Regions.

Can you run EC2 instances in an edge location?

You don't choose an edge location or launch servers in one. Edge locations serve CloudFront and the other edge services. If you need compute close to a particular city, AWS Local Zones extend a Region for that purpose.

How many edge locations does AWS have?

AWS currently says CloudFront has more than 750 points of presence in over 100 cities across more than 50 countries, plus 15 regional edge caches. The number grows, so check the CloudFront features page for the current figure rather than relying on older articles.

What is the difference between an edge location and a regional edge cache?

An edge location (POP) is close to viewers and has a smaller cache. A regional edge cache sits between the POPs and your origin, has a larger cache, keeps objects longer, and is shared by the POPs around it. It is on by default at no extra charge.

Does AWS Global Accelerator cache content?

No. Global Accelerator brings traffic onto the AWS network at the closest edge location and routes it to your endpoints over static anycast IP addresses, but it caches nothing. For caching, use CloudFront.

How do I remove a file from CloudFront before it expires?

Create an invalidation for its path. The first 1,000 paths a month are free, and a wildcard counts as one path. For files you update often, use versioned file names instead, so no invalidation is needed.

Watch the whiteboard video

The video draws the request path from viewer to POP to regional edge cache to origin, step by step, and works through the three-way exam trap with a practice question: AWS Edge Locations Explained on a Whiteboard (CLF-C02 & SAA-C03) on YouTube.