Edge Services - Concepts

Reviewed on 14 October 2024

Cache

The storage location where Edge Services stores copies of content that it has retrieved from a given origin. 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 origin 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. 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. This is necessary to ensure that traffic for your customized subdomain is correctly directed towards the Edge Services endpoint by DNS servers.

Edge Services

Edge Services is an additional feature for Scaleway Load Balancers and Object Storage buckets. It provides a caching service to improve performance by reducing load on your origin, and a customizable and secure endpoint for accessing content via Edge Services, which can be set to a subdomain of your choice.

Endpoint

The endpoint from which a given Edge Services pipeline can be accessed, e.g. https://pipeline-id-or-bucket-name.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 origin (Object Storage bucket or Load Balancer backend servers) directly. Edge Services automatically manages redirection from HTTP to HTTPS.

The endpoint can be customized with a user-defined subdomain, allowing you to replace the standardized endpoint with the subdomain of a domain you already own, e.g. http://my-own-domain.com. An associated certificate, and CNAME record will be required, in this case.

Origin

The primary source from which a Scaleway Edge Services pipeline retrieves and caches data. An origin can consist of either:

An Object Storage bucket, or
A Load Balancer and frontend port that Edge Services connects to to request content, and (optionally) a specified host associated with the Load Balancer, used in the HTTP request Host Header.

Origin host

In the case of a Load Balancer origin, 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 origin host is specified, the Load Balancer’s IP address is used in the Host Header.

The origin host must be associated with the origin Load Balancer / its backend servers, and only one host may be set per pipeline. If your Load Balancer is in front of multiple hosts, you can create a separate Edge Services pipeline for each. Each host will therefore get its own Edge Services endpoint and cache.

Origin Load Balancer

The Load Balancer defined by the user as origin for a given Edge Services pipeline. The pipeline connects to this Load Balancer, on the specified frontend port to request content.

Pipeline

An Edge Services pipeline consists of an origin for which Edge Services requests and caches content, and an endpoint from which this content is served via Edge Services. The pipeline’s endpoint can be customized with a user-defined subdomain and associated 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 Balancer origins. Note that the cache can be enabled and disabled at will, so it is an optional part of the pipeline, as is the customization of the endpoint.

Protocol

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