Historique des pannes de Amazon Web Services

1. 4 octobre 2026 à 16:14 UTCresolved

   Nous enquêtons sur une perte de paquets élevée dans la région UE-SUD-2.

2. 4 octobre 2026 à 16:36 UTCresolved

   Nous subissons une perte de paquets élevée avec une zone de disponibilité unique (eus2-az1) dans la région EU-SUD-2. Ce problème entraîne également une augmentation des latences et des taux d'erreur des API pour les autres workflows et les services AWS. Les ingénieurs étaient automatiquement engagés et travaillent à identifier la cause fondamentale et à atténuer le problème. Nous vous fournirons une autre mise à jour avant 10h15 PDT ou plus tôt lorsque de nouvelles informations seront disponibles.

3. 4 octobre 2026 à 17:06 UTCresolved

   Nos efforts pour atténuer la perte élevée de paquets avec une seule zone de disponibilité (eus2-az1) dans la région EU-SUD-2 sont toujours en cours. Nous constatons des signes d'amélioration grâce à de multiples efforts parallèles. Nous continuons de nous employer à confirmer la cause profonde et à atténuer complètement le problème. Bien que nous n'ayons pas d'estimation pour la durée de nos actions, nous vous tiendrons informé de nos progrès et vous fournirons une autre mise à jour d'ici 11h00 PDT ou plus tôt lorsque de nouvelles informations seront disponibles.

4. 4 octobre 2026 à 17:56 UTCresolved

   Nous avons identifié la cause profonde et nous concentrons actuellement nos efforts d'atténuation pour favoriser le rétablissement complet. Bien que nous n'ayons pas une estimation exacte de la durée de nos efforts actuels, nous nous attendons à voir des améliorations progressives au fur et à mesure de nos efforts. Nous vous fournirons une autre mise à jour avant 11h45 PDT, ou plus tôt si de nouvelles informations deviennent disponibles.

5. 4 octobre 2026 à 18:45 UTCresolved

   Nous voyons des signes précoces de rétablissement. Nous vous fournirons une autre mise à jour avant 12h00 PDT.

6. 4 octobre 2026 à 18:56 UTCresolved

   Entre 8h48 et 11h28 PDT, nous avons connu une perte de paquets élevée dans une seule zone de disponibilité (eus2-az1) dans la région EU-SUD-2. Ce problème a entraîné une augmentation des latences et des taux d'erreur des API pour plusieurs workflows et services AWS. Nous avons été automatiquement alertés à la question à 8h54, et immédiatement commencé à travailler pour identifier la cause fondamentale tout en prenant plusieurs chemins parallèles pour atténuer le problème. À 10 h, nos efforts d'atténuation ont permis d'apporter certaines améliorations. D'ici 10h38, nous avons identifié la cause fondamentale comme étant liée à un changement de configuration de réseau que nous avons été en mesure de revenir au changement qui a conduit à une atténuation complète de 11h28. Le problème a été résolu et le service fonctionne normalement.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 21 septembre 2026 à 23:26 UTCresolved

   Nous enquêtons sur l'augmentation des taux d'erreur de l'API dans la région US-EAST-1.

2. 21 septembre 2026 à 23:44 UTCresolved

   Nous pouvons confirmer des taux d'erreur accrus affectant les lancements de nouvelles instances, y compris des taux d'erreur de l'API élevés pour RunInstances, CreateFleet et les workflows de lancement EC2 connexes dans la région US-EAST-1. Les clients qui tentent de lancer de nouvelles instances EC2 peuvent éprouver des défaillances de lancement ou des latences de réponse API élevées. Nos ingénieurs sont activement engagés et travaillent à la récupération de la question. Nous voyons des signes initiaux de rétablissement. Les instances existantes restent inchangées. Nous recommandons de réessayer les appels d'API RunInstances échoués et CreateFleet. Nous fournirons une mise à jour avant 17h30 PDT ou plus tôt.

3. 22 septembre 2026 à 00:24 UTCresolved

   Entre 15h49 et 17h06 PDT, nous avons constaté une augmentation des taux d'erreurs affectant les nouveaux lancements d'instances dans la région US-EAST-1. Au cours de cette période, les clients peuvent avoir connu des taux d'erreur élevés lorsqu'ils tentent de lancer de nouvelles instances EC2 par l'intermédiaire de RunInstances, CreateFleet et les workflows de lancement EC2. Les services AWS qui lancent des instances EC2 pour le compte de clients, notamment Amazon ECS, AWS Fargate, Amazon EMR, ont également été touchés pendant cette période. Nous avons identifié la cause fondamentale comme étant un déploiement récent dans un sous-système au sein du service EC2 chargé du traitement des demandes de lancement d'instances. Nous avons amorcé un renversement du déploiement problématique et nous avons commencé à observer les premiers signes de rétablissement à 16 h 44. Les instances existantes restent inchangées. Le problème a été résolu et le service fonctionne normalement.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 3 septembre 2026 à 21:49 UTCresolved

   À partir de 14h12 PDT, nous avons commencé à connaître des taux d'erreur de l'API accrus pour STS et Se connecter lors de l'utilisation de SAML dans la région US-WEST-2. Notre équipe d'ingénieurs a été engagée automatiquement à 14h19 pour commencer à enquêter sur la cause fondamentale. Il n'y a pas de travail disponible pour l'instant. Nous fournirons une autre mise à jour avant 15h30 PDT.

2. 3 septembre 2026 à 22:26 UTCresolved

   Nous constatons des signes précoces de rétablissement et continuons de surveiller le rétablissement complet. Nous fournirons une autre mise à jour à 16 h 15, ou plus tôt si nous avons des informations supplémentaires à partager.

3. 3 septembre 2026 à 23:20 UTCresolved

   Nous continuons de voir la récupération se maintenir stable pour les API STS AssumeRoleWithSAML et AssumeRoleWithWebIdentity dans la région US-WEST-2. Les taux d'erreur sont maintenant de retour aux niveaux pré-événement, et nous continuons de surveiller activement pour confirmer la récupération complète. Nous fournirons une autre mise à jour avant 17 h 15 ou plus tôt.

4. 4 septembre 2026 à 00:07 UTCresolved

   Entre 14h12 et 15h18 PDT, nous avons constaté une augmentation des taux d'erreur de l'API affectant les API STS AssumeRoleWithSAML et AssumeRoleWithWebIdentity dans la région US-WEST-2. La cause fondamentale a été déterminée en raison d'un problème avec un sous-système STS chargé de communiquer avec des fournisseurs d'identité externes. D'autres services de SSFE qui s'appuient sur ces protocoles de fédération d'identité ont également été touchés. À 15 h 18, nous avons observé des signes de rétablissement et avons continué de surveiller pour assurer la stabilité et la récupération complète. Le problème est résolu et le service fonctionne normalement actuellement.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 21 août 2026 à 02:02 UTCresolved

   L'AP-NORTHEAST-UN-NORTHEAST Nous constatons une augmentation des taux d'erreurs affectant les mesures en temps réel dans la région AP-NORTHEAST-1. Les clients peuvent rencontrer des données métriques manquantes ou retardées en temps réel.

2. 21 août 2026 à 02:40 UTCresolved

   日本=8:58 AM=10:34 AM="AP-NORTHEAST-1""""""""""""" """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" Entre 16h58 et 18h34 PDT, nous avons connu des retards accrus affectant les mesures en temps réel pour Amazon Connect dans la région AP-NORTHEAST-1, ce qui a donné lieu à des données manquantes ou discontinues. Pendant ce temps, les clients ont peut-être connu des données manquantes dans les rapports d'analyse, et peuvent avoir observé des problèmes si l'on accède aux mesures en temps réel dans les flux de contact, comme la vérification de la dotation des agents. Nous avons identifié la cause profonde du problème avec le sous-système responsable de la livraison des événements métriques. Nous avons commencé à appliquer les mesures d'atténuation à 18 h 13 et nous avons atténué la question à 18 h 34. Le problème a été résolu et le service fonctionne normalement.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 19 août 2026 à 15:15 UTCresolved

   Nous enquêtons sur une question qui a une incidence sur le lancement de nouvelles instances et ressources de la CE2 dans une zone de disponibilité nouvellement lancée (euw2-az4) dans la région EU-WEST-2. Pendant ce temps, les clients touchés peuvent éprouver des problèmes lors de la création ou de la modification de ressources dans la région. D'autres services AWS peuvent également être touchés. Pour une récupération immédiate, nous recommandons aux clients d'utiliser des zones de disponibilité alternatives (euw2-az1, euw2-az2 et euw2-az3) le cas échéant. Les instances opérationnelles et les ressources existantes ne sont pas affectées. Nous fournirons une autre mise à jour avant 10h00 PDT, ou plus tôt si nous avons des informations supplémentaires à partager.

2. 19 août 2026 à 17:03 UTCresolved

   Le 18 août, nous avons lancé une nouvelle zone de disponibilité (euw2-az4) dans la région EU-WEST-2. Après le lancement, nous avons commencé à éprouver des erreurs en lançant des instances EC2 dans la nouvelle zone de disponibilité quand un sous-réseau par défaut n'est pas présent. Nous pouvons confirmer que les instances opérationnelles et les ressources existantes ne sont pas affectées. Les flux de travail qui obtiennent automatiquement une liste des zones de disponibilité dans la région via l'API DécrireDisponibilitéZones et ensuite tenter de lancer de nouvelles instances ou créer des ressources dans la nouvelle zone de disponibilité peuvent rencontrer des erreurs. Pour les échecs de lancement d'EC2, nous prenons des mesures d'atténuation pour créer automatiquement des sous-réseaux par défaut, lorsqu'un lancement d'instance d'EC2 vise la nouvelle zone de disponibilité. Pour les clients et les flux de travail qui nécessitent une remise en état immédiate <a href="https://docs.aws.amazon.com/vpc/latest/userguide/work-with-default-vpc.html#create-default-subnet">vous pouvez créer un sous-net par défaut</a> dans la nouvelle zone de disponibilité. Cela permettra aux lancements d'instance EC2 de se terminer avec succès. Pour d'autres ressources, telles que les fonctions Lambda, où la nouvelle zone de disponibilité n'est actuellement pas prise en charge, nous recommandons aux clients de mettre à jour leurs flux de travail afin d'exclure la zone de disponibilité nouvellement lancée et de poursuivre la création de ressources en utilisant les autres zones de disponibilité dans la région. Bien que nous n'ayons pas une estimation exacte de la durée de nos efforts d'atténuation, nous vous tiendrons au courant de nos progrès et vous fournirons une autre mise à jour avant 13h00 HAP ou plus tôt à mesure que de nouvelles informations seront disponibles.

3. 19 août 2026 à 18:47 UTCresolved

   Entre le 18 août 17h00 et le 19 août 11h00 PDT, nous avons connu des erreurs élevées en lançant des instances EC2 dans une zone de disponibilité nouvellement lancée (euw2-az4) dans la région EU-WEST-2. Après le lancement de la nouvelle zone de disponibilité, nous avons commencé à éprouver des erreurs en utilisant un VPC par défaut. Nous avons découvert la cause profonde du problème le 19 août à 9h00 et avons commencé à déployer un changement pour le résoudre à 9h30. Pendant que le changement était en cours, nous avons commencé à voir des améliorations progressives dans les lancements de nouveaux cas, avec une reprise complète à 11 h. Les procédures de fonctionnement et les ressources existantes n'ont pas été affectées. Certains services régionaux, comme les fonctions de Lambda ou les bases de données Aurora, n'étaient pas disponibles lors du lancement de la nouvelle zone de disponibilité et la disponibilité du service sera ajoutée au fil du temps. Les clients qui tentent de créer des ressources avant que les services ne soient disponibles verront un message indiquant qu'il n'est pas pris en charge dans la zone de disponibilité. Le problème a été résolu et le service fonctionne normalement.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 15 août 2026 à 03:42 UTCresolved

   Nous enquêtons sur l'augmentation de la perte de paquets, impactant la connectivité AWS Direct Connect pour certains clients de la région EU-CENTRAL-1.

2. 15 août 2026 à 04:42 UTCresolved

   Nous pouvons confirmer la perte de paquets impactant les connexions Direct Connect dans la région EU-CENTRAL-1. Les ingénieurs ont été automatiquement engagés et ont immédiatement commencé à travailler à la fois à identifier la cause fondamentale et à identifier plusieurs chemins parallèles pour atténuer le problème. À l'heure actuelle, nous voyons des signes précoces de rétablissement. Nous fournirons une autre mise à jour dans 60 minutes, ou plus tôt si nous avons des informations supplémentaires à partager.

3. 15 août 2026 à 05:55 UTCresolved

   A partir de 19:33 PM PDT, nous avons commencé à ressentir une perte de paquets accrue impactant la connectivité AWS Direct Connect pour certains clients de la région EU-CENTRAL-1. Bien que nous ayons fait des progrès, les connexions à l'emplacement Direct Connect suivant sont encore altérées : Equinix FR5, Francfort, DEU. Les clients qui ont une redondance multi-site configurée avec leurs chemins de connexion directe ne devraient pas observer l'impact en ce moment. Les clients qui n'ont de connexions qu'à l'emplacement d'Equinix FR5, Frankfurt, DEU continueront de connaître des problèmes de connectivité. Nous nous efforçons activement d'atténuer l'impact et de travailler en vue d'un rétablissement complet, mais nous nous attendons à un rétablissement complet à plusieurs heures. Nous fournirons une mise à jour dans 90 minutes, ou plus tôt si nous avons des informations supplémentaires à partager.

4. 15 août 2026 à 07:24 UTCresolved

   Nous travaillons activement au rétablissement de la connectivité par l'intermédiaire de Direct Connect : Equinix FR5, Francfort, DEU. Les clients qui n'ont de connexions qu'à l'emplacement d'Equinix FR5, Frankfurt, DEU continueront de connaître des problèmes de connectivité. Pour une solution de rechange impactés clients qui ont l'option disponible pour faire défaut vers VPN sont recommandés de le faire pour atteindre la récupération. Pour les clients utilisant la passerelle Direct Connect et la passerelle Transit, nous recommandons de créer un VPN site-vers-site AWS et de l'attacher à votre passerelle Transit, consultez les étapes <a href="https://aws.amazon.com/premiumsupport/knowledge-center/dx-configure-dx-and-vpn-failover-tgw/">ici</a>. Pour d'autres clients, nous vous recommandons d'établir un VPN site à site AWS comme chemin de sauvegarde temporaire, reportez-vous aux étapes <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnexions.html">ici</a>. À partir de ce moment, nous nous attendons à une récupération à plusieurs heures. Nous fournirons une autre mise à jour dans 90 minutes, ou plus tôt si nous avons des informations supplémentaires à partager.

5. 15 août 2026 à 09:08 UTCresolved

   Nous continuons à travailler à la récupération de la connectivité pour les connexions AWS Direct Connect à Equinix FR5, Francfort, DEU. La cause fondamentale est liée à un problème d'infrastructure des installations à l'emplacement qui a une incidence sur l'infrastructure du réseau. Les clients avec des connexions uniquement à cet endroit continueront à subir la perte de paquets ou la dégradation de la connectivité. Les clients ayant des configurations multi-site ou redondantes dans d'autres emplacements ne sont pas touchés. Pour une solution de rechange, les clients touchés qui ont l'option disponible pour faire défaut sur VPN sont invités à le faire. Pour les clients utilisant la passerelle de connexion directe et la passerelle de transit, nous vous recommandons de créer un VPN Site-to-Site AWS et de l'attacher à votre passerelle de transit, consultez les étapes <a href="https://aws.amazon.com/premiumsupport/knowledge-center/dx-configure-dx-and-vpn-failover-tgw/">ici</a>. Pour d'autres clients, nous vous recommandons d'établir un VPN Site-to-Site AWS comme chemin de sauvegarde temporaire, consultez les étapes <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnexions.html">ici</a>. À partir de ce moment, nous nous attendons à une récupération à plusieurs heures. Nous fournirons une autre mise à jour dans les 2 heures ou dès que nous aurons plus d'informations à partager.

6. 15 août 2026 à 11:10 UTCresolved

   La connectivité AWS Direct Connect reste altérée pour les clients ayant des connexions à l'emplacement Equinix FR5 à Francfort, DEU. Les clients ayant des configurations multi-sites ou redondantes dans d'autres endroits ne sont toujours pas touchés. Les ingénieurs s'emploient activement à rétablir la connectivité, avec des efforts continus dans plusieurs secteurs de travail pour résoudre le problème d'installation sous-jacent et remettre en service l'équipement du réseau touché. Nous continuons à nous attendre à ce que le rétablissement se fasse dans plusieurs heures. Pour une solution de rechange, il est recommandé aux clients touchés qui ont l'option de basculer vers VPN. Pour les clients utilisant la passerelle de connexion directe et la passerelle de transit, nous vous recommandons de créer un VPN Site-to-Site AWS et de l'attacher à votre passerelle de transit, consultez les étapes <a href="https://aws.amazon.com/premiumsupport/knowledge-center/dx-configure-dx-and-vpn-failover-tgw/">ici</a>. Pour d'autres clients, nous vous recommandons d'établir un VPN Site-to-Site AWS comme chemin de sauvegarde temporaire, consultez les étapes <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnexions.html">ici</a>. Nous fournirons une autre mise à jour dans les 2 heures ou dès que nous aurons plus d'informations à partager.

7. 15 août 2026 à 13:17 UTCresolved

   Les ingénieurs poursuivent leurs travaux pour rétablir la connectivité à l'emplacement d'Equinix FR5 à Francfort, DEU. Notre partenaire de co-implantation s'emploie à résoudre le problème de l'infrastructure des installations sous-jacentes et bien que les améliorations ne soient pas encore visibles par le client, nous progressons positivement vers la résolution. Pour les clients qui ont besoin d'une récupération immédiate, nous recommandons de ne pas passer au VPN, comme indiqué dans nos mises à jour précédentes. Nous fournirons une autre mise à jour avant 9h30 PDT, ou plus tôt si nous avons des informations supplémentaires à partager.

8. 15 août 2026 à 16:27 UTCresolved

   Notre partenaire de co-implantation continue de travailler à résoudre le problème sous-jacent de l'infrastructure des installations à l'emplacement d'Equinix FR5 à Francfort, DEU. L'accès à la zone touchée est actuellement restreint en raison de problèmes de sécurité, ce qui nuit à notre capacité d'évaluer l'état physique de l'équipement du réseau et de fournir un calendrier de récupération plus précis. D'après les renseignements actuels, le rétablissement complet n'est pas prévu à court terme et pourrait se prolonger au-delà d'aujourd'hui. Les connexions AWS Direct Connect à cet endroit demeurent altérées. Les clients ayant des connexions redondantes par d'autres emplacements ne sont pas touchés. Pour les clients utilisant la passerelle de connexion directe et la passerelle de transit, nous vous recommandons de créer un VPN Site-to-Site AWS et de l'attacher à votre passerelle de transit, consultez les étapes <a href="https://aws.amazon.com/premiumsupport/knowledge-center/dx-configure-dx-and-vpn-failover-tgw/">ici</a>. Pour d'autres clients, nous vous recommandons d'établir un VPN Site-to-Site AWS comme chemin de sauvegarde temporaire, consultez les étapes <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnexions.html">ici</a>. Nous fournirons une autre mise à jour avant 15h30 PDT, ou plus tôt si nous avons des informations supplémentaires à partager.

9. 15 août 2026 à 22:26 UTCresolved

   Notre partenaire de co-implantation poursuit ses travaux pour rétablir un accès sûr à la zone touchée à l'emplacement d'Equinix FR5 à Francfort, DEU. Une fois l'accès sécurisé, nos ingénieurs pourront évaluer les appareils réseau touchés. Nous continuons de suivre de près les progrès accomplis et partagerons une mise à jour d'ici 21 h 30 PDT, ou plus tôt à mesure que de nouvelles informations seront disponibles.

10. 16 août 2026 à 04:37 UTCresolved

    Nous sommes activement engagés avec notre partenaire de co-implantation pour restaurer la connectivité à Equinix FR5 à Francfort, DEU. Depuis notre dernière mise à jour, nous avons fait des progrès supplémentaires pour rétablir un accès sûr à la zone touchée à l'emplacement d'Equinix FR5 à Francfort, DEU. Parallèlement, nous avons accordé la priorité à l'ordre dans lequel des racks critiques et hautement prioritaires seront restaurés, dans le cadre des efforts d'atténuation. Selon notre évaluation actuelle, le rétablissement complet n'est pas prévu à court terme et pourrait s'étendre au-delà d'aujourd'hui. Les connexions AWS Direct Connect à cet endroit demeurent altérées. Les clients ayant des connexions exclusivement à cet endroit continueront à subir une perte de paquets. Les clients avec des configurations multi-sites ou redondantes dans d'autres emplacements de Direct Connect restent inchangés. Pour une solution de rechange, les clients touchés qui ont l'option disponible pour faire défaut sur VPN sont invités à le faire. Pour les clients utilisant la passerelle de connexion directe et la passerelle de transit, nous vous recommandons de créer un VPN Site-to-Site AWS et de l'attacher à votre passerelle de transit, consultez les étapes <a href="https://aws.amazon.com/premiumsupport/knowledge-center/dx-configure-dx-and-vpn-failover-tgw/">ici</a>. Pour d'autres clients, nous vous recommandons d'établir un VPN Site-to-Site AWS comme chemin de sauvegarde temporaire, consultez les étapes <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnexions.html">ici</a>. Nous continuons de suivre de près les progrès accomplis et nous partagerons une mise à jour d'ici le 16 août, à 3 h 30, ou plus tôt à mesure que de nouvelles informations seront disponibles.

11. 16 août 2026 à 10:25 UTCresolved

    Nous continuons de travailler avec notre partenaire de co-implantation pour rétablir la connectivité à l'emplacement d'Equinix FR5 à Francfort, DEU. Depuis notre dernière mise à jour, nous avons fait des progrès importants en vue de rétablir un accès sécuritaire à la région touchée. La procédure d'isolement électrique est en cours, nos équipes se trouvant sur place dans la salle électrique exécutant la désenergisation de l'infrastructure affectée. Une fois l'isolement vérifié et confirmé sécuritaire, les ingénieurs entreprendront une inspection physique de l'équipement du réseau touché afin de déterminer la portée du remplacement requis. D'après notre évaluation actuelle, on ne s'attend pas à un rétablissement complet à court terme en raison de l'ampleur des impacts potentiels sur l'équipement. Les connexions AWS Direct Connect à cet endroit demeurent altérées. Les clients ayant des connexions exclusivement à cet endroit continueront à subir une perte de paquets. Les clients avec des configurations multi-sites ou redondantes dans d'autres emplacements de Direct Connect restent inchangés. Pour une solution de rechange, les clients touchés qui ont l'option disponible pour faire défaut sur VPN sont invités à le faire. Pour les clients utilisant la passerelle de connexion directe et la passerelle de transit, nous vous recommandons de créer un VPN Site-to-Site AWS et de l'attacher à votre passerelle de transit, consultez les étapes <a href="https://aws.amazon.com/premiumsupport/knowledge-center/dx-configure-dx-and-vpn-failover-tgw/">ici</a>. Pour d'autres clients, nous vous recommandons d'établir un VPN Site-to-Site AWS comme chemin de sauvegarde temporaire, consultez les étapes <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnexions.html">ici</a>. Nous continuons de suivre de près les progrès et nous partagerons une mise à jour d'ici le 16 août, 9 h 30, ou plus tôt lorsque de nouvelles informations seront disponibles.

12. 16 août 2026 à 16:30 UTCresolved

    L'isolement électrique d'Equinix FR5 à Francfort, DEU est maintenant terminé et nos ingénieurs ont commencé à inspecter physiquement les équipements du réseau impacté. Nous n'avons pas encore de calendrier pour une résolution complète, alors que nous continuons d'évaluer l'ampleur de l'impact sur l'équipement. Les connexions Direct Connect à cet emplacement restent altérées. Les clients ayant des connexions exclusivement à cet endroit continueront à subir une perte de paquets. Les clients ayant des configurations multi-site ou redondantes dans d'autres emplacements de Direct Connect ne sont pas touchés. Nous recommandons que les clients touchés échouent au VPN jusqu'à ce que nous ayons plus de clarté sur les prochaines étapes et un calendrier de récupération. Pour les clients utilisant la passerelle de connexion directe et la passerelle de transit, vous pouvez créer un VPN site-à-site AWS et le joindre à votre passerelle de transit, consultez les étapes <a href="https://aws.amazon.com/premiumsupport/knowledge-center/dx-configure-dx-and-vpn-failover-tgw/">ici</a>. Pour d'autres clients, nous recommandons d'établir un VPN Site-to-Site AWS comme chemin de sauvegarde temporaire, reportez-vous aux étapes <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnexions.html">ici</a>. Nous fournirons une autre mise à jour d'ici le 16 août 17 h 30 PDT, ou plus tôt lorsque de nouvelles informations seront disponibles.

13. 16 août 2026 à 22:51 UTCresolved

    Nous avons terminé notre évaluation de l'équipement de réseau touché à l'emplacement d'Equinix FR5 à Francfort, DEU et avons maintenant une compréhension claire de l'étendue de l'impact. Nous progressons vers le rétablissement de la connectivité et nous adopterons une approche progressive de l'assainissement. Les clients avec des connexions exclusivement à cet endroit continueront à subir la perte de paquets jusqu'à ce que la réparation soit terminée. Les clients ayant des configurations multi-site ou redondantes dans d'autres emplacements de Direct Connect ne sont pas touchés. Nous fournirons une autre mise à jour d'ici le 16 août 22h30 PDT, ou plus tôt lorsque de nouvelles informations seront disponibles.

14. 17 août 2026 à 05:38 UTCresolved

    Nous continuons de progresser dans la remise en état progressive de notre site d'Equinix FR5 à Francfort, DEU. Depuis notre dernière mise à jour, une infrastructure de réseau dépendante a été restaurée. La remise en état des infrastructures restantes est en cours, une partie de la récupération étant tributaire de la livraison du matériel de remplacement. Le refroidissement a été entièrement rétabli, les conditions environnementales étant stables dans les limites normales d'exploitation. Les clients ayant des connexions exclusivement à cet endroit continueront de subir une perte de paquets à mesure que l'assainissement progresse. Les clients ayant des configurations multi-site ou redondantes dans d'autres emplacements de Direct Connect ne sont pas touchés. À l'heure actuelle, les lignes directrices et les recommandations déjà communiquées en matière d'atténuation demeurent inchangées. Nous fournirons une autre mise à jour d'ici le 17 août 16h30 PDT, ou plus tôt à mesure que l'assainissement progresse.

15. 17 août 2026 à 11:22 UTCresolved

    Nous continuons de progresser dans la remise en état progressive de notre site d'Equinix FR5 à Francfort, DEU. L'infrastructure du réseau et les systèmes dépendants continuent de s'améliorer à mesure que nous ramenons le matériel affecté en ligne. Certains matériels de remplacement ont été livrés et l'installation se poursuit à mesure que les composants arrivent sur place. En parallèle, nous sommes en train de déplacer le trafic réseau pour permettre aux appareils restaurés de commencer à servir les clients au fur et à mesure qu'ils viennent en ligne. Au fur et à mesure que nous progressons dans la récupération, les clients observeront la restauration en deux étapes. Dans la première étape, les sessions BGP seront rétablies mais les préfixes IP ne seront pas encore annoncés, ce qui indique que la reprise est encore en cours et que l'infrastructure sous-jacente n'est pas encore prête à transporter du trafic. Dans la deuxième étape, la publicité préfixe IP reprendra, où l'infrastructure est entièrement assainie et où la connectivité est rétablie. Bien que nous n'ayons pas actuellement une ETA pour une récupération complète, nous continuons de travailler aussi rapidement et en toute sécurité que possible pour atténuer l'impact pour les clients. Nous fournirons une autre mise à jour d'ici le 17 août 10h30, ou plus tôt à mesure que la remise en état progresse.

16. 17 août 2026 à 16:25 UTCresolved

    Nous continuons de travailler à la remise en état progressive de l'installation d'Equinix FR5 à Francfort, DEU. Nous assistons à des signes précoces de reprise tout en continuant de remédier à la situation. Nous travaillons activement pour ramener le matériel affecté restant en ligne et nous fournirons une autre mise à jour d'ici 12h30 PDT, ou plus tôt à mesure que l'assainissement progresse.

17. 17 août 2026 à 17:59 UTCresolved

    Nous voyons de larges signes de reprise à l'emplacement d'Equinix FR5 à Francfort, DEU. Nous avons rétabli la connectivité pour la majorité du matériel affecté et la plupart des connexions sont entièrement récupérées et stables. Il y a un petit nombre de clients qui resteront touchés jusqu'à ce que les autres appareils soient entièrement restaurés. Nous fournirons une autre mise à jour d'ici 14h00 HAP, ou plus tôt à mesure que l'assainissement progresse.

18. 17 août 2026 à 21:00 UTCresolved

    Nous continuons de travailler à ramener le matériel affecté en ligne. Depuis notre dernière mise à jour, nous avons fait des progrès qui ne seront pas visibles pour les clients, mais sont nécessaires pour la récupération. Nous travaillons en parallèle pour mettre tous les appareils en ligne le plus en toute sécurité possible. Ce travail devrait prendre plusieurs heures pour compléter et valider. Pour les clients qui ont besoin de solutions de rechange, nous vous recommandons d'envisager de ne pas passer au VPN. Pour les clients utilisant la passerelle de connexion directe et la passerelle de transit, vous pouvez créer un VPN site-à-site AWS et le joindre à votre passerelle de transit, consultez les étapes <a href="https://aws.amazon.com/premiumsupport/knowledge-center/dx-configure-dx-and-vpn-failover-tgw/">ici</a>. Pour d'autres clients, nous recommandons d'établir un VPN Site-to-Site AWS comme chemin de sauvegarde temporaire, reportez-vous aux étapes <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnexions.html">ici</a>. Nous fournirons une autre mise à jour d'ici 19h00 PDT ou plus tôt lorsque de nouvelles informations seront disponibles.

19. 18 août 2026 à 01:50 UTCresolved

    Nous assistons à une récupération importante pour la plupart des connexions client à ce stade. Bien que nous ne soyons pas encore complètement rétablis, les efforts de restauration progressent comme prévu à l'emplacement d'Equinix FR5 à Francfort, DEU. La remise en état de l'infrastructure restante implique l'achèvement des remplacements de matériel et la validation du trafic, qui sont tous deux en cours. Nous prévoyons d'autres récupérations visibles des clients à mesure que l'infrastructure restante sera remise en service. Les clients avec des connexions exclusivement à cet endroit continueront à subir la perte de paquets jusqu'à ce que la réparation soit terminée. À l'heure actuelle, les lignes directrices et les recommandations déjà communiquées en matière d'atténuation demeurent inchangées. Nous fournirons une autre mise à jour d'ici le 17 août 23h00 PDT ou plus tôt.

20. 18 août 2026 à 04:01 UTCresolved

    À partir du 14 août, 19:33 PDT, nous avons connu une augmentation de la perte de paquets impactant la connectivité AWS Direct Connect pour les clients avec des connexions à l'emplacement Equinix FR5 à Francfort, DEU. Les ingénieurs ont été engagés automatiquement à 19h45 le 14 août et ont immédiatement commencé à enquêter sur les mesures d'atténuation. À 20 h 30, nous avons constaté que l'équipement du réseau à l'emplacement du FR5 était altéré en raison de l'entrée de l'eau dans l'installation de co-implantation. En conséquence, le système de refroidissement a été altéré, ce qui a entraîné la surchauffe et l'arrêt des dispositifs. L'eau a également affecté les systèmes de distribution d'électricité qui ont désactivé l'alimentation des appareils du réseau. Les premiers efforts de rétablissement ont été retardés car les conditions environnementales dans l'installation devaient être stabilisées avant que les ingénieurs puissent accéder en toute sécurité à la zone touchée. Tout au long des 15 et 16 août, nos ingénieurs ont travaillé en coordination avec l'exploitant de l'installation pour remettre en état les dispositifs réseau défectueux tandis que la question de l'infrastructure sous-jacente a été abordée. À 19 h 26, le 17 août, tous les équipements réseau défectueux ont été restaurés avec succès et la connectivité à l'emplacement a été vérifiée comme étant pleinement opérationnelle avec une reprise soutenue. Nous ne nous attendons pas à ce que cette question se reproduise. Les clients ayant des connexions redondantes à travers d'autres emplacements de Direct Connect ont maintenu la connectivité à travers leurs chemins alternatifs tout au long de cet événement et ne nécessitent aucune autre action. Les clients qui ont implémenté une panne VPN comme solution de rechange peuvent maintenant revenir en toute sécurité à leurs principaux chemins de connexion directe. La connectivité a été vérifiée comme étant stable et pleinement opérationnelle. Les clients qui ont besoin d'aide supplémentaire peuvent communiquer avec AWS Support par l'intermédiaire de la console de gestion AWS ou du <a href="https://console.aws.amazon.com/support">Centre de soutien AWS</a>.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 31 juillet 2026 à 17:33 UTCresolved

   Nous pouvons confirmer la perte de paquets réseau élevée, impactant la connectivité AWS Direct Connect dans la région AP-SUD-1. Notre équipe d'ingénieurs a été engagée automatiquement à 9h54 pour commencer à enquêter sur la question. Il n'y a pas de solutions de rechange pour le moment. Nous fournirons une autre mise à jour avant 11h30 PDT.

2. 31 juillet 2026 à 18:27 UTCresolved

   Nous avons identifié la cause fondamentale d'un changement apporté à un système de configuration responsable de l'attribution des itinéraires aux appareils. Nous avons commencé les travaux pour réduire la perte de paquets qui affecte AWS Direct Connect dans la région AP-SUD-1, et nous nous attendons à ce que la récupération ait lieu progressivement au cours des 30 prochaines minutes. Au fur et à mesure que nous aurons confiance dans ces efforts, nous nous efforcerons de faire coïncider nos efforts pour accélérer la reprise. Nous fournirons une autre mise à jour avant 12h00 PDT.

3. 31 juillet 2026 à 18:54 UTCresolved

   Entre 9h42 et 11h44 PDT, nous avons connu une perte de paquets réseau élevée impactant la connectivité AWS Direct Connect dans la région AP-SUD-1. Notre équipe d'ingénieurs a été engagée automatiquement à 9h46 pour commencer à enquêter. D'ici 10h51, nous avons compris que la cause profonde était un changement de configuration apporté à un système responsable de l'attribution des itinéraires aux appareils. Au fur et à mesure que nous avons gagné en confiance dans nos mesures d'atténuation, nous avons parallélisé nos efforts pour réduire davantage la perte de paquets. Le problème est résolu et le service fonctionne normalement.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 24 juillet 2026 à 11:40 UTCresolved

   Nous enquêtons sur des problèmes de connectivité touchant plusieurs services de SSFE dans la région US-WEST-2.

2. 24 juillet 2026 à 11:56 UTCresolved

   Nous voyons des signes initiaux de rétablissement et nous continuons de travailler à un rétablissement complet.

3. 24 juillet 2026 à 12:30 UTCresolved

   Nous continuons de constater d'importants signes de rétablissement grâce à nos efforts d'atténuation des problèmes de connectivité touchant plusieurs services de SSFE dans la région US-WEST-2. Nous avons identifié la cause profonde comme un problème avec un dispositif de réseautage responsable de l'acheminement du réseau de la région vers le métro de Seattle. Les ingénieurs ont terminé tous les travaux d'atténuation. À mesure que les routes continuent d'être rétablies, les clients devraient constater une réduction continue des taux d'erreur et des délais de connexion aux services touchés. Nous suivons de près les progrès de la reprise et nous continuerons de travailler jusqu'à ce que toutes les routes aient été entièrement restaurées et que les mesures de service reviennent aux niveaux pré-événement. Nous fournirons une autre mise à jour dans les 30-45 prochaines minutes.

4. 24 juillet 2026 à 13:01 UTCresolved

   Entre 3 h 55 et 4 h 15, nous avons connu des problèmes de connectivité qui ont influé sur la connectivité de la région US-WEST-2. Cela a eu des répercussions sur plusieurs services de SSFE dans la région. Certains clients peuvent également avoir éprouvé des problèmes d'accès à la console de gestion AWS, avec des temps de connexion et des pages non réactives. La connectivité dans la région n'a pas été affectée. Nos ingénieurs ont été engagés automatiquement à 4:01 AM PDT, et immédiatement commencé à enquêter sur cette question. Nous avons identifié la cause fondamentale comme un problème avec les dispositifs de réseautage responsables de l'acheminement du réseau de la région vers le métro de Seattle, et avons commencé à travailler en parallèle sur plusieurs voies pour atténuer l'impact. Nous avons pris des mesures d'atténuation qui ont mené au rétablissement initial à 4 h 15 HAP. Alors que le réseau continuait de se stabiliser à la suite de nos mesures d'atténuation, un bref événement de reconvergence s'est produit entre 4:47 et 4:59 AM PDT. Au cours de cette période de reconvergence, certains clients ont peut-être eu des problèmes de connectivité intermittents avec la région à mesure que les routes de réseau ont été rétablies. Vers 16h59, toutes les routes avaient été entièrement restaurées et les mesures de service étaient retournées aux niveaux pré-événement. Les clients utilisant AWS Direct Connect via EqSe2, Westin Building Exchange, Seattle ont connu une fenêtre d'impact étendue de 3:55 à 5:12 AM PDT. Ces clients auraient eu des problèmes de connectivité jusqu'à ce que les routes réseau pour ce chemin spécifique soient entièrement restaurées à 5:12 AM PDT. Les clients reliés de façon redondante par d'autres emplacements AWS Direct Connect n'ont pas été touchés par cet événement. Le problème a été résolu et tous les services de SSFE fonctionnent normalement.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 17 juillet 2026 à 08:33 UTCresolved

   Nous enquêtons sur des problèmes avec Cost Explorer qui reflètent des données de facturation inexactes.

2. 17 juillet 2026 à 09:07 UTCresolved

   À partir du 16 juillet 19h38, nous avons commencé à afficher des données de facturation incorrectes dans la console de facturation et de gestion des coûts. Nos équipes d'ingénierie sont engagées et enquêtent sur la cause profonde. Nous fournirons une autre mise à jour avant 3:00 AM PDT ou plus tôt si plus d'information devient disponible.

3. 17 juillet 2026 à 10:03 UTCresolved

   Nous continuons de travailler à résoudre le problème touchant les données estimatives sur les coûts et l'utilisation affichées dans la console de facturation et de gestion des coûts. Nous avons identifié la cause fondamentale comme un problème avec le prix unitaire dans le sous-système de calcul de la facturation estimée et nous travaillons sur une atténuation. Les estimations de facturation affichées ne reflètent pas l'utilisation et les frais réels. Il n'y a pas d'action client requise pour le moment. Une fois la question atténuée, nous nous attendons à ce que la résolution complète prenne plusieurs heures alors que nous travaillons à recalculer les données de facturation estimées. Nous fournirons une autre mise à jour avant 16h00 PDT ou plus tôt si plus d'informations sont disponibles.

4. 17 juillet 2026 à 10:52 UTCresolved

   Nous continuons de travailler à résoudre le problème touchant les données estimatives sur les coûts et l'utilisation affichées dans la console de facturation et de gestion des coûts. Comme nous l'avons déjà dit, nous avons identifié la cause principale comme un problème de tarification unitaire dans le sous-système de calcul de la facturation estimative. Pour éviter que d'autres estimations de facturation inexactes ne soient affichées, nous avons interrompu les calculs de facturation estimés. Les clients qui voient actuellement des prévisions de factures normales continueront de voir ces estimations, et les clients qui voient des estimations gonflées ne les verront pas augmenter davantage pendant que nous travaillons à la résolution. Les estimations de facturation affichées ne reflètent pas l'utilisation et les frais réels. Nous continuons de nous employer à atténuer pleinement la question. Une fois la question atténuée, nous nous attendons à ce que la résolution complète prenne plusieurs heures alors que nous travaillons à recalculer les données de facturation estimées. Il n'y a pas d'action client requise pour le moment. Nous fournirons une autre mise à jour d'ici 5h00 HAP ou plus tôt si plus d'information devient disponible.

5. 17 juillet 2026 à 11:58 UTCresolved

   Nous continuons de travailler à résoudre le problème touchant les données estimatives sur les coûts et l'utilisation affichées dans la console de facturation et de gestion des coûts. Nous travaillons activement sur plusieurs voies d'atténuation en parallèle. Le premier chemin consiste à revenir au dernier bon calcul de la facture connu. Avec cette approche, les clients ne verront les données sur les coûts et l'utilisation que jusqu'au 15 juillet, mais les données sur les coûts gonflés seront supprimées. La deuxième voie consiste à revenir à une modification récente du sous-système de calcul de la facturation. Les estimations de facturation affichées ne reflètent pas l'utilisation et les frais réels. Il n'y a pas d'action client requise pour le moment. Une fois la question atténuée, nous nous attendons à ce que la résolution complète prenne plusieurs heures alors que nous travaillons à recalculer les données de facturation estimées. Nous fournirons une autre mise à jour d'ici 6h00 PDT ou plus tôt si plus d'information devient disponible.

6. 17 juillet 2026 à 12:54 UTCresolved

   Nous continuons de travailler sur de multiples voies d'atténuation en parallèle pour résoudre le problème touchant les données estimatives sur les coûts et l'utilisation affichées dans la console de facturation et de gestion des coûts, y compris le rapport sur les coûts et l'utilisation. Nous évaluons la reprise des calculs de facturation estimés, car notre surveillance interne indique que le sous-système de calcul de la facturation produit maintenant des estimations exactes. Nous effectuons une validation supplémentaire avant de procéder à cette démarche. Les estimations de facturation affichées ne reflètent pas l'utilisation et les frais réels. Il n'y a pas d'action client requise pour le moment. Nous fournirons une autre mise à jour d'ici 8h00 PDT ou plus tôt si plus d'information devient disponible.

7. 17 juillet 2026 à 14:53 UTCresolved

   Nous continuons de travailler à résoudre le problème touchant les données estimatives sur les coûts et l'utilisation présentées dans la console de facturation et de gestion des coûts, y compris le rapport sur les coûts et l'utilisation. Le recul d'un changement récent n'a pas résolu le problème et nous continuons d'étudier plusieurs voies d'atténuation. Les mises à jour estimatives des factures restent suspendues. Nous sommes en train de revenir aux dernières données de facturation précises. Les estimations de facturation affichées ne reflètent pas l'utilisation et les frais réels. Il n'y a pas d'action client requise pour le moment. Nous nous attendons à ce que cette atténuation prenne plusieurs heures à terminer au fur et à mesure que nous recalculons les données de facturation estimatives. Nous fournirons une autre mise à jour d'ici 10:00 AM PDT ou plus tôt si plus d'information devient disponible.

8. 17 juillet 2026 à 16:59 UTCresolved

   Nous avons identifié la cause fondamentale et atténué le problème sous-jacent, ce qui a entraîné l'affichage de données inexactes sur les coûts et l'utilisation dans la console de facturation et de gestion des coûts, ainsi que dans les rapports sur les coûts et l'utilisation. Nous avons commencé à remblayer les données pour corriger les données de coûts pour tous les clients. Nous nous attendons à ce que certains clients commencent à voir la récupération dans les trois prochaines heures, et la récupération complète pour tous les clients d'ici le 18 juillet 12:00 PM PDT. Jusqu'à ce que le remblayage soit terminé, certains clients peuvent encore voir des données de coûts et d'utilisation incorrectes. Les estimations de facturation affichées ne reflètent pas l'utilisation et les frais réels. Il n'y a pas d'action client requise pour le moment. Nous fournirons une autre mise à jour avant 13 h, ou plus tôt si l'information devient disponible.

9. 17 juillet 2026 à 19:56 UTCresolved

   Nos efforts de remblayage des données corrigées sur les coûts et l'utilisation sont toujours en cours. Nous progressons plus lentement que prévu. Alors que nous voyons certains comptes récupérer avec des données de coûts et d'utilisation correctes, nous nous attendons à ce que tous les comptes touchés soient récupérés d'ici le 19 juillet 12:00 AM PDT. Jusqu'à ce que le remblayage soit terminé, certains clients peuvent encore voir des données de coûts et d'utilisation incorrectes. Les estimations de facturation affichées ne reflètent pas l'utilisation et les frais réels. Il n'y a pas d'action client requise pour le moment. Nous fournirons une autre mise à jour d'ici 19 h, ou plus tôt si l'information devient disponible.

10. 18 juillet 2026 à 01:38 UTCresolved

    Nous continuons de faire des progrès constants en vue de résoudre le problème qui touche les données estimatives sur les coûts et l'utilisation présentées dans la console de facturation et de gestion des coûts. Nos efforts de remblayage des données corrigées sont toujours en cours, et nous nous attendons à ce que tous les comptes touchés soient entièrement récupérés d'ici le 19 juillet, 12h00 PDT. Jusqu'à ce que le remblayage soit terminé, certains clients peuvent encore observer des données incorrectes sur les coûts et l'utilisation dans la console de facturation et de gestion des coûts et les rapports sur les coûts et l'utilisation. Ces estimations ne tiennent pas compte de l'utilisation ou des frais réels. Les clients qui ont configuré leur rapport de coût et d'utilisation avec l'option « overwrite » ne nécessitent aucune action — leur rapport sera automatiquement mis à jour avec des données corrigées une fois le remblayage terminé. Les clients qui ont configuré leur rapport de coûts et d'utilisation avec l'option « Créer de nouvelles versions de rapport » conservent toutes les livraisons de rapports précédentes dans leur seau S3. La version du rapport fournie pendant la fenêtre touchée peut contenir des données inexactes. Une fois le remblayage des données terminé, une version corrigée du rapport sera livrée sous un nouvel AssemblyId. Les clients utilisant cette configuration doivent mettre à jour tous les processus en aval (tableaux Athena, pipelines Redshift, Amazon QuickSight ou ETL personnalisé) pour référencer le dernier assemblageId pour la période de facturation concernée, et peuvent supprimer ou archiver la version de rapport affectée pour empêcher le traitement des données statiques. Pour identifier le dernier rapport, les clients peuvent suivre les étapes de notre <a href="https://docs.aws.amazon.com/cur/latest/userguide/view-latest-cur.html">documentation</a>. Nous fournirons une autre mise à jour d'ici le 18 juillet, 1h00 HAP, ou plus tôt si des informations supplémentaires deviennent disponibles.

11. 18 juillet 2026 à 08:05 UTCresolved

    Nous continuons de faire des progrès substantiels en vue de résoudre la question qui touche les données estimatives sur les coûts et l'utilisation présentées dans la console de facturation et de gestion des coûts. Nos efforts d'atténuation fonctionnent comme prévu et nous constatons un nombre croissant de comptes reflétant des données exactes sur les coûts et l'utilisation. Nous nous attendons à ce que tous les comptes touchés soient entièrement recouvrés d'ici le 19 juillet, à 12 h 00 PDT. Jusqu'à ce que le remblayage soit terminé, certains clients peuvent encore observer des données incorrectes sur les coûts et l'utilisation dans la console de facturation et de gestion des coûts et les rapports sur les coûts et l'utilisation. Ces estimations ne tiennent pas compte de l'utilisation ou des frais réels. Nous fournirons une autre mise à jour d'ici le 18 juillet, 7h00 HAP, ou plus tôt si des informations supplémentaires deviennent disponibles.

12. 18 juillet 2026 à 13:57 UTCresolved

    Entre le 16 juillet à 19h38 PDT et le 18 juillet à 6h00 PDT, nous avons commencé à afficher des données de facturation incorrectes dans la console de facturation et de gestion des coûts, y compris le rapport sur les coûts et l'utilisation. Les clients peuvent avoir reçu des alertes de détection d'anomalies de budget et de coût erronés et avoir observé des estimations de coûts et d'utilisation gonflées. Le 16 juillet à 19h46 PDT, nos alarmes ont détecté des anomalies de coût mais n'ont pas arrêté le processus de production de factures estimé ou d'alerter nos équipes d'ingénierie. Nous avons été alertés de ce problème le 17 juillet à 12:19 PDT par les escalades de clients, et immédiatement commencé à enquêter. Nous avons d'abord informé nos clients via AWS Health le 17 juillet à 1:33 AM. À 8h24, nous avons mis en pause d'autres mises à jour des données de facturation estimatives et avons désactivé le budget et les alertes d'anomalies de coût comme mesure de précaution. Nous avons identifié la cause principale le 17 juillet à 12h00 PDT comme un changement de configuration dans notre système de calcul de factures. Ce système repose sur les données de conversion d'unités pour calculer les frais d'éléments de ligne. Le changement de configuration a fait échouer les mises à jour des données de conversion de l'unité, ce qui a entraîné des coûts de ligne gonflés, qui se sont propagés à la console de facturation et de gestion des coûts, ainsi que des alertes de budget et de coût. Nous avons atténué la question le 17 juillet à 12h30 PDT qui a corrigé la configuration de conversion des unités, et commencé à retraiter les données de coûts et d'utilisation pour tous les comptes clients. Nous avons commencé à observer la récupération à 16 h 19 PDT, et la majorité des comptes ont été entièrement recouvrés le 18 juillet à 6 h PDT. Il y a un petit nombre de comptes encore à traiter et nous afficherons les mises à jour de ces comptes sur le tableau de bord de la santé personnelle. Nous avons corrigé nos alarmes pour arrêter immédiatement le traitement et aviser nos équipes d'ingénierie en cas d'anomalies. Nous nous excusons de l'alarme que cet incident a causé à nos clients et nous effectuons une rétrospective approfondie pour empêcher que des événements comme celui-ci ne se reproduisent, ainsi que pour améliorer notre réponse lors des incidents de facturation. Le problème a été résolu et tous les services AWS fonctionnent maintenant normalement.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 16 juillet 2026 à 08:44 UTCresolved

   Nous enquêtons sur des erreurs 5xx accrues pour les clients Cloudfront utilisant la connectivité VPC Origins.

2. 16 juillet 2026 à 09:21 UTCresolved

   À partir de 12h45 PDT, nous constatons une augmentation des erreurs 5xx pour les clients CloudFront utilisant la connectivité VPC Origins. Nous avons confirmé que les clients utilisant d'autres types d'origine ne sont pas touchés par ce problème. Nos ingénieurs sont engagés et travaillent activement pour atténuer l'impact. Comme solution de rechange, les clients qui n'ont pas besoin de VPC Origins peuvent changer leur type d'origine pour résoudre les erreurs. Nous fournirons une autre mise à jour d'ici 3:15 AM PDT, ou plus tôt si plus d'information devient disponible.

3. 16 juillet 2026 à 10:18 UTCresolved

   Nous continuons à travailler pour résoudre les erreurs 5xx accrues pour les clients CloudFront en utilisant la connectivité VPC Origins. Les clients utilisant d'autres types d'origine ne sont pas touchés par cette question. Sur la base de notre enquête, nous croyons que la cause fondamentale est liée à un sous-système de traitement de paquets responsable du routage des demandes depuis les emplacements de bord de CloudFront vers les ressources des VPC clients. Nous continuons de recommander que les clients qui sont en mesure de le faire changent temporairement leur type d'origine pour résoudre les erreurs. Nous fournirons une autre mise à jour d'ici 4:15 AM PDT, ou plus tôt si des informations supplémentaires deviennent disponibles.

4. 16 juillet 2026 à 11:16 UTCresolved

   Nous continuons à travailler pour résoudre les erreurs 5xx accrues pour les clients CloudFront en utilisant la connectivité VPC Origins. Les clients utilisant d'autres types d'origine ne sont pas touchés par cette question. Nous avons élargi la portée du problème à la capacité de la table de routage au sein du sous-système de traitement des paquets responsable des demandes de routage des emplacements de bord de CloudFront vers les ressources des VPC clients. Nous avons identifié et nous testons actuellement une stratégie d'atténuation pour résoudre le problème. Une fois les essais terminés, nous déploierons l'atténuation par étapes. Sur la base des résultats de ces tests, nous fournirons un délai de résolution plus clair dans notre prochaine mise à jour. Nous continuons de recommander que les clients qui sont en mesure de le faire changent temporairement leur type d'origine pour résoudre les erreurs. Nous fournirons une autre mise à jour avant 5h15 PDT, ou plus tôt si des informations supplémentaires deviennent disponibles.

5. 16 juillet 2026 à 11:27 UTCresolved

   Nous voyons des signes initiaux de rétablissement et nous continuons de travailler à un rétablissement complet.

6. 16 juillet 2026 à 11:57 UTCresolved

   Nous continuons de constater d'importants signes de rétablissement grâce à nos efforts d'atténuation, et le rétablissement complet est attendu dans les 45 prochaines minutes.

7. 16 juillet 2026 à 12:21 UTCresolved

   Entre 12h45 et 16h18 PDT, nous avons constaté une augmentation des erreurs 5xx pour les clients CloudFront utilisant la connectivité VPC Origins. Nos ingénieurs ont été automatiquement engagés et ont immédiatement commencé à enquêter sur la cause profonde. En 2:57 AM PDT, nous avons identifié la cause profonde du problème comme une contrainte interne sur la flotte qui gère les connexions aux origines VPC privées. Lorsque cette contrainte a été atteinte, le système chargé de distribuer la configuration de routage à nos processeurs réseau n'a pas correctement chargé les données de configuration mises à jour, affectant le routage des connexions VPC Origin. À 3:52 AM PDT, nous avons pris plusieurs mesures d'atténuation qui ont conduit à un rétablissement complet à 4:18 AM PDT. Maintenant que le problème a été atténué, les clients qui ont temporairement changé leur type d'origine peuvent revenir en toute sécurité à ces changements. Les clients utilisant d'autres types d'origine n'ont pas été touchés par cette question. Le problème a été résolu et le service fonctionne normalement.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 15 juillet 2026 à 23:11 UTCresolved

   Nous étudions des problèmes de connectivité élevés avec une seule zone d'avalabilité (euc1-az2) dans la région EU-CENTRAL-1.

2. 15 juillet 2026 à 23:36 UTCresolved

   Nous assistons à des signes précoces de rétablissement et nous continuons de travailler à un règlement complet. Nous continuerons de fournir des mises à jour.

3. 16 juillet 2026 à 01:24 UTCresolved

   Entre 2:56 et 18:07 PM PDT, nous avons connu des problèmes de connectivité à un sous-ensemble d'instances EC2 dans une zone de disponibilité unique (euc1-az2) dans la région EU-CENTRAL-1. Au cours de cette période, les clients ont peut-être également connu des taux d'erreur et des latences accrus pour les lancements de nouvelles instances dans la zone touchée, ainsi que certaines API AWS qui utilisent les instances EC2 touchées. Certains services AWS ont également connu des problèmes de connectivité et des taux d'erreur accrus dans la zone touchée. Les ingénieurs ont été automatiquement engagés et ont immédiatement commencé à enquêter. Dans le cadre de nos efforts de rétablissement, nous avons déplacé le trafic de la zone de disponibilité touchée pour les services touchés à 15 h 04. À 15 h 05, nous avons identifié la cause profonde d'un changement récent de réseau qui a eu des répercussions. Les ingénieurs ont immédiatement repris ce changement qui s'est terminé à 16h28. Cela a permis de rétablir la connectivité du réseau à la zone touchée à 16 h 30. Nous avons continué à travailler jusqu'à ce que nous récupérions complètement les impacts à 18 h 07. Nous ne nous attendons pas à ce que cette question se reproduise. Le problème a été résolu et le service fonctionne normalement.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 6 juillet 2026 à 12:45 UTCresolved

   We are investigating increased error rates when calling EC2 Launch Template APIs in US-EAST-1 Region. During this time, affected customers may experience errors when creating, modifying, or referencing launch templates. Other AWS services that rely on launch templates may also be impacted. We will provide another update by 6:30 AM PDT or sooner, if we have additional information to share.

2. 6 juillet 2026 à 13:34 UTCresolved

   Starting at 2:56 AM PDT, we began experiencing increased error rates when calling EC2 Launch Template APIs in the US-EAST-1 Region. Our engineers have been engaged and are actively working to mitigate the impact. Additionally, Amazon Elastic Kubernetes (EKS) customers may experience errors when creating or updating clusters, or when launching and scaling nodes via Managed Node Groups, EKS Auto Mode, or Karpenter; this issue does not impact existing clusters and nodes. We have identified the root cause to be a congestion issue within an EC2 internal subsystem responsible for processing EC2 launch template workflows. We are pursuing multiple mitigation paths. We recommend that customers retry any failed requests during the impact window. While we do not currently have an ETA for full recovery, we are prioritizing this issue and will provide another update by 7:15 AM PDT or sooner if we have additional information to share.

3. 6 juillet 2026 à 14:12 UTCresolved

   We are seeing initial signs of recovery and continue to work toward full recovery.

4. 6 juillet 2026 à 14:53 UTCresolved

   Between 2:56 AM and 6:54 AM PDT, we experienced increased error rates when calling EC2 Launch Template APIs in the US-EAST-1 Region. During this time, affected customers may have experienced errors when creating, modifying, or describing Launch Templates. Other AWS services that rely on Launch Templates were also impacted. Amazon EC2 instances and Amazon EKS workloads already running on provisioned nodes continued to operate normally. Cluster modification operations, and Managed Node Group creation were also impacted. For EKS Auto Mode, impact was limited to operations requiring new capacity or changes, including node provisioning and pod scheduling. Our engineers were automatically engaged and immediately began investigating the root cause. We identified the root cause as a congestion issue within an EC2 internal subsystem responsible for processing EC2 launch template workflows. At 3:26 AM PDT, we took mitigation actions by introducing throttling for the affected APIs and we saw some recovery which was communicated directly with a subset of customers via the 'Your Account view' of the AWS Health Dashboard. We took multiple additional mitigation paths, incrementally lifting these throttle limits, and by 6:54 AM PDT, the issue was fully mitigated. We recommend that customers retry any failed requests. The issue has been resolved and all AWS services are now operating normally.

1. 30 juin 2026 à 21:02 UTCresolved

   We are investigating increased launch errors and API errors in the EU-NORTH-1 Region. Existing instances are not affected by this issue.

2. 30 juin 2026 à 21:21 UTCresolved

   We can confirm increased error rates for the EC2 APIs, as well as errors launching new EC2 instances in the EU-NORTH-1 Region. Other AWS Services that launch new instances or call the EC2 APIs as part of their workflows may also be affected by this issue. During this time, customers may receive an Internal Server Error in the Management Console and APIs. Engineers were automatically engaged and began investigating the issue. We are actively working on identifying the root cause. Existing instances are unaffected by this issue. We will provide an update by 3:15 PM, or sooner if we have additional information to share.

3. 30 juin 2026 à 21:29 UTCresolved

   We are seeing early signs of recovery and continue to work toward full recovery.

4. 30 juin 2026 à 21:53 UTCresolved

   Between 1:42 PM and 2:25 PM PDT we experienced increased error rates and latencies for EC2 APIs in the EU-NORTH-1 Region. This issue also affected new instance launches. Other AWS Services that launch new instances or call EC2 APIs as part of their workflows were also affected by this issue. Existing EC2 instances were unaffected by this issue. During this time, customers would have received an Internal Server Error in the Management Console and APIs. Engineers were automatically engaged and began investigating the root cause. We identified the root cause as a planned configuration change. This change was reverted and we began observing recovery at 2:19 PM. By 2:25 PM, the issue was fully mitigated. We do not expect this issue to reoccur. Since the issue was mitigated at 2:25 PM, we have been processing a backlog for ELB workflows and expect this backlog to complete within the next 30 minutes. We recommend customers retry requests that failed during this time. The issue has been resolved and all services are operating normally.

1. 13 juin 2026 à 01:26 UTCresolved

   To support compliance with the US Government export control directive, Anthropic has asked us to revoke access to Claude Fable 5 and Claude Mythos 5 for all users in all regions. All other models, including Opus 4.8, are not affected and you can continue using them in full confidence. Please view the <a href="https://www.anthropic.com/news/fable-mythos-access">Anthropic statement</a> for further details.

2. 15 juin 2026 à 18:13 UTCresolved

   Claude Fable 5 and Claude Mythos 5 models remain unavailable for all users in all regions. We are resolving this Health event. For further details please view the <a href="https://www.anthropic.com/news/fable-mythos-access">Anthropic statement</a>.

1. 6 juin 2026 à 04:24 UTCresolved

   Between 5:50 PM and 7:15 PM PDT, we experienced connectivity issues that may have impacted Internet performance for some customers in the SA-EAST-1 Region. During this time, connectivity to instances and services within the Region was not affected. Our engineering team was automatically engaged at 5:51 PM PDT and immediately began investigating the issue. We identified the root cause and implemented a fix, which mitigated the issue at 7:15 PM PDT. The issue has been resolved and the service is operating normally.

1. 22 mai 2026 à 23:38 UTCresolved

   We are investigating increased error rates for Route53 API calls.

2. 23 mai 2026 à 00:13 UTCresolved

   Between 4:00 PM and 4:46 PM, we experienced increased error rates for the Route53 APIs. This issue did not impact resolution of existing DNS records. Engineers were automatically engaged and immediately began investigating the issue. During this time, customers may have received 500s for Route53 APIs and the Route53 Management Console. We have identified the root cause and have mitigated this issue. Other AWS Services that call the Route53 APIs in their workflows may also have been impacted during this time. We recommend retrying any failed operations or stuck workflows. We do not expect this issue to reoccur. The issue has been resolved and the service is operating normally.

1. 8 mai 2026 à 00:25 UTCresolved

   We are investigating instance impairments in a single Availability Zone (use1-az4) in the US-EAST-1 Region. Other Availability Zones are not affected by the event and we are working to resolve the issue.

2. 8 mai 2026 à 00:53 UTCresolved

   We continue to investigate instance impairments to a single Availability Zone (use1-az4) in the US-EAST-1 Region. We have experienced an increase in temperatures within a single data center, which in some cases has caused impairments for instances in the Availability Zone. EC2 instances and EBS volumes hosted on impacted hardware are affected by the loss of power during the thermal event. Other AWS services that depend on the affected EC2 instances and EBS volumes in this Availability Zone, may also experience impairments. We will continue to provide updates as recovery continues.

3. 8 mai 2026 à 01:47 UTCresolved

   We continue to work towards mitigating the increased temperatures to its normal levels in the affected Availability Zone (use1-az4) in the US-EAST-1 Region. Other AWS services that depend on the affected EC2 instances and EBS volumes in this Availability Zone, may also experience impairments. We have weighed away traffic for most services at this time. We recommend customers utilize one of the other Availability Zones in the US-EAST-1 Region at this time, as existing instances in other AZ's remain unaffected by this issue. Customers may experience longer than usual provisioning times. We will provide an update by 7:45 PM PDT, or sooner if we have additional information to share.

4. 8 mai 2026 à 03:06 UTCresolved

   We are actively working to restore temperatures to normal levels in the affected Availability Zone (use1-az4) in the US-EAST-1 Region, though progress is slower than originally anticipated. Since our last update we have made incremental progress to restore cooling systems within the affected AZ, which will not be visible to external customers but are required for the restoration of affected services. In the impacted Availability Zone, EC2 Instances, EBS Volumes, and other AWS Services are also experiencing elevated error rates and latencies for some workflows. As part of our recovery effort, we have shifted traffic away from the impacted Availability Zone for most services. We recommend customers utilize one of the other Availability Zones in the US-EAST-1 Region, as existing instances in other AZs remain unaffected by this issue. If immediate recovery is required, we recommend customers restore from EBS Snapshots and/or replace affected resources by launching new replacement resources in one of the unaffected zones. We will provide an update by 10:00 PM PDT, or sooner if we have additional information to share.

5. 8 mai 2026 à 05:11 UTCresolved

   We are observing early signs of recovery. We continue to work towards restoring temperatures to normal levels and bring impacted racks back online in the affected Availability Zone (use1-az4) in the US-EAST-1 Region. We have been able to get additional cooling system capacity online, which has allowed us to recover some affected racks and are actively working to recover additional racks in a controlled and safe manner. In the impacted Availability Zone, EC2 Instances, EBS Volumes, and other AWS Services may continue to experience elevated error rates and latencies for some workflows until full recovery is achieved. We will provide an update by 11:30 PM PDT, or sooner if we have additional information to share.

6. 8 mai 2026 à 06:38 UTCresolved

   We continue to make progress in resolving the impaired EC2 instances in the affected Availability Zone (use1-az4) in the US-EAST-1 Region, and are working towards full recovery. We are actively working to bring additional cooling system capacity online, which will enable us to recover the remaining affected racks in a controlled and safe manner. In the impacted Availability Zone, EC2 Instances, EBS Volumes, and other AWS Services may continue to experience elevated error rates and latencies for some workflows. Customers will continue to see some of their affected EC2 instances and EBS volumes as impaired until we achieve full recovery. We will provide an update by May 8, 1:30 AM PDT, or sooner if we have additional information to share.

7. 8 mai 2026 à 08:32 UTCresolved

   Mitigation efforts remain underway to resolve the impaired EC2 instances and degraded EBS volumes in a single Availability Zone (use1-az4) in the US-EAST-1 Region. These EC2 instances and EBS volumes were impacted due to a loss of power during the thermal event. The work to bring additional cooling system capacity online, which will enable us to recover the remaining affected infrastructure in a controlled and safe manner, is taking longer than we had initially anticipated. Some services, such as IoT Core, ELB, NAT Gateway, and Redshift, have seen significant improvements in the recovery of their workflows. However, some customers will continue to see their affected EC2 instances and EBS volumes as impaired until we achieve full recovery. While we do not currently have an ETA for full recovery, we are prioritizing this issue and will provide another update by 3:30 AM PDT or sooner if additional information becomes available.

8. 8 mai 2026 à 10:54 UTCresolved

   We continue to make progress towards resolving the impaired EC2 instances and degraded EBS volumes in a single Availability Zone (use1-az4) in the US-EAST-1 Region. At this time, we wanted to provide some more details on the issue. Beginning on May 7 at 4:20 PM PDT, we began experiencing an increase in instance impairments within the affected zone due to the loss of power during a thermal event. Engineers were automatically engaged within minutes and immediately began investigating multiple mitigations. By 9:12 PM PDT, we restored power to a subset of the affected infrastructure and observed some signs of recovery, which have remained stable. We continue working to bring additional cooling system capacity online, which will enable us to recover the remaining affected hardware in the impacted zone in a controlled and safe manner. Some AWS services, such as IoT Core, ELB, NAT Gateway, and Redshift, continue to see significant improvements in the recovery of their workflows. However, some customers will continue to see their affected EC2 instances and EBS volumes as impaired until we achieve full recovery. If immediate recovery is required, we recommend customers restore from EBS snapshots and/or replace affected resources by launching new replacement resources in one of the unaffected zones. Based on our current mitigation efforts, we expect full recovery to take several hours. We are prioritizing this issue and will provide another update by 6:30 AM PDT or sooner if additional information becomes available.

9. 8 mai 2026 à 13:51 UTCresolved

   We continue working to resolve the impaired EC2 instances and degraded EBS volumes in a single Availability Zone (use1-az4) in the US-EAST-1 Region caused by a thermal event. During such an event, servers automatically shut down when the temperatures exceeded the operating thresholds in order to protect the hardware. We are actively working to bring additional cooling system capacity online, which will enable us to recover the remaining affected hardware in the impacted zone. Some customers will continue to see their affected EC2 instances and EBS volumes as impaired until we achieve full recovery. If immediate recovery is required, we recommend customers restore from EBS snapshots and/or replace affected resources by launching new replacement resources in one of the unaffected zones. In parallel, we are investigating increased error rates and query failures for Redshift clusters in the US-EAST-1 Region. During this time, affected customers may see errors for resume and restart workflows, as well as failover operations and availability issues. Our engineers are actively working to resolve this issue. Full recovery is still expected to take several hours. We are prioritizing this issue and will provide another update by 9:00 AM PDT or sooner if additional information becomes available.

10. 8 mai 2026 à 15:58 UTCresolved

    We continue our efforts to work towards the recovery of the impaired EC2 instances and degraded EBS volumes in a single Availability Zone (use1-az4) in the US-EAST-1 Region. We are making progress towards the restoration of the cooling system capacity that is required to recover the affected hardware in the impacted zone. Some customers will continue to see their affected EC2 instances and EBS volumes as impaired until the affected racks are recovered. We continue to recommend that customers who require immediate recovery restore from EBS snapshots and/or replace affected resources by launching new replacement resources in one of the unaffected zones. As part of our parallel investigation, we have identified the root cause of the increased error rates and query failures for Redshift clusters in the US-EAST-1 Region. This has been confirmed to be related to impact from an upstream dependency. Affected customers may continue to see errors for resume and restart workflows, failover operations, and impact to general availability. We are actively working to resolve the issue. Our timeline for full recovery is still expected to take several hours and will be incremental as we bring racks online in phases. We will provide an additional update by 12:30 PM or sooner if we have new information to provide.

11. 8 mai 2026 à 16:30 UTCresolved

    We have observed complete recovery of increased error rates and query failures for Redshift clusters in the US-EAST-1 Region. We were able to resolve the impact independently of the ongoing efforts to recover the affected hardware in the use1-az4 Availability Zone. The issue affecting Redshift has been resolved and the service is operating normally. We will provide an additional update regarding the efforts towards hardware restoration by 12:30 PM or sooner.

12. 8 mai 2026 à 18:12 UTCresolved

    We are experiencing an increase in timeouts to Amazon Managed Streaming for Apache Kafka partitions on a subset of clusters as a result of the ongoing issue in a single Availability Zone (use1-az4) in the US-EAST-1 Region. We are working in parallel to determine a path towards mitigation for affected clusters. We will provide an additional update by 12:30 PM or sooner.

13. 8 mai 2026 à 19:29 UTCresolved

    We continue to work towards the recovery of the impaired EC2 instances and degraded EBS volumes in a single Availability Zone (use1-az4) in the US-EAST-1 Region though efforts are slower than we had previously anticipated. We are taking measured steps to ensure that cooling capacity is brought online in a safe and controlled manner. As a result, EBS Volumes and EC2 instances affected by the issue will continue to experience impairments. We continue to recommend that customers who require immediate recovery restore from EBS snapshots and/or replace affected resourced by launching new replacement resources. Full recovery is still expected to take several hours. We will provide an additional update by 4:00 PM or sooner if we have new information to provide.

14. 8 mai 2026 à 23:00 UTCresolved

    We have begun to see improvements in the overall number of affected EC2 instances and degraded EBS volumes in a single Availability Zone (use1-az4) in the US-EAST-1 Region. The steps taken to supply additional cooling capacity have been showing steady signs of progress. Some EBS Volumes and EC2 instances affected by the issue will continue to experience impairments while we continue to drive these efforts. We continue to recommend that customers who require immediate recovery restore from EBS snapshots and/or replace affected resources by launching new replacement resources. In parallel, we have seen some improvements in Amazon Managed Streaming for Apache Kafka as a result of the parallel mitigation efforts being performed. We are still experiencing timeouts to partitions but are seeing continued progress. We do anticipate that recovery will still take several hours. We will provide an additional update by 7:30 PM or sooner if we have new information to provide.

15. 9 mai 2026 à 03:04 UTCresolved

    Starting May 7 4:20 PM PDT, we experienced increased impaired EC2 instances and degraded EBS volumes in a single facility (data center) within a single Availability Zone (use1-az4) in the US-EAST-1 Region. The issue was caused by a thermal event resulting in a loss of power. As part of our recovery effort, we shifted traffic away from the impacted Availability Zone for most services at May 7 5:06 PM. AWS services, like Elastic Load Balancing, Elastic Kubernetes Service, ElastiCache, Redshift, OpenSearch, Managed Streaming for Apache Kafka among others, that depend on the affected EC2 instances and EBS volumes in this Availability Zone, also experienced elevated error rates and latencies for some workflows and/or configurations. Our main effort during the event mitigation strategy was to bring back our cooling systems capacity. By May 8 1:50 PM, we were able to stabilize cooling system capacity to pre-event levels, which helped us to restore the majority of the impaired EC2 instances and EBS volumes. A small number of instances and EBS volumes remain impaired and we continue to work to recover all affected remaining resources. We will communicate with customers who are still impacted via the Your Account view of the AWS Health Dashboard. Customers that require further assistance with this event may contact AWS Support through the AWS Management Console or the AWS Support Center.

1. 27 avril 2026 à 11:27 UTCresolved

   We are investigating instance connectivity issues in a single Availability Zone (euw3-az2) in the EU-WEST-3 Region.

2. 27 avril 2026 à 12:05 UTCresolved

   Between 3:58 AM and 4:40 AM PDT, we experienced increased error rates and increased launch failures for EC2 instances in a single Availability Zone (euw3-az2) in the EU-WEST-3 Region. During this time, customers attempting to launch new EC2 instances in the affected Availability Zone would have experienced launch failures. Additionally, a subset of existing EC2 instances and EBS volumes in this Availability Zone were impacted and became unreachable. We have identified the root cause to be a loss of power to infrastructure within the affected Availability Zone. Engineers were engaged at 4:02 AM and immediately began working to restore power and assess the scope of impact. By 4:20 AM, power was successfully restored to the affected infrastructure. We then focused our efforts on recovering impacted EC2 instances and EBS volumes. By 4:40 AM, all impacted EC2 instances and EBS volumes had been fully recovered and were operating normally. No additional action is required for EC2 instances and EBS volumes that were impacted during the power loss event, as these have been fully recovered. While EC2 and EBS have recovered, some AWS services may take additional time to fully recover as they process backlogs and complete their own recovery procedures. The issue has been resolved and the service is operating normally.

1. 7 mars 2026 à 19:53 UTCresolved

   We are investigating increased error rates in the EU-CENTRAL-2 Region.

2. 7 mars 2026 à 20:17 UTCresolved

   We can confirm substantial error rates for PUT and GET requests to Amazon S3 in the EU-CENTRAL-2 Region. Engineers engaged immediately based on automated alarming. We have triangulated the issue to a subsystem responsible for assembling objects from bytes in storage. We have begun implementing mitigations, and are observing some improvement in error rates. We continue to work to identify the root cause, and are working on multiple parallel paths to fully mitigate the issue. Other AWS Services (such as EC2 launches) that rely on S3 are also affected by this issue. Existing EC2 instances are unaffected by this issue. We will provide another update by 12:45 PM PST, or sooner if we have additional information to share.

3. 7 mars 2026 à 20:28 UTCresolved

   We are seeing early signs of recovery and continue to monitor and work toward full recovery.

4. 7 mars 2026 à 21:04 UTCresolved

   Between 11:27 AM and 12:20 PM PST we experienced substantial error rates for S3 PUT/GET requests in EU-CENTRAL-2 Region. Engineers were engaged immediately based on automated alarming. We identified the root cause as an issue with a subsystem responsible for assembling objects bytes in storage. At 12:04 PM PST, we implemented mitigations and began observing early signs of recovery for S3. Error rates continued to improve, and other AWS Services continued to recover until 12:50 PM PST when we observed full recovery. We continue to work toward backfilling Cloudwatch logs, and expect that to continue over the next couple hours. We recommend customers retry any failed requests. The issue has been resolved and all services are operating normally.

1. 2 mars 2026 à 05:56 UTCresolved

   We are investigating increased API error rates in a single Availability Zone (mes1-az2) in the ME-SOUTH-1 Region.

2. 2 mars 2026 à 07:09 UTCresolved

   We are investigating connectivity and power issues affecting APIs and instances in a single Availability Zone (mes1-az2) in the ME-SOUTH-1 Region due to a localized power issue. Existing instances in this zone will also be affected. Other AWS Services may also be experiencing increased errors and latencies for their workflows, and we are working to route requests away from this affected Availability Zone. We recommend customers make use of other Availability Zones at this time. During this time, we are also experiencing delays in propagating DNS changes for Route53 to pops (Points of Presence) in ME-SOUTH-1.  Targeting new launches using RunInstances in the remaining AZs should succeed. Existing instances in the other AZs are not affected.

3. 2 mars 2026 à 09:03 UTCresolved

   We continue to work on a localized power issue affecting a single Availability Zone (mes1-az2) in the ME-SOUTH-1 Region. In the impacted Availability Zone, EC2 Instances, DB Instances, EBS Volumes, and other AWS Services are also experiencing elevated error rates and latencies for some workflows. As part of our recovery effort, we have shifted traffic away from the impacted Availability Zone for most services. We recommend customers utilize one of the other Availability Zones in the ME-SOUTH-1 Region, as existing instances in other AZs remain unaffected by this issue. We are actively working to restore power and connectivity, at which time we will begin recovering affected resources. Currently, we expect recovery to take many hours. We will provide an update by 2:30 AM PST, or sooner if we have additional information to share.

4. 2 mars 2026 à 10:41 UTCresolved

   We continue to work toward restoring power in the affected Availability Zone (mes1-az2) in the ME-SOUTH-1 Region. At this time, some AWS services have shifted traffic away from the affected Availability Zone and are seeing recovery for their affected operations and workflows. EC2 Instances, EBS Volumes, and other resources impacted in the affected Availability Zone will require a longer recovery timeline. Power has not yet been restored to the affected Availability Zone. If immediate recovery is required, we recommend customers restore from EBS Snapshots and/or launch replacement resources in one of the unaffected Availability Zones or an alternate Region. In parallel, we are actively working on reducing the error rates and latencies that some customers are experiencing with EC2 APIs. For now, we recommend continuing to retry any failed API requests. We will provide an update by 6:00 AM PST on March 2, or sooner if we have additional information to share.

5. 2 mars 2026 à 14:23 UTCresolved

   We continue to work toward restoring power in the impacted Availability Zone (mes1-az2) in the ME-SOUTH-1 Region. Meanwhile, EC2 instance and networking APIs have been restored for the other Availability Zones. Additionally, we have made improvements to the availability of RDS multi-AZ databases while operating with the impaired Availability Zone. These improvements will help customers create database exports to preserve data, and we recommend customers with databases in the affected Availability Zone consider creating exports as a precautionary measure. EC2 Instances, EBS Volumes, and other resources impacted in the affected Availability Zone will require a longer recovery timeline, as power has not yet been restored. We are expecting recovery to take at least a day, as it requires repair of facilities, cooling and power systems, coordination with local authorities, and careful assessment to ensure the safety of our operators. If immediate recovery is required, we recommend customers restore from EBS Snapshots and/or launch replacement resources in one of the unaffected Availability Zones or an alternate AWS Region. We will provide an update by 11:00 AM PST on March 2, or sooner if we have additional information to share.

6. 2 mars 2026 à 18:52 UTCresolved

   We continue to work towards restoring power in the affected Availability Zone (mes1-az2) in the ME-SOUTH-1 Region. We currently expect our recovery efforts to take at least a day. Our current guidance regarding immediate recovery remains unchanged from our previous update. Customers are able to disassociate Elastic IP addresses from resources in the affected Availability Zone and associate those with resources in the unaffected Availability Zones. This can be done by specifying --allow-reassociation when attempting to associate the Elastic IP to the new resource. We will provide you with further updates by 2:00 PM PST or sooner if new information becomes available.

7. 2 mars 2026 à 22:29 UTCresolved

   We continue to work towards restoring power in the affected Availability Zone (mes1-az2) in the ME-SOUTH-1 Region. We have no updated guidance on expected recovery times, and still expect this to take at least a day to fully restore power and connectivity. We continue to advise customers to launch replacement resources in one of the unaffected Availability Zones or an alternate AWS Region. At this time we recommend that customers that are capable of backing up data outside of the region consider doing so. You can view the current status of affected AWS services below. We will provide you with another update by 7:00 PM PST, or sooner if we have additional information to share.

8. 3 mars 2026 à 00:22 UTCresolved

   We are providing an update on the ongoing service disruptions affecting the AWS Middle East (UAE) Region (ME-CENTRAL-1) and the AWS Middle East (Bahrain) Region (ME-SOUTH-1). Due to the ongoing conflict in the Middle East, both affected regions have experienced physical impacts to infrastructure as a result of drone strikes. In the UAE, two of our facilities were directly struck, while in Bahrain, a drone strike in close proximity to one of our facilities caused physical impacts to our infrastructure. These strikes have caused structural damage, disrupted power delivery to our infrastructure, and in some cases required fire suppression activities that resulted in additional water damage. We are working closely with local authorities and prioritizing the safety of our personnel throughout our recovery efforts. In the ME-CENTRAL-1 (UAE) Region, two of our three Availability Zones (mec1-az2 and mec1-az3) remain significantly impaired. The third Availability Zone (mec1-az1) continues to operate normally, though some services have experienced indirect impact due to dependencies on the affected zones. In the ME-SOUTH-1 (Bahrain) Region, one facility has been impacted. Across both regions, customers are experiencing elevated error rates and degraded availability for services including Amazon EC2, Amazon S3, Amazon DynamoDB, AWS Lambda, Amazon Kinesis, Amazon CloudWatch, Amazon RDS, and the AWS Management Console and CLI. We are working to restore full service availability as quickly as possible, though we expect recovery to be prolonged given the nature of the physical damage involved. In parallel with efforts to restore the physical infrastructure at the affected sites, we are pursuing multiple software-based recovery paths that do not depend on the underlying facilities being fully brought back online. For Amazon S3 and Amazon DynamoDB, we are actively working to restore data access and service availability through software mitigations, including deploying updates to enable S3 to operate within the current infrastructure constraints and remediating impaired DynamoDB tables to restore read and write availability for dependent services. Our focus on restoring these foundational services is deliberate, as recovery of Amazon S3 and Amazon DynamoDB will in turn enable a broad range of dependent AWS services to recover. For other affected service APIs, we are deploying targeted software updates to reduce error rates and restore functionality where possible, independent of the physical recovery timeline. We are also working to restore access to the AWS Management Console and CLI through network-level changes that route traffic away from the affected infrastructure. While these software-based mitigations can address many of the service-level impacts, some recovery actions are constrained by the physical state of the affected facilities — meaning that full restoration of certain services will require the underlying infrastructure to be repaired and brought back online. Across all services, our teams are working in parallel on both the physical restoration of the affected facilities and these software-based mitigations, with the goal of restoring as much customer access as possible as quickly as possible, even ahead of full infrastructure recovery. In addition, we are prioritizing the restoration of services and tools that enable customers to back up and migrate their data and applications out of the affected regions. Finally, even as we work to restore these facilities, the ongoing conflict in the region means that the broader operating environment in the Middle East remains unpredictable. We recommend that customers with workloads running in the Middle East consider taking action now to backup data and potentially migrate your workloads to alternate AWS Regions. We recommend customers exercise their disaster recovery plans, recover from remote backups stored in other regions, and update their applications to direct traffic away from the affected regions. For customers requiring guidance on alternate regions, we recommend considering AWS Regions in the United States, Europe, or Asia Pacific, as appropriate for your latency and data residency requirements. We will continue to provide updates as recovery progresses and as the situation evolves. Our next update will be provided by 9:00 PM PST on March 2, 2026, or sooner if new information becomes available.

9. 3 mars 2026 à 06:27 UTCresolved

   We continue to work towards restoring power in the affected Availability Zone (mes1-az2) in the ME-SOUTH-1 Region. We have no updated guidance on expected recovery times, and still expect this to take at least a day to fully restore power and connectivity. AWS infrastructure is designed to be highly resilient, but given the uncertainty of the current situation, we encourage our customers to replicate Amazon S3 and critical data from the ME-SOUTH-1 Region to another AWS Region. For customers requiring guidance on alternate regions, we recommend considering AWS Regions in the United States, Europe, or Asia Pacific, as appropriate for your latency and data residency requirements. We will provide another update by March 3 at 3:00 AM PST, or sooner if new information becomes available. For more information on Cross-Region Replication, refer [1]. For more information on S3 Batch Replication, see [2]. For a simple script to quickly set up and start S3 Replication, see [3]. If you have questions or concerns, please contact AWS Support [4]. [1] <a href="https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html">https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html</a> [2] <a href="https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-batch-replication-batch.html">https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-batch-replication-batch.html</a> [3] <a href="https://github.com/awslabs/aws-support-tools/blob/master/S3/Setup_Replication/setup_replication.py">https://github.com/awslabs/aws-support-tools/blob/master/S3/Setup_Replication/setup_replication.py</a> [4] <a href="https://aws.amazon.com/support">https://aws.amazon.com/support</a>

10. 3 mars 2026 à 11:10 UTCresolved

    We continue to work toward restoring power in the affected Availability Zone (mes1-az2) in the ME-SOUTH-1 Region. The overall state of the region remains largely unchanged from our previous update. At this time, we have no updated guidance on expected timelines for fully restoring power and connectivity. We are taking all necessary steps to support the recovery process. While progress is being made, significant work remains before full restoration is complete. Given the ongoing uncertainty, we encourage customers to replicate their Amazon S3 data and other critical data from the ME-SOUTH-1 Region to another AWS Region, using the guidance provided in our previous update. We will continue to provide updates as recovery progresses and as the situation evolves. Our next update will be provided by 6:00 AM PST on March 3, or sooner if new information becomes available.

11. 3 mars 2026 à 14:02 UTCresolved

    Recovery efforts in the affected Availability Zone (mes1-az2) in the ME-SOUTH-1 Region are ongoing, with the situation remaining consistent with our last update. We have no change to expected timelines for fully restoring power and connectivity. While progress is being made, significant work remains before full restoration is complete. We continue to recommend customers launch replacement resources in one of the unaffected Availability Zones or an alternate AWS Region. Given the extended nature of this event, we continue to encourage customers to replicate Amazon S3 data and other critical workloads from ME-SOUTH-1 to another AWS Region using the guidance shared previously. We will provide our next update by 12:00 PM PST on March 3, or sooner if conditions change.

12. 3 mars 2026 à 16:40 UTCresolved

    We are providing an update on the ongoing service disruptions affecting the AWS Middle East (Bahrain) Region (ME-SOUTH-1). We continue to make progress on recovery efforts across multiple workstreams. With the immediate phase of this event now better understood, we are moving to a more targeted communication model. Going forward, updates will be delivered directly to affected customers through the AWS Personal Health Dashboard. Customers who require assistance with this event are encouraged to contact AWS Support through the AWS Management Console or the AWS Support Center. We continue to strongly recommend that customers with workloads running in the Middle East take action now to migrate those workloads to alternate AWS Regions. Customers should enact their disaster recovery plans, recover from remote backups stored in other Regions, and update their applications to direct traffic away from the affected Regions. For customers requiring guidance on alternate regions, we recommend considering AWS Regions in the United States, Europe, or Asia Pacific, as appropriate for your latency and data residency requirements.

13. 30 avril 2026 à 07:07 UTCinvestigating

    We are providing an update on the ongoing service disruption. The Middle East (Bahrain) Region (ME-SOUTH-1) has suffered damage due to the conflict in the Middle East and is currently unavailable. Customers should recover their resources in other Regions from remote backups. Relevant billing operations are currently suspended while we restore normal operations in this AWS Region. This process is expected to take several months.

14. 15 septembre 2026 à 10:22 UTCinvestigating

    We are providing an update on the disruption affecting the Middle East (Bahrain) (me-south-1) Region. The damage to our infrastructure spanned multiple Availability Zones and exceeded what our regional and multi-AZ services are designed to withstand. After a thorough assessment, we have determined that we are unable to restore access to the resources and data hosted exclusively in this Region. When the first Availability Zone was damaged in March, we began recommending that customers migrate their workloads to other Regions, and most did so before the Region became unavailable following the disruption of a second Availability Zone in April. Since then, we have supported the remaining customers in re-establishing their operations in alternate Regions, using backups where available or implementing alternative solutions to mitigate the impact of inaccessible data. In parallel, we assessed all affected infrastructure and exhausted every option for restoring data and resources that had not been migrated before the Region became unavailable. We remain committed to supporting our customers in Bahrain in the long term and will share a further update in early 2027. We have notified the relevant authorities and continue to work with them toward that goal.