Störungsverlauf von Amazon Web Services

1. 4. Oktober 2026 um 16:14 UTCresolved

   Wir untersuchen einen erhöhten Paketverlust in der EU-Süd-2-Region.

2. 4. Oktober 2026 um 16:36 UTCresolved

   Wir erleben einen erhöhten Paketverlust mit einer einzigen Availability Zone (eus2-az1) in der EU-Süd-2-Region. Dieses Problem führt auch zu erhöhten API-Latenzen und Fehlerraten für andere Workflows und AWS Services. Ingenieure wurden automatisch eingestellt und arbeiten daran, die Ursache zu identifizieren und das Problem zu mildern. Wir werden Ihnen ein weiteres Update bis 10:15 Uhr PDT oder früher zur Verfügung stellen, wenn neue Informationen verfügbar werden.

3. 4. Oktober 2026 um 17:06 UTCresolved

   Unsere Bemühungen, den erhöhten Paketverlust mit einer einzigen Availability Zone (eus2-az1) in der EU-Süd-2-Region zu mildern, sind noch im Gange. Wir sehen einige Anzeichen für Verbesserungen infolge mehrerer paralleler Bemühungen. Wir arbeiten weiter daran, die Ursache zu bestätigen und das Problem vollständig zu mildern. Obwohl wir derzeit keine Schätzung haben, wie lange unsere Aktionen dauern werden, werden wir Sie über unsere Fortschritte auf dem Laufenden halten und Ihnen bis 11:00 Uhr PDT oder früher, wenn neue Informationen verfügbar sind, ein weiteres Update zur Verfügung stellen.

4. 4. Oktober 2026 um 17:56 UTCresolved

   Wir haben die Ursache identifiziert und konzentrieren derzeit unsere Minderungsbemühungen auf die vollständige Genesung. Obwohl wir keine genaue Schätzung dafür haben, wie lange unsere aktuellen Bemühungen dauern werden, erwarten wir, dass sich unsere Bemühungen schrittweise verbessern werden. Wir werden Ihnen ein weiteres Update bis 11:45 Uhr PDT zur Verfügung stellen, oder früher, wenn neue Informationen verfügbar werden.

5. 4. Oktober 2026 um 18:45 UTCresolved

   Wir sehen erste Anzeichen einer Erholung. Wir werden Ihnen ein weiteres Update bis 12:00 Uhr PDT zur Verfügung stellen.

6. 4. Oktober 2026 um 18:56 UTCresolved

   Zwischen 8:48 Uhr und 11:28 Uhr PDT erlebten wir einen erhöhten Paketverlust innerhalb einer einzigen Availability Zone (eus2-az1) in der EU-Süd-2-Region. Dieses Problem führte zu erhöhten API-Latenzen und Fehlerraten für mehrere Workflows und AWS Services. Wir wurden automatisch um 8:54 Uhr auf das Problem aufmerksam gemacht und begannen sofort, die Ursache zu identifizieren, während wir mehrere parallele Pfade nahmen, um das Problem zu mildern. Bis 10:00 Uhr hatten unsere Minderungsbemühungen zu einigen Verbesserungen geführt. Bis 10:38 Uhr identifizierten wir die Ursache im Zusammenhang mit einer Netzwerkkonfigurationsänderung, so dass wir die Änderung rückgängig machen konnten, die bis 11:28 Uhr zu einer vollständigen Minderung führte. Das Problem wurde behoben und der Dienst funktioniert normal.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 21. September 2026 um 23:26 UTCresolved

   Wir untersuchen erhöhte API-Fehlerraten in der US-EAST-1-Region.

2. 21. September 2026 um 23:44 UTCresolved

   Wir können erhöhte Fehlerraten bei neuen Instanzstarts bestätigen, einschließlich erhöhter API-Fehlerraten für RunInstances, CreateFleet und verwandte EC2-Start-Workflows in der US-EAST-1-Region. Kunden, die versuchen, neue EC2-Instanzen zu starten, können Startfehler oder eine erhöhte API-Response-Latenz aufweisen. Unsere Ingenieure engagieren sich aktiv und arbeiten daran, das Problem zu beheben. Wir sehen erste Anzeichen einer Erholung. Bestehende Instanzen bleiben unberührt. Wir empfehlen, fehlgeschlagene RunInstances- und CreateFleet-API-Aufrufe erneut zu versuchen. Wir werden ein Update von 5:30 PM PDT oder früher zur Verfügung stellen.

3. 22. September 2026 um 00:24 UTCresolved

   Zwischen 15:49 Uhr und 17:06 Uhr PDT erlebten wir erhöhte Fehlerquoten bei neuen Instanzstarts in der US-EAST-1-Region. Während dieser Zeit konnten Kunden erhöhte Fehlerraten feststellen, wenn sie versuchten, neue EC2-Instanzen über RunInstances, CreateFleet und verwandte EC2-Start-Workflows zu starten. AWS-Dienste, die EC2-Instanzen im Auftrag von Kunden starten, darunter Amazon ECS, AWS Fargate, Amazon EMR, waren in diesem Zeitraum ebenfalls betroffen. Wir haben die Ursache als eine kürzlich erfolgte Bereitstellung in einem Subsystem innerhalb des EC2-Dienstes identifiziert, der für die Verarbeitung von Instanzstartanfragen verantwortlich ist. Wir initiierten ein Rollback des problematischen Einsatzes und begannen, erste Anzeichen einer Erholung um 16:44 Uhr zu beobachten. Bestehende Instanzen bleiben unberührt. Das Problem wurde behoben und der Dienst funktioniert normal.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 3. September 2026 um 21:49 UTCresolved

   Beginnend um 14:12 Uhr PDT, begannen wir mit erhöhten API-Fehlerraten für STS und Anmelden bei der Verwendung von SAML in der US-WEST-2-Region. Unser Ingenieurteam wurde automatisch um 14:19 Uhr eingestellt, um mit der Untersuchung der Ursache zu beginnen. Derzeit ist keine Arbeit verfügbar. Wir werden ein weiteres Update bis 15:30 Uhr PDT zur Verfügung stellen.

2. 3. September 2026 um 22:26 UTCresolved

   Wir sehen frühe Anzeichen einer Erholung und überwachen weiterhin die vollständige Erholung. Wir werden ein weiteres Update um 16:15 Uhr oder früher bereitstellen, wenn wir zusätzliche Informationen teilen möchten.

3. 3. September 2026 um 23:20 UTCresolved

   Wir sehen weiterhin eine stabile Erholung für die STS AssumeRoleWithSAML- und AssumeRoleWithWebIdentity-APIs in der US-WEST-2-Region. Die Fehlerquoten sind jetzt wieder auf dem Niveau vor dem Ereignis, und wir überwachen weiterhin aktiv, um die vollständige Wiederherstellung zu bestätigen. Wir werden ein weiteres Update bis 17:15 Uhr oder früher bereitstellen.

4. 4. September 2026 um 00:07 UTCresolved

   Zwischen 14:12 Uhr und 15:18 Uhr PDT verzeichneten wir erhöhte API-Fehlerraten bei den STS AssumeRoleWithSAML- und AssumeRoleWithWebIdentity-APIs in der US-WEST-2-Region. Es wurde festgestellt, dass die Ursache auf ein Problem mit einem STS-Subsystem zurückzuführen ist, das für die Kommunikation mit externen Identitätsanbietern verantwortlich ist. Auch andere AWS Services, die auf diese Identity Federation-Protokolle angewiesen sind, waren betroffen. Um 15:18 Uhr beobachteten wir Anzeichen einer Erholung und überwachten weiterhin, um Stabilität und vollständige Erholung zu gewährleisten. Das Problem ist behoben und der Dienst funktioniert zu diesem Zeitpunkt normal.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 21. August 2026 um 02:02 UTCresolved

   AP-NORTHEAST-1 リージリーーにににンにににににににムムににににににぱにぱぱぱぱぱぱぱぱぱぱぱぱぱぱぱぱぱすすすすすすすすすすすすすぱぱぱぱぱぱぱぱぱぱぱぱぱぱぱぱぱぱぱぱぱぱぱぱぱ� Wir erleben erhöhte Fehlerquoten bei Echtzeit-Metriken in der AP-NORTHEAST-1-Region. Kunden können fehlende oder verzögerte metrische Echtzeitdaten feststellen.

2. 21. August 2026 um 02:40 UTCresolved

   无しししししししし最新ししししししししししししししししししししししでででしでししだししししししだたしししただしただしただだムムムムムムムムムだムムムだムムだムムししにムム 10:13 Uhr に緩和策適用を開始し、�に影響でしたた。本事象は解決済みであでービは正常に稼働しています。| Zwischen 16:58 Uhr und 18:34 Uhr PDT erlebten wir erhöhte Verzögerungen bei Echtzeit-Metriken für Amazon Connect in der Region AP-NORTHEAST-1, was zu fehlenden oder veralteten Daten führte. Während dieser Zeit haben Kunden möglicherweise fehlende Daten in Analyseberichten und Probleme beim Zugriff auf Echtzeit-Metriken in Kontaktflüssen beobachtet, wie z. B. das Personal von Prüfagenten. Wir haben festgestellt, dass die Ursache ein Problem mit dem Subsystem ist, das für die metrische Ereignisbereitstellung verantwortlich ist. Wir begannen, die Abschwächungen um 6:13 Uhr anzuwenden und milderten das Problem um 6:34 Uhr. Das Problem wurde behoben und der Dienst funktioniert normal.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 19. August 2026 um 15:15 UTCresolved

   Wir untersuchen ein Problem, das sich auf die Einführung neuer EC2-Instanzen und Ressourcen in einer neu gestarteten Availability Zone (euw2-az4) in der EU-WEST-2-Region auswirkt. Während dieser Zeit können betroffene Kunden Probleme beim Erstellen oder Ändern von Ressourcen in der Region haben. Andere AWS-Dienste können ebenfalls betroffen sein. Für die sofortige Wiederherstellung empfehlen wir den Kunden, gegebenenfalls alternative Availability Zones (euw2-az1, euw2-az2 und euw2-az3) zu verwenden. Bestehende laufende Instanzen und Ressourcen sind nicht betroffen. Wir werden ein weiteres Update bis 10:00 Uhr PDT oder früher bereitstellen, wenn wir zusätzliche Informationen teilen müssen.

2. 19. August 2026 um 17:03 UTCresolved

   Am 18. August haben wir eine neue Availability Zone (euw2-az4) in der EU-WEST-2-Region eingeführt. Nach dem Start traten Fehler beim Starten von EC2-Instanzen in der neuen Availability Zone auf, wenn kein Standard-Subnetz vorhanden ist. Wir können bestätigen, dass bestehende laufende Instanzen und Ressourcen nicht betroffen sind. Workflows, die automatisch eine Liste der Verfügbarkeitszonen in der Region über die DescribeAvailabilityZones-API erhalten und dann versuchen, neue Instanzen zu starten oder Ressourcen in der neuen Verfügbarkeitszone zu erstellen, können auf Fehler stoßen. Für EC2-Instanz-Startfehler unternehmen wir Minderungsschritte, um automatisch Standard-Subnetze zu erstellen, wenn ein EC2-Instanz-Start auf die neue Availability Zone abzielt. Für Kunden und Workflows, die eine sofortige Behebung benötigen <a href="https://docs.aws.amazon.com/vpc/latest/userguide/work-with-default-vpc.html#create-default-subnet"> können Sie ein Standard-Subnetz</a> in der neuen Availability Zone erstellen. Dadurch können EC2-Instanzstarts erfolgreich abgeschlossen werden. Für andere Ressourcen wie Lambda-Funktionen, bei denen die neue Availability Zone derzeit nicht unterstützt wird, empfehlen wir Kunden, ihre Workflows zu aktualisieren, um die neu gestartete Availability Zone auszuschließen und die Ressourcenerstellung mit den anderen Availability Zones in der Region fortzusetzen. Obwohl wir keine genaue Schätzung haben, wie lange unsere Minderungsbemühungen dauern werden, werden wir Sie über unsere Fortschritte auf dem Laufenden halten und Ihnen bis 13:00 Uhr PDT oder früher, wenn neue Informationen verfügbar sind, ein weiteres Update zur Verfügung stellen.

3. 19. August 2026 um 18:47 UTCresolved

   Zwischen 18. August 17:00 Uhr und 19. August 11:00 Uhr PDT haben wir erhöhte Fehler beim Starten von EC2-Instanzen in einer neu gestarteten Availability Zone (euw2-az4) in der EU-WEST-2-Region festgestellt. Nach dem neuen Start der Availability Zone haben wir begonnen, Fehler bei der Verwendung eines Standard-VPC zu bemerken. Wir entdeckten die Ursache des Problems am 19. August um 9:00 Uhr und begannen mit der Bereitstellung einer Änderung, um das Problem um 9:30 Uhr zu beheben. Während die Änderung im Gange war, begannen wir, inkrementelle Verbesserungen in neuen Instanzstarts zu sehen, mit voller Erholung um 11:00 Uhr. Bestehende laufende Instanzen und Ressourcen waren nicht betroffen. Einige regionale Dienste, wie Lambda-Funktionen oder Aurora-Datenbanken, waren zum Start der neuen Availability Zone nicht verfügbar und die Serviceverfügbarkeit wird im Laufe der Zeit hinzugefügt. Kunden, die versuchen, Ressourcen zu erstellen, bevor die Dienste verfügbar sind, erhalten eine Meldung, dass sie in der Availability Zone nicht unterstützt werden. Das Problem wurde behoben und der Dienst funktioniert normal.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 15. August 2026 um 03:42 UTCresolved

   Wir untersuchen einen erhöhten Paketverlust, der sich auf die AWS Direct Connect-Konnektivität für einige Kunden in der EU-CENTRAL-1-Region auswirkt.

2. 15. August 2026 um 04:42 UTCresolved

   Wir können Paketverluste bei Direct Connect-Verbindungen in der EU-CENTRAL-1-Region bestätigen. Die Ingenieure wurden automatisch eingestellt und begannen sofort, sowohl die Ursache zu identifizieren als auch mehrere parallele Pfade zu identifizieren, um das Problem zu mildern. Zu diesem Zeitpunkt sehen wir frühe Anzeichen einer Erholung. Wir werden ein weiteres Update in 60 Minuten oder früher bereitstellen, wenn wir zusätzliche Informationen teilen müssen.

3. 15. August 2026 um 05:55 UTCresolved

   Ab 19:33 Uhr PDT erleben wir einen erhöhten Paketverlust, der sich auf die AWS Direct Connect-Konnektivität für einige Kunden in der EU-CENTRAL-1-Region auswirkt. Während wir Fortschritte gemacht haben, sind die Verbindungen zum folgenden Direct Connect-Standort immer noch beeinträchtigt: Equinix FR5, Frankfurt, DEU. Kunden, deren Redundanz mit ihren Direct Connect-Pfaden konfiguriert ist, sollten derzeit keine Auswirkungen beobachten. Kunden, die nur Verbindungen am Standort Equinix FR5, Frankfurt, DEU haben, werden weiterhin Probleme mit der Konnektivität haben. Wir arbeiten aktiv daran, die Auswirkungen zu mildern und auf eine vollständige Genesung hinzuarbeiten, erwarten jedoch, dass die vollständige Genesung mehrere Stunden entfernt ist. Wir werden ein Update in 90 Minuten oder früher bereitstellen, wenn wir zusätzliche Informationen teilen müssen.

4. 15. August 2026 um 07:24 UTCresolved

   Wir arbeiten aktiv daran, die Konnektivität über den Direct Connect-Standort Equinix FR5, Frankfurt, DEU wiederherzustellen. Kunden, die nur Verbindungen am Standort Equinix FR5, Frankfurt, DEU haben, werden weiterhin Probleme mit der Konnektivität haben. Für einen workaround werden kunden, die die option zum failover auf vpn haben, empfohlen, dies zu tun, um eine wiederherstellung zu erreichen. Für Kunden, die Direct Connect Gateway und Transit Gateway verwenden, empfehlen wir, ein AWS Site-to-Site VPN zu erstellen und es an Ihr Transit Gateway anzuhängen, siehe Schritte <a href="https://aws.amazon.com/premiumsupport/knowledge-center/dx-configure-dx-and-vpn-failover-tgw/">hier</a>. Für andere Kunden empfehlen wir die Einrichtung eines AWS Site-to-Site VPN als temporären Backup-Pfad, siehe Schritte <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html">hier</a>. Ab diesem Zeitpunkt erwarten wir, dass die Erholung mehrere Stunden entfernt ist. Wir werden ein weiteres Update in 90 Minuten oder früher bereitstellen, wenn wir zusätzliche Informationen teilen müssen.

5. 15. August 2026 um 09:08 UTCresolved

   Wir arbeiten weiter an der Wiederherstellung der Konnektivität für AWS Direct Connect-Verbindungen bei Equinix FR5, Frankfurt, DEU. Die Ursache hängt mit einem Problem der Anlageninfrastruktur am Standort zusammen, das sich auf die Netzwerkinfrastruktur auswirkt. Kunden mit Verbindungen ausschließlich an diesem Standort werden weiterhin einen Paketverlust oder eine Verschlechterung der Konnektivität erleben. Kunden mit mehreren Standorten oder redundanten Konfigurationen an anderen Standorten sind nicht betroffen. Für einen workaround werden betroffene kunden, die die option zum failover auf vpn haben, empfohlen, dies zu tun. Für Kunden, die Direct Connect Gateway und Transit Gateway verwenden, empfehlen wir, ein AWS Site-to-Site VPN zu erstellen und es an Ihr Transit Gateway anzuhängen, siehe Schritte <a href="https://aws.amazon.com/premiumsupport/knowledge-center/dx-configure-dx-and-vpn-failover-tgw/">hier</a>. Für andere Kunden empfehlen wir, ein AWS Site-to-Site VPN als temporären Backup-Pfad einzurichten, siehe Schritte <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html">hier</a>. Ab diesem Zeitpunkt erwarten wir, dass die Erholung mehrere Stunden entfernt ist. Wir werden innerhalb von 2 Stunden ein weiteres Update bereitstellen oder sobald wir weitere Informationen zu teilen haben.

6. 15. August 2026 um 11:10 UTCresolved

   Die AWS Direct Connect-Konnektivität bleibt für Kunden mit Verbindungen am Equinix FR5-Standort in Frankfurt, DEU, beeinträchtigt. Kunden mit mehreren Standorten oder redundanten Konfigurationen an anderen Standorten sind weiterhin nicht betroffen. Ingenieure arbeiten aktiv daran, die Konnektivität wiederherzustellen, wobei über mehrere Workstreams hinweg Anstrengungen unternommen werden, um das zugrunde liegende Facility-Problem zu lösen und die betroffenen Netzwerkgeräte wieder in Betrieb zu nehmen. Wir erwarten weiterhin, dass die Erholung mehrere Stunden entfernt ist. Für einen workaround werden betroffene kunden, die die möglichkeit haben, auf vpn zu scheitern, empfohlen, dies zu tun. Für Kunden, die Direct Connect Gateway und Transit Gateway verwenden, empfehlen wir, ein AWS Site-to-Site VPN zu erstellen und es an Ihr Transit Gateway anzuhängen, siehe Schritte <a href="https://aws.amazon.com/premiumsupport/knowledge-center/dx-configure-dx-and-vpn-failover-tgw/">hier</a>. Für andere Kunden empfehlen wir, ein AWS Site-to-Site VPN als temporären Backup-Pfad einzurichten, siehe Schritte <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html">hier</a>. Wir werden innerhalb von 2 Stunden ein weiteres Update bereitstellen oder sobald wir weitere Informationen zu teilen haben.

7. 15. August 2026 um 13:17 UTCresolved

   Ingenieure arbeiten weiter an der Wiederherstellung der Konnektivität am Equinix FR5-Standort in Frankfurt, DEU. Unser Co-Location-Partner arbeitet daran, das zugrunde liegende Infrastrukturproblem zu lösen, und obwohl die Verbesserungen noch nicht vom Kunden sichtbar sind, machen wir positive Fortschritte in Richtung Lösung. Für kunden, die eine sofortige genesung benötigen, empfehlen wir, das vpn nicht zu nutzen, wie in unseren vorherigen updates beschrieben. Wir werden ein weiteres Update bis 9:30 Uhr PDT oder früher bereitstellen, wenn wir zusätzliche Informationen teilen müssen.

8. 15. August 2026 um 16:27 UTCresolved

   Unser Co-Location-Partner arbeitet weiter an der Lösung des zugrunde liegenden Infrastrukturproblems am Equinix FR5-Standort in Frankfurt, DEU. Der Zugang zu dem betroffenen Bereich ist derzeit aufgrund von Sicherheitsbedenken eingeschränkt, was sich auf unsere Fähigkeit auswirkt, den physischen Zustand der Netzwerkausrüstung zu beurteilen und einen genaueren Wiederherstellungszeitpunkt bereitzustellen. Basierend auf aktuellen Informationen wird eine vollständige Erholung in naher Zukunft nicht erwartet und kann über den heutigen Tag hinausreichen. AWS Direct Connect-Verbindungen an diesem Standort bleiben beeinträchtigt. Kunden mit redundanten Verbindungen über andere Standorte bleiben davon unberührt. Für Kunden, die Direct Connect Gateway und Transit Gateway verwenden, empfehlen wir, ein AWS Site-to-Site VPN zu erstellen und es an Ihr Transit Gateway anzuhängen, siehe Schritte <a href="https://aws.amazon.com/premiumsupport/knowledge-center/dx-configure-dx-and-vpn-failover-tgw/">hier</a>. Für andere Kunden empfehlen wir, ein AWS Site-to-Site VPN als temporären Backup-Pfad einzurichten, siehe Schritte <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html">hier</a>. Wir werden ein weiteres Update bis 15:30 Uhr PDT oder früher bereitstellen, wenn wir zusätzliche Informationen teilen müssen.

9. 15. August 2026 um 22:26 UTCresolved

   Unser Co-Location-Partner arbeitet weiter daran, den sicheren Zugang zum betroffenen Gebiet am Equinix FR5-Standort in Frankfurt, DEU, wiederherzustellen. Sobald der sichere Zugang gesichert ist, können unsere Ingenieure die betroffenen Netzwerkgeräte beurteilen. Wir verfolgen den Fortschritt weiterhin genau und werden ein Update bis 21:30 Uhr PDT oder früher teilen, wenn neue Informationen verfügbar sind.

10. 16. August 2026 um 04:37 UTCresolved

    Wir arbeiten aktiv mit unserem Co-Location-Partner zusammen, um die Konnektivität am Equinix FR5-Standort in Frankfurt, DEU, wiederherzustellen. Seit unserem letzten Update haben wir schrittweise Fortschritte gemacht, um den sicheren Zugang zum betroffenen Gebiet am Standort Equinix FR5 in Frankfurt, DEU, wiederherzustellen. Parallel dazu haben wir die Reihenfolge priorisiert, in der kritische und hochpriorisierte Racks im Rahmen der Minderungsbemühungen wiederhergestellt werden. Basierend auf unserer aktuellen Einschätzung wird eine vollständige Erholung in naher Zukunft nicht erwartet und kann über den heutigen Tag hinausreichen. AWS Direct Connect-Verbindungen an diesem Standort bleiben beeinträchtigt. Kunden mit Verbindungen ausschließlich an diesem Standort werden weiterhin Paketverlust erleben. Kunden mit mehreren Standorten oder redundanten Konfigurationen an anderen Direct Connect-Standorten bleiben davon unberührt. Für einen workaround werden betroffene kunden, die die option zum failover auf vpn haben, empfohlen, dies zu tun. Für Kunden, die Direct Connect Gateway und Transit Gateway verwenden, empfehlen wir, ein AWS Site-to-Site VPN zu erstellen und es an Ihr Transit Gateway anzuhängen, siehe Schritte <a href="https://aws.amazon.com/premiumsupport/knowledge-center/dx-configure-dx-and-vpn-failover-tgw/">hier</a>. Für andere Kunden empfehlen wir, ein AWS Site-to-Site VPN als temporären Backup-Pfad einzurichten, siehe Schritte <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html">hier</a>. Wir verfolgen die Fortschritte weiterhin genau und werden ein Update bis zum 16. August 3:30 Uhr PDT oder früher teilen, wenn neue Informationen verfügbar werden.

11. 16. August 2026 um 10:25 UTCresolved

    Wir arbeiten weiterhin mit unserem Co-Location-Partner an der Wiederherstellung der Konnektivität am Equinix FR5-Standort in Frankfurt, DEU. Seit unserem letzten Update haben wir bedeutende Fortschritte bei der Wiederherstellung des sicheren Zugangs zu dem betroffenen Gebiet gemacht. Die elektrische Trennung ist jetzt im Gange, wobei unsere Teams vor Ort im elektrischen Raum die Entstromung der betroffenen Infrastruktur durchführen. Sobald die Isolierung verifiziert und als sicher bestätigt wurde, beginnen die Ingenieure mit einer physischen Inspektion der betroffenen Netzwerkausrüstung, um den Umfang des erforderlichen Ersatzes zu bestimmen. Basierend auf unserer aktuellen Einschätzung wird eine vollständige Wiederherstellung in naher Zukunft aufgrund des Umfangs des potenziellen Einflusses auf die Ausrüstung nicht erwartet. AWS Direct Connect-Verbindungen an diesem Standort bleiben beeinträchtigt. Kunden mit Verbindungen ausschließlich an diesem Standort werden weiterhin Paketverlust erleben. Kunden mit mehreren Standorten oder redundanten Konfigurationen an anderen Direct Connect-Standorten bleiben davon unberührt. Für einen workaround werden betroffene kunden, die die option zum failover auf vpn haben, empfohlen, dies zu tun. Für Kunden, die Direct Connect Gateway und Transit Gateway verwenden, empfehlen wir, ein AWS Site-to-Site VPN zu erstellen und es an Ihr Transit Gateway anzuhängen, siehe Schritte <a href="https://aws.amazon.com/premiumsupport/knowledge-center/dx-configure-dx-and-vpn-failover-tgw/">hier</a>. Für andere Kunden empfehlen wir, ein AWS Site-to-Site VPN als temporären Backup-Pfad einzurichten, siehe Schritte <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html">hier</a>. Wir verfolgen die Fortschritte weiterhin genau und werden ein Update bis zum 16. August 9:30 Uhr PDT oder früher teilen, wenn neue Informationen verfügbar werden.

12. 16. August 2026 um 16:30 UTCresolved

    Die elektrische Isolation bei Equinix FR5 in Frankfurt, DEU, ist nun abgeschlossen und unsere Ingenieure haben begonnen, die betroffenen Netzwerkgeräte physisch zu inspizieren. Wir haben noch keinen Zeitplan für eine vollständige Lösung, während wir weiterhin das Ausmaß der Auswirkungen auf die Ausrüstung bewerten. Direct Connect-Verbindungen an diesem Ort bleiben beeinträchtigt. Kunden mit Verbindungen ausschließlich an diesem Standort werden weiterhin Paketverlust erleben. Kunden mit mehreren Standorten oder redundanten Konfigurationen an anderen Direct Connect-Standorten sind nicht betroffen. Wir empfehlen, dass betroffen Kunden Failover zu VPN, bis wir mehr Klarheit über die nächsten Schritte und eine Wiederherstellung Timeline haben. Für Kunden, die Direct Connect Gateway und Transit Gateway verwenden, können Sie ein AWS Site-to-Site VPN erstellen und es an Ihr Transit Gateway anhängen, siehe Schritte <a href="https://aws.amazon.com/premiumsupport/knowledge-center/dx-configure-dx-and-vpn-failover-tgw/">hier</a>. Für andere Kunden empfehlen wir, ein AWS Site-to-Site VPN als temporären Backup-Pfad einzurichten, siehe Schritte <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html">hier</a>. Wir werden ein weiteres Update bis zum 16. August 5:30 Uhr PDT oder früher bereitstellen, wenn neue Informationen verfügbar sind.

13. 16. August 2026 um 22:51 UTCresolved

    Wir haben unsere Bewertung der betroffenen Netzwerkausrüstung am Equinix FR5-Standort in Frankfurt, DEU, abgeschlossen und haben nun ein klares Verständnis des Wirkungsbereichs. Wir machen Fortschritte bei der Wiederherstellung der Konnektivität und werden einen schrittweisen Ansatz zur Sanierung verfolgen. Kunden mit Verbindungen ausschließlich an diesem Standort werden weiterhin Paketverlust erleben, bis die Sanierung abgeschlossen ist. Kunden mit mehreren Standorten oder redundanten Konfigurationen an anderen Direct Connect-Standorten sind nicht betroffen. Wir werden ein weiteres Update bis zum 16. August 10:30 Uhr PDT oder früher bereitstellen, wenn neue Informationen verfügbar sind.

14. 17. August 2026 um 05:38 UTCresolved

    Wir machen weiterhin Fortschritte bei unserer schrittweisen Sanierung am Equinix FR5-Standort in Frankfurt, DEU. Seit unserem letzten Update wurde eine abhängige Netzwerkinfrastruktur wiederhergestellt. Die Sanierung der verbleibenden Infrastruktur ist im Gange, wobei ein Teil der Wiederherstellung von der Lieferung von Ersatzhardware abhängt. Die Kühlung wurde vollständig wiederhergestellt, wobei die Umweltbedingungen innerhalb der normalen Betriebsgrenzwerte stabil waren. Kunden mit Verbindungen ausschließlich an diesem Standort werden weiterhin Paketverlust erleben, wenn die Sanierung fortschreitet. Kunden mit mehreren Standorten oder redundanten Konfigurationen an anderen Direct Connect-Standorten sind nicht betroffen. Zuvor kommunizierte Minderungsleitlinien und Empfehlungen bleiben zu diesem Zeitpunkt unverändert. Wir werden ein weiteres Update bis zum 17. August 4:30 Uhr PDT oder früher zur Verfügung stellen, wenn die Sanierung fortschreitet.

15. 17. August 2026 um 11:22 UTCresolved

    Wir machen weiterhin Fortschritte bei unserer schrittweisen Sanierung am Equinix FR5-Standort in Frankfurt, DEU. Netzwerkinfrastruktur und abhängige Systeme verbessern sich weiter, da wir die betroffene Hardware wieder online bringen. Einige Ersatz-Hardware wurde geliefert und die Installation geht weiter, wenn die Komponenten vor Ort ankommen. Parallel dazu verschieben wir den Netzwerkverkehr, damit wiederhergestellte Geräte Kunden bedienen können, wenn sie online gehen. Während wir durch die Wiederherstellung voranschreiten, werden die Kunden die Wiederherstellung in zwei Phasen beobachten. In der ersten Phase werden BGP-Sitzungen wiederhergestellt, aber IP-Präfixe werden noch nicht angekündigt, was darauf hindeutet, dass die Wiederherstellung noch im Gange ist und die zugrunde liegende Infrastruktur noch nicht bereit ist, den Datenverkehr zu übertragen. In der zweiten Phase wird die IP-Präfix-Werbung fortgesetzt, wobei die Infrastruktur vollständig behoben und die Konnektivität wiederhergestellt wird. Obwohl wir derzeit keine ETA für die vollständige Wiederherstellung haben, arbeiten wir weiterhin so schnell und sicher wie möglich, um die Auswirkungen für die Kunden zu mildern. Wir werden ein weiteres Update bis zum 17. August 10:30 Uhr PDT oder früher zur Verfügung stellen, wenn die Sanierung fortschreitet.

16. 17. August 2026 um 16:25 UTCresolved

    Wir arbeiten weiterhin schrittweise an der schrittweisen Sanierung am Equinix FR5-Standort in Frankfurt, DEU. Wir sehen frühe Anzeichen einer Erholung, während wir das Problem weiterhin vollständig beheben. Wir arbeiten aktiv daran, die verbleibende betroffene Hardware wieder online zu bringen, und wir werden bis 12:30 Uhr PDT oder früher, wenn die Sanierung fortschreitet, ein weiteres Update bereitstellen.

17. 17. August 2026 um 17:59 UTCresolved

    Wir sehen breite Anzeichen einer Erholung am Standort Equinix FR5 in Frankfurt, DEU. Wir haben die Konnektivität für die meisten betroffenen Hardware wiederhergestellt und die meisten Verbindungen sind vollständig wiederhergestellt und stabil. Es gibt eine kleine Anzahl von Kunden, die betroffen bleiben, bis die verbleibenden Geräte vollständig wiederhergestellt sind. Wir werden ein weiteres Update bis 14:00 Uhr PDT oder früher zur Verfügung stellen, wenn die Sanierung fortschreitet.

18. 17. August 2026 um 21:00 UTCresolved

    Wir arbeiten weiter daran, betroffene Hardware wieder online zu bringen. Seit unserem letzten Update haben wir Fortschritte gemacht, die für die Kunden nicht sichtbar sind, aber für die Wiederherstellung erforderlich sind. Wir arbeiten parallel daran, alle Geräte so sicher wie möglich online zu bringen. Es wird erwartet, dass diese Arbeit mehrere Stunden dauern wird, bis sie abgeschlossen und validiert ist. Für kunden, die workarounds benötigen, empfehlen wir, dass sie erwägen, nicht auf vpn zu verzichten. Für Kunden, die Direct Connect Gateway und Transit Gateway verwenden, können Sie ein AWS Site-to-Site VPN erstellen und es an Ihr Transit Gateway anhängen, siehe Schritte <a href="https://aws.amazon.com/premiumsupport/knowledge-center/dx-configure-dx-and-vpn-failover-tgw/">hier</a>. Für andere Kunden empfehlen wir, ein AWS Site-to-Site VPN als temporären Backup-Pfad einzurichten, siehe Schritte <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html">hier</a>. Wir werden ein weiteres Update bis 19:00 Uhr PDT oder früher bereitstellen, wenn neue Informationen verfügbar sind.

19. 18. August 2026 um 01:50 UTCresolved

    Wir sehen eine signifikante Erholung für die meisten Kundenverbindungen in diesem Stadium. Obwohl wir noch nicht vollständig erholt sind, schreiten die Restaurierungsbemühungen wie erwartet am Equinix FR5-Standort in Frankfurt, DEU, voran. Die Sanierung der verbleibenden Infrastruktur beinhaltet den Abschluss von Hardware-Ersatz und die Validierung des Datenverkehrs, die beide aktiv im Gange sind. Wir erwarten eine weitere kundensichtbare Erholung, wenn die verbleibende Infrastruktur wieder in Betrieb genommen wird. Kunden mit Verbindungen ausschließlich an diesem Standort werden weiterhin Paketverlust erleben, bis die Sanierung abgeschlossen ist. Zuvor kommunizierte Minderungsleitlinien und Empfehlungen bleiben zu diesem Zeitpunkt unverändert. Wir werden ein weiteres Update bis zum 17. August 11:00 Uhr PDT oder früher zur Verfügung stellen.

20. 18. August 2026 um 04:01 UTCresolved

    Ab dem 14. August um 19:33 Uhr erlebten wir einen erhöhten Paketverlust durch die AWS Direct Connect-Konnektivität für Kunden mit Verbindungen am Equinix FR5-Standort in Frankfurt, DEU. Die Ingenieure wurden am 14. August um 19:45 Uhr automatisch eingestellt und begannen sofort mit der Untersuchung von Minderungsmaßnahmen. Bis 20:30 Uhr stellten wir fest, dass die Netzwerkausrüstung am FR5-Standort aufgrund des Wassereintritts in die Co-Location-Anlage beeinträchtigt war. Dadurch wurde das Kühlsystem beeinträchtigt, was zu einer Überhitzung und Abschaltung der Geräte führte. Wasser beeinflusste auch Stromverteilungssysteme, die den Strom für die Netzwerkgeräte deaktivierten. Die anfänglichen Wiederherstellungsbemühungen verzögerten sich, da die Umweltbedingungen in der Anlage eine Stabilisierung erforderten, bevor die Ingenieure sicher auf das betroffene Gebiet zugreifen konnten. Während des 15. und 16. August arbeiteten unsere Ingenieure in Abstimmung mit dem Anlagenbetreiber, um beeinträchtigte Netzwerkgeräte wiederherzustellen, während das zugrunde liegende Infrastrukturproblem behoben wurde. Am 17. August um 19:26 Uhr wurden alle beeinträchtigten Netzwerkgeräte erfolgreich wiederhergestellt und die Konnektivität zum Standort wurde mit nachhaltiger Wiederherstellung als voll funktionsfähig verifiziert. Wir erwarten nicht, dass sich dieses Problem wiederholt. Kunden mit redundanten Verbindungen an anderen Direct Connect-Standorten haben die Konnektivität über ihre alternativen Pfade während dieser Veranstaltung aufrechterhalten und erfordern keine weiteren Maßnahmen. Kunden, die vpn-failover als workaround implementiert haben, können jetzt sicher zu ihren primären direct connect-pfaden zurückkehren. Konnektivität wurde als stabil und voll funktionsfähig verifiziert. Kunden, die weitere Unterstützung benötigen, können den AWS Support über die AWS Management Console oder das <a href="https://console.aws.amazon.com/support">AWS Support Center</a> kontaktieren.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 31. Juli 2026 um 17:33 UTCresolved

   Wir können einen erhöhten Netzwerkpaketverlust bestätigen, der sich auf die AWS Direct Connect-Konnektivität in der Region AP-SOUTH-1 auswirkt. Unser Ingenieurteam wurde automatisch um 9:54 Uhr eingestellt, um mit der Untersuchung des Problems zu beginnen. Derzeit sind keine Workarounds verfügbar. Wir werden ein weiteres Update bis 11:30 Uhr PDT zur Verfügung stellen.

2. 31. Juli 2026 um 18:27 UTCresolved

   Wir haben die Ursache identifiziert, die mit einer Änderung eines Konfigurationssystems zusammenhängt, das für die Zuweisung von Routen zu den Geräten verantwortlich ist. Wir haben damit begonnen, den Paketverlust zu reduzieren, der sich auf AWS Direct Connect in der Region AP-SOUTH-1 auswirkt, und wir erwarten, dass die Wiederherstellung in den nächsten 30 Minuten schrittweise erfolgen wird. Wenn wir Vertrauen in diese Bemühungen gewinnen, werden wir versuchen, unsere Bemühungen zur Beschleunigung der Erholung zu parallelisieren. Wir werden ein weiteres Update bis 12:00 Uhr PDT zur Verfügung stellen.

3. 31. Juli 2026 um 18:54 UTCresolved

   Zwischen 9:42 Uhr und 11:44 Uhr PDT erlebten wir einen erhöhten Netzwerkpaketverlust, der sich auf die AWS Direct Connect-Konnektivität in der Region AP-SOUTH-1 auswirkte. Unser Ingenieurteam wurde automatisch um 9:46 Uhr eingestellt, um mit der Untersuchung zu beginnen. Um 10:51 Uhr verstanden wir, dass die Ursache eine Konfigurationsänderung ist, die an einem System vorgenommen wurde, das für die Zuweisung von Routen an Geräte verantwortlich ist. Als wir Vertrauen in unsere Minderungsschritte gewannen, parallelisierten wir unsere Bemühungen, den Paketverlust weiter zu reduzieren. Das Problem ist behoben und der Dienst funktioniert normal.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 24. Juli 2026 um 11:40 UTCresolved

   Wir untersuchen Konnektivitätsprobleme, die sich auf mehrere AWS-Dienste in der Region USA-WEST-2 auswirken.

2. 24. Juli 2026 um 11:56 UTCresolved

   Wir sehen erste Anzeichen einer Erholung und arbeiten weiter auf eine vollständige Erholung hin.

3. 24. Juli 2026 um 12:30 UTCresolved

   Wir sehen weiterhin erhebliche Anzeichen einer Erholung als Folge unserer Minderungsbemühungen für die Konnektivitätsprobleme, die mehrere AWS-Dienste in der Region USA-WEST-2 betreffen. Wir haben die Ursache als Problem mit einem Netzwerkgerät identifiziert, das für das Netzwerk-Routing von der Region zur Metro von Seattle verantwortlich ist. Ingenieure haben alle Minderungsarbeiten abgeschlossen. Da die Routen weiterhin wiederhergestellt werden, sollten die Kunden eine kontinuierliche Verringerung der Fehlerquoten und Timeouts bei der Verbindung zu den betroffenen Diensten sehen. Wir beobachten den Fortschritt der Wiederherstellung genau und werden weiterarbeiten, bis alle Routen vollständig wiederhergestellt sind und die Servicemetriken auf das Niveau vor dem Ereignis zurückkehren. Wir werden in den nächsten 30-45 Minuten ein weiteres Update bereitstellen.

4. 24. Juli 2026 um 13:01 UTCresolved

   Zwischen 3:55 Uhr und 4:15 Uhr PDT traten Konnektivitätsprobleme auf, die sich auf die Konnektivität in die US-WEST-2-Region auswirkten. Dies wirkte sich auf mehrere AWS-Dienste in der Region aus. Einige Kunden haben möglicherweise auch Probleme beim Zugriff auf die AWS-Verwaltungskonsole mit Verbindungszeiten und nicht reagierenden Seiten. Die Konnektivität innerhalb der Region war nicht betroffen. Unsere Ingenieure wurden automatisch um 4:01 Uhr PDT eingestellt und begannen sofort, dieses Problem zu untersuchen. Wir identifizierten die Ursache als ein Problem mit Netzwerkgeräten, die für das Netzwerk-Routing von der Region zur Metro von Seattle verantwortlich sind, und begannen parallel auf mehreren Pfaden zu arbeiten, um die Auswirkungen zu mildern. Wir haben Minderungsmaßnahmen ergriffen, die zu einer anfänglichen Erholung um 4:15 Uhr PDT führten. Da sich das Netzwerk nach unseren Minderungsmaßnahmen weiter stabilisierte, trat zwischen 4:47 Uhr und 4:59 Uhr ein kurzes Rekonvergenzereignis auf. Während dieser Rekonvergenzperiode hatten einige Kunden möglicherweise Probleme mit der Anbindung an die Region, da die Netzstrecken wiederhergestellt wurden. Bis 4:59 Uhr PDT waren alle Routen vollständig wiederhergestellt und die Servicemetriken auf das Niveau vor dem Event zurückgekehrt. Kunden, die AWS Direct Connect über EqSe2, Westin Building Exchange, Seattle, nutzten, erlebten ein erweitertes Aufprallfenster von 3:55 Uhr auf 5:12 Uhr PDT. Diese Kunden hätten Verbindungsprobleme gehabt, bis die Netzwerkrouten für diesen spezifischen Pfad um 5:12 Uhr PDT vollständig wiederhergestellt waren. Kunden, die redundant über andere AWS Direct Connect-Standorte verbunden waren, waren von diesem Ereignis nicht betroffen. Das Problem wurde behoben und alle AWS-Dienste funktionieren normal.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 17. Juli 2026 um 08:33 UTCresolved

   Wir untersuchen Probleme mit Cost Explorer, die ungenaue geschätzte Abrechnungsdaten widerspiegeln.

2. 17. Juli 2026 um 09:07 UTCresolved

   Ab dem 16. Juli 19:38 Uhr PDT begannen wir, falsche geschätzte Abrechnungsdaten in der Abrechnungs- und Kostenmanagement-Konsole anzuzeigen. Unsere Ingenieurteams sind engagiert und untersuchen die Ursachen. Wir werden ein weiteres Update bis 3:00 Uhr PDT oder früher bereitstellen, wenn weitere Informationen verfügbar sind.

3. 17. Juli 2026 um 10:03 UTCresolved

   Wir arbeiten weiterhin daran, das Problem zu beheben, das sich auf die geschätzten Kosten- und Nutzungsdaten auswirkt, die in der Abrechnungs- und Kostenmanagement-Konsole angezeigt werden. Wir haben die Ursache als ein Problem mit der Stückpreisgestaltung innerhalb des geschätzten Abrechnungsberechnungs-Subsystems identifiziert und arbeiten an einer Minderung. Die angezeigten Abrechnungsschätzungen spiegeln nicht die tatsächliche Nutzung und Gebühren wider. Derzeit sind keine Kundenaktionen erforderlich. Sobald das Problem behoben ist, erwarten wir, dass die vollständige Lösung mehrere Stunden in Anspruch nimmt, während wir die geschätzten Abrechnungsdaten neu berechnen. Wir werden ein weiteres Update bis 4:00 Uhr PDT oder früher bereitstellen, wenn weitere Informationen verfügbar sind.

4. 17. Juli 2026 um 10:52 UTCresolved

   Wir arbeiten weiterhin daran, das Problem zu beheben, das sich auf die geschätzten Kosten- und Nutzungsdaten auswirkt, die in der Abrechnungs- und Kostenmanagement-Konsole angezeigt werden. Wie bereits erwähnt, haben wir die Ursache als Problem mit der Stückpreisgestaltung innerhalb des Subsystems für die Berechnung der geschätzten Abrechnung identifiziert. Um zu verhindern, dass weitere ungenaue Abrechnungsschätzungen angezeigt werden, haben wir die Berechnung der geschätzten Abrechnung angehalten. Kunden, die derzeit normale Rechnungsschätzungen sehen, werden diese Schätzungen weiterhin sehen, und Kunden, die überhöhte Schätzungen sehen, werden sie nicht weiter steigen sehen, während wir auf eine Lösung hinarbeiten. Die angezeigten Abrechnungsschätzungen spiegeln nicht die tatsächliche Nutzung und Gebühren wider. Wir arbeiten weiter daran, das Problem vollständig zu mildern. Sobald das Problem behoben ist, erwarten wir, dass die vollständige Lösung mehrere Stunden in Anspruch nimmt, während wir die geschätzten Abrechnungsdaten neu berechnen. Derzeit sind keine Kundenaktionen erforderlich. Wir werden ein weiteres Update bis 5:00 Uhr PDT oder früher bereitstellen, wenn weitere Informationen verfügbar sind.

5. 17. Juli 2026 um 11:58 UTCresolved

   Wir arbeiten weiterhin daran, das Problem zu beheben, das sich auf die geschätzten Kosten- und Nutzungsdaten auswirkt, die in der Abrechnungs- und Kostenmanagement-Konsole angezeigt werden. Wir arbeiten aktiv an mehreren Minderungspfaden parallel. Der erste Weg beinhaltet die Rückkehr zur letzten bekannten Gutschätzungsrechnung. Mit diesem Ansatz werden Kunden nur Kosten- und Nutzungsdaten bis zum 15. Juli sehen, jedoch werden die überhöhten Kostendaten entfernt. Der zweite Weg beinhaltet das Zurückrollen einer kürzlichen Änderung des Abrechnungsberechnungs-Subsystems. Die angezeigten Abrechnungsschätzungen spiegeln nicht die tatsächliche Nutzung und Gebühren wider. Derzeit sind keine Kundenaktionen erforderlich. Sobald das Problem behoben ist, erwarten wir, dass die vollständige Lösung mehrere Stunden in Anspruch nimmt, während wir die geschätzten Abrechnungsdaten neu berechnen. Wir werden ein weiteres Update bis 6:00 Uhr PDT oder früher bereitstellen, wenn weitere Informationen verfügbar sind.

6. 17. Juli 2026 um 12:54 UTCresolved

   Wir arbeiten weiterhin parallel an mehreren Minderungspfaden, um das Problem zu beheben, das sich auf die in der Abrechnungs- und Kostenmanagement-Konsole angezeigten Kosten- und Nutzungsdaten auswirkt, einschließlich des Kosten- und Nutzungsberichts. Wir bewerten die Wiederaufnahme der geschätzten Abrechnungsberechnungen, da unsere interne Überwachung darauf hinweist, dass das Abrechnungsberechnungs-Subsystem jetzt genaue Schätzungen erstellt. Wir führen eine zusätzliche Validierung durch, bevor wir mit diesem Weg fortfahren. Die angezeigten Abrechnungsschätzungen spiegeln nicht die tatsächliche Nutzung und Gebühren wider. Derzeit sind keine Kundenaktionen erforderlich. Wir werden ein weiteres Update bis 8:00 Uhr PDT oder früher bereitstellen, wenn weitere Informationen verfügbar sind.

7. 17. Juli 2026 um 14:53 UTCresolved

   Wir arbeiten weiterhin daran, das Problem zu beheben, das sich auf die geschätzten Kosten- und Nutzungsdaten auswirkt, die in der Abrechnungs- und Kostenmanagement-Konsole angezeigt werden, einschließlich des Kosten- und Nutzungsberichts. Das Rollback einer kürzlichen Änderung hat das Problem nicht gelöst, und wir untersuchen weiterhin mehrere Minderungspfade. Geschätzte Rechnung Updates bleiben pausiert. Wir sind dabei, zu den letzten genauen geschätzten Abrechnungsdaten zurückzukehren. Die angezeigten Abrechnungsschätzungen spiegeln nicht die tatsächliche Nutzung und Gebühren wider. Derzeit sind keine Kundenaktionen erforderlich. Wir erwarten, dass diese Abschwächung mehrere Stunden dauern wird, während wir die geschätzten Abrechnungsdaten neu berechnen. Wir werden ein weiteres Update bis 10:00 Uhr PDT oder früher bereitstellen, wenn weitere Informationen verfügbar sind.

8. 17. Juli 2026 um 16:59 UTCresolved

   Wir haben die Ursache identifiziert und das zugrunde liegende Problem gemildert, das dazu führt, dass in der Abrechnungs- und Kostenmanagement-Konsole sowie in den Kosten- und Nutzungsberichten falsche Kosten- und Nutzungsdaten angezeigt werden. Wir haben mit dem Ausfüllen von Daten begonnen, um Kostendaten für alle Kunden zu korrigieren. Wir erwarten, dass einige Kunden innerhalb der nächsten drei Stunden eine Erholung und alle Kunden bis zum 18. Juli 12:00 Uhr PDT eine vollständige Erholung sehen werden. Bis die Auffüllung abgeschlossen ist, können einige Kunden immer noch falsche Kosten- und Nutzungsdaten sehen. Die angezeigten Abrechnungsschätzungen spiegeln nicht die tatsächliche Nutzung und Gebühren wider. Derzeit sind keine Kundenaktionen erforderlich. Wir werden ein weiteres Update bis 13:00 Uhr oder früher bereitstellen, wenn Informationen verfügbar sind.

9. 17. Juli 2026 um 19:56 UTCresolved

   Unsere Bemühungen, korrigierte Kosten- und Nutzungsdaten aufzufüllen, sind noch im Gange. Wir kommen langsamer voran als erwartet. Während wir sehen, dass sich einige Konten mit korrekten Kosten- und Nutzungsdaten erholen, erwarten wir, dass alle betroffenen Konten bis zum 19. Juli 12:00 Uhr PDT wiederhergestellt werden. Bis die Auffüllung abgeschlossen ist, können einige Kunden immer noch falsche Kosten- und Nutzungsdaten sehen. Die angezeigten Abrechnungsschätzungen spiegeln nicht die tatsächliche Nutzung und Gebühren wider. Derzeit sind keine Kundenaktionen erforderlich. Wir werden ein weiteres Update bis 19:00 Uhr oder früher bereitstellen, wenn Informationen verfügbar sind.

10. 18. Juli 2026 um 01:38 UTCresolved

    Wir machen weiterhin stetige Fortschritte bei der Behebung des Problems, das sich auf die in der Abrechnungs- und Kostenmanagement-Konsole angezeigten geschätzten Kosten- und Nutzungsdaten auswirkt. Unsere Bemühungen, korrigierte Daten aufzufüllen, sind weiterhin im Gange, und wir erwarten, dass alle betroffenen Konten bis zum 19. Juli, 12:00 Uhr PDT, vollständig wiederhergestellt werden. Bis zum Abschluss der Nachfüllung können einige Kunden immer noch falsche Kosten- und Nutzungsdaten in der Abrechnungs- und Kostenmanagement-Konsole sowie in den Kosten- und Nutzungsberichten feststellen. Diese Schätzungen spiegeln nicht die tatsächliche Nutzung oder Gebühren wider. Kunden, die ihren Kosten- und Nutzungsbericht mit der Option "Überschreiben" konfiguriert haben, benötigen keine Maßnahmen - ihr Bericht wird automatisch mit korrigierten Daten aktualisiert, sobald die Auffüllung abgeschlossen ist. Kunden, die ihren Kosten- und Nutzungsbericht mit der Option "Neue Berichtsversionen erstellen" konfiguriert haben, behalten alle vorherigen Berichtslieferungen in ihrem S3-Bucket. Die Berichtsversion, die während des betroffenen Fensters geliefert wird, kann ungenaue Daten enthalten. Sobald die Datenauffüllung abgeschlossen ist, wird eine korrigierte Berichtsversion unter einer neuen AssemblyId geliefert. Kunden, die diese Konfiguration verwenden, sollten alle nachgelagerten Prozesse (Athena-Tabellen, Redshift-Pipelines, Amazon QuickSight oder benutzerdefiniertes ETL) aktualisieren, um auf die neueste AssemblyId für den betroffenen Abrechnungszeitraum zu verweisen, und können die betroffene Berichtsversion löschen oder archivieren, um die Verarbeitung veralteter Daten zu verhindern. Um den aktuellen Bericht zu identifizieren, können Kunden die Schritte in unserer <a href="https://docs.aws.amazon.com/cur/latest/userguide/view-latest-cur.html">Dokumentation</a> befolgen. Wir werden ein weiteres Update bis zum 18. Juli, 1:00 Uhr PDT oder früher bereitstellen, wenn zusätzliche Informationen verfügbar sind.

11. 18. Juli 2026 um 08:05 UTCresolved

    Wir machen weiterhin erhebliche Fortschritte bei der Behebung des Problems, das sich auf die in der Abrechnungs- und Kostenmanagement-Konsole angezeigten geschätzten Kosten- und Nutzungsdaten auswirkt. Unsere Minderungsbemühungen funktionieren wie erwartet und wir sehen eine zunehmende Anzahl von Konten, die korrekte Kosten- und Nutzungsdaten widerspiegeln. Wir erwarten, dass alle betroffenen Konten bis zum 19. Juli, 12:00 Uhr PDT, vollständig wiederhergestellt sind. Bis zum Abschluss der Nachfüllung können einige Kunden immer noch falsche Kosten- und Nutzungsdaten in der Abrechnungs- und Kostenmanagement-Konsole sowie in den Kosten- und Nutzungsberichten feststellen. Diese Schätzungen spiegeln nicht die tatsächliche Nutzung oder Gebühren wider. Wir werden ein weiteres Update bis zum 18. Juli, 7:00 Uhr PDT oder früher bereitstellen, wenn zusätzliche Informationen verfügbar sind.

12. 18. Juli 2026 um 13:57 UTCresolved

    Zwischen dem 16. Juli um 19:38 Uhr PDT und dem 18. Juli um 6:00 Uhr PDT begannen wir, falsche geschätzte Abrechnungsdaten in der Abrechnungs- und Kostenmanagement-Konsole anzuzeigen, einschließlich des Kosten- und Nutzungsberichts. Kunden haben möglicherweise fehlerhafte Warnmeldungen zu Budget- und Kostenanomalien erhalten und überhöhte Kosten- und Nutzungsdaten beobachtet. Am 16. Juli um 19:46 Uhr PDT erkannten unsere Alarme Kostenanomalien, konnten aber den geschätzten Rechnungserzeugungsprozess nicht stoppen oder unsere Ingenieurteams alarmieren. Wir wurden am 17. Juli um 12:19 Uhr PDT durch Kundeneskalationen auf dieses Problem aufmerksam gemacht und begannen sofort mit der Untersuchung. Wir informierten Kunden zuerst über AWS Health am 17. Juli um 1:33 Uhr. Um 8:24 Uhr PDT unterbrachen wir weitere Aktualisierungen der geschätzten Abrechnungsdaten und schalteten Budget- und Kostenanomalien als Vorsichtsmaßnahme aus. Wir haben die Ursache am 17. Juli um 12:00 Uhr PDT als Konfigurationsänderung in unserem Rechnungsberechnungssystem identifiziert. Dieses System stützt sich auf Einheitenumrechnungsdaten zur Berechnung der Gebühren für Streckenpositionen. Die Konfigurationsänderung führte dazu, dass Updates der Einheitenkonvertierungsdaten fehlschlugen, was zu überhöhten Kosten für Linienelemente führte, die an die Abrechnungs- und Kostenmanagementkonsole weitergeleitet und Budget- und Kostenanomalien ausgelöst wurden. Wir haben das Problem am 17. Juli um 12:30 Uhr PDT gemildert, was die Gerätekonvertierungskonfiguration korrigierte und mit der Wiederaufbereitung von Kosten- und Nutzungsdaten für alle Kundenkonten begann. Wir begannen, die Erholung um 4:19 Uhr PDT zu beobachten, und die meisten Konten wurden bis zum 18. Juli um 6:00 Uhr PDT vollständig wiederhergestellt. Es gibt eine kleine Anzahl von Konten, die noch verarbeitet werden, und wir werden Updates für diese Konten auf dem Personal Health Dashboard veröffentlichen. Wir haben unsere Alarme korrigiert, um die Verarbeitung sofort einzustellen und unsere Engineering-Teams zu benachrichtigen, wenn Anomalien auftreten. Wir entschuldigen uns für den alarm, den dieser vorfall unseren kunden verursacht hat, und führen eine gründliche retrospektive durch, um zu verhindern, dass sich solche ereignisse wiederholen, und verbessern unsere reaktion bei abrechnungsvorfällen. Das Problem wurde behoben und alle AWS-Dienste funktionieren jetzt normal.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 16. Juli 2026 um 08:44 UTCresolved

   Wir untersuchen erhöhte 5xx-Fehler für Cloudfront-Kunden, die VPC Origins-Konnektivität verwenden.

2. 16. Juli 2026 um 09:21 UTCresolved

   Ab 12:45 Uhr PDT erleben wir erhöhte 5xx-Fehler für CloudFront-Kunden, die VPC Origins-Konnektivität verwenden. Wir haben bestätigt, dass Kunden, die andere Ursprungstypen verwenden, von diesem Problem nicht betroffen sind. Unsere Ingenieure sind engagiert und arbeiten aktiv daran, die Auswirkungen zu verringern. Als Workaround können Kunden, die keine VPC Origins benötigen, ihren Ursprungstyp ändern, um die Fehler zu beheben. Wir werden ein weiteres Update bis 3:15 Uhr PDT oder früher bereitstellen, wenn weitere Informationen verfügbar sind.

3. 16. Juli 2026 um 10:18 UTCresolved

   Wir arbeiten weiter daran, die erhöhten 5xx-Fehler für CloudFront-Kunden mit VPC Origins-Konnektivität zu beheben. Kunden, die andere Ursprungstypen verwenden, bleiben von diesem Problem unberührt. Basierend auf unserer Untersuchung glauben wir, dass die Ursache mit einem Paketverarbeitungs-Subsystem zusammenhängt, das für das Routing von Anfragen von CloudFronts Edge-Standorten an Ressourcen innerhalb von Kunden-VPCs verantwortlich ist. Wir empfehlen weiterhin, dass Kunden, die dazu in der Lage sind, ihren Herkunftstyp vorübergehend ändern, um die Fehler zu beheben. Wir werden ein weiteres Update bis 4:15 Uhr PDT oder früher bereitstellen, wenn zusätzliche Informationen verfügbar sind.

4. 16. Juli 2026 um 11:16 UTCresolved

   Wir arbeiten weiter daran, die erhöhten 5xx-Fehler für CloudFront-Kunden mit VPC Origins-Konnektivität zu beheben. Kunden, die andere Ursprungstypen verwenden, bleiben von diesem Problem unberührt. Wir haben das Problem weiter auf die Routing-Tabellenkapazität innerhalb des Paketverarbeitungs-Subsystems ausgeweitet, das für Routing-Anfragen von CloudFronts Edge-Standorten an Ressourcen innerhalb von Kunden-VPCs verantwortlich ist. Wir haben eine Minderungsstrategie identifiziert und testen derzeit, um das Problem zu lösen. Sobald die Tests abgeschlossen sind, werden wir die Minderung in einem schrittweisen Ansatz einsetzen. Basierend auf den Ergebnissen dieser Tests werden wir in unserem nächsten Update eine klarere geschätzte Zeit für die Auflösung bereitstellen. Wir empfehlen weiterhin, dass Kunden, die dazu in der Lage sind, ihren Herkunftstyp vorübergehend ändern, um die Fehler zu beheben. Wir werden ein weiteres Update bis 5:15 Uhr PDT oder früher bereitstellen, wenn zusätzliche Informationen verfügbar sind.

5. 16. Juli 2026 um 11:27 UTCresolved

   Wir sehen erste Anzeichen einer Erholung und arbeiten weiter auf eine vollständige Erholung hin.

6. 16. Juli 2026 um 11:57 UTCresolved

   Wir sehen weiterhin signifikante Anzeichen einer Erholung als Ergebnis unserer Minderungsbemühungen, wobei eine vollständige Erholung innerhalb der nächsten 45 Minuten erwartet wird.

7. 16. Juli 2026 um 12:21 UTCresolved

   Zwischen 12:45 Uhr und 4:18 Uhr PDT haben wir bei CloudFront-Kunden mit VPC Origins-Konnektivität erhöhte 5xx-Fehler festgestellt. Unsere Ingenieure wurden automatisch eingestellt und begannen sofort, die Ursache zu untersuchen. Bis 2:57 Uhr PDT identifizierten wir die Ursache des Problems als interne Einschränkung für die Flotte, die Verbindungen zu privaten VPC-Ursprüngen verwaltet. Als diese Einschränkung erreicht wurde, konnte das System, das für die Verteilung der Routing-Konfiguration an unsere Netzwerkprozessoren verantwortlich war, die aktualisierten Konfigurationsdaten nicht korrekt laden, was sich auf das Routing von VPC Origin-Verbindungen auswirkte. Um 3:52 Uhr PDT haben wir mehrere Minderungsmaßnahmen ergriffen, die zu einer vollständigen Erholung um 4:18 Uhr PDT führten. Jetzt, da das Problem gemildert wurde, können Kunden, die vorübergehend ihren Ursprungstyp geändert haben, diese Änderungen sicher rückgängig machen. Kunden, die andere Ursprungstypen verwenden, waren von diesem Problem nicht betroffen. Das Problem wurde behoben und der Dienst funktioniert normal.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 15. Juli 2026 um 23:11 UTCresolved

   Wir untersuchen erhöhte Konnektivitätsprobleme mit einer einzigen Avalability-Zone (euc1-az2) in der EU-CENTRAL-1-Region.

2. 15. Juli 2026 um 23:36 UTCresolved

   Wir sehen frühe Anzeichen einer Erholung und arbeiten weiter an einer vollständigen Lösung. Wir werden weiterhin Updates bereitstellen.

3. 16. Juli 2026 um 01:24 UTCresolved

   Zwischen 14:56 Uhr und 18:07 Uhr PDT gab es Verbindungsprobleme mit einer Teilmenge von EC2-Instanzen in einer einzigen Availability Zone (euc1-az2) in der EU-CENTRAL-1-Region. Während dieser Zeit haben Kunden möglicherweise auch erhöhte Fehlerraten und Latenzen für neue Instanz-Starts in der betroffenen Zone erlebt, zusammen mit einigen AWS-APIs, die die betroffenen EC2-Instanzen verwenden. Einige AWS Services hatten auch Verbindungsprobleme und erhöhte Fehlerraten innerhalb der betroffenen Zone. Ingenieure wurden automatisch eingestellt und begannen sofort zu untersuchen. Als Teil unserer Wiederherstellungsbemühungen verlagerten wir den Datenverkehr um 15:04 Uhr von der betroffenen Availability Zone für betroffene Dienste. Um 15:05 Uhr identifizierten wir die Ursache für eine kürzliche Netzwerkänderung, die die Auswirkungen verursachte. Die Ingenieure begannen sofort, diese Änderung rückgängig zu machen, die um 16:28 Uhr abgeschlossen wurde. Dies führte zur Wiederherstellung der Netzwerkverbindung zur betroffenen Zone um 16:30 Uhr. Wir arbeiteten weiter, bis wir die Auswirkungen um 18:07 Uhr vollständig erholt hatten. Wir erwarten nicht, dass sich dieses Problem wiederholt. Das Problem wurde behoben und der Dienst funktioniert normal.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 6. Juli 2026 um 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. Juli 2026 um 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. Juli 2026 um 14:12 UTCresolved

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

4. 6. Juli 2026 um 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. Juni 2026 um 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. Juni 2026 um 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. Juni 2026 um 21:29 UTCresolved

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

4. 30. Juni 2026 um 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. Juni 2026 um 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. Juni 2026 um 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. Juni 2026 um 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 um 23:38 UTCresolved

   We are investigating increased error rates for Route53 API calls.

2. 23. Mai 2026 um 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 um 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 um 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 um 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 um 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 um 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 um 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 um 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 um 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 um 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 um 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 um 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 um 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 um 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 um 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 um 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. April 2026 um 11:27 UTCresolved

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

2. 27. April 2026 um 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. März 2026 um 19:53 UTCresolved

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

2. 7. März 2026 um 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. März 2026 um 20:28 UTCresolved

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

4. 7. März 2026 um 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. März 2026 um 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. März 2026 um 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. März 2026 um 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. März 2026 um 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. März 2026 um 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. März 2026 um 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. März 2026 um 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. März 2026 um 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. März 2026 um 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. März 2026 um 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. März 2026 um 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. März 2026 um 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. April 2026 um 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. September 2026 um 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.