An edge location is a small site, close to ordinary users, that holds copies of popular content and handles the first part of every request.

The simple definition

A server is a computer that answers requests from other computers. Your website’s main servers are called the origin, because that is where the original files and the real application live. An edge location is a site placed at the “edge” of the network, meaning near the people who use it, rather than deep in a far-off data center. It holds temporary copies of your files, and it can also do useful work such as checking security and picking the best route to your origin.

A point of presence (PoP) is another name for such a site. Each one contains servers, storage for cached copies, and fast connections to internet providers. Azure has a large number of them around the world, many more than it has full regions.

Why the word “edge”?

Network designers imagine the internet as a core, made of big data centers and long cables, with the users sitting around the outside. The places where the core meets the users are the edge. Moving work to the edge shortens the trip data has to make.

Edges solve problems that no amount of server power can fix, because the biggest enemy is simply distance.

An example for each reason

Edge computing has a small vocabulary. Learn these terms once and everything else becomes easier to follow.

flowchart LR
  U["User on a phone or laptop"] --> E["Edge location: nearby PoP with cache"]
  E -- "cache hit: answer right away" --> U
  E -- "cache miss: ask the origin" --> O["Origin in an Azure region"]
  O --> E
    

Hit ratio: the number that matters most

The cache hit ratio is the share of requests that the edge answers from its stored copies. If out of 100 requests, 90 are answered by the edge, the hit ratio is 90 percent. A higher hit ratio means faster pages and a quieter origin. Most of the tuning you will do in this guide is aimed at raising it safely.

Beginners often mix these up. They are different things with different jobs.

Several Azure services use edge locations. Knowing which does what saves you from picking the wrong tool.

What the shift to Front Door means for you

Microsoft once offered several CDN products, including some built on partner networks. Over time it has retired some of them and now recommends Azure Front Door as the main service for content delivery and global web entry. The ideas in this guide, such as origins, caching, TTL, and hit ratio, apply to all of them, so what you learn here stays useful even as product names change.

An edge location is small compared with a region, but it is carefully built for one purpose: answering many requests, very quickly.

The physical parts

Most edge locations sit inside well-connected facilities where many internet providers meet. They hold racks of servers, fast storage for cached files, network switches, power backup, and cooling. Because they are small and numerous, they can be placed in many cities, including ones with no full region.

The network connections

An edge’s value comes largely from its connections. It links to local internet service providers directly, which is called peering. This means a user’s request often reaches the edge in just a few hops, without wandering through many networks. From the edge to your origin, traffic travels over Microsoft’s private global network, which is usually faster and more stable than the open internet.

flowchart TB
  U["Users in many cities"] --> ISP["Local internet providers"]
  ISP --> P1["Edge PoP in City 1"]
  ISP --> P2["Edge PoP in City 2"]
  P1 --> BB["Microsoft private global network"]
  P2 --> BB
  BB --> R["Origin in an Azure region: web app, storage, API"]
  subgraph IN["Inside an edge PoP"]
    direction LR
    TLS["TLS and HTTP handling"] --> WAF["Security rules"]
    WAF --> CH["Cache storage"]
    CH --> RT["Routing to origin"]
  end
  P1 --> TLS
    

What the software inside does

• Connection handling: the edge completes the secure connection with the user close by, which saves time.
• Security checks: rules can block bad requests before they ever reach your origin.
• Cache lookup: the edge checks whether it already holds a fresh copy of the requested file.
• Compression and optimisation: the edge can shrink files so they travel faster.
• Routing: on a miss, the edge picks a healthy origin and forwards the request.

Nobody types the address of an edge location. Clever routing sends each visitor to a good one automatically.

Step 1: the name lookup

When you type a website address, your device asks the Domain Name System, or DNS, for the numeric address that belongs to that name. DNS works like a phone book for the internet. When your site uses an edge service, its name points to the edge network instead of directly to your origin.

Step 2: anycast routing

Edge networks often use a technique called anycast. The same address is announced from many locations at once. The internet’s routing system, which always tries to find short paths, then delivers each user’s traffic to the closest announcing location. A user in Chennai and a user in London can type the same address and land in different cities without any special effort.

Step 3: a faster handshake

Opening a secure connection needs several back-and-forth messages. If those messages had to travel all the way to a distant origin, each one would add delay. With an edge, the handshake happens with the nearby edge location. The edge then keeps a long-lived, ready connection to your origin, so it can reuse it for many users. This trick, sometimes called connection splitting, is why even requests that cannot be cached often feel faster when they pass through an edge.

Follow two requests for the same picture. The first one fills the cache, and the second enjoys the result.

sequenceDiagram
  participant A as First User
  participant B as Second User
  participant E as Edge Location
  participant O as Origin
  A->>E: Request logo picture
  E->>E: Look in cache, not found
  E->>O: Fetch logo picture
  O-->>E: Picture with caching instructions
  E->>E: Store a copy
  E-->>A: Picture, a bit slower, cache miss
  B->>E: Request logo picture
  E->>E: Look in cache, found and fresh
  E-->>B: Picture, very fast, cache hit
    

What happens at each step

• Look in the cache: the edge builds a key from the web address, and sometimes from other details, and checks whether it holds a fresh copy.
• Fetch from the origin: on a miss, the edge asks your origin for the file. The origin’s reply includes instructions about how long the file may be kept.
• Store a copy: if the rules allow it, the edge saves the file for later visitors.
• Reply to the user: the edge sends the file on, and adds helpful details, such as whether it came from the cache.

Each edge has its own cache

An important detail: the cache in one edge location is separate from the cache in another. A file stored in the Mumbai edge is not automatically in the London edge. Each edge fills its cache as its own local visitors ask for files. This is why a file can be fast for users in one city and slower for the very first visitor in another.

A cached file is like food in a shop: fresh for a while, then it must be checked, replaced, or thrown away.

Who decides how long to keep a file?

The origin tells the edge. It does this by sending caching instructions with each file, usually in a setting called Cache-Control, which includes a maximum age. The edge service can also apply its own rules that override or fill gaps. The period a copy may be kept is the time to live, or TTL.

Choosing a TTL

The edge is powerful, but it must be told what is safe to keep. The key question is simple: is this response the same for everyone?

Static content: the perfect fit

Static content is the same for every visitor. Pictures, videos, style sheets, scripts, fonts, downloadable documents, and software installers are all static. They make up the large majority of the bytes on a typical website, which is why edges help so much.

Dynamic content: handle with thought

Dynamic content changes depending on who asks or when. Your shopping basket, a search result, a bank balance, or a live score are dynamic. Some dynamic pages, such as a public product list that changes every few minutes, can still be cached for a short time. Others, such as anything personal, must never be shared between users.

Accelerating what cannot be cached

Even uncacheable responses can gain from the edge. The nearby secure handshake, the warm and reused connection to the origin, and the use of Microsoft’s private network all reduce delay. This feature is often called dynamic site acceleration. It does not store the response, but it makes the trip shorter and steadier.

A few small settings decide whether your hit ratio is 95 percent or 30 percent.

The cache key

To decide whether it already holds a file, the edge builds a cache key, usually from the web address of the request. Two requests with the same key share one stored copy. Two requests with different keys are treated as different files, even if they return identical content.

Query strings

A query string is the part of an address after a question mark, such as a tracking tag or a page number. If the edge treats every different query string as a separate file, a marketing campaign that adds a random tag to every link can make every request a miss. Most edge services let you choose how to handle this:

• Ignore query strings: all requests for the same path share one cached copy. Good for static files where the tag does not change the content.
• Use every query string: each different query string is cached separately. Good where the query truly changes the response.
• Include only chosen parameters: cache by the important ones and ignore the rest. Often the best balance.

Compression

Text files such as web pages, style sheets, and scripts shrink dramatically when compressed. Edge services can compress files on the fly and store compressed copies, so users download fewer bytes. Images and videos are already compressed, and compressing them again gains little.

File versioning: the cleanest way to update

The best way to change a cached file is not to purge it, but to give the new version a new name. For example, instead of changing “site.css”, publish “site.v8.css” and update the page to point to it. Old copies in the cache are simply never asked for again. Visitors immediately see the new version, and you can give the files a very long TTL. Build tools often add a short code, called a fingerprint, to file names automatically.

The edge is only as good as the origin it protects. Azure lets you describe your origins and how to choose among them.

What counts as an origin

An origin can be a storage account that holds files, an App Service web app, a virtual machine, a load balancer in a region, a container app, or even a server outside Azure. You tell the edge service where the origin lives and how to talk to it.

Origin groups

An origin group is a set of origins that serve the same content, often in different regions. The edge service picks among them according to rules you choose.

Health probes

A health probe is a small, repeated test request that each edge sends to your origins, for example asking a simple status page whether it is alive. If an origin fails several tests, the edge stops sending traffic there and uses another one. When the origin recovers, traffic returns. This is how a failure at the origin can be hidden from users.

Let us put every piece together in a typical, practical design for a growing website.

The example is a shopping website with customers in several countries. Photos and scripts are served from storage, pages and the shopping logic run in two regions, and an edge service sits in front of everything.

flowchart TB
  U["Customers worldwide"] --> DNS["DNS name pointing to the edge service"]
  DNS --> FD["Azure Front Door: nearest edge PoP"]
  FD --> WAF["Web Application Firewall rules"]
  WAF --> C{"Cached copy available?"}
  C -- "Yes" --> U
  C -- "No: static files" --> ST["Origin 1: Blob Storage with images and scripts"]
  C -- "No: pages and API" --> OG["Origin group with health probes"]
  OG --> A["Region A: Application Gateway and App Service"]
  OG --> B["Region B: Application Gateway and App Service"]
  A --> DB["Database with replication"]
  B --> DB
    

The role of each part

• DNS name: a friendly address that leads customers to the edge service.
• Front Door edge: terminates the secure connection nearby, applies rules, and serves cached files.
• Web Application Firewall: blocks common attacks before they touch your servers.
• Blob Storage origin: holds large static files, cheap and durable.
• Origin group: two regional applications, so a regional problem does not stop the shop.
• Application Gateway: shares traffic among servers inside each region.
• Database: the shared source of truth, with copies for safety.

The benefits of the edge are measurable. Here is how to understand and estimate them.

Distance and delay

Light in a fibre cable moves at roughly two-thirds of its speed in empty space. A useful rule of thumb is that a round trip costs about one millisecond for each hundred kilometres between the two points, even in a perfect world. Real networks add detours and equipment delay, so actual figures are higher.

A worked example

Suppose a user is 8,000 kilometres from your origin. The idealised round trip is about 80 milliseconds. Before the page can start, the device usually needs about one round trip to open the connection and another to set up encryption, so two round trips, and then one more to send the request and receive the first byte. That is roughly three round trips, about 240 milliseconds, before the first byte arrives, and real life will be slower.

Now suppose an edge location is 100 kilometres away. One round trip costs about 1 millisecond, so the same three round trips cost about 3 milliseconds when the file is cached. For a page with dozens of files, the saving adds up to a clear and noticeable improvement.

Offload: how much work the origin saves

If your site receives one million requests a day and the edge answers 90 percent of them, your origin handles only 100,000. That is ten times less work. If the hit ratio improves to 95 percent, the origin handles 50,000, which is half as much again. A small improvement in hit ratio can mean a big reduction at the origin when the ratio is already high.

Other measures worth watching

• Time to first byte: how long until the first piece of the answer arrives.
• Byte hit ratio: the share of data, not just requests, served from cache. Large files matter more here.
• Origin latency: how fast your origin answers on misses.
• Error rate: the share of requests that fail, from the user’s side and the origin’s side.

The edge is your front door. A strong front door keeps problems outside before they reach anything valuable.

Encryption and certificates

HTTPS encrypts the connection between the user and the site, so that nobody in between can read it or change it. The edge handles this for you, using a certificate, a digital proof of identity for your website. Azure can issue and renew certificates for your custom domain automatically in many cases, which removes a common cause of outages: forgetting to renew. Also use encryption between the edge and the origin, so the whole path is protected.

The main protections

An edge works quietly, so you need numbers to know whether it is doing its job.

Where to look

Azure Monitor collects metrics for edge services, and you can send detailed access logs and firewall logs to a log workspace or a storage account for searching. Many logs include a header that says whether a response was a hit or a miss, which lets you study exactly which files are not being cached.

Alerts worth setting

• A sudden fall in hit ratio, which can mean a configuration change or a new query string pattern.
• A rise in server error responses from the origin.
• An origin marked unhealthy by the probes.
• A large jump in data transfer, which affects cost.
• An approaching certificate expiry, if you manage certificates yourself.

Edge services usually save money overall, because they reduce origin work, but they have their own meters.

What you are typically charged for

Ways to keep costs sensible

• Raise the hit ratio: every extra hit is a request the origin does not pay for.
• Compress text files: fewer bytes cost less to send.
• Resize images: serve images in sizes suited to the device, not giant originals.
• Choose the tier honestly: pick the higher tier only if you need its features.
• Review geography: if most of your users are in one expensive zone, check whether pricing there is acceptable.
• Budget alerts: set a budget and warnings, since a viral download can raise transfer sharply.

The edge is helpful for most public websites, but it is not free of costs and risks.

Do you need an edge service?

Most edge problems come from a handful of repeated mistakes. Learn them here, before they reach your visitors.

Good edge setups are built with a small set of dependable habits.

A step-by-step setup order

When something looks wrong, work from the symptom to the layer that most likely causes it.

A cache is a copy, and copies of your content can end up in many countries. This matters when the law cares where data lives.

When you choose a region, you choose where your main data is stored. An edge service works differently: it keeps temporary copies in many places around the world, wherever your visitors happen to be. For public content such as pictures and scripts, this is exactly what you want. For regulated or private content, it needs thought.

Things to consider

• Public versus private data: public marketing files are fine to cache widely. Personal, health, or financial data should not be cached at the edge at all.
• Where TLS ends: secure connections end at the edge, so the edge briefly sees the content, even if it does not store it. Review the provider’s data handling statements.
• Logs: access logs that mention users can themselves count as personal data, so decide where they are stored and for how long.
• Regional controls: some products let you limit which parts of the world your content is served from. Check what is available and what it costs.
• Compliance documents: Microsoft publishes audit reports and certifications. Check that the edge service you chose is covered by the standards your industry needs.

The scenarios below show typical uses of edge networks. They are general patterns, not descriptions of any named company’s private setup.

Each lab is small and ends with cleanup. Use the cheapest available options, and watch the cost page.

Lab 1: Serve a static site through an edge service

• Create a storage account, enable static website hosting, and upload a simple page and a picture.
• Create an edge service profile and add the storage endpoint as the origin.
• Open the page through the edge address, and then directly through the storage address. Compare how they respond.
• Look at the response headers for the hit or miss indicator. Reload several times and watch it change.
• Delete the resource group when finished.

What you learn: the difference between the origin and the edge, and how a first request misses and later ones hit.

Lab 2: Watch TTL in action

• Set a very short TTL for the picture, such as a minute, and request it twice quickly. Note the hit.
• Replace the picture at the origin with a different one under the same name. Request it again and see the old picture still shown until the TTL ends.
• Now upload a version with a new file name and update the page. Notice that the new picture appears immediately.

What you learn: why versioned file names beat waiting or purging.

Lab 3: Try a firewall rule

• Enable the firewall on your edge profile, if the chosen tier supports it.
• Add a simple custom rule that blocks requests to a path you choose, such as an admin page that does not exist.
• Request that path and confirm it is blocked at the edge. Look in the firewall log to see the matched rule.
• Remove the rule and delete the resource group.

What you learn: that the edge can reject unwanted requests before they reach your origin.

Every important word from this guide in one place, each with a plain comparison.

Plain answers to what beginners ask most often.