---
title: Edge Services - Concepts
description: Understand Scaleway Edge Services terminology with our glossary of the core concepts underpinning this product. Learn about key features, architecture, and best practices.
tags: edge-services edge services pipeline custom-domain cache
dates:
  creation: 2024-07-24
  validation: 2026-06-09
---
import image from './assets/scaleway-edge-services-pipeline.webp'

## Backend

A backend (formerly referred to as [origin](#origin)) is the primary source from which a Scaleway Edge Services pipeline retrieves and caches data. An Edge Services backend can consist of either:

- An [Object Storage bucket](/object-storage/how-to/create-a-bucket/), or
- A [Load Balancer](/load-balancer/how-to/create-load-balancer/) and frontend port that Edge Services connects to in order to request content, and (optionally) a specified [host](#destination-host) associated with the Load Balancer, used in the HTTP request `Host` header.

<Message type="note">
An Edge Services backend is different from a [Load Balancer backend](/load-balancer/reference-content/configuring-backends/), which is a backend server receiving requests forwarded by a [Load Balancer frontend](/load-balancer/reference-content/configuring-frontends/). 
</Message>

You can also use a [Serverless Container](/serverless-containers/concepts/) (or [Serverless Function](/serverless-functions/concepts/)) as an Edge Services backend. This feature is not available in the Scaleway console. See [How to deploy a Serverless Container behind Edge Services](/serverless-containers/how-to/deploy-container-behind-edge-services/) for instructions using the CLI or Terraform.

## Cache

The storage location where Edge Services stores copies of content that it has retrieved from a given backend. When users request content from the Edge Services endpoint, it serves content directly from the cache wherever possible, in accordance with the caching rules defined by the user. This reduces load on the bucket or Load Balancer/backend servers.

Note that if an object has a caching directive, the caching directive always takes precedence over any lifetime setting defined in Edge Services.

## Certificate

The SSL/TLS certificate for your subdomain to enable Edge Services to serve content over HTTPS, if you have customized your [Edge Services endpoint](#endpoint). You can choose between uploading your own certificate held in Scaleway Secret Manager, or letting Edge Services generate a fully-managed Let's Encrypt certificate.

## CNAME record

The CNAME record pointing your subdomain to the Edge Services endpoint, if you have customized your [Edge Services endpoint](#endpoint). This is necessary to ensure that traffic for your customized subdomain is correctly directed towards the Edge Services endpoint by DNS servers.

Refer to [CNAME records for Edge Services](/edge-services/reference-content/cname-record/) for more information.

## Destination host

In the case of a Load Balancer as an Edge Services backend, the specific host for which Edge Services requests and caches data. This is an optional setting: when specified, this host (e.g. `mydomain.com`) is used in the HTTP `Host` header when Edge Services requests data from the Load Balancer. If no destination host is specified, the `Host` from the incoming request is used.

The destination host must be associated with the Load Balancer (or its backend servers). You can set only one host per pipeline. If your Load Balancer is in front of multiple hosts, you can create a separate Edge Services pipeline for each. Each host therefore gets its own Edge Services endpoint and cache.

## Edge Services

Edge Services is an additional feature for Scaleway Load Balancers and Object Storage buckets. It provides:
- A [caching service](/edge-services/how-to/configure-cache/) to improve performance by reducing load on your [backend](#backend)
- A [Web Application Firewall](/edge-services/how-to/configure-waf/) to protect your backend from threats and malicious activity
- A customizable and secure [endpoint](#endpoint) for accessing content via Edge Services, which can be set to a subdomain of your choice.

Read the [Edge Services Quickstart](/edge-services/quickstart/) to get started.

## Endpoint

The endpoint from which a given Edge Services pipeline can be accessed, e.g. `https://pipeline-id.svc.edge.scw.cloud`. When a client requests content from the Edge Services endpoint, it is served by Edge Services and its cache, rather than from the backend (Object Storage bucket or Load Balancer) directly. Edge Services automatically manages redirection from HTTP to HTTPS.

You can customize the endpoint with a user-defined subdomain, replacing the standardized endpoint with the subdomain of a domain you already own — e.g., `http://my-own-domain.com`. Using customized endpoints requires an associated [certificate](#certificate), and [CNAME record](#cname-record).

## Exclusions

In the context of an Edge Services [Web Application Firewall](#waf), exclusions let you define filters for requests that should not be evaluated by WAF, but rather pass straight to the backend. Learn more about [creating exclusions](/edge-services/how-to/configure-waf/#how-to-set-exclusions).

## Origin

Previously, the term origin was used to describe a Load Balancer or Object Storage bucket that was the target of an Edge Services pipeline. Moving forward, for enhanced clarity, we will use the term [backend](#backend) rather than origin.

## Paranoia level

In the context of an Edge Services [Web Application Firewall](#waf), the paranoia level determines how sensitive the request-evaluation mechanism is to potential threats. Four paranoia levels are available, with level 1 being the least sensitive, and level 4 being the most sensitive. The higher the paranoia level, the more likely it is that a given request will be judged to be malicious. For full details on paranoia levels, see our [detailed documentation](/edge-services/reference-content/understanding-waf/#waf-ruleset-and-paranoia-levels).

## Pipeline

<Lightbox image={image} alt="A diagram shows the elements and workflow of an Edge Services pipeline. The user connects to the customizable Edge Services endpoint (with its SSL/TLS certificate), which fetches content from the Edge Services cache, which itself fetches content to cache from a backend which is either an Object Storage bucket or Load Balancer. A Web Application Firewall sits between the cache and backend, protecting the backend from threats." />

An Edge Services pipeline consists of a [backend](#backend), which Edge Services can protect from threats with a [Web Application Firewall](#waf), and for which it also requests and [caches](#cache) content. Each pipeline also has an [endpoint](#endpoint) from which content is accessed and served via Edge Services. The pipeline's endpoint can be customized with a user-defined [subdomain](/domains-and-dns/concepts/#subdomain) and associated [certificate](#certificate) so that Edge Services can serve content over HTTPS.

You can create an Edge Services pipeline for each of your Object Storage buckets or Load Balancers. You can enable and disable caching, WAF, and other optional parts of the pipeline at any time. Customizing the endpoint is also optional.

## Protocol

The protocol (HTTP or HTTPS) that the Edge Services pipeline should use when sending requests to a backend. HTTPS is recommended, but you should choose the protocol that corresponds to your Load Balancer setup.

## WAF

An Edge Services Web Application Firewall (WAF) evaluates requests to your backend to determine whether they are potentially malicious. You can set the [paranoia level](#paranoia-level) to be used when evaluating requests. Requests identified as malicious are then blocked or logged depending on your settings. Find out more about [configuring a WAF](/edge-services/how-to/configure-waf/).