Edge Services

Pourquoi

Signalements a deux sortes de trafic. Le premier est celui de l'API : créer un signalement, consulter ceux de son quartier. Le second est apparu avec la page publique de chaque métropole, qui affiche des statistiques (nombre de signalements par type, délai moyen de traitement) et une carte. Cette page est consultée par des milliers d'habitants le lendemain d'une intempérie, et chaque consultation recalcule les mêmes statistiques dans la base. Le même jour, les journaux du répartiteur montrent des milliers de requêtes qui essaient des injections SQL dans les paramètres de recherche.

Deux besoins, donc : ne plus recalculer mille fois une réponse identique, et filtrer les requêtes manifestement hostiles avant qu'elles n'atteignent l'application. Le premier relève d'un cache placé devant l'application, le second d'un pare-feu applicatif. Scaleway regroupe les deux dans Edge Services, un service que l'on place devant un répartiteur de charge ou un bucket. Cette leçon le met en place pour Signalements, et insiste sur ce qu'il ne fait pas, parce que c'est là que se trouvent les mauvaises surprises.

Les concepts

Ce qu'est Edge Services

La documentation de Scaleway présente Edge Services comme une solution pour exposer des services HTTP sur Internet, qui apporte trois choses :

• un cache, qui sert directement le contenu déjà récupéré sans solliciter le backend ;
• un pare-feu applicatif web (WAF, Web Application Firewall) ;
• un point d'accès HTTPS, à une adresse fournie par Scaleway (<pipeline>.svc.edge.scw.cloud) ou à un sous-domaine qui vous appartient.

Au 5 octobre 2026, le service est en disponibilité générale depuis le 1er novembre 2024 pour les buckets et les répartiteurs de charge. Les conteneurs et fonctions serverless sont acceptés comme backend, mais seulement par l'API, la CLI ou Terraform, pas par la console. Le routage vers plusieurs backends dans un même pipeline est, d'après sa page dédiée, en bêta publique et disponible uniquement par l'API.

On rapproche souvent Edge Services d'un CDN (content delivery network), parce qu'il fait du cache HTTP devant une origine. La documentation consultée ne décrit pas de réseau de points de présence répartis dans le monde : ne comptez pas sur lui pour rapprocher le contenu d'utilisateurs lointains comme le ferait un CDN mondial. Pour Signalements, dont les utilisateurs sont en France, ce n'est pas le sujet : ce qui compte est de soulager l'application.

Le pipeline et ses étapes

Un pipeline est une chaîne d'étapes (stages) que traverse chaque requête. L'API et la CLI les exposent une par une :

    flowchart LR
  C["Client"] --> D["DNS stage<br/>noms servis"]
  D --> T["TLS stage<br/>certificat"]
  T --> K["Cache stage<br/>réponse en cache ?"]
  K -- "non" --> W["WAF stage<br/>requête hostile ?"]
  W --> B["Backend stage<br/>répartiteur ou bucket"]
  K -- "oui" --> C
  

• L'étape DNS porte les noms servis par le pipeline : le nom par défaut fourni par Scaleway, et vos sous-domaines.
• L'étape TLS porte le certificat de ces noms.
• L'étape cache répond si elle a une copie fraîche.
• L'étape WAF évalue les requêtes qui n'ont pas été servies par le cache.
• L'étape backend désigne l'origine : un bucket, ou un répartiteur de charge et l'un de ses frontends.

La conséquence de cet ordre est écrite dans la documentation : le WAF ne protège que le backend, pas le cache. Une requête servie par le cache n'est pas évaluée par le pare-feu, ce qui est logique (elle ne touche pas l'application) et réduit le nombre de requêtes facturées au titre du WAF.

Ce qu'un cache HTTP a le droit de garder

Un cache partagé, comme celui d'Edge Services, sert la même réponse à des personnes différentes. La question centrale n'est donc pas technique, elle est fonctionnelle : cette réponse est-elle la même pour tout le monde ?

La norme HTTP sur les caches, la RFC 9111, donne à l'application les moyens de le dire, par l'en-tête de réponse Cache-Control :

S'y ajoutent les validateurs de la RFC 9110 : un ETag (une empreinte de la version de la ressource) ou une date Last-Modified. Quand une copie n'est plus fraîche, le cache peut demander à l'origine « a-t-elle changé depuis ? » (If-None-Match), et l'origine répond 304 Not Modified sans renvoyer le corps. Enfin, l'en-tête Vary dit de quelles en-têtes de requête dépend la réponse (la langue, par exemple) : le cache garde alors une copie par valeur.

Pour Edge Services, la documentation fixe deux règles :

• une directive de cache de la réponse l'emporte toujours sur la durée de vie réglée dans Edge Services, qui ne s'applique qu'aux réponses sans directive (d'où son nom dans l'API, fallback_ttl) ;
• par sécurité, les réponses aux requêtes qui portent des cookies ne sont pas mises en cache par défaut, quels que soient leurs en-têtes ; un réglage de l'étape de cache (include_cookies) change ce comportement, avec un avertissement explicite sur le risque d'exposer un contenu authentifié.

Le pare-feu applicatif

Le WAF d'Edge Services applique l'OWASP Core Rule Set (CRS), un jeu de règles libre qui détecte les familles d'attaques courantes (injection SQL, cross-site scripting, traversée de répertoires...). Scaleway met les règles à jour lui-même. Deux réglages :

• le mode : journaliser seulement (log_only) ou bloquer (enable) ;
• le niveau de paranoïa, de 1 à 4 : plus il est élevé, plus le jeu de règles est sensible, et plus il produit de faux positifs (des requêtes légitimes classées comme hostiles). La documentation de Scaleway recommande le niveau 1 pour tout serveur exposé, le niveau 2 quand de vraies données d'utilisateurs sont en jeu.

Les exclusions (100 au plus par pipeline) laissent passer sans évaluation les requêtes qui correspondent à un chemin (expression régulière) ou à une méthode HTTP. Elles s'appliquent au WAF entier, pas règle par règle. Et le WAF n'analyse que les 16 384 premiers octets du corps des requêtes : une charge placée plus loin n'est pas vue.

La facturation

Edge Services se paie par abonnement mensuel au niveau du projet, avec trois formules (Starter, Professional, Advanced) qui incluent un nombre de pipelines, un volume de données servies depuis le cache, et un nombre de requêtes filtrées par le WAF. Ce qui dépasse est facturé en plus, au prorata. La formule Starter n'inclut pas le WAF, qui s'y ajoute par une option payante. Le transfert du backend vers le cache, ou du backend directement vers l'utilisateur, ne compte pas dans le volume. Les prix sont sur la page tarifs de Scaleway ; la page de facturation de la documentation donne des exemples chiffrés, en précisant qu'ils peuvent changer.

En pratique

Pour Signalements, le plan est le suivant :

• un pipeline devant le répartiteur lb-signalements, servi sous signalements.example.com (domaine de documentation de la RFC 2606, à remplacer par le vôtre) ;
• le cache pour les pages et statistiques publiques, rien d'autre ;
• le WAF, d'abord en journalisation, puis en blocage.

Les commandes ont été vérifiées avec l'aide de la CLI 2.62 ; on peut tout faire aussi depuis la console, qui crée les étapes pour vous.

Préparer l'application : dire ce qui se met en cache

Le travail commence dans le code, pas dans la console. Pour chaque route, une décision :

En Flask, un décorateur suffit :

from functools import wraps

from flask import make_response


def cache_partage(secondes_partage: int, secondes_navigateur: int = 0):
    """Marque une réponse comme identique pour tous, mise en cache par Edge Services."""
    def decorateur(vue):
        @wraps(vue)
        def enveloppe(*args, **kwargs):
            reponse = make_response(vue(*args, **kwargs))
            reponse.headers["Cache-Control"] = (
                f"public, s-maxage={secondes_partage}, max-age={secondes_navigateur}"
            )
            return reponse
        return enveloppe
    return decorateur

• s-maxage règle la durée dans le cache d'Edge Services, max-age celle du navigateur. Une durée courte côté navigateur garde la possibilité de corriger vite : une purge vide le cache d'Edge Services, pas celui des navigateurs.
• /sante en no-store : une vérification de santé servie par un cache dirait « tout va bien » pendant cinq minutes après une panne.

Et surtout : aucune route qui dépend de l'utilisateur ne doit être marquée public. Une réponse « mes signalements » mise en cache serait servie à la personne suivante.

Choisir la formule et créer le pipeline

$ scw edge-services plan list
$ scw edge-services plan select plan-name=professional
$ PIPE=$(scw edge-services pipeline create name=signalements-public \
    description="Signalements : cache et WAF devant lb-signalements" -o json | jq -r .id)

Les étapes se créent de la dernière à la première, puisque chacune désigne la suivante. D'abord le backend, le répartiteur et son frontend HTTPS :

$ LB_ID=$(scw lb lb list name=lb-signalements zone=fr-par-1 -o json | jq -r '.[0].id')
$ FE_ID=$(scw lb frontend list lb-id="$LB_ID" name=https zone=fr-par-1 -o json | jq -r '.[0].id')
$ BACK=$(scw edge-services backend-stage create pipeline-id="$PIPE" \
    scaleway-lb.lbs.0.id="$LB_ID" scaleway-lb.lbs.0.zone=fr-par-1 \
    scaleway-lb.lbs.0.frontend-id="$FE_ID" scaleway-lb.lbs.0.is-ssl=true \
    scaleway-lb.lbs.0.domain-name=signalements.example.com -o json | jq -r .id)

• is-ssl=true : Edge Services parle HTTPS au répartiteur, dont le frontend 443 a déjà un certificat (leçon 6 du cours Le cloud : les fondamentaux).
• domain-name : le nom envoyé dans l'en-tête Host vers le répartiteur, ce que la documentation appelle l'hôte de destination. Sans lui, c'est le Host de la requête entrante qui est transmis.

Puis le WAF, en journalisation seulement, au niveau 2 :

$ WAF=$(scw edge-services waf-stage create pipeline-id="$PIPE" \
    mode=log_only paranoia-level=2 backend-stage-id="$BACK" -o json | jq -r .id)

Puis le cache, branché sur le WAF, avec une durée de repli nulle : seules les réponses qui portent une directive explicite seront gardées.

$ CACHE=$(scw edge-services cache-stage create pipeline-id="$PIPE" \
    waf-stage-id="$WAF" fallback-ttl=0s -o json | jq -r .id)

fallback-ttl=0s est un choix de prudence : une route oubliée, sans Cache-Control, n'est pas mise en cache. On ne met en cache que ce que l'application a déclaré cacheable. La documentation précise qu'une valeur nulle signifie que les objets ne sont pas mis en cache, sauf directive.

Le domaine et le certificat

$ TLS=$(scw edge-services tls-stage create pipeline-id="$PIPE" \
    cache-stage-id="$CACHE" managed-certificate=true -o json | jq -r .id)
$ scw edge-services dns-stage create pipeline-id="$PIPE" tls-stage-id="$TLS" \
    fqdns.0=signalements.example.com -o json | jq '{default_fqdn, fqdns}'

managed-certificate=true demande un certificat Let's Encrypt géré et renouvelé par Scaleway ; l'alternative est un certificat rangé dans Secret Manager. La documentation impose un sous-domaine (pas l'apex du domaine), parce que l'aiguillage se fait par un enregistrement CNAME vers le nom par défaut du pipeline (default_fqdn dans la réponse) :

signalements.example.com.  300  IN  CNAME  <pipeline>.svc.edge.scw.cloud.

Si la zone est chez Scaleway, l'enregistrement est créé pour vous, et la documentation demande de ne pas le modifier. Sinon, créez-le chez votre hébergeur DNS. Il remplace les enregistrements A et AAAA vers le répartiteur créés à la leçon 10 : abaissez leur TTL la veille, comme pour toute bascule. L'enregistrement CAA de la leçon 10 autorise Let's Encrypt, ce qui convient au certificat géré.

Vérifier le cache

$ curl -s -o /dev/null -D - -X GET https://signalements.example.com/metropoles/12/statistiques | grep -i -E 'x-cache|cache-control|age'

La documentation recommande curl -X GET -I plutôt que curl -I : ce dernier envoie une requête HEAD, qui ne déclenche pas toujours la même logique de cache. L'en-tête X-Cache vaut miss à la première requête, puis hit-fresh aux suivantes, tant que la copie est fraîche. Faites le même essai sur /signalements avec le cookie de session d'un agent : la réponse doit rester miss, et son Cache-Control doit être private, no-store.

Purger après une publication

Une correction des statistiques est publiée ; la copie en cache a encore quatre minutes à vivre. On purge :

$ scw edge-services purge-request create pipeline-id="$PIPE" \
    assets.0=/metropoles/12/statistiques
$ scw edge-services purge-request create pipeline-id="$PIPE" all=true

La documentation de la console limite la purge par objet à cinq chemins à la fois, sans purge par répertoire. La seconde commande vide tout le cache du pipeline : à éviter en pleine charge, puisque toutes les requêtes suivantes retombent sur l'application le temps que le cache se remplisse.

Passer le WAF en blocage

Laissez le WAF en journalisation plusieurs jours, sur du trafic réel. Examinez les requêtes qu'il aurait bloquées (dans Cockpit, leçon 14) : de vraies attaques, ou des requêtes légitimes ? Les faux positifs typiques d'une application comme Signalements sont les champs de texte libre (une description qui contient ' OR ou des chevrons) et les téléversements. Quand la liste est comprise, ajoutez les exclusions strictement nécessaires, puis passez en blocage :

$ scw edge-services waf-stage update "$WAF" mode=enable

La même commande change le niveau de paranoïa (paranoia-level) ; les exclusions se gèrent dans la console ou par l'API. Un faux positif en mode blocage, c'est un habitant dont le signalement est refusé sans explication : le passage en blocage est une décision à prendre avec l'équipe produit, et à surveiller dans les jours qui suivent.

Le bucket des photos : non

On pourrait être tenté de mettre aussi le bucket des photos derrière Edge Services. La documentation l'interdit de fait pour Signalements : le bucket peut rester privé, mais chaque objet servi par Edge Services doit être public (sauf en mode site web statique). Les photos des signalements peuvent montrer des personnes ou des plaques d'immatriculation ; elles restent privées, servies par URL présignées (leçon 5 du cours précédent). Edge Services convient en revanche à des fichiers vraiment publics : les feuilles de style et scripts de la page publique, les fonds de carte, un jeu de données ouvert.

Sous le capot

Ce que voit le répartiteur. Avec Edge Services devant lui, le répartiteur ne voit plus les adresses des habitants, mais celles des serveurs d'Edge Services. L'adresse réelle du client voyage dans un en-tête (X-Forwarded-For), ajouté à chaque intermédiaire. La leçon 12 explique comment l'application doit le lire sans faire confiance à n'importe qui.

Ce que coûte un « miss ». Une requête qui n'est pas servie par le cache traverse deux connexions de plus : client vers Edge Services, Edge Services vers le répartiteur. Elle est donc légèrement plus lente qu'une requête directe. Le gain vient du taux de succès (hit ratio) : si les statistiques sont demandées mille fois pour un calcul, 999 requêtes ne touchent ni le répartiteur, ni l'application, ni la base.

La clé du cache. Un cache range ses copies selon une clé, au minimum la méthode, l'hôte et le chemin avec ses paramètres. /statistiques?periode=7j et /statistiques?periode=30j sont deux entrées distinctes, et /statistiques?periode=7j&_=1696500000 (un paramètre anti-cache ajouté par certains scripts) en est une troisième, jamais réutilisée. Gardez des URL canoniques pour ce que vous voulez voir mis en cache.

Pourquoi les cookies désactivent le cache. Un cookie signale souvent une session, donc une réponse personnalisée. Ne pas mettre en cache les réponses aux requêtes avec cookie protège d'une erreur d'en-tête côté application. Le prix : un site qui envoie un cookie de mesure d'audience sur toutes ses pages ne profite plus du cache. Le remède documenté est de servir les ressources statiques depuis un sous-domaine sans cookie.

Pièges courants

Une page personnelle mise en cache. Une route qui dépend de l'utilisateur marquée public par erreur (ou avec include_cookies activé) sert les données d'une personne à la suivante. C'est l'incident le plus grave que peut provoquer un cache. Défense : fallback-ttl=0s, private, no-store par défaut sur toute route authentifiée, et un test automatique qui vérifie l'en-tête des routes sensibles.

Le répartiteur toujours joignable en direct. La documentation indique qu'un répartiteur privé ne peut pas servir de backend : il doit garder une adresse publique. Un attaquant qui la connaît (elle est restée dans les anciens enregistrements DNS, dans des journaux, dans des annuaires de certificats) peut contourner Edge Services, donc son WAF. La parade est une ACL sur le frontend du répartiteur : l'API des répartiteurs propose une condition ips_edge_services (argument match.ips-edge-services de scw lb acl create), décrite comme restreignant les connexions à celles qui viennent d'Edge Services. La leçon 12 la met en place. Tant qu'elle n'est pas en place, considérez le WAF comme une couche que l'on peut contourner.

Tester avec curl -I. Une requête HEAD peut contourner la logique de cache et donner une conclusion fausse. curl -X GET -I.

Purger un répertoire. La purge par chemin ne vide que l'objet exact. Pour invalider une famille de pages, versionnez leurs URL (/carte?v=42) ou réduisez leur durée de vie.

Le WAF en blocage dès le premier jour. Les faux positifs touchent les utilisateurs réels, sur les champs de texte libre en premier. Toujours commencer en journalisation.

Oublier la limite de 16 Ko. Le WAF n'examine que les 16 384 premiers octets du corps. Il ne remplace pas la validation des entrées par l'application.

Sécurité

• Un WAF est une défense en profondeur, pas une correction : une injection SQL bloquée par le CRS reste une faille dans le code. L'application utilise des requêtes paramétrées, échappe ses sorties, valide ses entrées ; le WAF retient le bruit et donne du temps quand une faille est découverte.
• Le cache est une surface d'attaque : empoisonnement (faire mettre en cache une réponse manipulée, par exemple grâce à un en-tête non pris en compte dans la clé), fuite de données personnelles par un Cache-Control erroné. Les réponses ne doivent dépendre que de ce qui est dans la clé du cache, ou le déclarer par Vary.
• Le WAF journalise des requêtes, donc parfois des données personnelles saisies par les habitants. Les journaux suivent la politique de conservation de Cockpit et du projet.
• Le certificat géré est renouvelé par Scaleway ; un certificat importé dans Secret Manager est à votre charge, expiration comprise.
• Les droits : modifier un pipeline, c'est pouvoir rediriger le trafic d'un domaine ou désactiver le WAF. Réservez les jeux de permissions d'Edge Services à l'équipe qui exploite le domaine.

En production

• Mesurez le taux de succès du cache et les volumes servis (Cockpit). Un taux bas signale des en-têtes manquants, des cookies, ou des URL non canoniques.
• Surveillez le volume inclus dans la formule : un pic (une page publique relayée par la presse locale) peut dépasser le volume de cache inclus et produire des frais supplémentaires, ce qui reste en général bien moins cher que d'absorber le pic sur les instances.
• Revoyez les exclusions du WAF à chaque évolution de l'application : une exclusion large (/api/.*) ajoutée pour un faux positif retire toute protection à toute l'API.
• Edge Services n'est pas une protection contre les attaques par déni de service volumétriques dans la documentation consultée : elle n'en parle pas. Si c'est un risque pour vous, posez la question au support et lisez les engagements de l'offre.
• Chez Lyneko, les applications sur Kapsule passent par l'ingress Traefik ; la documentation d'Edge Services consacre une section aux répartiteurs créés par Kubernetes, qui demandent un réglage particulier : à lire avant de placer Edge Services devant un cluster.

Exercices

1. Cacheable ou pas (niveau 200). Pour chacune des réponses suivantes, donnez l'en-tête Cache-Control adapté, et dites si Edge Services la gardera. (a) GET /signalements/4812 pour un agent connecté. (b) GET /metropoles/12/carte.png, régénérée chaque nuit. (c) GET /sante. (d) Le fichier app.3f9a2c.js de la page publique, dont le nom contient l'empreinte de son contenu.

2. Le WAF contourné (niveau 200). Un audit montre que des requêtes d'injection SQL atteignent l'application alors que le WAF est en mode blocage au niveau 2. Donnez trois explications possibles et, pour chacune, comment la vérifier.

3. La bascule DNS (niveau 200). Décrivez, dans l'ordre, la mise en service d'Edge Services devant Signalements sans coupure, en partant des enregistrements A et AAAA de la leçon 10.

Récapitulatif

• Edge Services place devant un répartiteur ou un bucket un cache, un WAF fondé sur l'OWASP CRS et un point d'accès HTTPS, éventuellement sur votre sous-domaine avec un certificat géré.
• Un pipeline enchaîne les étapes DNS, TLS, cache, WAF, backend ; le WAF ne voit que ce que le cache n'a pas servi.
• Ce qui se met en cache se décide dans l'application, avec Cache-Control (public, s-maxage, private, no-store) ; une directive l'emporte sur la durée de repli d'Edge Services, et les requêtes avec cookie ne sont pas mises en cache par défaut.
• On vérifie avec curl -X GET -I et l'en-tête X-Cache, on purge objet par objet ou en entier.
• Le WAF se déploie en journalisation, puis en blocage, avec des exclusions étroites ; il n'examine que les 16 premiers kilo-octets du corps.
• Limites : objets de bucket publics seulement, répartiteur public, à fermer par une ACL qui n'accepte qu'Edge Services, pas de réseau mondial décrit, facturation par abonnement avec dépassements.

Pour aller plus loin

• La RFC 9111, sections 3 (stockage) et 5.2 (directives Cache-Control).
• La documentation de l'OWASP Core Rule Set sur les niveaux de paranoïa et l'ajustement des faux positifs.
• La page Scaleway sur le routage et les backends multiples, pour servir l'API et des fichiers statiques depuis un même pipeline.
• Le cours HTTP et les API web, pour les requêtes conditionnelles et la sémantique des méthodes.
• La leçon 12, qui renforce le répartiteur situé derrière Edge Services.