Une zone pleine, un plan de contrôle mondial à terre : les leçons des pannes CloudFront et europe-west4-a de juillet 2026

Juillet 2026 a offert aux équipes plateforme deux incidents dont la valeur pédagogique dépasse largement leur durée. Non pas parce qu’ils étaient les plus longs ou les plus coûteux de ces dix-huit mois — la série 2025 (DynamoDB en octobre, Azure fin octobre, Cloudflare en novembre) reste la référence en la matière — mais parce qu’ils illustrent deux angles morts que la plupart des architectures « multi-AZ » ne couvrent pas : la globalité du plan de contrôle et l’hétérogénéité des garanties de résilience entre services managés d’un même fournisseur.

Deux incidents, une même famille de causes

16 juillet, CloudFront. Pendant 3 h 33, tous les clients utilisant la fonctionnalité VPC Origins ont reçu des erreurs 5xx, indépendamment de leur région, de leur distribution ou de leur trafic. La cause déclenchante est d’une banalité déconcertante : une limite de capacité atteinte dans une seule zone de disponibilité à Francfort. Cette contrainte locale a mis à terre un composant du plan de contrôle CloudFront à portée mondiale. Parmi les victimes visibles : Canvas et Blackboard (en pleine période d’examens et d’inscriptions pour une partie du monde universitaire), Hugging Face, et la loterie nationale britannique.

Une semaine plus tôt, europe-west4-a. Une défaillance de refroidissement dans une unique zone de la région Pays-Bas de Google Cloud a provoqué une coupure classique. Ce qui l’était moins : quinze heures après le début de l’incident, Google Cloud VMware Engine, NetApp Volumes et Bare Metal Solutions restaient indisponibles. Là où les VM Compute Engine et les charges Kubernetes régionalement distribuées se rétablissaient ou basculaient, ces trois services — qui reposent sur du matériel dédié, non fongible, provisionné physiquement dans la zone — n’avaient aucun chemin de reprise automatique.

Deux mécanismes différents, un même enseignement : le périmètre d’une panne n’est pas déterminé par le périmètre de sa cause. Dans un cas, une cause zonale produit un effet global. Dans l’autre, une cause zonale produit un effet zonal… mais dont la durée est dictée par une logistique physique, pas par un basculement logiciel.

Sur le plan de la communication, les deux épisodes rappellent une règle de base : le niveau de détail publié varie fortement d’un fournisseur et d’un incident à l’autre. Avant de construire une conclusion architecturale, il faut vérifier ce qui a effectivement été écrit dans le postmortem ou le Health Dashboard, et distinguer ce que le fournisseur affirme de ce que vos propres traces ont mesuré.

Le plan de contrôle tombe globalement, même quand la cause est locale

La distinction plan de données / plan de contrôle est enseignée depuis longtemps, mais elle est encore mal internalisée dans les revues d’architecture. Rappel opérationnel :

• Plan de données : ce qui sert le trafic. Servir un objet en cache, router un paquet, lire une ligne dans une base répliquée.
• Plan de contrôle : ce qui décide de la configuration. Créer une distribution, résoudre un mapping origine, propager une politique, attacher un ENI, autoriser un appel.

Le multi-AZ, et même le multi-région, protège essentiellement le plan de données. Or les fonctionnalités récentes des fournisseurs sont souvent implémentées avec un plan de contrôle centralisé et mondial — c’est plus simple, plus cohérent, et cela suffit… jusqu’au jour où une contrainte de capacité dans un unique datacenter le fait basculer. VPC Origins est exactement ce cas : la résolution de l’accès privé à votre VPC depuis le réseau edge n’est pas une opération purement locale au point de présence.

La conséquence pratique est brutale : aucune de vos décisions de placement ne vous protège d’une panne de plan de contrôle mondial d’un service que vous avez placé sur le chemin critique. La seule protection est de disposer d’un chemin qui n’emprunte pas ce plan de contrôle.

Cartographier son rayon d’explosion, service par service

L’exercice le plus rentable après ces incidents ne coûte rien : produire un inventaire honnête de votre stack, avec pour chaque dépendance sa portée réelle (zonale, régionale, globale) et son mode de reprise (automatique, manuel, physique).

Une trame minimale :

Le point à retendu cas néerlandais : « service managé » ne signifie pas « résilience équivalente ». Un service adossé à du matériel dédié provisionné dans une zone hérite du profil de risque d’un datacenter, pas d’un service cloud-native. Si votre VMware Engine héberge un contrôleur de domaine, un ERP ou une base historique, votre RTO réel est celui d’une remise en route physique.

Cet inventaire peut être partiellement automatisé. Côté GCP, pour repérer les ressources déclarées dans une zone unique :

gcloud asset search-all-resources \
  --scope="projects/mon-projet" \
  --query="location:europe-west4-a" \
  --format="table(assetType, name, location)"

Côté AWS, l’identification des sous-réseaux et ressources mono-AZ :

aws ec2 describe-subnets \
  --query 'Subnets[].{AZ:AvailabilityZone,Subnet:SubnetId,Tags:Tags[?Key==`Name`].Value|[0]}' \
  --output table

aws cloudfront get-distribution-config --id E1EXAMPLE \
  | jq '.DistributionConfig.Origins.Items[] | {Id, DomainName, VpcOriginConfig}'

Le livrable n’est pas le tableau : c’est la liste des dépendances pour lesquelles vous n’avez aucune action possible pendant l’incident. Cette liste doit être courte, connue de la direction, et documentée comme un risque accepté.

Le piège des fonctionnalités récentes

VPC Origins est une bonne fonctionnalité : elle supprime l’exposition publique de l’origine, simplifie les groupes de sécurité et évite la gymnastique des listes de préfixes. Elle est aussi, en juillet 2026, relativement jeune — et les fonctionnalités jeunes concentrent statistiquement les surprises de plan de contrôle.

Cela ne veut pas dire « ne pas adopter ». Cela veut dire : n’adopter une nouveauté sur un chemin critique qu’avec un chemin de repli déjà provisionné et déjà testé. Concrètement, pour ce cas précis :

1. Conserver l’origine publique de secours (ALB restreint par la liste de préfixes CloudFront + validation d’un header secret), désactivée mais opérationnelle.
2. Déclarer un origin group avec critères de bascule.
3. Garder un TTL DNS suffisamment court sur l’enregistrement client pour pouvoir sortir de CloudFront entièrement.

Extrait de configuration d’un groupe d’origines :

{
  "OriginGroups": {
    "Quantity": 1,
    "Items": [{
      "Id": "og-primaire-secours",
      "FailoverCriteria": { "StatusCodes": { "Quantity": 4, "Items": [500, 502, 503, 504] } },
      "Members": {
        "Quantity": 2,
        "Items": [
          { "OriginId": "vpc-origin-alb-prive" },
          { "OriginId": "alb-public-restreint" }
        ]
      }
    }]
  }
}

Avertissement d’honnêteté technique : un origin group ne couvre que les erreurs remontées comme erreurs d’origine, sur les méthodes idempotentes, et ne sauve pas un incident dont l’origine est le service edge lui-même. C’est précisément pourquoi le point 3 — la sortie DNS — reste indispensable.

Concevoir des dégradations utiles

Une architecture mature ne répond pas « disponible / indisponible » mais dispose d’un continuum. Quatre briques donnent le meilleur rapport effort/valeur :

• Mode statique : une version pré-générée du parcours critique (page d’accueil, catalogue, statut de commande en lecture seule) hébergée sur un bucket derrière un chemin totalement distinct. Elle doit être régénérée par un job périodique, sinon elle sera périmée le jour où vous en aurez besoin.
• Cache de secours : servir du contenu périmé plutôt qu’une erreur. Sur un reverse proxy en amont ou en aval, c’est deux directives :

location / {
    proxy_pass http://backend;
    proxy_cache zone_app;
    proxy_cache_valid 200 5m;
    proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
    proxy_cache_background_update on;
    add_header X-Cache-Status $upstream_cache_status always;
}

• Disjoncteurs avec dégradation explicite : quand un appel sortant échoue au-delà d’un seuil, retourner une réponse partielle documentée plutôt que propager le 5xx. Le point difficile n’est pas le disjoncteur, c’est de décider à l’avance ce que le produit affiche dans ce mode.
• Budget d’erreur : 3 h 33 d’indisponibilité totale consomment déjà plus que le budget annuel d’un SLO à 99,95 %. Ce chiffre est l’argument qui débloque les arbitrages budgétaires en revue d’architecture — utilisez-le.

Ce qui reste opérable quand le plan de contrôle du fournisseur est figé

Hypothèse de travail à adopter par défaut : pendant l’incident, vous ne pourrez rien créer, rien modifier, rien déployer. Console en lecture seule, API en throttling, pipelines en échec.

Ce qui reste généralement praticable :

• Les changements côté données : feature flags stockés dans une base ou un fichier de configuration déjà chargé par les instances, valeurs de configuration lues à chaud, entrées DNS chez un registrar tiers.
• Ce qui est déjà provisionné : une capacité de secours démarrée, même à échelle réduite, vaut infiniment mieux qu’un plan de scaling qui suppose un plan de contrôle fonctionnel.
• Les leviers hors du fournisseur touché : un DNS géré ailleurs, un CDN secondaire déjà configuré en warm standby.

À l’inverse, tout runbook qui commence par « déployer un correctif », « créer une nouvelle distribution » ou « appliquer un Terraform » est inutilisable dans ce contexte. C’est le test le plus rapide pour évaluer la qualité d’un runbook : combien de ses étapes exigent un plan de contrôle disponible ?

Trois game days qui valent l’investissement

1. « La console est en lecture seule » : durée 90 minutes, l’équipe doit maintenir le service et communiquer sans aucune création ou modification de ressource. Interdiction d’utiliser le CI/CD. Résultat attendu : une liste de runbooks à réécrire.
2. Bascule d’origine : basculer réellement du chemin privé vers le chemin public de secours en production, hors incident, sur une fenêtre annoncée. Mesurer le temps de propagation, les erreurs générées, les surprises de headers, de certificats et de WAF.
3. Validation DNS et TTL : inventorier les TTL de tous les enregistrements du chemin critique, vérifier qui détient les accès au registrar (souvent une personne, souvent en vacances en juillet), et chronométrer une bascule complète. Un TTL à 3 600 s découvert le jour J transforme un incident de 20 minutes en incident de 90.

Lire un postmortem fournisseur en ingénieur

Un postmortem public est un document de communication autant qu’un document technique. Les questions à poser à votre account team :

• Quel est le périmètre réel du composant défaillant : zonal, régional, global ? Est-ce documenté quelque part de contractuel ?
• Cette fonctionnalité a-t-elle un plan de contrôle partagé entre régions ? Si oui, laquelle est prépondérante ?
• Quelles limites de capacité peuvent produire un effet client, et sont-elles observables par nous ?
• Le SLA couvre-t-il cette fonctionnalité spécifiquement, ou seulement le service parent ? Quel est le crédit, et surtout : le crédit est-il proportionné à votre perte ? (Il ne l’est jamais — c’est le point à faire acter.)
• Quels changements d’architecture le fournisseur a-t-il engagés, avec quelle échéance ?

Confrontez systématiquement le récit publié à vos propres séries temporelles. Un écart entre l’heure de début annoncée et l’heure de vos premiers 5xx est une information utile pour vos futures détections.

Grille de décision : jusqu’où aller

• Multi-AZ : le défaut non négociable. Coût faible, protège des incidents physiques localisés — mais pas d’europe-west4-a si votre charge est sur du matériel dédié zonal.
• Multi-région, actif-passif tiède : justifié dès que l’indisponibilité de quelques heures a un coût métier supérieur au surcoût d’infrastructure. Condition impérative : la bascule est testée périodiquement, et la réplication de données a un RPO mesuré, pas supposé.
• Multi-région actif-actif : réservé aux charges dont le modèle de données tolère la latence et les conflits d’écriture. La complexité opérationnelle est elle-même une source de pannes.
• Multi-cloud : rarement justifié pour l’ensemble de la stack, souvent justifié pour trois composants précis — DNS, statut/page de secours, et observabilité. Un monitoring hébergé chez le fournisseur en panne ne sert à rien.
• Risque accepté : parfaitement légitime, à condition d’être écrit, chiffré en durée d’indisponibilité probable, signé par un décideur métier, et revu chaque année. « On n’y avait pas pensé » n’est pas un risque accepté.

Les rapports de fiabilité du premier semestre 2026 recensent plus de 30 000 incidents sur 1 082 fournisseurs : à cette échelle, la question n’est plus de savoir si vos dépendances tomberont, mais lesquelles tomberont ensemble et ce que vous aurez encore le droit de faire à ce moment-là. Les deux pannes de juillet montrent que la réponse ne se trouve pas dans le choix d’un fournisseur, mais dans une propriété de votre propre système : la capacité à changer de comportement sans changer d’infrastructure. Un chemin de repli pré-provisionné, un TTL court, un mode statique régénéré chaque nuit et un flag lisible depuis la base coûtent quelques jours-homme. Ils constituent la seule partie de votre disponibilité qui reste sous votre contrôle quand celui du fournisseur ne l’est plus.