Historia awarii Amazon Web Services

1. 4 października 2026 16:14 UTCresolved

   Prowadzimy śledztwo w sprawie zwiększonej utraty pakietów w regionie UE-SOUTH-2.

2. 4 października 2026 16:36 UTCresolved

   Doświadczamy zwiększonej utraty pakietów z jednej strefy dostępności (eus2-az1) w regionie UE-SOUTH-2. Ta kwestia prowadzi również do zwiększenia opóźnień API i poziomów błędów w przypadku innych przepływów pracy i usług AWS. Inżynierowie byli automatycznie zaangażowani i pracują nad zidentyfikowaniem przyczyny i złagodzeniem problemu. Dostarczymy Państwu kolejną aktualizację do 10: 15 AM PDT lub wcześniej, gdy nowe informacje staną się dostępne.

3. 4 października 2026 17:06 UTCresolved

   Nasze wysiłki mające na celu złagodzenie zwiększonej utraty pakietów za pomocą jednej strefy dostępności (eus2-az1) w regionie UE-SOUTH-2 są nadal w toku. Widzimy pewne oznaki poprawy w wyniku wielu równoległych wysiłków. Nadal pracujemy nad potwierdzeniem zasadniczej przyczyny i pełnym złagodzeniem tej kwestii. Chociaż obecnie nie mamy szacunków na to, jak długo będą trwać nasze działania, będziemy informować Państwa o naszych postępach i dostarczyć Państwu kolejną aktualizację do 11: 00 AM PDT lub wcześniej, gdy nowe informacje staną się dostępne.

4. 4 października 2026 17:56 UTCresolved

   Zidentyfikowaliśmy przyczynę i obecnie skupiamy nasze wysiłki łagodzące, aby doprowadzić do pełnego powrotu do zdrowia. Chociaż nie mamy dokładnych szacunków na to, jak długo będą trwać nasze obecne wysiłki, oczekujemy, że w miarę trwania naszych wysiłków nastąpi przyrostowa poprawa. Dostarczymy Państwu kolejną aktualizację do 11: 45 AM PDT, lub wcześniej, jeśli nowe informacje staną się dostępne.

5. 4 października 2026 18:45 UTCresolved

   Widzimy wczesne oznaki powrotu do zdrowia. Dostarczymy Państwu kolejną aktualizację do 12: 00 PM PDT.

6. 4 października 2026 18:56 UTCresolved

   Między 8: 48 a 11: 28 AM PDT, doświadczyliśmy zwiększonej utraty pakietów w jednej strefie dostępności (eus2-az1) w regionie UE-SOUTH-2. Ta kwestia doprowadziła do zwiększenia opóźnień API i poziomu błędów dla wielu przepływów pracy i usług AWS. Zostaliśmy automatycznie poinformowani o tej sprawie o 8: 54 rano i natychmiast rozpoczęliśmy pracę nad zidentyfikowaniem przyczyny źródłowej, jednocześnie podejmując wiele równoległych ścieżek w celu złagodzenia problemu. Do 10: 00 nasze wysiłki łagodzące doprowadziły do pewnych ulepszeń. Do 10: 38, zidentyfikowaliśmy przyczynę początkową jako związaną ze zmianą konfiguracji sieci, że byliśmy w stanie odwrócić zmianę, która doprowadziła do całkowitego złagodzenia o 11: 28. Problem został rozwiązany i usługa działa normalnie.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 21 września 2026 23:26 UTCresolved

   Badamy zwiększony poziom błędów API w regionie US- EAST-1.

2. 21 września 2026 23:44 UTCresolved

   Możemy potwierdzić zwiększony poziom błędów mających wpływ na uruchomienie nowej instancji, w tym podwyższony poziom błędów API w odniesieniu do pozycji startowych, Flota Stwórcza oraz związane z nimi przepływy pracy EC2 w regionie US- EAST-1. Klienci próbujący uruchomić nowe instancje EC2 mogą doświadczyć niepowodzenia startu lub podwyższone opóźnienie API reakcji. Nasi inżynierowie są aktywnie zaangażowani i pracują nad naprawą problemu. Widzimy początkowe oznaki powrotu do zdrowia. Istniejące przypadki pozostają nienaruszone. Polecamy ponowną próbę nieudanej pozycji i połączenia API Floty Kreatywnej. Dostarczymy aktualizację do 5: 30 PM PDT lub wcześniej.

3. 22 września 2026 00:24 UTCresolved

   Pomiędzy 15: 49 PM a 17: 06 PM PDT, doświadczyliśmy zwiększonego poziomu błędów wpływających na uruchomienie nowej instancji w regionie US- EAST-1. W tym czasie klienci mogli doświadczyć zwiększonego wskaźnika błędów podczas próby uruchomienia nowych instancji EC2 poprzez RunInstances, CreateFlota i powiązane przepływy pracy EC2. Na usługi AWS uruchamiające sprawy EC2 w imieniu klientów, w tym Amazon ECS, AWS Fargate, Amazon EMR, wpłynęły między innymi w tym okresie. Zidentyfikowaliśmy główną przyczynę jako niedawne wprowadzenie do podsystemu w ramach usługi EC2 odpowiedzialnej za przetwarzanie wniosków o uruchomienie instancji. Rozpoczęliśmy wycofywanie problematycznego rozmieszczenia i zaczęliśmy obserwować początkowe oznaki powrotu do zdrowia o 16: 44. Istniejące przypadki pozostają nienaruszone. Problem został rozwiązany i usługa działa normalnie.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 3 września 2026 21:49 UTCresolved

   Począwszy od 2: 12 PM PDT, zaczęliśmy doświadczać zwiększonych wskaźników błędów API dla STS i Zaloguj się podczas korzystania z SAML w regionie US- WEST-2. Nasz zespół inżynieryjny został automatycznie włączony o 14: 19, aby rozpocząć badanie przyczyny. W tej chwili nie ma żadnej pracy. Dostarczymy kolejną aktualizację do 3: 30 PM PDT.

2. 3 września 2026 22:26 UTCresolved

   Widzimy wczesne oznaki powrotu do zdrowia i nadal monitorujemy pełną regenerację. Dostarczymy kolejną aktualizację o 16: 15 lub wcześniej, jeśli będziemy mieli dodatkowe informacje do przekazania.

3. 3 września 2026 23:20 UTCresolved

   Nadal obserwujemy stabilną regenerację dla STS AssumeRoleWithSAML i AssumeRoleWithWebIdentity API w regionie US- WEST-2. Wskaźniki błędów wracają do poziomów sprzed zdarzenia, a my nadal aktywnie monitorujemy, aby potwierdzić pełne odzyskanie. Dostarczymy kolejną aktualizację do 17: 15 lub wcześniej.

4. 4 września 2026 00:07 UTCresolved

   Między 2: 12 PM a 3: 18 PM PDT, doświadczyliśmy zwiększonych wskaźników błędów API wpływających na STS AssumeRoleWithSAML i AssumeRoleWithWebIdentity API w regionie US- WEST-2. Podstawową przyczynę uznano za spowodowaną problemem z podsystemem STS odpowiedzialnym za komunikację z zewnętrznymi dostawcami tożsamości. Inne usługi AWS, które opierają się na tych protokołach federacyjnych tożsamości również zostały naruszone. O 15: 18 obserwowaliśmy oznaki powrotu do zdrowia i kontynuowaliśmy monitorowanie w celu zapewnienia stabilności i pełnego powrotu do zdrowia. Problem jest rozwiązany i usługa działa normalnie w tym czasie.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 21 sierpnia 2026 02:02 UTCresolved

   AP- NORTHEAST- 1 = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = 124 = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = W regionie AP- NORTHEAST-1 doświadczamy zwiększonego poziomu błędów wpływających na wskaźniki czasu rzeczywistego. Klienci mogą doświadczyć brakujących lub opóźnionych danych metrycznych w czasie rzeczywistym.

2. 21 sierpnia 2026 02:40 UTCresolved

   W związku z tym, że AP- NORTHEAST- jest to jeden z najtrudniejszych powodów, dla których nie ma pewności co do tego, czy jest to możliwe, czy nie. 10: 13 AM to jest to: 34 AM to jest to jest to, co się dzieje. W tym czasie klienci mogli doświadczać brakujących danych w raportach analitycznych i mogli obserwować problemy, jeśli dostęp do wskaźników czasu rzeczywistego w ramach przepływów kontaktowych, takich jak sprawdzanie personelu agenta. Zidentyfikowaliśmy główną przyczynę problemu z podsystemem odpowiedzialnym za dostarczanie zdarzeń metrycznych. Zaczęliśmy stosować środki łagodzące o 6: 13 i złagodziliśmy problem o 6: 34. Problem został rozwiązany i usługa działa normalnie.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 19 sierpnia 2026 15:15 UTCresolved

   Badamy problem, który wpływa na uruchomienie nowych instancji i zasobów EC2 w nowo uruchomionej strefie dostępności (euw2-az4) w regionie UE-WEST-2. W tym czasie zainteresowani klienci mogą doświadczać problemów przy tworzeniu lub modyfikowaniu zasobów w regionie. Mogą mieć również wpływ na inne usługi AWS. W celu natychmiastowego odzyskania, zalecamy, aby klienci korzystali w stosownych przypadkach z alternatywnych stref dostępności (euw2-az1, euw2-az2 i euw2-az3). Istniejące bieżące przypadki i zasoby nie są naruszone. Dostarczymy kolejną aktualizację do 10: 00 AM PDT, lub wcześniej, jeśli będziemy mieli dodatkowe informacje do udostępnienia.

2. 19 sierpnia 2026 17:03 UTCresolved

   18 sierpnia uruchomiliśmy nową strefę dostępności (euw2-az4) w regionie UE-WEST-2. Po uruchomieniu, zaczęliśmy doświadczać błędów uruchamiania instancji EC2 w nowej strefie dostępności, gdy nie ma domyślnej podsieci. Możemy potwierdzić, że istniejące przypadki i zasoby nie są naruszone. Przepływy pracy, które automatycznie otrzymują listę stref dostępności w regionie za pośrednictwem API DescribeAvabilityZones, a następnie próbują uruchomić nowe instancje lub utworzyć zasoby w nowej strefie dostępności mogą napotkać błędy. W przypadku awarii startowych na przykładzie EC2 podejmujemy działania łagodzące, aby automatycznie tworzyć domyślne podsieci, w których nie ma jeszcze takich podsieci, kiedy uruchomienie na przykładzie EC2 jest ukierunkowane na nową strefę dostępności. Dla klientów i przepływów pracy, które wymagają natychmiastowej remediacji < a href = "https: / / docs.aws.amazon.com / vpc / last / userguide / work- with- default- vpc.html # create- default- subnet" > można utworzyć domyślną podsieć < / a > w nowej strefie dostępności. Dzięki temu instancja EC2 będzie mogła z powodzeniem zakończyć prace. W przypadku innych zasobów, takich jak funkcje Lambda, gdzie nowa Strefa Dostępności nie jest obecnie obsługiwana, zalecamy aktualizację ich przepływów pracy, aby wykluczyć nowo uruchomioną Strefę Dostępności i kontynuować tworzenie zasobów przy użyciu innych Strefy Dostępności w regionie. Chociaż nie mamy dokładnych szacunków na to, jak długo będą trwać nasze wysiłki łagodzące, będziemy informować na bieżąco na temat naszych postępów i dostarczyć Państwu kolejną aktualizację do 1: 00 PM PDT lub wcześniej, gdy nowe informacje staną się dostępne.

3. 19 sierpnia 2026 18:47 UTCresolved

   Między 18 sierpnia 5: 00 PM a 19 sierpnia 11: 00 AM PDT, doświadczyliśmy zwiększonych błędów uruchamiających EC2 instancje w nowo uruchomionej strefie dostępności (euw2-az4) w regionie UE-WEST-2. Po uruchomieniu nowej strefy dostępności zaczęliśmy doświadczać błędów przy użyciu domyślnego VPC. Odkryliśmy główną przyczynę problemu 19 sierpnia o 9: 00 rano i zaczęliśmy wprowadzać zmiany w celu rozwiązania problemu o 9: 30 rano. Podczas gdy zmiana była w toku, zaczęliśmy dostrzegać przyrostowe ulepszenia w nowych instancjach, przy pełnym odzyskaniu o 11: 00 rano. Istniejące bieżące przypadki i zasoby nie zostały naruszone. Niektóre usługi regionalne, takie jak funkcje Lambda lub bazy danych Aurory, nie były dostępne przy uruchomieniu nowej strefy dostępności, a dostępność usług zostanie z czasem dodana. Klienci, którzy próbują utworzyć zasoby zanim usługi staną się dostępne, zobaczą wiadomość informującą, że nie jest obsługiwany w strefie dostępności. Problem został rozwiązany i usługa działa normalnie.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 15 sierpnia 2026 03:42 UTCresolved

   Badamy zwiększoną utratę pakietów, wpływając na łączność AWS Direct Connect dla niektórych klientów w regionie EU-CENTRAL-1.

2. 15 sierpnia 2026 04:42 UTCresolved

   Możemy potwierdzić utratę pakietów wpływającą na połączenia Direct Connect w regionie EU-CENTRAL-1. Inżynierowie byli automatycznie zaangażowani i natychmiast zaczęli pracować zarówno w celu zidentyfikowania przyczyny, jak i identyfikacji wielu równoległych ścieżek w celu złagodzenia problemu. W tym czasie widzimy wczesne oznaki wyzdrowienia. Dostarczymy kolejną aktualizację w ciągu 60 minut lub wcześniej, jeśli będziemy mieli dodatkowe informacje do przekazania.

3. 15 sierpnia 2026 05:55 UTCresolved

   Począwszy od 7: 33 PM PDT, zaczęliśmy doświadczać zwiększonej utraty pakietów wpływającej na łączność AWS Direct Connect dla niektórych klientów w regionie EU-CENTRAL-1. Chociaż poczyniliśmy postępy, połączenia z następującą lokalizacją Direct Connect są nadal osłabione: Equinix FR5, Frankfurt, DEU. Klienci, którzy mają multi-site redundancy skonfigurowane ze swoimi ścieżkami Direct Connect nie powinni obserwować wpływu w tym czasie. Klienci, którzy mają tylko połączenia w Equinix FR5, Frankfurt nad Menem, lokalizacja DEU będą nadal doświadczać problemów z połączeniami. Aktywnie pracujemy nad złagodzeniem skutków i dążeniem do pełnego powrotu do zdrowia, ale spodziewamy się, że pełne wyzdrowienie nastąpi za kilka godzin. Dostarczymy aktualizację w ciągu 90 minut, lub wcześniej, jeśli będziemy mieli dodatkowe informacje do przekazania.

4. 15 sierpnia 2026 07:24 UTCresolved

   Aktywnie pracujemy nad przywróceniem łączności poprzez bezpośrednie połączenie: Equinix FR5, Frankfurt, DEU. Klienci, którzy mają tylko połączenia w Equinix FR5, Frankfurt nad Menem, lokalizacja DEU będą nadal doświadczać problemów z połączeniami. W celu uzyskania zwrotu zaleca się, aby w przypadku obejścia przez klientów, którzy mają możliwość niepowodzenia dla VPN, zrobić to. Dla klientów korzystających z bramy Direct Connect i bramki Transit, zalecamy utworzenie AWS Site- to-Site VPN i dołączyć go do bramy Transit, odnoszą się do kroków < a href = "https: / / aws.amazon.com / premiumsupport / knowdge- center / dx- configure- dx- and- vpn- failover-tgw /" > tutaj < / a >. Dla innych klientów zalecamy ustanowienie AWS Site- to-Site VPN jako tymczasowej ścieżki tworzenia kopii zapasowych, odsyłaj kroki < a href = "https: / / docs.aws.amazon.com / vpn / last / s2svpn / SetupVPNConnections.html" > tutaj < / a >. Od tej pory spodziewamy się, że powrót do zdrowia będzie za kilka godzin. Dostarczymy kolejną aktualizację w ciągu 90 minut, lub wcześniej, jeśli będziemy mieli dodatkowe informacje do przekazania.

5. 15 sierpnia 2026 09:08 UTCresolved

   Nadal pracujemy na rzecz odzyskania łączności dla połączeń AWS Direct Connect w Equinix FR5, Frankfurt, DEU. Przyczyna jest związana z problemem infrastruktury obiektu w miejscu, które wpływa na infrastrukturę sieciową. Klienci z połączeniami wyłącznie w tej lokalizacji będą nadal doświadczać utraty pakietów lub degradacji połączeń. Klienci z wielostronikową lub zbędną konfiguracją w innych lokalizacjach nie mają wpływu. W odniesieniu do pracy, wpływających klientów, którzy mają możliwość niepowodzenia VPN zaleca się to zrobić. Dla klientów korzystających z bramki Direct Connect i bramki Transit Gateway, zalecamy utworzenie AWS Site- to-Site VPN i podłączenie go do bramy Transit, odnoszą się do kroków < a href = "https: / / aws.amazon.com / premiumsupport / knowdge- center / dx- configure- dx- and- vpn- failover- tgw /" > tutaj < / a >. Dla innych klientów zalecamy ustanowienie AWS Site- to- Site VPN jako tymczasowej ścieżki tworzenia kopii zapasowych, odnoszą się do kroków < a href = "https: / / docs.aws.amazon.com / vpn / last / s2svpn / SetupVPNConnections.html" > tutaj < / a >. Od tej pory spodziewamy się, że powrót do zdrowia będzie za kilka godzin. Dostarczymy kolejną aktualizację w ciągu 2 godzin lub jak tylko będziemy mieli więcej informacji do przekazania.

6. 15 sierpnia 2026 11:10 UTCresolved

   Łączność AWS Direct Connect pozostaje osłabiona dla klientów z połączeniami w lokalizacji Equinix FR5 we Frankfurcie nad Menem. Klienci z wielostronikową lub zbędną konfiguracją w innych lokalizacjach pozostają nietknięci. Inżynierowie aktywnie pracują nad przywróceniem łączności, a wysiłki podejmowane w ramach wielu strumieni prac mają na celu rozwiązanie problemu podstawowego obiektu i przywrócenie do eksploatacji urządzeń sieciowych. Oczekujemy, że wyzdrowienie będzie za kilka godzin. Do pracy wokół, uderzeni klienci, którzy mają możliwość niepowodzenia VPN są zalecane, aby to zrobić. Dla klientów korzystających z bramki Direct Connect i bramki Transit Gateway, zalecamy utworzenie AWS Site- to-Site VPN i podłączenie go do bramy Transit, odnoszą się do kroków < a href = "https: / / aws.amazon.com / premiumsupport / knowdge- center / dx- configure- dx- and- vpn- failover- tgw /" > tutaj < / a >. Dla innych klientów zalecamy ustanowienie AWS Site- to- Site VPN jako tymczasowej ścieżki tworzenia kopii zapasowych, odnoszą się do kroków < a href = "https: / / docs.aws.amazon.com / vpn / last / s2svpn / SetupVPNConnections.html" > tutaj < / a >. Dostarczymy kolejną aktualizację w ciągu 2 godzin lub jak tylko będziemy mieli więcej informacji do przekazania.

7. 15 sierpnia 2026 13:17 UTCresolved

   Inżynierowie kontynuują prace nad przywróceniem łączności w lokalizacji Equinix FR5 we Frankfurcie nad Menem. Nasz partner współlokacji pracuje nad rozwiązaniem problemu infrastruktury bazowej i chociaż ulepszenia nie są jeszcze widoczne dla klientów, czynimy pozytywne postępy w kierunku restrukturyzacji i uporządkowanej likwidacji. Dla klientów, którzy wymagają natychmiastowego odzyskania, zalecamy niepowodzenie VPN, jak opisano w naszych poprzednich aktualizacjach. Dostarczymy kolejną aktualizację do 9: 30 AM PDT, lub wcześniej, jeśli mamy dodatkowe informacje do przekazania.

8. 15 sierpnia 2026 16:27 UTCresolved

   Nasz partner współlokacji nadal pracuje nad rozwiązaniem problemu infrastruktury bazowej w lokalizacji Equinix FR5 we Frankfurcie nad Menem. Dostęp do dotkniętego obszaru jest obecnie ograniczony ze względu na obawy dotyczące bezpieczeństwa, co wpływa na naszą zdolność do oceny stanu fizycznego sprzętu sieciowego i zapewnia dokładniejszy harmonogram odzyskiwania. Na podstawie aktualnych informacji nie oczekuje się pełnego odzyskania pomocy w najbliższym czasie i może to wykraczać poza obecne ramy. Połączenia AWS Direct Connect w tej lokalizacji pozostają osłabione. Klienci z zbędnymi połączeniami przez inne miejsca pozostają nietknięci. Dla klientów korzystających z bramki Direct Connect i bramki Transit Gateway, zalecamy utworzenie AWS Site- to-Site VPN i podłączenie go do bramy Transit, odnoszą się do kroków < a href = "https: / / aws.amazon.com / premiumsupport / knowdge- center / dx- configure- dx- and- vpn- failover- tgw /" > tutaj < / a >. Dla innych klientów zalecamy ustanowienie AWS Site- to- Site VPN jako tymczasowej ścieżki tworzenia kopii zapasowych, odnoszą się do kroków < a href = "https: / / docs.aws.amazon.com / vpn / last / s2svpn / SetupVPNConnections.html" > tutaj < / a >. Dostarczymy kolejną aktualizację do 3: 30 PM PDT, lub wcześniej, jeśli będziemy mieli dodatkowe informacje do udostępnienia.

9. 15 sierpnia 2026 22:26 UTCresolved

   Nasz partner współlokacji nadal pracuje nad przywróceniem bezpiecznego dostępu do obszaru dotkniętego chorobą w lokalizacji Equinix FR5 we Frankfurcie nad Menem. Gdy zabezpieczymy bezpieczny dostęp, nasi inżynierowie będą mogli ocenić dotknięte urządzenia sieciowe. Nadal uważnie śledzimy postępy i udostępnimy aktualizację do 9: 30 PM PDT, lub wcześniej, gdy nowe informacje staną się dostępne.

10. 16 sierpnia 2026 04:37 UTCresolved

    Aktywnie współpracujemy z naszym partnerem współlokacji, aby przywrócić łączność w Equinix FR5 we Frankfurcie nad Menem. Od naszej ostatniej aktualizacji, poczyniliśmy stopniowe postępy w celu przywrócenia bezpiecznego dostępu do dotkniętego obszaru w lokalizacji Equinix FR5 we Frankfurcie nad Menem. Równolegle ustaliliśmy kolejność, w jakiej zostaną przywrócone krytyczne i priorytetowe stojaki w ramach działań łagodzących. Na podstawie naszej obecnej oceny, w najbliższej perspektywie nie oczekuje się pełnego powrotu do zdrowia i może wykraczać poza obecne ramy. Połączenia AWS Direct Connect w tej lokalizacji pozostają osłabione. Klienci z połączeniami wyłącznie w tej lokalizacji będą nadal doświadczać utraty pakietów. Klienci z wielostronikową lub zbędną konfiguracją w innych lokalizacjach Direct Connect pozostają bez zmian. W odniesieniu do pracy, wpływających klientów, którzy mają możliwość niepowodzenia VPN zaleca się to zrobić. Dla klientów korzystających z bramki Direct Connect i bramki Transit Gateway, zalecamy utworzenie AWS Site- to-Site VPN i podłączenie go do bramy Transit, odnoszą się do kroków < a href = "https: / / aws.amazon.com / premiumsupport / knowdge- center / dx- configure- dx- and- vpn- failover- tgw /" > tutaj < / a >. Dla innych klientów zalecamy ustanowienie AWS Site- to- Site VPN jako tymczasowej ścieżki tworzenia kopii zapasowych, odnoszą się do kroków < a href = "https: / / docs.aws.amazon.com / vpn / last / s2svpn / SetupVPNConnections.html" > tutaj < / a >. Nadal uważnie śledzimy postępy i udostępnimy aktualizację do 16 sierpnia 3: 30 AM PDT, lub wcześniej, gdy nowe informacje staną się dostępne.

11. 16 sierpnia 2026 10:25 UTCresolved

    Kontynuujemy współpracę z naszym partnerem współlokacji w celu przywrócenia łączności w lokalizacji Equinix FR5 we Frankfurcie nad Menem. Od ostatniej aktualizacji poczyniliśmy znaczne postępy w kierunku przywrócenia bezpiecznego dostępu do dotkniętego obszaru. Procedura izolacji elektrycznej jest już w toku, a nasze zespoły są na miejscu w sali elektrycznej, wykonując odenergetyzację dotkniętej infrastruktury. Po sprawdzeniu izolacji i potwierdzeniu bezpieczeństwa inżynierowie rozpoczną fizyczną inspekcję wadliwego sprzętu sieciowego w celu określenia wymaganego zakresu wymiany. W oparciu o naszą obecną ocenę, w najbliższym czasie nie oczekuje się pełnego powrotu do zdrowia ze względu na zakres potencjalnego wpływu na sprzęt. Połączenia AWS Direct Connect w tej lokalizacji pozostają osłabione. Klienci z połączeniami wyłącznie w tej lokalizacji będą nadal doświadczać utraty pakietów. Klienci z wielostronikową lub zbędną konfiguracją w innych lokalizacjach Direct Connect pozostają bez zmian. W odniesieniu do pracy, wpływających klientów, którzy mają możliwość niepowodzenia VPN zaleca się to zrobić. Dla klientów korzystających z bramki Direct Connect i bramki Transit Gateway, zalecamy utworzenie AWS Site- to-Site VPN i podłączenie go do bramy Transit, odnoszą się do kroków < a href = "https: / / aws.amazon.com / premiumsupport / knowdge- center / dx- configure- dx- and- vpn- failover- tgw /" > tutaj < / a >. Dla innych klientów zalecamy ustanowienie AWS Site- to- Site VPN jako tymczasowej ścieżki tworzenia kopii zapasowych, odnoszą się do kroków < a href = "https: / / docs.aws.amazon.com / vpn / last / s2svpn / SetupVPNConnections.html" > tutaj < / a >. Nadal uważnie śledzimy postępy i udostępnimy aktualizację do 16 sierpnia 9: 30 AM PDT, lub wcześniej, gdy nowe informacje staną się dostępne.

12. 16 sierpnia 2026 16:30 UTCresolved

    Izolacja elektryczna w Equinix FR5 we Frankfurcie nad Menem (DEU) jest już kompletna, a nasi inżynierowie rozpoczęli fizyczne inspekcje wadliwego sprzętu sieciowego. Nie mamy jeszcze harmonogramu pełnej restrukturyzacji i uporządkowanej likwidacji, podczas gdy nadal oceniamy zakres wpływu na sprzęt. Bezpośrednie połączenia Connect w tej lokalizacji pozostają osłabione. Klienci z połączeniami wyłącznie w tej lokalizacji będą nadal doświadczać utraty pakietów. Klienci z wielozakładową lub zbędną konfiguracją w innych lokalizacjach Direct Connect nie mają wpływu. Zalecamy, aby wpłynął na niepowodzenie VPN klientów, dopóki nie będziemy mieli większej jasności w kolejnych krokach i harmonogramie odzyskiwania. Dla klientów korzystających z bramki Direct Connect i bramki Transit Gateway, można utworzyć AWS Site- to-Site VPN i dołączyć go do swojej bramki Transit, odnoszą się do kroków < a href = "https: / / aws.amazon.com / premierumsupport / knowdge- center / dx- configure- dx- and- vpn- failover- tgw /" > tutaj < / a >. Dla innych klientów zalecamy ustanowienie AWS Site- to- Site VPN jako tymczasowej ścieżki tworzenia kopii zapasowych, odnosić się do kroków < a href = "https: / / docs.aws.amazon.com / vpn / last / s2svpn / SetupVPNConnections.html" > tutaj < / a >. Dostarczymy kolejną aktualizację do 16 sierpnia 5: 30 PM PDT, lub wcześniej, gdy nowe informacje staną się dostępne.

13. 16 sierpnia 2026 22:51 UTCresolved

    Zakończyliśmy naszą ocenę wpływu urządzeń sieciowych w lokalizacji Equinix FR5 we Frankfurcie nad Menem, DUE, a teraz mamy jasny obraz zakresu oddziaływania. Postępujemy w kierunku przywrócenia łączności i podejmiemy stopniowe podejście do rekultywacji. Klienci z połączeniami wyłącznie w tej lokalizacji będą nadal doświadczać utraty pakietów aż do zakończenia rekultywacji. Klienci z wielozakładową lub zbędną konfiguracją w innych lokalizacjach Direct Connect nie mają wpływu. Dostarczymy kolejną aktualizację do 16 sierpnia 10: 30 PM PDT, lub wcześniej, gdy nowe informacje staną się dostępne.

14. 17 sierpnia 2026 05:38 UTCresolved

    Kontynuujemy postępy w stopniowej rekultywacji w lokalizacji Equinix FR5 we Frankfurcie nad Menem. Od naszej ostatniej aktualizacji przywrócono infrastrukturę sieci zależnej. Regeneracja pozostałej infrastruktury jest w toku, a część odzysku zależy od dostawy sprzętu zastępczego. Chłodzenie zostało w pełni przywrócone, a warunki środowiskowe stabilne w normalnych progach operacyjnych. Klienci z połączeniami wyłącznie w tej lokalizacji będą nadal doświadczać utraty pakietów w miarę postępów w rekultywacji. Klienci z wielozakładową lub zbędną konfiguracją w innych lokalizacjach Direct Connect nie mają wpływu. Dotychczasowe przekazane wytyczne i zalecenia dotyczące łagodzenia zmiany klimatu pozostają niezmienione. Dostarczymy kolejną aktualizację do 17 sierpnia 4: 30 AM PDT, lub wcześniej w miarę postępu rekultywacji.

15. 17 sierpnia 2026 11:22 UTCresolved

    Kontynuujemy postępy w stopniowej rekultywacji w lokalizacji Equinix FR5 we Frankfurcie nad Menem. Infrastruktura sieciowa i systemy zależne w dalszym ciągu się ulepszają, ponieważ wnosimy dotknięte sprzętem z powrotem do sieci. Niektóre części zamienne zostały dostarczone i instalacja jest w trakcie, gdy komponenty przybywają na miejsce. Równolegle przesuwamy ruch sieciowy, aby umożliwić odrestaurowanym urządzeniom rozpoczęcie obsługi klientów, gdy są one online. W miarę postępów w odzyskiwaniu, klienci będą obserwować odbudowę w dwóch etapach. W pierwszym etapie sesje BGP zostaną ponownie ustanowione, ale przedrostki IP nie zostaną jeszcze ogłoszone, co wskazuje na to, że ożywienie jest nadal w toku, a podstawowa infrastruktura nie jest jeszcze gotowa do przewożenia ruchu. W drugim etapie reklama prefiksu IP zostanie wznowiona, w którym to momencie infrastruktura zostanie w pełni naprawiona i przywrócona łączność. Chociaż obecnie nie mamy ETA do pełnego odzyskania, nadal pracujemy tak szybko i bezpiecznie, aby złagodzić skutki dla klientów. Dostarczymy kolejną aktualizację do 17 sierpnia 10: 30 AM PDT, lub szybciej, jak rekultywacja postępuje.

16. 17 sierpnia 2026 16:25 UTCresolved

    Kontynuujemy prace nad stopniową rekultywacją w lokalizacji Equinix FR5 we Frankfurcie nad Menem. Obserwujemy wczesne oznaki ożywienia gospodarczego, podczas gdy nadal w pełni rozwiązujemy tę kwestię. Aktywnie pracujemy nad ponownym uruchomieniem sprzętu, który został dotknięty i dostarczymy kolejną aktualizację do godziny 12: 30 PDT, lub wcześniej w miarę postępów w rekultywacji.

17. 17 sierpnia 2026 17:59 UTCresolved

    Widzimy szerokie oznaki ożywienia w miejscu Equinix FR5 we Frankfurcie nad Menem. Przywróciliśmy łączność dla większości dotkniętego sprzętu, a większość połączeń jest w pełni odzyskana i stabilna. Istnieje niewielka liczba klientów, którzy pozostaną dotknięci do czasu całkowitego przywrócenia pozostałych urządzeń. Dostarczymy kolejną aktualizację do 2: 00 PM PDT, lub wcześniej w miarę postępów w rekultywacji.

18. 17 sierpnia 2026 21:00 UTCresolved

    Kontynuujemy pracę nad przywróceniem sprzętu. Od naszej ostatniej aktualizacji dokonaliśmy postępów, które nie będą widoczne dla klientów, ale są wymagane do odzyskania. Pracujemy równolegle, aby wszystkie urządzenia były jak najbezpieczniej dostępne. Oczekuje się, że prace te potrwają kilka godzin, aby zakończyć i potwierdzić. Dla klientów, którzy wymagają pracy, zalecamy, aby rozważyć niepowodzenie VPN. Dla klientów korzystających z bramki Direct Connect i bramki Transit Gateway, można utworzyć AWS Site- to-Site VPN i dołączyć go do swojej bramki Transit, odnoszą się do kroków < a href = "https: / / aws.amazon.com / premierumsupport / knowdge- center / dx- configure- dx- and- vpn- failover- tgw /" > tutaj < / a >. Dla innych klientów zalecamy ustanowienie AWS Site- to- Site VPN jako tymczasowej ścieżki tworzenia kopii zapasowych, odnosić się do kroków < a href = "https: / / docs.aws.amazon.com / vpn / last / s2svpn / SetupVPNConnections.html" > tutaj < / a >. Dostarczymy kolejną aktualizację do 7: 00 PM PDT lub wcześniej, gdy nowe informacje staną się dostępne.

19. 18 sierpnia 2026 01:50 UTCresolved

    Widzimy znaczące ożywienie większości połączeń z klientami na tym etapie. Mimo że nie jesteśmy jeszcze w pełni odzyskani, wysiłki na rzecz odbudowy postępują zgodnie z oczekiwaniami w miejscu Equinix FR5 we Frankfurcie nad Menem (DEU). Regeneracja pozostałej infrastruktury polega na zakończeniu wymiany sprzętu i walidacji ruchu, z których oba są aktywnie w toku. Przewidujemy dalszą regenerację widoczną dla klientów, ponieważ pozostała infrastruktura zostaje przywrócona do użytku. Klienci z połączeniami wyłącznie w tej lokalizacji będą nadal doświadczać utraty pakietów aż do zakończenia rekultywacji. Dotychczasowe przekazane wytyczne i zalecenia dotyczące łagodzenia zmiany klimatu pozostają niezmienione. Dostarczymy kolejną aktualizację do 17 sierpnia 11: 00 PDT lub wcześniej.

20. 18 sierpnia 2026 04:01 UTCresolved

    Począwszy od 14 sierpnia 7: 33 PM PDT, doświadczyliśmy zwiększonej utraty pakietów wpływającej na łączność AWS Direct Connect dla klientów z połączeniami w lokalizacji Equinix FR5 we Frankfurcie, DEU. Inżynierowie zostali automatycznie włączeni o 7: 45 14 sierpnia i natychmiast zaczęli badać ograniczenia. O 20: 30 zidentyfikowaliśmy, że sprzęt sieciowy w miejscu FR5 został uszkodzony z powodu wlotu wody do obiektu kolokacji. W rezultacie system chłodzenia był osłabiony, co doprowadziło do przegrzania i wyłączenia urządzeń. Woda wpłynęła również na systemy dystrybucji energii, które wyłączyły zasilanie urządzeń sieciowych. Początkowe wysiłki w zakresie odzysku zostały opóźnione, ponieważ warunki środowiskowe w zakładzie wymagały stabilizacji, zanim inżynierowie mogli bezpiecznie dostać się do obszaru dotkniętego chorobą. W dniach 15 i 16 sierpnia nasi inżynierowie współpracowali z operatorem obiektu w celu przywrócenia uszkodzonych urządzeń sieciowych, podczas gdy problem infrastruktury leżącej u ich podstaw został rozwiązany. 17 sierpnia o godzinie 7: 26 przywrócono wszystkie uszkodzone urządzenia sieciowe, a łączność z lokalizacją została zweryfikowana jako w pełni sprawna i trwała. Nie oczekujemy, że ta kwestia się powtórzy. Klienci z zbędnymi połączeniami w innych lokalizacjach Direct Connect utrzymywali łączność poprzez swoje alternatywne ścieżki podczas tego wydarzenia i nie wymagają dalszych działań. Klienci, którzy wdrożyli defeafover VPN jako obejście może teraz bezpiecznie wrócić do swoich podstawowych ścieżek Direct Connect. Połączenie zostało zweryfikowane jako stabilne i w pełni sprawne. Klienci wymagający dalszej pomocy mogą skontaktować się z AWS Support za pośrednictwem konsoli zarządzania AWS lub < a href = "https: / / console.aws.amazon.com / support" > AWS Support Center < / a >.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 31 lipca 2026 17:33 UTCresolved

   Możemy potwierdzić wzrost utraty pakietów sieciowych, wpływając na łączność AWS Direct Connect w regionie AP- SOUTH-1. Nasz zespół inżynieryjny został automatycznie zaangażowany o 9: 54 rano, aby rozpocząć badanie problemu. Obecnie nie ma dostępnych pracownic. Dostarczymy kolejną aktualizację do 11: 30 AM PDT.

2. 31 lipca 2026 18:27 UTCresolved

   Zidentyfikowaliśmy przyczynę, która ma być związana ze zmianą dokonaną w systemie konfiguracyjnym odpowiedzialnym za przydzielanie tras do urządzeń. Rozpoczęliśmy prace nad zmniejszeniem utraty pakietów, która wpływa na AWS Direct Connect w regionie AP- SOUTH-1 i oczekujemy, że odzysk nastąpi stopniowo w ciągu najbliższych 30 minut. W miarę zdobywania zaufania do tych wysiłków, będziemy dążyć do równomiernej realizacji naszych wysiłków na rzecz przyspieszenia naprawy gospodarczej. Dostarczymy kolejną aktualizację do godziny 12: 00 PDT.

3. 31 lipca 2026 18:54 UTCresolved

   Między 9: 42 AM a 11: 44 AM PDT, doświadczyliśmy zwiększonej utraty pakietów sieciowych wpływającej na łączność AWS Direct Connect w regionie AP- SOUTH-1. Nasz zespół inżynieryjny został automatycznie włączony o 9: 46, aby rozpocząć śledztwo. O 10: 51, zrozumieliśmy, że główną przyczyną jest zmiana konfiguracji systemu odpowiedzialnego za przydzielanie tras do urządzeń. Gdy zdobyliśmy zaufanie do naszych działań łagodzących, porównaliśmy nasze wysiłki na rzecz dalszego ograniczenia utraty pakietów. Problem jest rozwiązany i usługa działa normalnie.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 24 lipca 2026 11:40 UTCresolved

   Badamy kwestie związane z połączeniem, które wpływają na wiele usług AWS w regionie US- WEST-2.

2. 24 lipca 2026 11:56 UTCresolved

   Widzimy początkowe oznaki powrotu do zdrowia i nadal pracujemy nad pełnym powrotem do zdrowia.

3. 24 lipca 2026 12:30 UTCresolved

   Nadal dostrzegamy znaczące oznaki ożywienia w wyniku naszych wysiłków na rzecz łagodzenia problemów związanych z połączeniem, mających wpływ na wiele usług AWS w regionie US- WEST-2. Zidentyfikowaliśmy przyczynę jako problem z urządzeniem sieciowym odpowiedzialnym za przekierowanie sieci z regionu do Seattle Metro. Inżynierowie zakończyli wszystkie prace łagodzące. Ponieważ trasy są w dalszym ciągu odnawiane, klienci powinni nadal odczuwać zmniejszenie poziomu błędów i skrótów czasowych przy łączeniu się z usługami, których dotyczą. Dokładnie monitorujemy postępy w odzyskiwaniu pomocy i będziemy kontynuować prace do momentu pełnego przywrócenia wszystkich tras i powrotu wskaźników usług do poziomu sprzed zdarzeń. Dostarczymy kolejną aktualizację w ciągu najbliższych 30- 45 minut.

4. 24 lipca 2026 13:01 UTCresolved

   Między 3: 55 a 4: 15 AM PDT, doświadczyliśmy problemów związanych z połączeniem, które wpłynęły na łączność z regionem US- WEST-2. To wpłynęło na wiele usług AWS w regionie. Niektórzy klienci mogli również doświadczyć problemów dostępu do konsoli AWS Management Console, z przerwami w połączeniach i nieodpowiadającymi stronami. Nie miało to wpływu na łączność wewnątrz regionu. Nasi inżynierowie zostali automatycznie zaangażowani o 4: 01 AM PDT i natychmiast zaczęli badać tę kwestię. Zidentyfikowaliśmy główną przyczynę jako problem z urządzeniami sieciowymi odpowiedzialnymi za routing sieci z regionu do Seattle Metro i zaczęliśmy równolegle pracować na wielu ścieżkach, aby złagodzić wpływ. Podjęliśmy środki łagodzące, które doprowadziły do początkowego powrotu do zdrowia o 4: 15. Ponieważ sieć w dalszym ciągu stabilizowała się po naszych działaniach łagodzących, doszło do krótkiego zdarzenia rekonwergencji między 4: 47 a 4: 59 AM PDT. W tym okresie rekonwalescencji niektórzy klienci mogli mieć do czynienia z problemem przerywanej łączności z regionem w związku z ponownym ustanowieniem tras sieciowych. Do 4: 59 AM PDT wszystkie trasy zostały w pełni odrestaurowane, a wskaźniki usług powróciły do poziomu sprzed zdarzenia. Klienci korzystający z AWS Direct Connect poprzez EqSe2, Westin Building Exchange, Seattle doświadczyli wydłużenia okna zderzeniowego od 3: 55 do 5: 12 AM PDT. Klienci ci doświadczyli problemów związanych z łącznością do czasu całkowitego przywrócenia tras sieciowych na tę konkretną ścieżkę o godzinie 5: 12 AM PDT. Klienci podłączyli się w trybie awaryjnym przez inne lokalizacje AWS Direct Connect nie byli pod wpływem tego wydarzenia. Problem został rozwiązany i wszystkie usługi AWS działają normalnie.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 17 lipca 2026 08:33 UTCresolved

   Badamy problemy z Cost Explorer odzwierciedlające niedokładne szacowane dane rachunkowe.

2. 17 lipca 2026 09:07 UTCresolved

   Począwszy od 16 lipca 7: 38 PM PDT, rozpoczęliśmy wyświetlanie nieprawidłowych szacunkowych danych rozliczeniowych w konsoli Billing and Cost Management Console. Nasze zespoły inżynieryjne są zaangażowane i badają przyczynę. Dostarczymy kolejną aktualizację do 3: 00 AM PDT lub wcześniej, jeśli więcej informacji stanie się dostępne.

3. 17 lipca 2026 10:03 UTCresolved

   Nadal pracujemy nad rozwiązaniem problemu wpływającego na szacunkowe koszty i wykorzystanie danych wyświetlanych w konsoli Billing and Cost Management Console. Zidentyfikowaliśmy główną przyczynę jako problem z cenami jednostkowymi w ramach szacowanego podsystemu obliczania rachunków i pracujemy nad ograniczeniem emisji. Wyświetlane szacunki nie odzwierciedlają rzeczywistego wykorzystania i opłat. W tej chwili nie wymaga się żadnych działań klientów. Po złagodzeniu problemu oczekujemy, że pełna rezolucja zajmie wiele godzin, kiedy będziemy pracować nad przetworzeniem szacunkowych danych rachunkowych. Dostarczymy kolejną aktualizację do 4: 00 AM PDT lub wcześniej, jeśli więcej informacji stanie się dostępne.

4. 17 lipca 2026 10:52 UTCresolved

   Nadal pracujemy nad rozwiązaniem problemu wpływającego na szacunkowe koszty i wykorzystanie danych wyświetlanych w konsoli Billing and Cost Management Console. Jak poprzednio udostępniliśmy, zidentyfikowaliśmy przyczynę podstawową jako problem z cenami jednostkowymi w ramach szacowanego podsystemu obliczania rachunków. Aby zapobiec wyświetlaniu dalszych niedokładnych szacunków, wstrzymaliśmy szacowane obliczenia rachunków. Klienci, którzy obecnie widzą normalne szacunki rachunków będą nadal widzieć te szacunki, a klienci, którzy widzą zawyżone szacunki nie będą widzieć ich wzrost, podczas gdy my pracujemy w kierunku restrukturyzacji i uporządkowanej likwidacji. Wyświetlane szacunki nie odzwierciedlają rzeczywistego wykorzystania i opłat. Nadal pracujemy nad pełnym złagodzeniem tej kwestii. Po złagodzeniu problemu oczekujemy, że pełna rezolucja zajmie wiele godzin, kiedy będziemy pracować nad przetworzeniem szacunkowych danych rachunkowych. W tej chwili nie wymaga się żadnych działań klientów. Dostarczymy kolejną aktualizację do 5: 00 AM PDT lub wcześniej, jeśli więcej informacji stanie się dostępne.

5. 17 lipca 2026 11:58 UTCresolved

   Nadal pracujemy nad rozwiązaniem problemu wpływającego na szacunkowe koszty i wykorzystanie danych wyświetlanych w konsoli Billing and Cost Management Console. Równolegle pracujemy nad wieloma ścieżkami łagodzącymi. Pierwsza ścieżka polega na powrocie do ostatniego dobrze oszacowanego rachunku. Dzięki temu podejściu klienci będą mogli zobaczyć tylko dane dotyczące kosztów i wykorzystania do 15 lipca, jednak dane dotyczące zawyżonych kosztów zostaną usunięte. Druga ścieżka polega na cofnięciu ostatniej zmiany podsystemu obliczania rachunków. Wyświetlane szacunki nie odzwierciedlają rzeczywistego wykorzystania i opłat. W tej chwili nie wymaga się żadnych działań klientów. Po złagodzeniu problemu oczekujemy, że pełna rezolucja zajmie wiele godzin, kiedy będziemy pracować nad przetworzeniem szacunkowych danych rachunkowych. Dostarczymy kolejną aktualizację do 6: 00 AM PDT lub wcześniej, jeśli więcej informacji stanie się dostępne.

6. 17 lipca 2026 12:54 UTCresolved

   Równolegle pracujemy nad wieloma ścieżkami łagodzenia skutków zmiany klimatu, aby rozwiązać problem wpływający na szacunkowe dane dotyczące kosztów i wykorzystania zawarte w konsoli do rozliczeń i zarządzania kosztami, w tym na sprawozdanie dotyczące kosztów i wykorzystania. Oceniamy wznowienie szacowanych obliczeń rozliczeń, ponieważ nasz wewnętrzny monitoring wskazuje, że podsystem obliczeń rozliczeń tworzy obecnie dokładne szacunki. Przeprowadzamy dodatkową walidację przed pójściem tą ścieżką. Wyświetlane szacunki nie odzwierciedlają rzeczywistego wykorzystania i opłat. W tej chwili nie wymaga się żadnych działań klientów. Dostarczymy kolejną aktualizację do 8: 00 AM PDT lub wcześniej, jeśli pojawi się więcej informacji.

7. 17 lipca 2026 14:53 UTCresolved

   Kontynuujemy prace nad rozwiązaniem problemu wpływającego na szacunkowe dane dotyczące kosztów i wykorzystania wyświetlane w konsoli Billing and Cost Management Console, w tym sprawozdanie dotyczące kosztów i wykorzystania. Cofnięcie ostatniej zmiany nie rozwiązało tej kwestii i nadal badamy wiele ścieżek łagodzących. Szacunkowe aktualizacje rachunków pozostają wstrzymane. Jesteśmy w trakcie powrotu do ostatnich dokładnych szacunkowych danych rachunkowych. Wyświetlane szacunki nie odzwierciedlają rzeczywistego wykorzystania i opłat. W tej chwili nie wymaga się żadnych działań klientów. Oczekujemy, że to ograniczenie zajmie kilka godzin, aby zakończyć pracę nad przetworzeniem szacunkowych danych rachunkowych. Dostarczymy kolejną aktualizację do 10: 00 AM PDT lub wcześniej, jeśli więcej informacji stanie się dostępne.

8. 17 lipca 2026 16:59 UTCresolved

   Zidentyfikowaliśmy przyczynę i złagodziliśmy problem powodujący wyświetlanie nieprawidłowych szacunkowych danych dotyczących kosztów i wykorzystania w konsoli Billing and Cost Management Console oraz Cost and Usage Reports. Rozpoczęliśmy uzupełnianie danych w celu skorygowania kosztów dla wszystkich klientów. Oczekujemy, że niektórzy klienci zaczną widzieć poprawę w ciągu najbliższych trzech godzin, a pełne odzyskanie dla wszystkich klientów do 18 lipca 12: 00 PM PDT. Dopóki backfill nie jest kompletny, niektórzy klienci mogą nadal zobaczyć błędne dane dotyczące kosztów i wykorzystania. Wyświetlane szacunki nie odzwierciedlają rzeczywistego wykorzystania i opłat. W tej chwili nie wymaga się żadnych działań klientów. Dostarczymy kolejną aktualizację do 1: 00 PM, lub wcześniej, jeśli informacje staną się dostępne.

9. 17 lipca 2026 19:56 UTCresolved

   Nasze wysiłki na rzecz uzupełnienia skorygowanych szacunkowych danych dotyczących kosztów i wykorzystania nadal trwają. Postępujemy wolniej niż przewidywano. Podczas gdy widzimy, że niektóre konta odzyskują się z poprawnymi danymi dotyczącymi kosztów i wykorzystania, oczekujemy, że wszystkie konta, których to dotyczy, zostaną odzyskane do 19 lipca 12: 00 AM PDT. Dopóki backfill nie jest kompletny, niektórzy klienci mogą nadal zobaczyć błędne dane dotyczące kosztów i wykorzystania. Wyświetlane szacunki nie odzwierciedlają rzeczywistego wykorzystania i opłat. W tej chwili nie wymaga się żadnych działań klientów. Dostarczymy kolejną aktualizację do 7: 00 PM, lub wcześniej, jeśli informacje staną się dostępne.

10. 18 lipca 2026 01:38 UTCresolved

    Nadal czynimy stałe postępy w rozwiązywaniu problemu wpływającego na szacunkowe koszty i wykorzystanie danych wyświetlanych w konsoli Billing and Cost Management Console. Nasze wysiłki na rzecz uzupełniania skorygowanych danych nadal trwają i oczekujemy, że wszystkie wpływające na nie rachunki zostaną w pełni odzyskane do 19 lipca, 12: 00 AM PDT. Dopóki backfill nie zostanie ukończony, niektórzy klienci mogą nadal obserwować nieprawidłowe dane dotyczące kosztów i wykorzystania w konsoli Billing and Cost Management Console oraz Cost and Usage Reports. Szacunki te nie odzwierciedlają rzeczywistego wykorzystania lub opłat. Klienci, którzy skonfigurowali swój raport kosztów i użytkowania z opcją "Zastąp" nie wymagają żadnych działań - ich raport będzie automatycznie aktualizowany z poprawionymi danymi po zakończeniu backfill. Klienci, którzy skonfigurowali swój raport kosztów i użytkowania z opcją "Tworzenie nowych wersji raportu" zachowują wszystkie poprzednie dostawy raportu w swoim wiadrze S3. Wersja raportu dostarczona w czasie uderzenia może zawierać niedokładne dane. Po zakończeniu wypełniania backfill danych, poprawiona wersja raportu zostanie dostarczona w ramach nowego assemblyId. Klienci korzystający z tej konfiguracji powinni aktualizować wszelkie procesy niższego szczebla (tabele Athena, rurociągi Redshift, Amazon QuickSight lub niestandardowe ETL) w celu odniesienia się do najnowszego assemblyId dla danego okresu rozliczeniowego, a także mogą usunąć lub archiwizować poprawną wersję raportu, aby zapobiec przetwarzaniu niejasnych danych. Aby zidentyfikować najnowszy raport, klienci mogą śledzić kroki w naszym < a href = "https: / / docs.aws.amazon.com / cur / last / userguide / view- latest- cur.html" > dokumentacja < / a >. Dostarczymy kolejną aktualizację do 18 lipca, 1: 00 AM PDT, lub wcześniej, jeśli dodatkowe informacje staną się dostępne.

11. 18 lipca 2026 08:05 UTCresolved

    Nadal czynimy znaczne postępy w rozwiązywaniu problemu wpływającego na szacunkowe dane dotyczące kosztów i wykorzystania wyświetlane w konsoli Billing and Cost Management Console. Nasze wysiłki w zakresie łagodzenia zmiany klimatu działają zgodnie z oczekiwaniami i obserwujemy coraz większą liczbę rachunków odzwierciedlających prawidłowe dane dotyczące kosztów i wykorzystania. Oczekujemy, że wszystkie dotknięte konta zostaną w pełni odzyskane do 19 lipca, 12: 00 PDT. Dopóki backfill nie zostanie ukończony, niektórzy klienci mogą nadal obserwować nieprawidłowe dane dotyczące kosztów i wykorzystania w konsoli Billing and Cost Management Console oraz Cost and Usage Reports. Szacunki te nie odzwierciedlają rzeczywistego wykorzystania lub opłat. Dostarczymy kolejną aktualizację do 18 lipca, 7: 00 AM PDT, lub wcześniej, jeśli dodatkowe informacje staną się dostępne.

12. 18 lipca 2026 13:57 UTCresolved

    Między 16 lipca o 7: 38 PM PDT a 18 lipca o 6: 00 AM PDT, zaczęliśmy wyświetlać błędne dane księgowe w konsoli Billing and Cost Management Console, w tym raport kosztów i użytkowania. Klienci mogli otrzymywać błędne ostrzeżenia o wykrywaniu nieprawidłowości w budżecie i koszcie oraz obserwować zawyżone dane szacunkowe dotyczące kosztów i wykorzystania. 16 lipca o 7: 46 PM PDT, nasze alarmy wykryły anomalie kosztów, ale nie udało się zatrzymać szacowanego procesu generowania rachunków lub ostrzec naszych zespołów inżynieryjnych. Zostaliśmy powiadomieni o tej sprawie 17 lipca o 12: 19 AM PDT przez eskalację klientów, i natychmiast zaczęli badać. Po raz pierwszy poinformowaliśmy klientów poprzez AWS Health 17 lipca o 1: 33 rano. O 8: 24 AM PDT przerwaliśmy dalsze aktualizacje szacunkowych danych rozliczeniowych i wyłączyliśmy alarmy o nieprawidłowościach budżetowych i kosztowych jako środek zapobiegawczy. 17 lipca o godzinie 12: 00 zidentyfikowaliśmy przyczynę pierwotną PDT jako zmianę konfiguracji naszego systemu obliczania rachunków. System ten opiera się na danych dotyczących konwersji jednostek w celu obliczenia opłat za pozycje linii. Zmiana konfiguracji spowodowała niepowodzenie aktualizacji danych dotyczących konwersji jednostek, co spowodowało zawyżone koszty pozycji linii, które rozprzestrzeniły się na konsolę Billing and Cost Management oraz wywołało alarmy o nieprawidłowościach budżetowych i kosztowych. Zminimalizowaliśmy tę kwestię 17 lipca o 12: 30 PM PDT, co poprawiło konfigurację konwersji jednostki i rozpoczęło ponowne przetwarzanie danych dotyczących kosztów i wykorzystania dla wszystkich kont klientów. Zaczęliśmy obserwować odzyskanie o 4: 19 PM PDT, a większość kont została w pełni odzyskana do 18 lipca o 6: 00 AM PDT. Istnieje niewielka liczba kont nadal przetwarzanych, a my zamieścimy aktualizacje tych kont na tablicy osobistej zdrowia. Poprawiliśmy nasze alarmy, aby natychmiast wstrzymać przetwarzanie i powiadomić nasze zespoły inżynieryjne, kiedy wystąpią anomalie. Przepraszamy za alarm, który spowodował ten incydent naszych klientów i prowadzą gruntowną retrospektywę, aby zapobiec powtórzeniu się takich wydarzeń, jak również poprawić naszą reakcję w przypadku wystąpienia incydentów rozliczeń. Problem został rozwiązany i wszystkie usługi AWS działają teraz normalnie.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 16 lipca 2026 08:44 UTCresolved

   Badamy zwiększone błędy 5xx dla klientów Cloudfront wykorzystujących łączność VPC Origins.

2. 16 lipca 2026 09:21 UTCresolved

   Zaczynając od 12: 45 AM PDT, doświadczamy zwiększonych błędów 5xx dla klientów CloudFront wykorzystujących łączność VPC Origins. Potwierdziliśmy, że ta kwestia nie wpływa na klientów wykorzystujących inne rodzaje pochodzenia. Nasi inżynierowie są zaangażowani i aktywnie pracują nad złagodzeniem skutków. W ramach pracy, klienci, którzy nie wymagają VPC Origins mogą zmienić swój typ pochodzenia, aby rozwiązać błędy. Dostarczymy kolejną aktualizację do 3: 15 AM PDT, lub wcześniej, jeśli więcej informacji stanie się dostępne.

3. 16 lipca 2026 10:18 UTCresolved

   Nadal pracujemy nad rozwiązaniem zwiększonych błędów 5xx dla klientów CloudFront wykorzystujących łączność VPC Origins. Ta kwestia nie ma wpływu na klientów wykorzystujących inne rodzaje pochodzenia. Opierając się na naszym dochodzeniu, uważamy, że przyczyna jest związana z podsystemem przetwarzania pakietów, odpowiedzialnym za kierowanie wniosków z lokalizacji krawędzi CloudFront do zasobów w obrębie VPC klientów. Nadal zalecamy, aby klienci, którzy są w stanie to zrobić tymczasowo zmienić swój typ pochodzenia, aby rozwiązać błędy. Dostarczymy kolejną aktualizację do 4: 15 AM PDT, lub wcześniej, jeśli dodatkowe informacje staną się dostępne.

4. 16 lipca 2026 11:16 UTCresolved

   Nadal pracujemy nad rozwiązaniem zwiększonych błędów 5xx dla klientów CloudFront wykorzystujących łączność VPC Origins. Ta kwestia nie ma wpływu na klientów wykorzystujących inne rodzaje pochodzenia. Przeanalizowaliśmy tę kwestię w dół do pojemności tabeli routingu w ramach podsystemu przetwarzania pakietów odpowiedzialnego za wnioski o routing z lokalizacji krawędzi CloudFront do zasobów w obrębie VPC klientów. Zidentyfikowaliśmy i obecnie badamy strategię łagodzenia zmiany klimatu w celu rozwiązania tej kwestii. Po zakończeniu testów wdrożymy środki łagodzące w sposób stopniowy. Opierając się na wynikach tych testów, zapewnimy jaśniejszy, szacunkowy czas na rezolucję w naszej następnej aktualizacji. Nadal zalecamy, aby klienci, którzy są w stanie to zrobić tymczasowo zmienić swój typ pochodzenia, aby rozwiązać błędy. Dostarczymy kolejną aktualizację do 5: 15 AM PDT, lub wcześniej, jeśli dodatkowe informacje staną się dostępne.

5. 16 lipca 2026 11:27 UTCresolved

   Widzimy początkowe oznaki powrotu do zdrowia i nadal pracujemy nad pełnym powrotem do zdrowia.

6. 16 lipca 2026 11:57 UTCresolved

   Nadal dostrzegamy znaczące oznaki ożywienia w wyniku naszych wysiłków na rzecz łagodzenia zmiany klimatu, przy czym w ciągu najbliższych 45 minut spodziewamy się pełnego ożywienia.

7. 16 lipca 2026 12:21 UTCresolved

   Między 12: 45 AM a 4: 18 AM PDT, doświadczyliśmy zwiększonych błędów 5xx dla klientów CloudFront wykorzystujących łączność VPC Origins. Nasi inżynierowie byli automatycznie zaangażowani i natychmiast zaczęli badać przyczynę. Do 2: 57 AM PDT, zidentyfikowaliśmy główną przyczynę problemu jako wewnętrzne ograniczenie floty, która zarządza połączeniami do prywatnych początków VPC. Po osiągnięciu tego ograniczenia system odpowiedzialny za dystrybucję konfiguracji routingu do naszych procesorów sieciowych nie załadował poprawnie zaktualizowanych danych konfiguracyjnych, wpływając na routing połączeń VPC Origin. O 3: 52 AM PDT, podjęliśmy wiele działań łagodzących, które doprowadziły do pełnego powrotu do zdrowia o 4: 18 AM PDT. Teraz, gdy problem został złagodzony, klienci, którzy tymczasowo zmienili swój rodzaj pochodzenia mogą bezpiecznie odwrócić te zmiany. Kwestia ta nie miała wpływu na klientów korzystających z innych rodzajów pochodzenia. Problem został rozwiązany i usługa działa normalnie.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 15 lipca 2026 23:11 UTCresolved

   Badamy podniesione problemy z łącznością z jedną strefą Awalability (euc1-az2) w regionie EU-CENTRAL-1.

2. 15 lipca 2026 23:36 UTCresolved

   Widzimy wczesne oznaki powrotu do zdrowia i nadal pracujemy nad pełną rezolucją. Będziemy nadal dostarczać aktualizacje.

3. 16 lipca 2026 01:24 UTCresolved

   Między 2: 56 PM a 6: 07 PM PDT, doświadczyliśmy problemów z dostępem do podzbioru instancji EC2 w jednej strefie dostępności (euch1-az2) w regionie EU- CENTRAL-1. W tym czasie klienci mogli również doświadczyć zwiększonego poziomu błędów i opóźnień w uruchamianiu nowych instancji w strefie dotkniętej, wraz z niektórymi AWS API, które korzystają z dotkniętych instancji EC2. Niektóre usługi AWS również doświadczyły problemów związanych z łącznością i zwiększyły poziom błędów w strefie dotkniętej problemem. Inżynierowie byli automatycznie zaangażowani i natychmiast rozpoczęli śledztwo. W ramach naszych wysiłków na rzecz odbudowy, przesunęliśmy ruch z strefy dostępności dla poszkodowanych usług o 15: 04. O 15: 05 zidentyfikowaliśmy główną przyczynę niedawnej zmiany sieciowej wywołującej skutki. Inżynierowie natychmiast zaczęli cofać tę zmianę, która zakończyła się o 16: 28. Doprowadziło to do przywrócenia łączności sieciowej do dotkniętej strefy o godz. 16.30. Kontynuowaliśmy pracę do czasu całkowitego odzyskania skutków o 18: 07. Nie oczekujemy ponownego wystąpienia tej kwestii. Problem został rozwiązany i usługa działa normalnie.

Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.

1. 6 lipca 2026 12:45 UTCresolved

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

2. 6 lipca 2026 13:34 UTCresolved

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

3. 6 lipca 2026 14:12 UTCresolved

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

4. 6 lipca 2026 14:53 UTCresolved

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

1. 30 czerwca 2026 21:02 UTCresolved

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

2. 30 czerwca 2026 21:21 UTCresolved

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

3. 30 czerwca 2026 21:29 UTCresolved

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

4. 30 czerwca 2026 21:53 UTCresolved

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

1. 13 czerwca 2026 01:26 UTCresolved

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

2. 15 czerwca 2026 18:13 UTCresolved

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

1. 6 czerwca 2026 04:24 UTCresolved

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

1. 22 maja 2026 23:38 UTCresolved

   We are investigating increased error rates for Route53 API calls.

2. 23 maja 2026 00:13 UTCresolved

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

1. 8 maja 2026 00:25 UTCresolved

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

2. 8 maja 2026 00:53 UTCresolved

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

3. 8 maja 2026 01:47 UTCresolved

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

4. 8 maja 2026 03:06 UTCresolved

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

5. 8 maja 2026 05:11 UTCresolved

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

6. 8 maja 2026 06:38 UTCresolved

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

7. 8 maja 2026 08:32 UTCresolved

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

8. 8 maja 2026 10:54 UTCresolved

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

9. 8 maja 2026 13:51 UTCresolved

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

10. 8 maja 2026 15:58 UTCresolved

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

11. 8 maja 2026 16:30 UTCresolved

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

12. 8 maja 2026 18:12 UTCresolved

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

13. 8 maja 2026 19:29 UTCresolved

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

14. 8 maja 2026 23:00 UTCresolved

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

15. 9 maja 2026 03:04 UTCresolved

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

1. 27 kwietnia 2026 11:27 UTCresolved

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

2. 27 kwietnia 2026 12:05 UTCresolved

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

1. 7 marca 2026 19:53 UTCresolved

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

2. 7 marca 2026 20:17 UTCresolved

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

3. 7 marca 2026 20:28 UTCresolved

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

4. 7 marca 2026 21:04 UTCresolved

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

1. 2 marca 2026 05:56 UTCresolved

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

2. 2 marca 2026 07:09 UTCresolved

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

3. 2 marca 2026 09:03 UTCresolved

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

4. 2 marca 2026 10:41 UTCresolved

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

5. 2 marca 2026 14:23 UTCresolved

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

6. 2 marca 2026 18:52 UTCresolved

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

7. 2 marca 2026 22:29 UTCresolved

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

8. 3 marca 2026 00:22 UTCresolved

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

9. 3 marca 2026 06:27 UTCresolved

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

10. 3 marca 2026 11:10 UTCresolved

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

11. 3 marca 2026 14:02 UTCresolved

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

12. 3 marca 2026 16:40 UTCresolved

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

13. 30 kwietnia 2026 07:07 UTCinvestigating

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

14. 15 września 2026 10:22 UTCinvestigating

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