Bouclier d'origine Fastly (Origin Shielding) : configuration, vérification et déploiement sûrs

Publié le

14 juil. 2026

Mis à jour le

15 juil. 2026

Temps de lecture

22 min de lecture

Sans shielding, chaque POP Fastly peut récupérer indépendamment un objet absent de son cache local. Avec le bouclier d'origine Fastly, un miss de périphérie local va d'abord vers un POP de shield désigné. Si le shield possède l'objet, il répond au POP de périphérie sans requête à l'origine ; seul un miss de shield atteint l'origine. Cela crée une deuxième couche de cache partagé et concentre le trafic à destination de l'origine via un POP.

Prenons Acme Shop, un commerçant dont l'origine catalogue réside dans une seule région cloud européenne. L'objectif concret de ce guide : mettre un bouclier d'origine Fastly devant son backend catalogue public, prouver qu'un edge miss peut devenir un shield hit sans jamais toucher l'origine, et conserver une version non shieldée prête pour la restauration.

Cette topologie est utile pour le contenu pouvant être mis en cache et demandé mondialement, ainsi que pour contrôler la pression de connexion sur l'origine. Ce n'est pas un contrôle d'accès, cela n'empêche pas le trafic direct vers l'origine et ce n'est pas une amélioration universelle de la latence. Un edge hit reste le chemin le plus court. Un miss local qui se déplace vers un shield ajoute un saut interne, et un shield mal situé peut dégrader le chemin de miss. Mesurez le résultat pour vos routes et régions d'utilisateurs plutôt que de traiter la fonctionnalité comme une valeur par défaut.

Le bouclier d'origine Fastly est un réglage par backend, pas un interrupteur global — c'est précisément ce qui le rend facile à mal configurer à l'échelle : une origine reçoit un shield bien placé, la suivante reste sur un réglage par défaut, et personne ne le remarque avant qu'une revue d'incident ne demande pourquoi la charge d'origine a doublé après un basculement de trafic. Dans un edge géré multi-fournisseurs, c'est exactement le type de détail opérationnel qu'Optimi suit de façon délibérée plutôt que de le laisser à une tâche de configuration ponctuelle : l'affectation de shield de chaque backend, les preuves de vérification des cache miss et la tendance de charge d'origine méritent une surveillance continue, pas seulement au moment du déploiement.

Prérequis et périmètre

Avant de modifier le service, disposez d'un service Fastly actif avec une version connue comme fiable, d'un inventaire documenté des backends, de l'autorisation de cloner et d'activer des versions, de l'accès aux logs d'origine et Fastly, et d'un domaine de test représentatif. Identifiez pour chaque backend sa région physique ou cloud, son nom DNS, le nom de certificat TLS, l'en-tête Host attendu, la politique de cache, le chemin de contrôle de santé et la limite de capacité.

Choisissez un périmètre initial d'un backend pouvant être mis en cache, à forte lecture, et d'un petit ensemble de chemins. Excluez les pages authentifiées, les écritures, les flux de paiement ou d'inventaire et le trafic PASS volontairement non mis en cache de la première expérience. Ces requêtes peuvent toujours transiter par un shield lorsqu'elles sont transmises à un backend, mais ne bénéficient pas du même cache partagé et peuvent accroître le trafic interne.

Enregistrez une référence sur au moins un cycle de trafic normal : taux de requêtes et de sortie d'origine, nombre de connexions d'origine et latence p95, distribution de l'état du cache Fastly, erreurs de périphérie et d'origine, latence client p95/p99 par région et bande passante de diffusion. Définissez un seuil de restauration avant de modifier la configuration.

Scénario Acme Shop

L'origine catalogue d'Acme Shop se trouve dans une seule région cloud européenne. Commencez uniquement avec son backend public GET /products/demo-mug.webp : un visiteur dans une autre région peut être servi par le cache de périphérie local, un edge miss peut interroger le shield proche de l'origine, et seul un miss de shield atteint l'origine d'Acme Shop. Les sessions, le paiement et les API privées restent hors périmètre.

1. Sélectionner un POP de shield d'origine près de chaque origine

Utilisez l'API Fastly POP ou le panneau de contrôle Fastly pour obtenir les identifiants de shield valides. Le nom humain du POP et l'identifiant de shield ne sont pas nécessairement les mêmes. Par exemple, la documentation de shielding Fastly distingue le nom du POP Amsterdam (AMS) de son identifiant de shield amsterdam-nl.

Sélectionnez le POP de shield d'origine principalement selon la proximité et la qualité réseau du backend, non selon la localisation moyenne des visiteurs. Un shield proche de l'origine peut réduire le coûteux segment vers l'origine et rendre un cache partagé plus efficace. Testez ensuite le chemin complet depuis les régions utilisateur importantes. Une audience mondialement distribuée avec une origine unique bénéficie souvent d'un shield près de cette origine ; les origines géographiquement séparées doivent normalement avoir des shields choisis indépendamment.

Deux éléments supplémentaires doivent entrer dans la décision, au-delà de la géographie brute :

• Interconnexion réseau privée (PNI). Lorsqu'un POP de shield dispose d'une interconnexion privée avec le fournisseur cloud qui héberge l'origine, le trafic entre eux peut rester hors de l'internet public. Fastly documente la disponibilité des PNI par POP ; si l'origine d'Acme Shop se trouve chez un fournisseur disposant d'une PNI vers un shield proche, préférez ce shield à un POP tout aussi proche mais sans PNI. Les origines AWS n'en bénéficient pas encore comme peuvent le faire Azure et GCP : tenez donc compte du fournisseur réel, pas seulement de la distance.
• Palier de capacité du POP de shield. Fastly classe ses POP par capacité de cache (de small à large). Un shield qui gère un catalogue à fort trafic et largement réutilisé bénéficie d'un POP à plus forte capacité ; un backend à périmètre restreint dispose de plus de latitude. Vérifiez la liste actuelle des POP avant d'engager un backend à fort volume sur un shield de petite capacité.

Utilisez cette table de décision avant de choisir un emplacement :

La documentation Fastly recommande de sélectionner un centre de données proche du backend et note que chaque backend peut posséder son propre shield. Ne sélectionnez pas un shield sur la seule base d'une carte. Testez la résolution DNS, le handshake TLS, le premier octet et le débit d'origine soutenu via le chemin visé. Notez aussi que le shielding ne peut être affecté qu'à des backends gérés via l'interface web, l'API ou le CLI : un backend déclaré entièrement en VCL personnalisé ne peut pas porter de propriété shield. Si Acme Shop déplace plus tard un backend vers une définition purement VCL, le shielding devra être reconsidéré spécifiquement pour ce backend.

2. Cloner la version active et affecter le shield

Effectuez ce changement dans une nouvelle version de service. Dans le panneau de contrôle Fastly, sélectionnez le service, choisissez Edit configuration et clonez la version active. Ouvrez Origins, choisissez le backend et sélectionnez l'emplacement de shield dans le menu Shielding. Enregistrez le changement de backend. Répétez pour chaque backend dans le périmètre, en utilisant l'emplacement choisi pour ce backend plutôt que de copier aveuglément un emplacement.

Pour une configuration gérée par API ou CLI, définissez la propriété shield de l'objet backend sur l'identifiant de shield. Mettez à jour le backend existant dans la version candidate explicitement enregistrée et modifiable. N'utilisez pas latest, active ni --autoclone dans une commande de changement de production, car cela rend la version cible implicite.

fastly service backend update \
  --service-id="$FASTLY_SERVICE_ID" \
  --version="$FASTLY_CANDIDATE_VERSION" \
  --name="app_origin" \
  --shield="amsterdam-nl"

Ne définissez FASTLY_CANDIDATE_VERSION qu'après avoir cloné et enregistré la nouvelle version brouillon. Cette mise à jour ne change que la propriété shield ; elle préserve l'adresse du backend, TLS, le délai d'attente, le contrôle de santé, le host override et les paramètres de connexion déjà revus dans le clone. N'utilisez fastly service backend create que pour ajouter intentionnellement un nouveau backend, en précisant la même version candidate explicite ainsi que tous les paramètres requis du backend.

Si vous modifiez l'en-tête de requête Host avant qu'il atteigne le shield, ajoutez le nom d'hôte modifié à la liste des domaines du service. Fastly utilise l'hôte entrant pour identifier le service au shield ; un hôte modifié inconnu peut produire un 500. Préférez le paramètre backend override_host pour le saut final vers l'origine plutôt que de modifier Host tôt dans une logique personnalisée.

Validez la version clonée et examinez le diff. Confirmez que le backend sélectionné possède toujours l'adresse attendue, la validation de certificat TLS, SNI, le contrôle de santé, le budget de délai d'attente, les conditions, endpoints de journalisation et la politique de cache. Gardez la version active intacte et immédiatement activable pour la restauration.

3. Comprendre le chemin de cache miss du bouclier d'origine Fastly

Le bouclier d'origine Fastly ne change pas la façon dont un edge hit est servi ; il modifie seulement ce qui se passe après un edge miss. Pour un objet avec une clé de cache partagée correcte, les chemins de requête sont :

1. Edge HIT : le POP de périphérie renvoie son objet en cache. Le shielding et l'origine ne sont pas impliqués.
2. Edge MISS, shield HIT : le POP de périphérie transmet au shield. Le shield renvoie son objet en cache, qui peut alimenter le POP de périphérie. L'origine ne reçoit aucune requête.
3. Edge MISS, shield MISS : le POP de périphérie transmet au shield, et le shield récupère depuis l'origine. La réponse peut être mise en cache aux deux niveaux selon la politique de cache.
4. Requête backend PASS ou non cacheable : la requête utilise toujours le chemin de shield lorsqu'elle est transmise au backend, mais ne bénéficie pas d'un cache hit réutilisable. Évaluez ce trafic séparément.

C'est pourquoi le shielding peut réduire la charge d'origine sans augmenter chaque edge cache hit des visiteurs. Cela explique aussi pourquoi le taux global de cache hit Fastly peut sembler plus faible que prévu : un edge miss et shield hit comptent à la fois comme un miss et un hit, tandis qu'une récupération d'origine via le shield peut enregistrer deux misses. Utilisez les métriques brutes de requête, hit, miss, shield et origine plutôt qu'un seul ratio agrégé comme unique critère de réussite.

Concrètement, avec les chiffres d'Acme Shop : sans shielding, chaque POP de périphérie qui expire indépendamment sa copie de demo-mug.webp dans la même fenêtre de TTL ouvre sa propre récupération d'origine — une douzaine de cache misses régionaux simultanés peut produire une douzaine de récupérations d'origine. Une fois le shield affecté, seul le premier de ces misses à atteindre le shield déclenche une récupération d'origine ; les autres deviennent des shield hits et n'atteignent jamais l'origine d'Acme Shop. C'est l'effet concret à rechercher dans la comparaison référence/déploiement, pas seulement un pourcentage de miss plus faible.

Même les requêtes PASS et autres requêtes non cacheables ne sont pas totalement épargnées : elles traversent tout de même le saut de shield, et comme les POP Fastly maintiennent des pools de connexions ouvertes entre eux, ce saut inter-POP présente en général une latence d'établissement plus faible qu'une connexion neuve établie directement de la périphérie vers l'origine. N'y voyez pas une raison de router volontairement du trafic non cacheable via un shield — c'est un effet secondaire, pas un objectif de conception.

Assurez-vous que la clé de cache ne mélange pas les utilisateurs, droits, variantes de langue ou en-têtes sensibles à la sécurité. N'utilisez pas le shield pour masquer une politique Vary non sûre. Si vous modifiez les directives de cache, préférez un Surrogate-Control explicite pour la fraîcheur côté Fastly et Cache-Control pour la fraîcheur côté navigateur lorsque ces exigences diffèrent.

4. Vérification des cache miss sur un domaine hors production

Activez d'abord la configuration clonée sur un service de développement ou de staging, ou utilisez un domaine et une origine isolés représentatifs. Réchauffez un ensemble d'objets publics connus par des requêtes répétées, puis émettez des requêtes depuis plus d'une région externe. Gardez les objets de test séparés du contenu spécifique aux clients et utilisez un TTL court et documenté afin que le test soit facile à invalider.

Utilisez curl -I ou votre exécuteur de tests HTTP pour capturer les en-têtes et conserver la sortie avec l'horodatage, la région de test, l'URL, l'état de réponse, Age, les en-têtes liés au cache, l'ID de requête et la version de déploiement. X-Cache et X-Served-By sont les en-têtes standards de Fastly pour l'état du cache : X-Cache rapporte une séquence HIT/MISS séparée par des virgules, par exemple MISS, HIT pour un chemin edge-miss/shield-hit, et X-Served-By nomme les nœuds de cache interrogés. Pour une vérification plus fine des cache miss, envoyer Fastly-Debug: 1 sur une requête (à ne jamais exposer aux utilisateurs réels) fait apparaître Fastly-Debug-TTL et Fastly-Debug-Path, qui rapportent l'état hit/miss par nœud, le TTL restant et la grâce. Traitez la présentation exacte des en-têtes comme dépendante de la configuration, pas comme un contrat applicatif stable, mais appuyez-vous sur ces en-têtes nommés plutôt que d'inférer l'état du cache indirectement.

À l'origine, journalisez un ID de corrélation sûr avec le modèle de chemin, l'état, la latence, la source de requête et l'identité d'amont sélectionnée. Exécutez cette séquence :

1. Demandez un objet public froid depuis la région A et confirmez une récupération d'origine attendue.
2. Demandez le même objet depuis la région B après que la région A a rempli le shield ; confirmez la réponse attendue et recherchez un service de cache shield plutôt qu'une autre récupération d'origine.
3. Répétez après l'expiration du TTL et pendant une purge contrôlée pour observer le comportement de regroupement des misses et la capacité d'origine.
4. Testez une route non cacheable et une route privée pour garantir qu'aucune ne devient du contenu de cache partagé.
5. Rendez temporairement l'origine de staging lente ou non saine et confirmez le délai configuré, le comportement d'erreur visible par l'utilisateur, l'alerte et la décision de restauration.
6. Si une logique VCL ou Compute personnalisée modifie la réponse, demandez le même objet une fois via le chemin qui remplit le shield puis une fois déjà chaud à la périphérie, et comparez les corps de réponse. Une réponse modifiée pendant le passage d'exécution au shield est mise en cache et resservie à chaque POP de périphérie qui la touche ensuite ; un écart ici est un signal d'empoisonnement de cache, pas un simple bug d'affichage isolé.

Les tests Compute locaux peuvent simuler des sites de shielding via la table [local_server.shielding_sites] de fastly.toml — en associant un identifiant de shield à "Local" ou à une URL de shield distante — mais le serveur local ne possède pas de cache en lecture-écriture traversant (readthrough), et ne peut donc pas prouver le routage global Fastly, la topologie réelle de cache ni la latence inter-POP. Utilisez-les pour les tests de logique ; utilisez un service isolé en direct pour la vérification du chemin et des cache miss.

5. Observer les en-têtes, logs et la charge d'origine

Ajoutez un tableau de bord qui compare la référence et la période de déploiement par route, backend et région utilisateur :

• edge hits, edge misses, shield hits, shield misses et taux de requêtes d'origine
• réponses Fastly et d'origine 4xx/5xx, délais d'attente des backends et état des contrôles de santé
• latence client et backend p50/p95/p99, séparée par hit et miss lorsque possible
• connexions d'origine, CPU, files d'attente, sortie et événements de limite de débit d'amont
• utilisation Fastly des requêtes et de la bande passante, y compris les implications de trafic inter-POP

Corrélez les logs Fastly et d'origine avec un ID de requête ou de trace. Capturez le résultat de cache, le POP ou la région lorsque permis, le nom du backend, la version, la durée d'origine et une raison d'échec sûre. Ne journalisez pas les cookies, en-têtes d'autorisation, chaînes de requête signées ni corps de réponse privés.

Vérifiez le comportement attendu par des preuves, pas seulement par une moyenne de tableau de bord. Un essai réussi montre moins de requêtes d'origine dupliquées pour le même objet cacheable, une saturation d'origine stable ou améliorée, aucune fuite de cache inattendue et une latence acceptable dans les régions utilisateur. Un shield hit évite une récupération d'origine mais peut néanmoins être plus lent qu'un edge hit local ; comparez chaque chemin séparément.

Utilisez uniquement des accès de diagnostic autorisés. Lisez X-Cache avec X-Served-By, Age, les données de debug Fastly lorsqu'elles sont autorisées, et le compteur de requêtes d'origine d'Acme Shop : aucun en-tête isolé ne prouve le chemin à lui seul. À titre d'illustration, un edge HIT local affiche typiquement :

Age: 42
X-Cache: HIT
Origin requests for /products/demo-mug.webp: 0

tandis qu'un edge MISS suivi d'un shield HIT affiche :

Age: 42
X-Cache: MISS, HIT
X-Served-By: cache-shield, cache-edge
Origin requests for /products/demo-mug.webp: 0

• Résultat positif : après un réchauffement depuis la région A, une requête depuis la région B a le corps attendu et démontre un chemin edge-miss/shield-hit sans nouvelle requête d'origine.
• Résultat négatif attendu : une route privée conserve son comportement privé/pass et n'acquiert pas de réponse de cache partagé.
• Échec : toute erreur visible par l'utilisateur, tout écart de corps de réponse, toute récupération d'origine inattendue pour l'objet réchauffé, ou toute latence de chemin de miss au-delà du seuil convenu arrête le déploiement et impose la version antérieure non shieldée.

6. Déployer progressivement

Activez d'abord le shielding pour un backend ou groupe de routes. Observez-le pendant une période de pointe complète, un cycle d'expiration de cache et un déploiement d'origine courant si possible. N'étendez que lorsque la réduction de charge d'origine et les résultats de latence utilisateur respectent les seuils convenus. Si un système de gestion de configuration prend en charge les environnements, promouvez la version revue à travers eux ; n'effectuez pas de modifications manuelles de production inexpliquées entre les étapes.

Restauration

La restauration n'est simple que si elle est préparée :

1. Conservez dans l'enregistrement de changement le numéro de version active actuel et la version antérieure connue comme fiable.
2. Si les erreurs, la latence, la sécurité du cache ou le comportement d'origine dépassent une condition d'arrêt, activez la version antérieure sans affectation de shield.
3. Vérifiez l'état de version active, les requêtes synthétiques, le trafic d'origine et les logs liés au cache après propagation.
4. Conservez la version défaillante, les logs, les échantillons de requête dont les valeurs sensibles ont été retirées et les métriques pour l'analyse de cause racine.

N'essayez pas de résoudre aveuglément un incident d'origine en activant le shielding. Si l'origine est surchargée, le shielding peut réduire les cache misses dupliqués, mais il ne peut pas satisfaire une charge de travail non cacheable ni restaurer une dépendance non saine. Appliquez d'abord la politique de surcharge, de basculement et de contenu obsolète du service là où elles sont sûres.

Dépannage

Réserves de redondance, sécurité et configuration

Le shielding présente des compromis opérationnels importants :

• Accessibilité du shield : si un POP de shield configuré est inaccessible pour une requête, Fastly peut envoyer cette requête directement du POP de périphérie à l'origine. Les contrôles d'origine et la capacité doivent tolérer ce chemin de contournement. Dans du VCL ou du code Compute personnalisé, privilégiez toujours l'échec ouvert vers l'origine plutôt que de lever une erreur quand la sélection de shield échoue : un shield manquant ou en mauvaise santé doit se dégrader vers une récupération d'origine directe, pas vers un 500.

• Sécurité de l'origine : le shielding n'est ni une liste d'autorisation ni un pare-feu. Maintenez l'accès direct à l'origine restreint par réseau privé ou contrôles de sources Fastly, ainsi qu'une authentification périphérie-vers-origine. Testez le chemin direct vers l'origine indépendamment.

• Origines multiples et équilibrage de charge : configurez et évaluez le shielding par backend. L'équilibrage de charge automatique de Fastly exige que tous les backends d'un même director d'équilibrage partagent un seul emplacement de shield ; il ne prend pas en charge des shields différents par backend au sein d'un même groupe équilibré. Si Acme Shop a besoin de shields différents par backend dans une logique personnalisée, utilisez une sélection de backend conditionnelle ou la fonction VCL fastly.try_select_shield(shield, fallback), qui ne sélectionne un director de shield que s'il est sain et n'a pas déjà été visité pour cette requête, et revient sinon au backend fourni :

  sub vcl_miss {
    set req.backend = fastly.try_select_shield(ssl_shield_amsterdam_nl, req.backend);
  }
  

  Affecter req.backend directement, sans passer par cette fonction ni par les conditions générées, désactive silencieusement le shielding pour cette route — c'est une cause fréquente d'un backend qui paraît configuré avec un shield mais qui n'affiche jamais de hits au niveau shield.

• Gestion de Host : Fastly identifie le service à l'aide de l'hôte sur la requête interne. Conservez un hôte reconnu par le service jusqu'au dernier saut d'origine ou utilisez override_host sur le backend.

• VCL et Compute personnalisés : le VCL s'exécute une fois à la périphérie et une nouvelle fois au shield lorsque le shielding est actif ; utilisez req.backend.is_shield (vrai uniquement au shield) et req.backend.is_origin (vrai uniquement sur le saut final vers l'origine) pour brancher la logique correctement — ces propriétés supposent qu'un backend soit déjà affecté, donc vérifiez-les dans vcl_miss/vcl_pass, pas dans vcl_recv. Le shielding Compute est explicite dans le SDK : shield.runningOn() indique si l'exécution a lieu au shield, et shield.encryptedBackend() fournit le tunnel chiffré vers celui-ci. Sur les deux plateformes, cantonnez toute mutation orientée origine derrière la vérification côté origine et les changements orientés client derrière la vérification côté périphérie — une mutation appliquée pendant le passage au shield se retrouve mise en cache et rejouée vers chaque POP de périphérie qui touche ensuite l'objet, ce qui est un risque d'empoisonnement de cache, pas seulement un bug de logique. Les backends définis entièrement en VCL personnalisé ne peuvent porter aucune propriété shield, et Fastly Fiddle ne prend pas en charge les API de shielding : prototypez donc cette logique sur un vrai service.

• Adresse client : au shield, le client immédiat est un autre POP Fastly, si bien que client.ip reflète le POP de périphérie, pas le visiteur. Lisez Fastly-Client-IP pour la véritable adresse IP client, et en VCL réinitialisez client.identity à partir de celle-ci (set client.identity = req.http.Fastly-Client-IP;) si une logique fondée sur l'identité, comme l'équilibrage sticky, dépend du visiteur réel. N'utilisez cela qu'après avoir défini la frontière de confiance du proxy.

• Coût et capacité : le trafic inter-POP contribue aux requêtes et à la bande passante — le saut périphérie-vers-shield et le saut shield-vers-origine sont chacun facturés. Un backend avec une forte part de trafic PASS peut ajouter près d'un saut complet de trafic facturé sans aucun bénéfice de cache. Mesurez le trafic Fastly ajouté face aux économies de sortie et de capacité d'origine, et traitez une route à fort taux de PASS comme un signal à corriger plutôt que comme un shield à laisser indéfiniment actif.

Liste de contrôle opérationnelle

Avant l'activation en production, confirmez que chaque backend possède un identifiant de shield justifié ; que les domaines et le host override fonctionnent sur le saut interne ; que TLS et les contrôles de santé sont intacts ; que les clés de cache isolent le contenu privé ; que l'origine peut tolérer le contournement du shield ; que les en-têtes et logs prouvent le chemin de cache miss attendu ; que les tableaux de bord séparent les résultats de périphérie, shield et origine ; et qu'une version connue comme fiable sans shielding est prête à être activée.

Références Fastly principales

• Guide de configuration du shielding
• Concepts, effets et scénarios avancés du shielding
• Référence API backend
• Référence API des versions de service Fastly
• Référence du serveur local fastly.toml
• Tester et déboguer sur la plateforme Compute
• Fonction VCL fastly.try_select_shield()
• Vérifier le cache
• Guide développeur : backends