Edge Services - Concepts
CacheLink to this anchor
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.
CertificateLink to this anchor
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 recordLink to this anchor
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 ServicesLink to this anchor
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
- A Web Application Firewall to protect your origin from threats and malicious activity
- A customizable and secure endpoint for accessing content via Edge Services, which can be set to a subdomain of your choice.
EndpointLink to this anchor
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 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.
ExclusionsLink to this anchor
In the context of an Edge Services Web Application Firewall, exclusions let you define filters for requests that should not be evaluated by WAF, but rather pass straight to the Load Balancer origin. Learn more about creating exclusions
OriginLink to this anchor
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 hostLink to this anchor
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 BalancerLink to this anchor
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.
Paranoia levelLink to this anchor
In the context of an Edge Services Web Application Firewall, 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.
PipelineLink to this anchor
An Edge Services pipeline consists of an origin, which Edge Services can protect from threats with a Web Application Firefall, and for which it also requests and caches content. Each pipeline also has an endpoint from which content is accessed 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. Edge Services can also protect
You can create an Edge Services pipeline for each of your Object Storage buckets or Load Balancer origins. Note that caching and WAF can be enabled and disabled at will, so are optional parts of the pipeline, as is the customization of the endpoint. WAF is only available for Load Balancer origins, not Object Storage buckets.
ProtocolLink to this anchor
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.
WAFLink to this anchor
An Edge Services Web Application Firewall (WAF) evaluates requests to your origin to determine whether they are potentially malicious. You can set the paranoia level to be used when evaluating requests. Requests that are judged to be malicious are then blocked or logged, depending on the settings you choose. Find out more about configuring a WAF.