---
title: Shielding
summary: null
url: https://www.fastly.com/documentation/guides/concepts/shielding
---

When Fastly makes requests to your origin servers, those requests may come from any of our [POPs](https://www.fastly.com/documentation/guides/concepts/pop), which act independently. However, if you wish, you may designate one [POP](https://www.fastly.com/documentation/guides/concepts/pop) location as a 'shield', collecting requests from across the Fastly network. In this arrangement, requests to your origin server will come only from the designated shield [POP](https://www.fastly.com/documentation/guides/concepts/pop), and all other Fastly locations will forward requests to the shield.

![Shielding illustration](/img/shielding-precomposed.svg)

Shielding has significant benefits:

- **Reduces origin load**: reduces the volume of requests from Fastly to your origin servers
- **Improves cache hit ratio (CHR)**: increases the probability of end user requests resulting in a cache `HIT` (albeit potentially not from the first [POP](https://www.fastly.com/documentation/guides/concepts/pop) which handles the request)
- **Speeds up connections**: reduces connection setup latency for `MISS` and `PASS` requests that must be served from origin (this feels counter-intuitive, but takes advantage of the fact that all Fastly [POPs](https://www.fastly.com/documentation/guides/concepts/pop) always have a pool of open connections to all other Fastly [POPs](https://www.fastly.com/documentation/guides/concepts/pop), reducing the time required for costly [multi-roundtrip handshakes](https://hpbn.co/transport-layer-security-tls/#tls-handshake)).

## Enabling and disabling shielding

Shielding may be enabled when adding or editing an origin server, and may be selected per-origin. If your origin servers are in different locations, it may make sense to choose different shields for each origin server. You can enable shielding via the [web interface](https://www.fastly.com/documentation/guides/getting-started/hosts/shielding), or set the [`shield`](https://www.fastly.com/documentation/reference/api/services/backend/#field_shield) property of a `Backend` object when you create or modify it using the API or CLI. For example:

```term
$ fastly backend create --name=app_server --address=192.168.123.123 --shield=amsterdam-nl --service-id=9yqrXWr5kfqroswtmxgQDz --version=latest
SUCCESS: Created backend app_server (service 9yqrXWr5kfqroswtmxgQDz version 1)
```

Each [POP](https://www.fastly.com/documentation/guides/concepts/pop) has a shield identifier. These are listed in the properties returned from the [`/pops`](https://www.fastly.com/documentation/reference/api/utils/pops/#list-pops) API endpoint. For example, the [POP](https://www.fastly.com/documentation/guides/concepts/pop) in Amsterdam has the name `AMS` but a shield identifier of `amsterdam-nl`. See [choosing a shield location](https://www.fastly.com/documentation/guides/concepts/shielding#choosing-a-shield-location).

## Effects of shielding

Enabling shielding on a Fastly service will create side effects that should be considered carefully.

### Double execution

Services using shielding **will (in many cases) execute their edge code twice**: once at the edge location and once at the shield location. However, if a request is received directly at the shield location, then any backend requests will go directly to your origin, so the edge code will only execute once.

`req.backend.is_origin` and `req.backend.is_shield` tell you whether a backend request made from the current POP will go to your origin server or to a shield POP, which is usually important when manipulating a request. `fastly.ff.visits_this_service` tells you whether the current POP is acting as a shield POP or not, which is more often important when manipulating a response.

For example, use `req.backend.is_origin` to determine whether to modify request headers before forwarding a request to an origin:

```vcl context="sub vcl_miss { ... }"
if (req.backend.is_origin) {
  set req.http.host = "example.com";
}
```

But use `fastly.ff.visits_this_service` to determine whether to modify response headers before delivering a response:

```vcl context="sub vcl_deliver { ... }"
if (fastly.ff.visits_this_service == 0) {
  set resp.http.Cache-Control = "no-store, private";
}
```

Both of these conditionals will ensure that the associated logic only runs once. Here are some more examples of operations typically associated with one or the other phase:

| Do with edge check                                                                                                                                                                           | Do with origin check                                        |
| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------- |
| `fastly.ff.visits_this_service == 0`                                                                                                                                                         | `req.backend.is_origin == true`                             |
| Manipulating the request URL<br />Normalizing the request<br />Authentication<br />Security filtering (e.g., WAF or bot detection)<br />Redirects<br />Geolocation<br />A/B testing<br />ESI | Compressing responses<br />Setting backend-specific headers |

Be aware that changes made to a response at a shield [POP](https://www.fastly.com/documentation/guides/concepts/pop) will be viewed by an edge [POP](https://www.fastly.com/documentation/guides/concepts/pop) as if they are part of the response from the origin. Therefore any changes you want to make to a response just before serving it to the browser should be done only on the edge.

> **HINT:** As well as using the above conditional expressions, you can also write your code in a way that is idempotent, that is, it only has effect once, and if you run it again, nothing happens.
>
> For example, **static bucket storage** origins like [AWS S3](https://aws.amazon.com/s3/) or [GCS](https://cloud.google.com/storage) may [require a path prefix](https://www.fastly.com/documentation/guides/integrations/non-fastly-services/developer-guide-backends/#modifying-the-request-path) to be added to the URL. Doing this unconditionally may result in the prefix being added _twice_, e.g. `/bucket-name/bucket-name/path/to/file`. While you could use a variable such as `fastly.ff.visits_this_service` to avoid this, a better solution is to detect the presence of the prefix:
>
> ```vcl
> if (req.url.path !~ "^/bucket-name/") {
>   set req.url = "/bucket-name/" + req.url;
> }
> ```

### No VCL-defined backends

For VCL services, it is possible to [define backends](https://www.fastly.com/documentation/reference/vcl/declarations/backend/) using VCL code as well as via the web interface, API or CLI. However, you **cannot apply shielding to origins that you define in VCL**.

### Host header hidden problems

Fastly uses the HTTP `Host` header on inbound requests to select the correct service to handle the request. If the `Host` header doesn't match a known customer domain an HTTP `500` (Internal Server Error) response is served to the end user.

If you change the value of `req.http.host` as part of your edge code and it executes at the edge [POP](https://www.fastly.com/documentation/guides/concepts/pop), then be aware that Fastly may not be able to trigger the correct service when the request arrives at the shield [POP](https://www.fastly.com/documentation/guides/concepts/pop). Either manipulate the `Host` header only when the request is known to be going to your own origin (see `req.backend.is_origin`), or use the [`override_host`](https://www.fastly.com/documentation/reference/api/services/backend/#field_override_host) property when creating the backend (and don't modify `req.http.host` in VCL). The latter option is often the most conceptually straightforward and least prone to error.

### Client IP inaccuracy

Requests that have come from another Fastly [POP](https://www.fastly.com/documentation/guides/concepts/pop) will report the IP of the source [POP](https://www.fastly.com/documentation/guides/concepts/pop) as `client.ip` in VCL. To reliably access the true client IP, use the Fastly-provided `Fastly-Client-IP` header.

> **HINT:** The `client.identity` variable is also influenced by the apparent client IP, so if making use of client [directors](https://www.fastly.com/documentation/guides/concepts/load-balancing/#custom-directors), `client.identity` should be reset to `Fastly-Client-IP` or to an identifier specific to your service.
>
> ```vcl
> set client.identity = req.http.Fastly-Client-IP;
> ```

### Cache hit ratio inaccuracy

If a request results in a _MISS_ at an edge POP and is forwarded to a shield POP where it finds a _HIT_, the user is ultimately served from cache, but we will record _both the miss and the hit_ for the purpose of calculating your cache hit ratio. While 'shield hits' will involve more latency for end users than 'edge hits', the hit will still mean there is no need for an origin request. Equally, a request that does reach your origin server will be counted as two misses, one at the edge, and one at the shield.

This will result in a cache hit ratio (CHR) that may be lower than you expect. Since there are multiple ways of calculating CHR on shielded configurations, you may like to use our [historical stats API](https://www.fastly.com/documentation/reference/api/metrics-stats/historical-stats/) to get raw numbers and perform your own calculations.

### Backend assignment in VCL

If you wish to write custom VCL logic for assigning a backend to a request (i.e. `set req.backend = backend_name;`), and that backend is shielded, see [multiple backends](https://www.fastly.com/documentation/guides/concepts/shielding#multiple-backends), to avoid overriding (or being overridden by) the generated shield routing logic.

### Billing implications

Traffic from one Fastly [POP](https://www.fastly.com/documentation/guides/concepts/pop) to another will count towards your request count and billable bandwidth. In the most extreme case, if your service is configured to PASS every request, then your request count and delivery bandwidth will almost double, since most requests will be presented to two Fastly [POPs](https://www.fastly.com/documentation/guides/concepts/pop), but in more realistic scenarios, shielding will often reduce costs overall. [See our guide in documentation for more information](https://www.fastly.com/documentation/guides/getting-started/hosts/shielding/).

## Advanced shielding scenarios

Shielding can be used in many different configurations and variations. Some of the most common include:

### Shielding on Compute

Use the Shielding API in the [Rust](https://docs.rs/fastly/0.11.4/fastly/shielding/index.html), [JavaScript](https://js-compute-reference-docs.edgecompute.app/docs/shielding/Shield/), and [Go](https://pkg.go.dev/github.com/fastly/compute-sdk-go@v1.6.1/shielding) SDKs to extend the benefits of shielding to Compute services. Much like how [Cache APIs](https://docs.fastly.com/products/cache-apis) allow for novel use of cache, shielding on Compute extends the power and use cases of Compute. The Shielding API allows a Compute instance to detect if it is running at the edge or shield, move workloads to the shield, and to run code in either context.

> **NOTE:** Shielding APIs are not supported in Fastly Fiddle or local testing servers.

### Multiple backends

If you have multiple backends (for example because you are performing [load balancing](https://www.fastly.com/documentation/guides/concepts/load-balancing), have origin servers serving different regions, or a microservices architecture), then each backend must have shielding configured independently.

![Multiple backends](/img/multi-origin-precomposed.svg)

Configure each backend with the shield location that is most appropriate for its origin server, by setting the [`shield`](https://www.fastly.com/documentation/reference/api/services/backend/#field_shield) property to your chosen shield identifier. Backends may share the same shield POP or may shield in different locations, unless they have [automatic load balancing](https://www.fastly.com/documentation/guides/concepts/load-balancing#automatic-load-balancing) enabled, in which case all backends must shield in the same location.

With multiple backends your service also requires some configuration to tell Fastly which backend to use. If you do not have custom VCL and use conditions or automatic load balancing to select backends, this happens automatically. However, if you want to use custom VCL to select an origin that is shielded, we recommend combining custom VCL with conditions:

1. Declare a custom local boolean variable per backend at the start of `vcl_recv`
2. Add a [condition](https://www.fastly.com/documentation/guides/full-site-delivery/conditions/using-conditions) to each backend, which selects that backend if the matching variable is true, e.g., `var.backend_a == true`
3. Add custom backend selection logic _before_ the `#FASTLY` placeholder in your VCL code (or using a [VCL snippet](https://www.fastly.com/documentation/guides/full-site-delivery/fastly-vcl/about-fastly-vcl/#vcl-snippets))

For example:

```vcl context="sub vcl_recv { ... }"
declare local var.backend_a BOOL;
declare local var.backend_b BOOL;

if (req.url.path ~ "^/account(?:/.*)?\z") {
  set var.backend_a = true;
} else {
  set var.backend_b = true;
}

#FASTLY RECV
```

This way, Fastly is able to perform the backend selection (the code to do this will be generated and will replace the `#FASTLY RECV` placeholder), and will assign the shield POP or the actual origin server as appropriate, while still ultimately selecting the correct backend for the request based on your own logic.

> **NOTE (Why is this?):** The `vcl_recv` subroutine is where backend selection happens. Some of this code is generated and managed by Fastly within the `#FASTLY RECV` placeholder that is required to be in [your VCL file](https://www.fastly.com/documentation/guides/full-site-delivery/fastly-vcl/about-fastly-vcl/#custom-vcl). The order of execution is:
>
> 1. Custom VCL prior to `#FASTLY RECV`
> 2. VCL snippets
> 3. Generated backend assignments
> 4. Generated shield routing logic
> 5. Custom VCL after `#FASTLY RECV`
>
> Fastly generates backend assignments based on your defined backends and any conditions that are applied to them, and then if the backend that got assigned is a shielded backend, will reassign the request to the shield POP instead of the actual backend (unless the current POP _is_ the shield POP). There is no opportunity to write custom VCL between steps 3 and 4, but if you add a condition on all backends which uses variables defined earlier in custom VCL or VCL snippets, you can set the values of those variables and they will be used by the generated backend assignments.
>
> If you assign directly to `req.backend` in your own code _after_ `#FASTLY RECV`, your assignment will override the shield routing and you'll effectively disable shielding. If you assign to `req.backend` _before_ `#FASTLY RECV` (or in a VCL snippet), your assignment will be overridden by the generated backend assignments.

### Service pinning

If your service is [pinned](https://www.fastly.com/documentation/reference/glossary#term-service-pinning), the end user's [domain](https://www.fastly.com/documentation/reference/glossary#term-domain) may not be explicitly linked to it. This is because your service responds to any request resolving to your [Fastly-assigned dedicated IP space](https://www.fastly.com/documentation/guides/concepts/routing-traffic-to-fastly/#dedicated-ips), as long as a TLS configuration exists. When a request moves from an edge POP to a shield POP, the shield may not know which service to invoke. To resolve this, capture the original HTTP Host header, set it when the request is not on the edge, and ensure it matches a domain explicitly associated with your service before forwarding to the shield.

```vcl context="sub vcl_vcl { ... }"
#capture the incoming hostname from the client
if (fastly.ff.visits_this_service == 0 && req.restarts == 0) {
    set req.http.x-orig-host = req.http.host;
}
#overwrite the anchor hostname at the shield with the original client requested hostname
if (fastly.ff.visits_this_service > 0  && req.http.x-orig-host) {
    set req.http.host = req.http.x-orig-host;
}
```

```vcl context="sub vcl_miss { ... } / sub vcl_pass { ... }"
set bereq.http.host = if (
  req.backend.is_shield,
  "{some-name}.freetls.fastly.net", # A domain explicitly associated with your service, to allow shielding to work
  req.http.x-orig-host           # The hostname to forward to your backend
);
```

### Enable or disable shielding for a single request

If a shielded backend is selected and the current POP is not the designated shield POP, shielding will happen by default if `req.restarts == 0` (i.e., the request has not been `restart`ed). You can change this using a "recv" [VCL snippet](https://www.fastly.com/documentation/guides/full-site-delivery/fastly-vcl/about-fastly-vcl/#vcl-snippets)):

```vcl
set var.fastly_req_do_shield = true;
```

You may want to do this to achieve use cases such as:

- Enable shielding even after a `restart`
- Disable shielding for certain URL paths which cannot be cached

`var.fastly_req_do_shield` is a [custom VCL variable](https://www.fastly.com/documentation/reference/vcl/variables/#user-defined-variables) defined by Fastly's generated VCL. It's defined at the beginning of the `#FASTLY RECV` macro and affects the shielding decisions made at the end of `#FASTLY RECV`, so the only way to use it effectively is in a [VCL snippet](https://www.fastly.com/documentation/guides/full-site-delivery/fastly-vcl/about-fastly-vcl/#vcl-snippets), because snippets are rendered within the `#FASTLY RECV` macro.

## Debugging

Shielding increases the number of potential outcomes for a request presented to a Fastly edge. It's possible that the request will be answered directly from the edge [POP](https://www.fastly.com/documentation/guides/concepts/pop). If the edge [POP](https://www.fastly.com/documentation/guides/concepts/pop) doesn't have the object, the request might still result in a cache HIT, but from the _shield_ [POP](https://www.fastly.com/documentation/guides/concepts/pop). Observing these effects and understanding how they affect your metrics can be a necessary step in debugging services with shielding enabled.

The `X-Served-By`, `X-Cache-Hits` and `X-Cache` response headers, which normally show only one entry without shielding enabled, will include an entry for each Fastly [POP](https://www.fastly.com/documentation/guides/concepts/pop) that has processed the request, but bear in mind that if a request is a HIT at the edge, the entry representing the _shield_ [POP](https://www.fastly.com/documentation/guides/concepts/pop) will be from when the cached object was originally cached. First, start by understanding the possible values of `X-Cache`:

| X‑Cache                     | Meaning                                                                                                                                                                                                                                                          | CHR implications |
| --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- |
| **<code>MISS, MISS</code>** | The object was not in cache at either the edge or the shield. The requested object was fetched from the backend. This will count as _two_ misses as part of the calculation of your headline CHR.                                                                | 2 misses         |
| **`HIT, MISS`**             | The object was not in cache at the edge, so was forwarded to the shield, where it was found in cache. This outcome will contribute one 'miss' to your headline CHR although ultimately the request is satisfied from within the Fastly network.                  | 1 hit, 1 miss    |
| **`MISS, HIT`**             | The object was found in cache at the edge. When the object was (previously) fetched from the shield, it was a MISS at the shield. The 'MISS' here is a record of a prior event, not something that happened in this request.                                     | 1 hit            |
| **`HIT, HIT`**              | The object was found in cache at the edge. When the object was (previously) fetched from the shield, it was a HIT at the shield. The first 'HIT' here is a record of a prior event, not something that happened in this request.                                 | 1 hit            |
| **`HIT`**                   | The object was found in cache, and the [POP](https://www.fastly.com/documentation/guides/concepts/pop) that received the request in this case happens to be the designated shield, so the object was originally loaded directly from the backend.                | 1 hit            |
| **`MISS`**                  | The object was not in cache, and the [POP](https://www.fastly.com/documentation/guides/concepts/pop) that received the request in this case happens to be the designated shield, so the object was fetched directly from the backend and served to the end user. | 1 miss           |

So, where the `X-Cache` header contains two entries and the second one is 'HIT', the first entry in each of the three debugging headers relates to when the object was _originally fetched_ from the shield, not the current status of the object at the shield.

Additionally, the `X-Cache-Hits` header records the value of the `obj.hits` VCL variable, which is local to the _individual cache node_. To optimise and balance load, Fastly may cache objects on multiple machines in a [POP](https://www.fastly.com/documentation/guides/concepts/pop), and particularly hot objects may end up cached on every node in the [POP](https://www.fastly.com/documentation/guides/concepts/pop) (see [clustering](https://www.fastly.com/documentation/guides/full-site-delivery/fastly-vcl/clustering-in-vcl) to learn more). As a result, where the second token of `X-Cache` is 'HIT', the _first_ token of `X-Cache-Hits` will refer to the number of hits recorded on the individual cache server at the shield [POP](https://www.fastly.com/documentation/guides/concepts/pop) at the time that the object was served from the shield to the edge. This can often be confusing.

### Example response data

Imagine a request for an object that is not cached by Fastly, on a service with shielding enabled. The response would contain headers that look like this:

```http
X-Cache: MISS, MISS
X-Served-By: cache-iad2120-IAD, cache-sjc3120-SJC
X-Cache-Hits: 0, 0
```

In this instance, the `X-Cache: MISS, MISS` shows that the request has transited two Fastly [POPs](https://www.fastly.com/documentation/guides/concepts/pop) and was not in the cache in either of them. `X-Served-By` lists the servers acting as the [delivery node](https://www.fastly.com/documentation/guides/full-site-delivery/fastly-vcl/clustering-in-vcl) in each [POP](https://www.fastly.com/documentation/guides/concepts/pop), in the order in which they processed the _response_. In this case, `cache-iad2120-IAD` (Dulles, Virginia) was the shield [POP](https://www.fastly.com/documentation/guides/concepts/pop) (closest to the backend), and therefore saw the response first, and `cache-sjc3120-SJC` (San Jose, California) was the edge [POP](https://www.fastly.com/documentation/guides/concepts/pop) (closest to the end user).

If the same request is made, moments later, by the same user on a still-open connection, it would be expected to be handled by exactly the same edge server:

```http
X-Cache: MISS, HIT
X-Served-By: cache-iad2120-IAD, cache-sjc3120-SJC
X-Cache-Hits: 0, 1
```

This time, the request was a hit at the edge cache-node (cache-sjc3120-SJC). Because it is a hit at the edge it would not be forwarded to a shield. The MISS listed for `cache-iad2120-IAD` reflects the state of that node from the first request, and not its current state. The object is now cached in both POPs. Making a third request on the same connection would result in the same response except that `X-Cache-Hits` would now be `0, 2`.

Requesting the object again on a fresh connection will likely result in the request being handled by a different edge cache server:

```http
X-Cache: MISS, HIT
X-Served-By: cache-iad2120-IAD, cache-sjc3122-SJC
X-Cache-Hits: 0, 1
```

This third request is very similar to the second, but in being handled by a different cache node (`cache-sjc3122-SJC`) at the edge [POP](https://www.fastly.com/documentation/guides/concepts/pop), `X-Cache-Hits` reflects the hit count at the _individual server level_ so still shows only 1 hit on this machine and 0 at the shield POP.

## Choosing a shield location

You should choose a shield POP that is physically close to your origin servers. There are a few other parameters that can be taken into account too:

- Some Fastly POPs have interconnection points with cloud provider networks. Where a POP has a private network interconnect (PNI), requests from that POP to any host that is within that provider's network will typically flow over the interconnect and not via the public internet. If your origin is hosted with one of these providers, choose a shield location where we have an interconnect for optimal performance and potential cost savings.
- Fastly POPs vary dramatically in size and current spare capacity. Choose a POP that offers the largest cache storage for a better cache hit ratio at the shield, and therefore reduced origin traffic.

### Understanding PNI cost savings

Depending on your origin's provider, choosing a shield location with an interconnect could provide significant cost savings.

| Provider                   | Cost savings                                                                                                                    | Availability                          |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------- |
| Amazon Web Services        | None                                                                                                                            | Not applicable                        |
| Backblaze B2 Cloud Storage | [Free egress](https://www.fastly.com/documentation/guides/integrations/non-fastly-services/data-transfer-with-backblaze-b2)     | Any shield location                   |
| Google Cloud Platform      | [Discounted egress](https://www.fastly.com/documentation/guides/integrations/non-fastly-services/discounted-egress-from-google) | All GCP PNIs                          |
| Microsoft Azure            | [Free egress](https://www.fastly.com/documentation/guides/integrations/non-fastly-services/outbound-data-transfer-from-azure)   | AMS, BFI, CHI, DFW, IAD, and PAO only |

### Shield locations

The following POPs are suitable for shielding Fastly services:

## Shield POPs

| Location | POP | Capacity | Shield code | PNIs | Recommended for |
|----------|-----|----------|-------------|------|------------------|
| Amsterdam | AMS | Medium | amsterdam-nl | Amazon Web Services, Microsoft Azure, Google Cloud Platform | Microsoft Azure (west-europe), Google Cloud Platform (europe-west4) |
| Ashburn | IAD | Large | iad-va-us | Amazon Web Services, Microsoft Azure, Google Cloud Platform | Microsoft Azure (east-us), Amazon Web Services (ca-central-1), Amazon Web Services (us-east-1), Google Cloud Platform (northamerica-northeast1), Google Cloud Platform (us-east1), Google Cloud Platform (us-east4) |
| Atlanta | PDK | Large | atlanta-ga-us | Google Cloud Platform |  |
| Auckland | AKL | Small | auckland-akl |  |  |
| Bogota | BOG | Medium | bog-bogota-co |  |  |
| Boston | BOS | Small | bos-ma-us |  |  |
| Brisbane | BNE | Small | brisbane-au |  |  |
| Brussels | BRU | Small | bru-brussels-be | Amazon Web Services, Google Cloud Platform |  |
| Cape Town | CPT | Small | cpt-capetown-za |  | Amazon Web Services (af-south-1) |
| Chennai | MAA | Small | maa-chennai-in |  |  |
| Chicago | CHI | Large | chi-il-us | Amazon Web Services, Microsoft Azure, Google Cloud Platform | Amazon Web Services (us-east-2), Google Cloud Platform (us-central1), Google Cloud Platform (us-east5) |
| Christchurch | CHC | Small | chc-christchurch-nz |  |  |
| Copenhagen | CPH | Small | cph-copenhagen-dk | Amazon Web Services |  |
| Dallas | DFW | Large | dallas-tx-us | Amazon Web Services, Microsoft Azure, Google Cloud Platform | Google Cloud Platform (us-south1) |
| Delhi | DEL | Small | del-delhi-in | Amazon Web Services, Google Cloud Platform | Google Cloud Platform (asia-south2) |
| Denver | DEN | Medium | den-co-us | Google Cloud Platform | Google Cloud Platform (us-west3) |
| Dublin | DUB | Medium | dub-dublin-ie | Amazon Web Services | Amazon Web Services (eu-west-1) |
| Frankfurt | FRA | Large | frankfurt-de | Amazon Web Services, Microsoft Azure, Google Cloud Platform | Amazon Web Services (eu-central-1), Amazon Web Services (eu-central-2), Amazon Web Services (eu-south-1), Google Cloud Platform (europe-central2), Google Cloud Platform (europe-west3), Google Cloud Platform (europe-west6), Google Cloud Platform (me-west1) |
| Fujairah Al Mahta | FJR | Small | fjr-fujairah-uae | Amazon Web Services | Amazon Web Services (me-south-1) |
| Helsinki | HEL | Small | hel-helsinki-fi | Google Cloud Platform | Google Cloud Platform (europe-north1) |
| Hong Kong | HKG | Small | hongkong-hk | Amazon Web Services, Microsoft Azure, Google Cloud Platform | Amazon Web Services (ap-east-1), Google Cloud Platform (asia-east2) |
| Houston | IAH | Large | iah-tx-us | Amazon Web Services |  |
| Hyderabad | HYD | Small | hyd-hyderabad-in | Amazon Web Services, Microsoft Azure |  |
| Johannesburg | JNB | Small | jnb-johannesburg-za |  |  |
| Kolkata | CCU | Small | ccu-kolkata-in | Amazon Web Services |  |
| Lisbon | LIS | Small | lis-lisbon-pt | Amazon Web Services |  |
| London | LCY | Large | london_city-uk | Amazon Web Services, Microsoft Azure, Google Cloud Platform | Amazon Web Services (eu-west-2), Google Cloud Platform (europe-west2) |
| London | LHR | Medium | london-uk | Amazon Web Services, Microsoft Azure, Google Cloud Platform |  |
| London | LON | Medium | lon-london-uk | Amazon Web Services |  |
| Los Angeles | BUR | Medium | bur-ca-us | Microsoft Azure, Google Cloud Platform | Microsoft Azure (west-us), Google Cloud Platform (us-west2), Google Cloud Platform (us-west4) |
| Madrid | MAD | Medium | mad-madrid-es | Amazon Web Services, Google Cloud Platform | Google Cloud Platform (europe-southwest1) |
| Manchester | MAN | Medium | man-manchester-uk | Amazon Web Services |  |
| Marseille | MRS | Medium | mrs-marseille-fr | Amazon Web Services, Google Cloud Platform |  |
| Melbourne | MEL | Medium | melbourne-au | Amazon Web Services, Microsoft Azure | Google Cloud Platform (australia-southeast2) |
| Miami | MIA | Medium | miami-fl-us | Google Cloud Platform |  |
| Milan | MXP | Medium | mxp-milan-it | Amazon Web Services, Google Cloud Platform | Google Cloud Platform (europe-west8) |
| Minneapolis | MSP | Medium | msp-mn-us |  |  |
| Montreal | YUL | Medium | yul-montreal-ca | Microsoft Azure |  |
| Mumbai | BOM | Medium | bom-mumbai-in | Amazon Web Services | Amazon Web Services (ap-south-1), Google Cloud Platform (asia-south1) |
| New York City | LGA | Medium | lga-ny-us | Amazon Web Services, Google Cloud Platform |  |
| Newark | EWR | Medium | ewr-nj-us | Amazon Web Services, Microsoft Azure |  |
| Osaka | ITM | Medium | osaka-jp | Amazon Web Services, Microsoft Azure, Google Cloud Platform | Amazon Web Services (ap-northeast-3) |
| Oslo | OSL | Small | osl-oslo-no | Amazon Web Services |  |
| Paris | PAR | Large | paris-fr | Amazon Web Services, Google Cloud Platform | Amazon Web Services (eu-west-3), Google Cloud Platform (europe-west1), Google Cloud Platform (europe-west9) |
| Perth | PER | Small | perth-au |  |  |
| Portland | PDX | Small | pdx-or-us |  |  |
| Rio de Janeiro | GIG | Medium | gig-riodejaneiro-br | Microsoft Azure, Google Cloud Platform | Google Cloud Platform (southamerica-west1) |
| San Jose | SJC | Medium | sjc-ca-us | Amazon Web Services, Microsoft Azure, Google Cloud Platform | Amazon Web Services (us-west-1) |
| Sao Paulo | GRU | Medium | gru-saopaulo-br | Amazon Web Services, Microsoft Azure, Google Cloud Platform | Amazon Web Services (sa-east-1), Google Cloud Platform (southamerica-east1) |
| Seattle | BFI | Large | bfi-wa-us | Amazon Web Services, Microsoft Azure, Google Cloud Platform | Amazon Web Services (us-west-2), Google Cloud Platform (us-west1) |
| Seoul | ICN | Medium | icn-seoul-kr |  | Amazon Web Services (ap-northeast-2), Google Cloud Platform (asia-northeast3) |
| Singapore | SIN | Large | sin-singapore-sg | Amazon Web Services, Microsoft Azure, Google Cloud Platform | Amazon Web Services (ap-southeast-1), Amazon Web Services (ap-southeast-3), Google Cloud Platform (asia-east1), Google Cloud Platform (asia-southeast1) |
| Sofia | SOF | Small | sof-sofia-bg | Google Cloud Platform |  |
| Stockholm | BMA | Medium | stockholm-bma | Amazon Web Services, Google Cloud Platform | Amazon Web Services (eu-north-1) |
| Sydney | SYD | Medium | sydney-au | Amazon Web Services, Microsoft Azure, Google Cloud Platform | Microsoft Azure (australia-east), Amazon Web Services (ap-southeast-2), Google Cloud Platform (australia-southeast1) |
| Sydney | WSI | Medium | wsi-australia-au | Amazon Web Services, Microsoft Azure, Google Cloud Platform | Amazon Web Services (ap-southeast-2) |
| Tokyo | NRT | Large | nrt-tokyo-jp | Amazon Web Services, Microsoft Azure, Google Cloud Platform | Amazon Web Services (ap-northeast-1) |
| Toronto | YYZ | Medium | yyz-on-ca | Microsoft Azure, Google Cloud Platform | Google Cloud Platform (northamerica-northeast2) |
| Vienna | VIE | Medium | vie-vienna-at | Amazon Web Services |  |

This is not a complete list of Fastly POPs. For a complete list, see the [POPs API](https://www.fastly.com/documentation/reference/api/utils/pops/), run <kbd>fastly pops</kbd> on your terminal, or see our [network map](https://www.fastly.com/network).