Guides

CloudFront 5xx : Ce que les équipes d’origines VPC doivent vérifier

Les origines VPC de CloudFront ont renvoyé des erreurs 5xx pendant des heures le 16 juillet.

Par Alec Chizhik 20 juillet 2026 6 min de lecture

CloudFront 5xx : Ce que les équipes d’origines VPC doivent vérifier

Le 16 juillet 2026, les distributions CloudFront avec des origines VPC ont diffusé des erreurs 5xx pendant des heures. Une limite interne au sein de la flotte dédiée aux origines privées a bloqué la configuration de routage en périphérie – souvent alors que leur propre ALB semblait encore sain. Quiconque place des origines privées derrière CloudFront a besoin d’un basculement, avant que la prochaine défaillance du plan de contrôle ne verrouille la porte mondiale.

Les points clés en bref

Fenêtre 07:45–11:18 UTC. Seules les origines VPC touchées ; les origines publiques classiques et les origines S3 ont continué de fonctionner. AWS a cité une limite interne de gestion des connexions comme déclencheur.
Solution de contournement : changer le type d’origine. Sans distribution de staging préparée et IaC testé, l’avis sur le tableau de bord de statut reste sans effet.
Risque en cascade. Canvas, Blackboard, Hugging Face et les fournisseurs d’identité ont été impactés – même si votre propre application était « verte », la connexion et le CDN en amont pouvaient afficher des erreurs 5xx.

En lien :AWS Sovereign Cloud : ce qui est vraiment séparé / Les 200 millisecondes qui chassent les utilisateurs du SaaS

Ce qui a réellement dysfonctionné le 16 juillet

Les origines VPC relient CloudFront à des Application Load Balancers, Network Load Balancers ou des instances EC2 dans des sous-réseaux privés. La périphérie est le seul point d’entrée public ; l’origine n’a pas besoin d’IP publique. C’est précisément ce lien privé qui dépend d’une flotte interne AWS, chargée de distribuer la configuration de routage aux processeurs réseau.

Lorsque cette flotte a atteint une limite interne, le système n’a plus pu charger correctement les données de routage mises à jour. Conséquence : une augmentation des erreurs 5xx pour les clients utilisant des connexions à des origines VPC. D’autres types d’origines sont restés épargnés, selon les mises à jour AWS Health. La panne a duré, selon le résumé final, de 07:45 à 11:18 UTC – soit trois heures et demie de perturbations mondiales sur une fonctionnalité critique.

Indicateur clé

3,5 heures

Fenêtre d’impact pour les origines VPC (07:45–11:18 UTC) selon le résumé de résolution AWS du 16 juillet 2026.

Pourquoi les architectures hautement disponibles ont tout de même flanché

De nombreuses équipes ont opté pour les origines VPC précisément pour cette raison : une posture de sécurité renforcée, moins de surface d’attaque exposée, et CloudFront comme point d’entrée unique. Cela réduit la surface d’exposition, mais concentre également le chemin de données. Si la couche de gestion des connexions pour les origines privées tombe en panne, ni la multi-AZ dans votre propre compte ni une réplique dans une autre région suivant le même modèle ne sont utiles, dès lors que le même chemin de configuration global est concerné.

AWS a suggéré comme solution de contournement de modifier le type d’origine – c’est-à-dire de passer d’une origine VPC à une configuration d’origine accessible publiquement. Cela semble simple, mais n’est réalisable en pratique que si l’alternative existe déjà sous forme de distribution de staging ou de module Terraform testé. Ceux qui, lors de l’incident, ouvrent des Security Groups et modifient le DNS perdent les 90 premières minutes.

Checklist pour les équipes platforme DACH

Premièrement : l’inventaire. Quelles distributions utilisent des VPC Origins ? Quels parcours métiers en dépendent – authentification, API, médias, portails partenaires ? Sans cette liste, chaque message de page de statut n’est que du bruit.

Deuxièmement : le chemin de bascule. Préparez une alternative éprouvée : une origine publique derrière des listes de préfixes strictes, un second point d’entrée CDN ou un basculement ciblé vers un groupe d’origines. Le déploiement continu dans CloudFront (distribution de staging) permet de tester le changement à blanc avant que la page de statut ne passe au rouge.

Troisièmement : l’observabilité au-delà de l’ALB. Les erreurs 5xx en périphérie et les métriques de latence des origines doivent déclencher des alertes séparées. Si seul l’état « Healthy Host » du groupe cible est au vert, vous détecterez l’erreur du plan de contrôle trop tard.

# Trouver les VPC Origins dans la liste des comptes (AWS CLI)
aws cloudfront list-vpc-origins --query 'VpcOriginList[*].[Id,Arn,Status]' --output table
# Lister les distributions avec les domaines d'origine
aws cloudfront list-distributions \
  --query "DistributionList.Items[*].{Id:Id,Origins:Origins.Items[*].DomainName}" \
  --output json

Deuxième ligne : les SaaS qui tombent avec vous

Les outils de suivi d’incidents ont signalé des impacts chez des fournisseurs d’identité, des plateformes EdTech comme Canvas et Blackboard, ainsi que des outils de développement et d’IA. Pour les PME, c’est la leçon désagréable : même si votre propre distribution est irréprochable, l’IdP en amont peut bloquer la connexion. Les cartes de dépendances doivent donc considérer le CDN et l’identité comme des risques de premier ordre, et pas seulement la liste de vos namespaces Kubernetes.

Le basculement régional seul sauve rarement des incidents de configuration globaux. Le multi-cloud comme solution apporte sa propre charge opérationnelle et touche souvent les mêmes dépendances SaaS. Plus réaliste souvent : préparer des solutions de contournement connues, automatiser les flux de statut et tenir prêts des modèles de communication pour l’impact business.

Ce que vous pouvez faire concrètement cette semaine

Prévoyez un exercice de 60 minutes : simulez le statut « VPC Origins 5xx », ouvrez le runbook de contournement, promouvez la distribution de staging ou appliquez le plan IaC, mesurez le rollback. Documentez quelles exceptions de sécurité nécessite le fallback public et qui les valide. Ainsi, le prochain incident ne sera pas une revue de sécurité improvisée à 3 heures du matin.

Les VPC Origins restent un modèle de sécurité robuste. Ils ne sont hautement disponibles que si la défaillance du chemin de connexion privé est intégrée dans la conception – et testée.

Foire aux questions

Que sont les CloudFront VPC Origins ?

Les VPC Origins permettent à CloudFront de récupérer du contenu depuis des sous-réseaux privés – typiquement un ALB, NLB ou EC2 sans exposition publique. CloudFront devient le seul point d’entrée public, la connexion à l’origine passe par un chemin privé géré par AWS.

Pourquoi le multi-AZ dans son propre compte n’a-t-il pas aidé ?

L’erreur se situait dans la flotte qui gère globalement les connexions aux VPC Origins privés et distribue la configuration de routage. La redondance locale dans le compte ne change rien à une limite dans ce chemin de gestion des connexions.

Quel contournement AWS a-t-il proposé ?

Lors de l’incident, AWS a recommandé de changer le type d’origine – en abandonnant le VPC Origin pour une autre configuration d’origine. Cela ne fonctionne en pratique qu’avec un staging préparé, de l’IaC et des règles de sécurité testées.

Quelles métriques dois-je alerter ?

Le taux d’erreurs 5xx de CloudFront et la latence des origines, séparément de l’état « Healthy Host » du groupe cible. Ajoutez des vérifications synthétiques depuis l’extérieur de la région et des alertes sur le flux AWS Health pour les problèmes opérationnels de CloudFront.

Un second fournisseur CDN suffit-il ?

En tant que stratégie partielle, oui ; comme solution miracle, non. De nombreuses dépendances SaaS restent sur le même hyperscaler. Priorisez le basculement pour vos chemins d’entrée critiques et l’identité, avant de repenser toute votre architecture multi-cloud.