Istoricul incidentelor AWS

1. 4 octombrie 2026 la 16:14 UTCresolved

   Investigăm pierderi mari de pachete în regiunea UE-SOUTH-2.

2. 4 octombrie 2026 la 16:36 UTCresolved

   Avem pierderi mari de pachete cu o singură zonă de disponibilitate (eus2-az1) în regiunea UE-SOUTH-2. Această problemă duce, de asemenea, la creșterea API latențe și rate de eroare pentru alte fluxuri de lucru și servicii AWS. Inginerii au fost angajaţi automat şi lucrează la identificarea cauzei profunde şi la atenuarea problemei. Vă vom oferi o altă actualizare până la 10:15 AM PDT sau mai devreme ca noi informații devine disponibil.

3. 4 octombrie 2026 la 17:06 UTCresolved

   Eforturile noastre de a atenua pierderea ridicată a pachetelor cu o singură zonă de disponibilitate (eus2-az1) din regiunea UE-SOUTH-2 sunt încă în curs de desfășurare. Vedem unele semne de îmbunătățire ca urmare a eforturilor paralele multiple. Continuăm să lucrăm pentru a confirma cauza fundamentală și pentru a atenua pe deplin problema. Deşi în prezent nu avem o estimare pentru cât timp vor dura acţiunile noastre, vă vom ţine la curent cu progresul nostru şi vă vom furniza o altă actualizare până la ora 11:00 PDT sau mai devreme după ce noi informaţii vor fi disponibile.

4. 4 octombrie 2026 la 17:56 UTCresolved

   Am identificat cauza principală și ne concentrăm în prezent eforturile de atenuare pentru a conduce recuperarea completă. Deşi nu avem o estimare exactă pentru cât timp vor dura eforturile noastre actuale, ne aşteptăm să vedem îmbunătăţiri suplimentare pe măsură ce eforturile noastre continuă. Vă vom oferi o altă actualizare până la 11:45 AM PDT, sau mai devreme în cazul în care informațiile noi devin disponibile.

5. 4 octombrie 2026 la 18:45 UTCresolved

   Vedem semne timpurii de recuperare. Vă vom oferi o altă actualizare până la 12:00 PM PDT.

6. 4 octombrie 2026 la 18:56 UTCresolved

   Între orele 8:48 AM și 11:28 AM PDT, am înregistrat pierderi mari de pachete într-o singură zonă de disponibilitate (eus2-az1) în regiunea UE-SOUTH-2. Această problemă a dus la creșterea API latențe și rate de eroare pentru mai multe fluxuri de lucru și AWS Services. Am fost alertaţi automat cu privire la această problemă la ora 8:54 AM şi am început imediat să lucrăm pentru identificarea cauzei profunde în timp ce luăm mai multe căi paralele pentru a atenua această problemă. Până la ora 10:00, eforturile noastre de atenuare au dus la unele îmbunătățiri. Până la 10:38 AM, am identificat cauza rădăcină ca fiind legată de o schimbare a configurației de rețea pe care am reușit să o revenim la schimbarea care a dus la atenuarea completă până la 11:28 AM. Problema a fost rezolvată, iar serviciul funcționează normal.

Traducere automată din actualizarea oficială a incidentului.

1. 21 septembrie 2026 la 23:26 UTCresolved

   Investigăm rate crescute de eroare API în regiunea SUA-EAST-1.

2. 21 septembrie 2026 la 23:44 UTCresolved

   Putem confirma rate de eroare crescute care afectează lansări noi de instanță, inclusiv rate ridicate de eroare API pentru RunInvestments, CreateFleet, și fluxuri de lucru asociate de lansare EC2 în regiunea SUA-EAST-1. Clienții care încearcă să lanseze noi cazuri EC2 pot experimenta eșecuri de lansare sau latență crescută de răspuns API. Inginerii noştri sunt angajaţi activ şi lucrează la recuperarea problemei. Vedem semne iniţiale de recuperare. Cazurile existente rămân neafectate. Vă recomandăm să rejudecați RunInstances eșuate și CreateFleet API apeluri. Vom furniza o actualizare până la 5:30 PM PDT sau mai devreme.

3. 22 septembrie 2026 la 00:24 UTCresolved

   Între 3:49 PM și 5:06 PM PDT, am experimentat rate de eroare crescute care afectează noile lansări de instanță în regiunea SUA-EAST-1. În acest timp, este posibil ca clienții să fi avut rate de eroare ridicate atunci când au încercat să lanseze noi instanțe CE2 prin intermediul RunInstances, CreateFleet, și fluxuri de lucru de lansare CE2 aferente. Serviciile AWS care lansează cazuri EC2 în numele clienților, inclusiv Amazon ECS, AWS Fargate, Amazon EMR, au fost, printre altele, afectate în această perioadă. Am identificat cauza principală ca fiind o implementare recentă a unui subsistem în cadrul serviciului CE2 responsabil cu procesarea cererilor de lansare de exemplu. Am iniţiat o reluare a implementării problematice şi am început să observăm primele semne de recuperare la ora 4:44 PM. Cazurile existente rămân neafectate. Problema a fost rezolvată, iar serviciul funcționează normal.

Traducere automată din actualizarea oficială a incidentului.

1. 3 septembrie 2026 la 21:49 UTCresolved

   Incepand de la 2:12 PM PDT, am inceput sa experimentam rate crescute de eroare API pentru STS si sa ne inregistram cand folosim SAML in Regiunea US-WEST-2. Echipa noastră de ingineri a fost angajată automat la 2:19 PM pentru a începe investigarea cauzei profunde. Nu există nici o muncă disponibilă în acest moment. Vom furniza o altă actualizare până la 3:30 PM PDT.

2. 3 septembrie 2026 la 22:26 UTCresolved

   Vedem semne timpurii de recuperare şi continuăm să monitorizăm recuperarea completă. Vom furniza o altă actualizare la 4:15 PM, sau mai devreme dacă avem informații suplimentare pentru a partaja.

3. 3 septembrie 2026 la 23:20 UTCresolved

   Continuăm să vedem recuperarea menţinându-se constantă pentru STS AssumeRoleWithSAML şi AssumeRole WithWebIdentity APIs în regiunea US-WEST-2. Ratele de eroare au revenit la nivelurile anterioare evenimentului şi continuăm monitorizarea activă pentru a confirma recuperarea completă. Vom furniza o altă actualizare până la 5:15 PM sau mai devreme.

4. 4 septembrie 2026 la 00:07 UTCresolved

   Între 2:12 PM și 3:18 PM PDT, am experimentat rate crescute de eroare API care afectează STS AssumeRoleWithSAML și AssumeRoleWithWebIdentity APIs în regiunea US-WEST-2. Cauza principală a fost determinată ca urmare a unei probleme cu un subsistem STS responsabil cu comunicarea cu furnizorii externi de identitate. Au fost afectate și alte servicii AWS care se bazează pe aceste protocoale ale federației de identitate. La ora 3:18 PM am observat semne de recuperare şi am continuat să monitorizăm stabilitatea şi recuperarea completă. Problema este rezolvată și serviciul funcționează în mod normal în acest moment.

Traducere automată din actualizarea oficială a incidentului.

1. 21 august 2026 la 02:02 UTCresolved

   AP-NORTHEAST-1 Avem rate de eroare crescute care afectează indicatorii în timp real în regiunea AP-NORTHEAST-1. Clienții pot prezenta date metrice lipsă sau întârziate în timp real.

2. 21 august 2026 la 02:40 UTCresolved

   == Legături externe == 10:13 AM În acest timp, este posibil ca clienții să fi experimentat date lipsă în cadrul rapoartelor de analiză și să fi observat probleme în cazul accesării datelor în timp real în cadrul fluxurilor de contact, cum ar fi verificarea personalului agentului. Am identificat cauza principală pentru a fi o problemă cu subsistemul responsabil pentru livrarea evenimentului metric. Am început să aplicăm atenuările la 6:13 PM și am redus problema la 6:34 PM. Problema a fost rezolvată, iar serviciul funcționează normal.

Traducere automată din actualizarea oficială a incidentului.

1. 19 august 2026 la 15:15 UTCresolved

   Investigăm o problemă care are un impact asupra lansării unor noi cazuri și resurse CE2 într-o zonă de disponibilitate nou lansată (euw2-az4) în regiunea UE-WEST-2. În acest timp, clienții afectați pot experimenta probleme atunci când creează sau modifică resurse în regiune. Alte servicii AWS pot fi, de asemenea, afectate. Pentru recuperare imediată, recomandăm clienților să utilizeze zone de disponibilitate alternative (euw2-az1, euw2-az2, și euw2-az3), după caz. Cazurile și resursele existente în funcționare nu sunt afectate. Vom furniza o altă actualizare până la ora 10:00 PDT, sau mai devreme dacă avem informații suplimentare pentru a partaja.

2. 19 august 2026 la 17:03 UTCresolved

   La 18 august am lansat o nouă zonă de disponibilitate (euw2-az4) în regiunea UE-WEST-2. După lansare, am început să experimentăm erori lansând cazuri EC2 în noua zonă de disponibilitate atunci când o subnet implicit nu este prezent. Putem confirma că actualele cazuri și resurse existente nu sunt afectate. Fluxurile de lucru care primesc automat o listă de zone de disponibilitate în regiune prin intermediul DescrieAvailabilityZones API și apoi încearcă să lanseze noi cazuri sau să creeze resurse în noua zonă de disponibilitate pot întâmpina erori. În ceea ce privește eșecurile lansării CE2, luăm măsuri de atenuare pentru a crea automat subneturi implicite, unde unul nu este deja prezent, atunci când o lansare de instanță CE2 vizează noua zonă de disponibilitate. Pentru clienții și fluxurile de lucru care necesită o remediere imediată <a href="https://docs.aws.amazon.com/vpc/ultima/userguide/work-with-default-vpc.html#create-default-subnet [62], puteți crea o subnetă implicită</a> în noua zonă de disponibilitate. Acest lucru va permite lansărilor de instanță CE2 să se finalizeze cu succes. Pentru alte resurse, cum ar fi funcțiile Lambda, în cazul în care noua zonă de disponibilitate nu este în prezent susținută, recomandăm clienților actualizarea fluxurilor lor de lucru pentru a exclude zona de disponibilitate nou lansată și pentru a continua crearea de resurse folosind celelalte zone de disponibilitate din regiune. Deşi nu avem o estimare exactă pentru cât timp vor dura eforturile noastre de atenuare, vă vom ţine la curent cu progresul nostru şi vă vom furniza o altă actualizare până la ora 1:00 PDT sau mai devreme după ce noi informaţii vor fi disponibile.

3. 19 august 2026 la 18:47 UTCresolved

   În perioada 18 august 5:00 - 19 august 11:00 AM PDT, am experimentat erori ridicate lansând cazuri EC2 într-o zonă de disponibilitate nou lansată (euw2-az4) în regiunea UE-WEST-2. După lansarea noii zone de disponibilitate, am început să experimentăm erori atunci când folosim un VPC implicit. Am descoperit cauza principală a problemei pe 19 august la ora 9:00 şi am început să efectuăm o schimbare pentru rezolvarea problemei la ora 9:30 AM. În timp ce schimbarea a fost în curs de desfășurare, am început să vedem îmbunătățiri suplimentare în noile lansări de instanță, cu recuperare completă la ora 11:00 AM. Cazurile existente și resursele existente nu au fost afectate. Unele servicii regionale, cum ar fi funcțiile Lambda sau bazele de date Aurora, nu au fost disponibile la lansarea noii Zone de disponibilitate, iar disponibilitatea serviciilor va fi adăugată în timp. Clientii care incearca sa creeze resurse inainte ca serviciile sa devina disponibile vor vedea un mesaj raportand ca nu este sprijinit in Zona Availabila. Problema a fost rezolvată, iar serviciul funcționează normal.

Traducere automată din actualizarea oficială a incidentului.

1. 15 august 2026 la 03:42 UTCresolved

   Investigăm creșterea pierderilor de pachete, impactul asupra conectivității AWS Direct Connect pentru unii clienți din regiunea UE-CENTRAL-1.

2. 15 august 2026 la 04:42 UTCresolved

   Putem confirma pierderea pachetelor care afectează conexiunile directe în regiunea UE-CENTRAL-1. Inginerii au fost angajaţi automat şi au început imediat să lucreze atât pentru a identifica cauza rădăcină, şi identifica mai multe căi paralele pentru a atenua problema. În acest moment, vedem semne timpurii de recuperare. Vom furniza o altă actualizare în 60 de minute, sau mai devreme dacă avem informații suplimentare pentru a partaja.

3. 15 august 2026 la 05:55 UTCresolved

   Începând de la ora 7:33 PM PDT, am început să experimentăm o pierdere crescută de pachete care afectează conectivitatea AWS Direct Connect pentru unii clienți din regiunea UE-CENTRAL-1. În timp ce am făcut progrese, conexiunile la următoarea locație Direct Connect sunt încă afectate: Equinix FR5, Frankfurt, DEU. Clienţii care au redundanţă multi-site configurată cu traseele lor Direct Connect nu trebuie să observe impactul în acest moment. Clienții care au doar conexiuni la Equinix FR5, Frankfurt, DEU vor continua să aibă probleme de conectivitate. Suntem activ de lucru pentru a atenua impactul și munca spre recuperare completă, dar se așteaptă recuperarea completă este de mai multe ore distanță. Vom furniza o actualizare în 90 de minute, sau mai devreme dacă avem informații suplimentare pentru a partaja.

4. 15 august 2026 la 07:24 UTCresolved

   Lucrăm în mod activ pentru a restabili conectivitatea prin intermediul locației Direct Connect: Equinix FR5, Frankfurt, DEU. Clienții care au doar conexiuni la Equinix FR5, Frankfurt, DEU vor continua să aibă probleme de conectivitate. Pentru o analiză a clienților afectați care au opțiunea disponibilă de a eşua la VPN se recomandă să se facă acest lucru pentru a realiza recuperarea. Pentru clienţii care utilizează portalul Direct Connect şi Transit Gateway, recomandăm crearea unui AWS Site-to-Site VPN şi ataşarea acestuia la Transit Gateway, consultaţi paşii <a href="https://aws.amazon.com/premium support/cunoastere-centru/dx-configure-dx-and-vpn-failover-tgw/Europhere</a>. Pentru alti clienti recomandam stabilirea unui AWS Site-to-Site VPN ca o cale de backup temporara, referindu-se la pasii <a href="https://docs.aws.amazon.com/vpn/test/s2svpn/SetUpVPnconnections.html Din acest moment, ne așteptăm recuperare este de mai multe ore distanță. Vom furniza o altă actualizare în 90 de minute, sau mai devreme dacă avem informații suplimentare pentru a partaja.

5. 15 august 2026 la 09:08 UTCresolved

   Continuăm să lucrăm pentru recuperarea conectivității pentru conexiunile AWS Direct Connect la Equinix FR5, Frankfurt, DEU. Cauza principală este legată de o problemă de infrastructură a infrastructurii de infrastructură la locul care afectează infrastructura rețelei. Clienții cu conexiuni exclusiv la această locație vor continua să experimenteze pierderea pachetelor sau degradarea conectivității. Clienţii cu configuraţii multi-site sau redundante în alte locaţii nu sunt afectaţi. Pentru o analiză, se recomandă clienţilor afectaţi care au opţiunea de a eşua la VPN. Pentru clienţii care utilizează portalul Direct Connect şi Transit Gateway, vă recomandăm crearea unui AWS Site-to-Site VPN şi ataşarea acestuia la poarta dumneavoastră Transit Gateway, consultaţi paşii <a href="https://aws.amazon.com/premium support/cunoastere-centru/dx-configuration-dx-and-vpn-failover-tgw/phere</a>. Pentru alţi clienţi, recomandăm stabilirea unui AWS Site-to-Site VPN ca o cale de rezervă temporară, să se refere la paşii <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPnconnections.html [57]here</a>. Din acest moment, ne așteptăm recuperare este de mai multe ore distanță. Vom furniza o altă actualizare în termen de 2 ore sau de îndată ce avem mai multe informații pentru a partaja.

6. 15 august 2026 la 11:10 UTCresolved

   Conectivitatea AWS Direct Connect rămâne afectată pentru clienții cu conexiuni la locația Equinix FR5 din Frankfurt, DEU. Clienții cu configurații multi-site sau redundante în alte locații continuă să fie neafectați. Inginerii lucrează în mod activ la restabilirea conectivității, eforturile fiind în curs de desfășurare în cadrul mai multor fluxuri de lucru pentru a soluționa problema instalației subiacente și pentru a readuce în funcțiune echipamentele de rețea afectate. Ne aşteptăm ca recuperarea să fie la mai multe ore distanţă. Pentru un lucru în jurul, clienții cu impact care au opțiunea de a eșua la VPN sunt recomandați să facă acest lucru. Pentru clienţii care utilizează portalul Direct Connect şi Transit Gateway, vă recomandăm crearea unui AWS Site-to-Site VPN şi ataşarea acestuia la poarta dumneavoastră Transit Gateway, consultaţi paşii <a href="https://aws.amazon.com/premium support/cunoastere-centru/dx-configuration-dx-and-vpn-failover-tgw/phere</a>. Pentru alţi clienţi, recomandăm stabilirea unui AWS Site-to-Site VPN ca o cale de rezervă temporară, să se refere la paşii <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPnconnections.html [57]here</a>. Vom furniza o altă actualizare în termen de 2 ore sau de îndată ce avem mai multe informații pentru a partaja.

7. 15 august 2026 la 13:17 UTCresolved

   Inginerii continuă să lucreze pentru restabilirea conectivității la Equinix FR5 din Frankfurt, DEU. Partenerul nostru de colocaţie lucrează la soluţionarea problemei infrastructurii de bază şi, în timp ce îmbunătăţirile nu sunt încă vizibile pentru clienţi, facem progrese pozitive către soluţionare. Pentru clienţii care necesită recuperare imediată, vă recomandăm să eşuaţi la VPN, aşa cum este subliniat în actualizările noastre anterioare. Vom furniza o altă actualizare până la 9:30 AM PDT, sau mai devreme dacă avem informații suplimentare pentru a partaja.

8. 15 august 2026 la 16:27 UTCresolved

   Partenerul nostru de colocaţie continuă să lucreze pentru rezolvarea problemei infrastructurii de bază la sediul Equinix FR5 din Frankfurt, DEU. Accesul la zona afectată este în prezent limitat din cauza preocupărilor legate de siguranță, care afectează capacitatea noastră de a evalua starea fizică a echipamentelor de rețea și de a oferi un calendar de recuperare mai precis. Pe baza informaţiilor actuale, nu se aşteaptă o recuperare completă pe termen apropiat şi se poate extinde dincolo de prezent. Conexiunile AWS Direct Connect la această locație rămân afectate. Clienții cu conexiuni redundante prin alte locații rămân neafectați. Pentru clienţii care utilizează portalul Direct Connect şi Transit Gateway, vă recomandăm crearea unui AWS Site-to-Site VPN şi ataşarea acestuia la poarta dumneavoastră Transit Gateway, consultaţi paşii <a href="https://aws.amazon.com/premium support/cunoastere-centru/dx-configuration-dx-and-vpn-failover-tgw/phere</a>. Pentru alţi clienţi, recomandăm stabilirea unui AWS Site-to-Site VPN ca o cale de rezervă temporară, să se refere la paşii <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPnconnections.html [57]here</a>. Vom furniza o altă actualizare până la 3:30 PM PDT, sau mai devreme dacă avem informații suplimentare pentru a partaja.

9. 15 august 2026 la 22:26 UTCresolved

   Partenerul nostru de colocaţie continuă să lucreze pentru a restabili accesul sigur în zona afectată la locaţia Equinix FR5 din Frankfurt, DEU. Odată ce accesul în condiții de siguranță a fost asigurat, inginerii noștri vor putea evalua dispozitivele de rețea afectate. Continuăm să urmărim îndeaproape progresul și vom partaja o actualizare până la 9:30 PM PDT, sau mai devreme ca noi informații devin disponibile.

10. 16 august 2026 la 04:37 UTCresolved

    Ne-am angajat activ cu partenerul nostru de colocație pentru a restabili conectivitatea la adresa Equinix FR5 din Frankfurt, DEU. De la ultima noastră actualizare, am făcut progrese incrementale pentru a restabili accesul sigur la zona afectată la locația Equinix FR5 din Frankfurt, DEU. În paralel, am prioritizat ordinea în care vor fi restaurate rafturile critice şi prioritare, ca parte a eforturilor de atenuare. Pe baza evaluării noastre actuale, nu se preconizează o redresare completă pe termen apropiat și s-ar putea extinde dincolo de prezent. Conexiunile AWS Direct Connect la această locație rămân afectate. Clientii cu conexiuni exclusiv la aceasta locatie vor continua sa experimenteze pierderea pachetelor. Clienții cu configurații multi-site sau redundante în alte locații Direct Connect rămân neafectați. Pentru o analiză, se recomandă clienţilor afectaţi care au opţiunea de a eşua la VPN. Pentru clienţii care utilizează portalul Direct Connect şi Transit Gateway, vă recomandăm crearea unui AWS Site-to-Site VPN şi ataşarea acestuia la poarta dumneavoastră Transit Gateway, consultaţi paşii <a href="https://aws.amazon.com/premium support/cunoastere-centru/dx-configuration-dx-and-vpn-failover-tgw/phere</a>. Pentru alţi clienţi, recomandăm stabilirea unui AWS Site-to-Site VPN ca o cale de rezervă temporară, să se refere la paşii <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPnconnections.html [57]here</a>. Continuăm să urmărim îndeaproape progresul și vom partaja o actualizare până la 16 august 3:30 AM PDT, sau mai devreme ca noi informații devine disponibil.

11. 16 august 2026 la 10:25 UTCresolved

    Continuăm să lucrăm cu partenerul nostru de colocaţie pentru a restabili conectivitatea la locaţia Equinix FR5 din Frankfurt, DEU. De la ultima noastră actualizare, am făcut progrese semnificative în vederea restabilirii accesului sigur în zona afectată. Procedura de izolare electrică este acum în curs de desfășurare, cu echipele noastre pe site-ul în camera electrică de executare de de-energizare a infrastructurii afectate. Odată ce izolarea este verificată și confirmată în condiții de siguranță, inginerii vor începe o inspecție fizică a echipamentelor de rețea afectate pentru a determina domeniul de aplicare a înlocuirii necesare. Pe baza evaluării noastre actuale, nu se preconizează o recuperare completă în viitorul apropiat din cauza domeniului de aplicare a potenţialului impact asupra echipamentelor. Conexiunile AWS Direct Connect la această locație rămân afectate. Clientii cu conexiuni exclusiv la aceasta locatie vor continua sa experimenteze pierderea pachetelor. Clienții cu configurații multi-site sau redundante în alte locații Direct Connect rămân neafectați. Pentru o analiză, se recomandă clienţilor afectaţi care au opţiunea de a eşua la VPN. Pentru clienţii care utilizează portalul Direct Connect şi Transit Gateway, vă recomandăm crearea unui AWS Site-to-Site VPN şi ataşarea acestuia la poarta dumneavoastră Transit Gateway, consultaţi paşii <a href="https://aws.amazon.com/premium support/cunoastere-centru/dx-configuration-dx-and-vpn-failover-tgw/phere</a>. Pentru alţi clienţi, recomandăm stabilirea unui AWS Site-to-Site VPN ca o cale de rezervă temporară, să se refere la paşii <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPnconnections.html [57]here</a>. Continuăm să urmărim îndeaproape progresul și vom partaja o actualizare până la 16 august 9:30 AM PDT, sau mai devreme ca noi informații devin disponibile.

12. 16 august 2026 la 16:30 UTCresolved

    Izolarea electrică de la Equinix FR5 din Frankfurt, Deu este acum completă şi inginerii noştri au început să inspecteze fizic echipamentul de reţea afectat. Încă nu avem un calendar pentru o rezoluție completă, în timp ce continuăm să evaluăm amploarea impactului asupra echipamentelor. Conectarea directă la această locație rămâne afectată. Clientii cu conexiuni exclusiv la aceasta locatie vor continua sa experimenteze pierderea pachetelor. Clienţii cu configuraţii multi-site sau redundante în alte locaţii Direct Connect nu sunt afectaţi. Vă recomandăm ca clienţii afectaţi să eşueze la VPN până când vom avea mai multă claritate cu privire la etapele următoare şi un calendar de recuperare. Pentru clienții care utilizează Poarta Direct Connect și Transit Gateway, puteți crea un AWS Site-to-Site VPN și să-l atașați la Poarta de Tranzit, consultați pașii <a href="https://aws.amazon.com/premium support/cunoștințe-centru/dx-configurare-dx-and-vpn-failover-tgw/enphere</a>. Pentru alti clienti, recomandam stabilirea unui AWS Site-to-Site VPN ca o cale de rezerva temporara, se refera la pasii <a href="https://docs.aws.amazon.com/vpn/ultima/s2svpn/SetUpVPnconnections.html Vom furniza o altă actualizare până la 16 august 5:30 PM PDT, sau mai devreme ca noi informații devine disponibile.

13. 16 august 2026 la 22:51 UTCresolved

    Ne-am finalizat evaluarea echipamentelor de rețea afectate la locația Equinix FR5 din Frankfurt, DEU și acum avem o înțelegere clară a sferei impactului. Facem progrese în direcția restabilirii conectivității și vom lua o abordare treptată a remedierii. Clientii cu conexiuni exclusiv la aceasta locatie vor continua sa experimenteze pierderea pachetelor pana cand remedierea este completa. Clienţii cu configuraţii multi-site sau redundante în alte locaţii Direct Connect nu sunt afectaţi. Vom furniza o altă actualizare până la 16 august 10:30 PM PDT, sau mai devreme ca noi informații devine disponibil.

14. 17 august 2026 la 05:38 UTCresolved

    Continuăm să facem progrese în ceea ce privește remedierea treptată a situației Equinix FR5 din Frankfurt, DEU. De la ultima actualizare, o infrastructură de rețea dependentă a fost restaurată. Remediarea infrastructurii rămase este în curs de desfășurare, o parte din recuperare fiind dependentă de livrarea hardware-ului de înlocuire. Răcirea a fost restabilită complet, condiţiile de mediu fiind stabile în limitele pragurilor normale de funcţionare. Clientii cu conexiuni exclusiv la aceasta locatie vor continua sa experimenteze pierderea pachetelor pe masura ce de remediere progreseaza. Clienţii cu configuraţii multi-site sau redundante în alte locaţii Direct Connect nu sunt afectaţi. Orientările și recomandările privind atenuarea comunicate anterior rămân neschimbate în acest moment. Vom furniza o altă actualizare până la 17 august 4:30 AM PDT, sau mai devreme ca remediere progresează.

15. 17 august 2026 la 11:22 UTCresolved

    Continuăm să facem progrese în ceea ce privește remedierea treptată a situației Equinix FR5 din Frankfurt, DEU. Infrastructura de rețea și sistemele dependente continuă să se îmbunătățească pe măsură ce aducem hardware-ul afectat înapoi online. A fost livrat un echipament de înlocuire, iar instalarea este în curs de desfășurare pe măsură ce componentele sosesc la fața locului. În paralel, schimbăm traficul de rețea pentru a permite dispozitivelor restaurate să înceapă să servească clienții pe măsură ce aceștia vin online. Pe măsură ce progresăm prin recuperare, clienții vor observa restaurarea în două etape. În prima etapă, sesiunile BBP vor restabili însă prefixele IP nu vor fi încă anunțate, ceea ce indică faptul că redresarea este încă în curs de desfășurare și infrastructura de bază nu este încă pregătită să transporte traficul. În cea de-a doua etapă, anunţul prefix IP se va relua, moment în care infrastructura este complet mediată şi conectivitatea este restabilită. Deși nu avem în prezent un ETA pentru recuperarea completă, continuăm să lucrăm cât mai repede și în siguranță posibil pentru a atenua impactul asupra clienților. Vom furniza o altă actualizare până la 17 august 10:30 AM PDT, sau mai devreme ca remediere progresează.

16. 17 august 2026 la 16:25 UTCresolved

    Continuăm să lucrăm la remedierea treptată treptată la sediul Equinix FR5 din Frankfurt, DEU. Vedem semne timpurii de recuperare în timp ce continuăm să remediem pe deplin problema. Suntem activ de lucru pentru a aduce hardware-ul afectat rămas înapoi on-line și vom oferi o altă actualizare până la 12:30 PM PDT, sau mai devreme ca progrese de remediere.

17. 17 august 2026 la 17:59 UTCresolved

    Vedem semne largi de recuperare la sediul Equinix FR5 din Frankfurt, DEU. Am restabilit conectivitatea pentru majoritatea hardware-ului afectat și majoritatea conexiunilor sunt complet recuperate și stabile. Există un număr mic de clienți care vor rămâne afectate până când dispozitivele rămase sunt complet restaurate. Vom furniza o altă actualizare până la ora 2:00 PM PDT, sau mai devreme ca remediere progresează.

18. 17 august 2026 la 21:00 UTCresolved

    Continuăm să lucrăm la aducerea hardware-ului afectat înapoi online. De la ultima noastră actualizare am făcut progrese care nu vor fi vizibile pentru clienți, dar este necesar pentru recuperare. Lucrăm în paralel pentru a aduce toate dispozitivele online cât mai sigur posibil. Această activitate este de așteptat să dureze câteva ore pentru a finaliza și valida. Pentru clienții care necesită workaround-uri, vă recomandăm să luați în considerare eșec pe la VPN. Pentru clienții care utilizează Poarta Direct Connect și Transit Gateway, puteți crea un AWS Site-to-Site VPN și să-l atașați la Poarta de Tranzit, consultați pașii <a href="https://aws.amazon.com/premium support/cunoștințe-centru/dx-configurare-dx-and-vpn-failover-tgw/enphere</a>. Pentru alti clienti, recomandam stabilirea unui AWS Site-to-Site VPN ca o cale de rezerva temporara, se refera la pasii <a href="https://docs.aws.amazon.com/vpn/ultima/s2svpn/SetUpVPnconnections.html Vom furniza o altă actualizare până la ora 19:00 PDT sau mai devreme ca noi informații devine disponibil.

19. 18 august 2026 la 01:50 UTCresolved

    Vedem o recuperare semnificativă pentru majoritatea conexiunilor clienţilor în acest stadiu. Deși nu ne-am recuperat încă pe deplin, eforturile de restaurare progresează așa cum s-a așteptat la locația FR5 Equinix din Frankfurt, DEU. Remediarea infrastructurii rămase implică finalizarea înlocuirilor hardware și validarea traficului, ambele fiind în curs de desfășurare în mod activ. Anticipăm o redresare mai vizibilă a clienților, deoarece infrastructura rămasă este readusă în funcțiune. Clientii cu conexiuni exclusiv la aceasta locatie vor continua sa experimenteze pierderea pachetelor pana cand remedierea este completa. Orientările și recomandările privind atenuarea comunicate anterior rămân neschimbate în acest moment. Vom furniza o altă actualizare până la 17 august 11:00 PDT sau mai devreme.

20. 18 august 2026 la 04:01 UTCresolved

    Începând cu 14 august 7:33 PM PDT, am experimentat o pierdere crescută a pachetelor care afectează conectivitatea AWS Direct Connect pentru clienții cu conexiuni la sediul Equinix FR5 din Frankfurt, DEU. Inginerii au fost angajaţi automat la ora 7:45 PM pe 14 august şi au început imediat investigarea atenuărilor. Până la 8:30 PM, am identificat că echipamentul de rețea de la locația FR5 a fost afectat din cauza pătrunderii apei în instalația de colocare. Ca urmare, sistemul de răcire a fost afectat, ceea ce a dus la supraîncălzirea și oprirea dispozitivelor. Apa a afectat, de asemenea, sistemele de distribuție a energiei electrice care au dezactivat puterea pentru dispozitivele de rețea. Eforturile iniţiale de recuperare au fost amânate deoarece condiţiile de mediu din cadrul instalaţiei au necesitat stabilizarea înainte ca inginerii să poată accesa în siguranţă zona afectată. În perioada 15 și 16 august, inginerii noștri au lucrat în coordonare cu operatorul instalației pentru a restabili dispozitivele de rețea afectate, în timp ce problema infrastructurii subiacente a fost abordată. Până la ora 19:26 PM, la 17 august, toate echipamentele de rețea afectate au fost restaurate cu succes, iar conectivitatea la locație a fost verificată ca fiind pe deplin operațională cu recuperare susținută. Nu ne aşteptăm ca această problemă să reapară. Clientii cu conexiuni redundante in alte locatii Direct Connect au mentinut conectivitatea prin traseele lor alternative pe parcursul acestui eveniment si nu mai necesita actiune. Clientii care au implementat esecul VPN ca un workaround pot reveni acum în condiții de siguranță la căile lor primare Direct Connect. Conectivitatea a fost verificată ca fiind stabilă și pe deplin operațională. Clienții care necesită asistență suplimentară pot contacta AWS Support prin intermediul Console AWS Management sau al <a href="https://console.aws.amazon.com/support [52AWS Support Center</a>.

Traducere automată din actualizarea oficială a incidentului.

1. 31 iulie 2026 la 17:33 UTCresolved

   Putem confirma pierderea mare a pachetelor de rețea, impactul AWS Connect direct de conectivitate în regiunea AP-SOUTH-1. Echipa noastră de ingineri a fost angajată automat la 9:54 AM pentru a începe investigarea problemei. În acest moment nu există soluţii disponibile. Vom furniza o altă actualizare până la 11:30 AM PDT.

2. 31 iulie 2026 la 18:27 UTCresolved

   Am identificat cauza radacina pentru a fi legate de o schimbare facuta la un sistem de configurare responsabil pentru atribuirea de rute la dispozitive. Am început activitatea de reducere a pierderii pachetului care afectează AWS Direct Connect în regiunea AP-SOUTH-1 și ne așteptăm ca recuperarea să aibă loc treptat în următoarele 30 de minute. Pe măsură ce vom dobândi încredere în aceste eforturi, vom încerca să ne paralelizăm eforturile de a accelera redresarea. Vom furniza o altă actualizare până la 12:00 PM PDT.

3. 31 iulie 2026 la 18:54 UTCresolved

   Intre 9:42 AM si 11:44 AM PDT, am experimentat pierderi mari de pachete de retea cu impact asupra conexiunii AWS Direct Connect in regiunea AP-SOUTH-1. Echipa noastră de ingineri s-a angajat automat la 9:46 AM pentru a începe investigaţia. Până la 10:51 AM, am înțeles cauza rădăcină pentru a fi o schimbare de configurare făcut la un sistem responsabil pentru atribuirea de rute la dispozitive. Pe măsură ce am câștigat încrederea în pașii noștri de atenuare, am paralelizat eforturile noastre de a reduce în continuare pierderea pachetului. Problema este rezolvată și serviciul funcționează în mod normal.

Traducere automată din actualizarea oficială a incidentului.

1. 24 iulie 2026 la 11:40 UTCresolved

   Investigăm probleme legate de conecivitate care afectează mai multe servicii AWS în regiunea US-WEST-2.

2. 24 iulie 2026 la 11:56 UTCresolved

   Vedem semne iniţiale de recuperare şi continuăm să lucrăm spre o recuperare completă.

3. 24 iulie 2026 la 12:30 UTCresolved

   Continuăm să vedem semne semnificative de redresare ca urmare a eforturilor noastre de atenuare a problemelor de conectivitate care afectează mai multe servicii AWS în regiunea SUA-WEST-2. Am identificat cauza principală ca fiind o problemă cu un dispozitiv de rețea responsabil pentru rutarea rețelei din regiune către metroul din Seattle. Inginerii au terminat toate lucrările de atenuare. Deoarece rutele continuă să fie restaurate, clienții ar trebui să vadă o reducere continuă a ratelor de eroare și a termenelor de conectare la serviciile afectate. Monitorizăm îndeaproape progresele înregistrate în redresare și vom continua să lucrăm până când toate rutele vor fi restaurate complet și indicatorii de servicii vor reveni la nivelurile anterioare evenimentului. Vom furniza o altă actualizare în următoarele 30-45 de minute.

4. 24 iulie 2026 la 13:01 UTCresolved

   Între 3:55 AM și 4:15 AM PDT, am avut probleme de conectivitate care au afectat conectivitatea la regiunea US-WEST-2. Acest lucru a afectat mai multe servicii AWS în regiune. Unii clienți ar fi putut avea, de asemenea, probleme accesând Consola de Management AWS, cu timeout-uri de conectare și pagini care nu răspund. Conectivitatea în cadrul regiunii nu a fost afectată. Inginerii noştri au fost angajaţi automat la 4:01 AM PDT şi au început imediat să investigheze această problemă. Am identificat cauza principală ca fiind o problemă cu dispozitivele de rețea responsabile pentru rutarea rețelei din regiune către metroul din Seattle și am început să lucrăm în paralel pe mai multe căi pentru atenuarea impactului. Am luat măsuri de atenuare care au dus la recuperarea inițială la 4:15 AM PDT. Pe măsură ce reţeaua a continuat să se stabilizeze în urma acţiunilor noastre de atenuare, un scurt eveniment de reconversie a avut loc între 4:47 AM şi 4:59 AM PDT. În cursul acestei perioade de reconversie, unii clienți ar fi putut avea probleme de conectivitate intermitente la regiune, deoarece rutele de rețea au fost restabilite. Până la ora 4:59 AM PDT, toate rutele au fost restaurate complet, iar indicatorii de service au revenit la nivelurile anterioare evenimentului. Clientii utilizand AWS Direct Connect prin EqSe2, Westin Building Exchange, Seattle a experimentat o fereastra extinsa de impact de la 3:55 AM la 5:12 AM PDT. Acești clienți ar fi avut probleme de conectivitate până când rutele de rețea pentru această cale specifică ar fi fost restaurate integral la ora 5:12 AM PDT. Clienții conectați redundant prin alte locații AWS Direct Connect nu au fost afectate de acest eveniment. Problema a fost rezolvată și toate serviciile AWS funcționează în mod normal.

Traducere automată din actualizarea oficială a incidentului.

1. 17 iulie 2026 la 08:33 UTCresolved

   Investigăm probleme cu Cost Explorer care reflectă date de facturare incorecte estimate.

2. 17 iulie 2026 la 09:07 UTCresolved

   Incepand cu data de 16 Iulie 7:38 PM PDT, am inceput sa afisam date de facturare estimate incorect in Consola Billing si Cost Management. Echipele noastre de ingineri sunt angajate şi investighează cauza principală. Vom furniza o altă actualizare până la ora 3:00 PDT sau mai devreme, dacă mai multe informații devin disponibile.

3. 17 iulie 2026 la 10:03 UTCresolved

   Continuăm să lucrăm pentru a rezolva problema care afectează datele estimate privind costurile și utilizarea afișate în Consola de facturare și de gestionare a costurilor. Am identificat cauza principală ca fiind o problemă cu tarifarea unitară în cadrul subsistemului de calcul al facturilor estimat și lucrăm la o atenuare. Estimările de facturare afișate nu reflectă utilizarea efectivă și taxele. Nu sunt necesare acțiuni ale clienților în acest moment. Odată ce problema a fost atenuată, ne aşteptăm ca rezoluţia completă să dureze mai multe ore în timp ce lucrăm prin rezumarea datelor estimate privind facturarea. Vom furniza o altă actualizare până la ora 4:00 PDT sau mai devreme dacă mai multe informații devin disponibile.

4. 17 iulie 2026 la 10:52 UTCresolved

   Continuăm să lucrăm pentru a rezolva problema care afectează datele estimate privind costurile și utilizarea afișate în Consola de facturare și de gestionare a costurilor. După cum s-a împărtășit anterior, am identificat cauza principală ca fiind o problemă cu tarifarea unitară în cadrul subsistemului de calcul al facturilor estimat. Pentru a preveni afișarea altor estimări de facturare incorecte, am întrerupt calculele estimate de facturare. Clienții care văd în prezent estimări normale ale facturilor vor continua să vadă aceste estimări, iar clienții care văd estimări umflate nu vor vedea creșterea lor în timp ce lucrăm spre rezoluție. Estimările de facturare afișate nu reflectă utilizarea efectivă și taxele. Continuăm să lucrăm la atenuarea completă a problemei. Odată ce problema a fost atenuată, ne aşteptăm ca rezoluţia completă să dureze mai multe ore în timp ce lucrăm prin rezumarea datelor estimate privind facturarea. Nu sunt necesare acțiuni ale clienților în acest moment. Vom furniza o altă actualizare până la ora 5:00 PDT sau mai devreme, dacă mai multe informații devin disponibile.

5. 17 iulie 2026 la 11:58 UTCresolved

   Continuăm să lucrăm pentru a rezolva problema care afectează datele estimate privind costurile și utilizarea afișate în Consola de facturare și de gestionare a costurilor. Lucrăm activ pe mai multe căi de atenuare în paralel. Prima cale implică revenirea la ultima bună estimare a facturilor. Cu această abordare, clienţii vor vedea date de cost şi utilizare doar până pe 15 iulie, dar datele de cost umflate vor fi eliminate. A doua cale implică o modificare recentă a subsistemului de calcul al facturii. Estimările de facturare afișate nu reflectă utilizarea efectivă și taxele. Nu sunt necesare acțiuni ale clienților în acest moment. Odată ce problema a fost atenuată, ne aşteptăm ca rezoluţia completă să dureze mai multe ore în timp ce lucrăm prin rezumarea datelor estimate privind facturarea. Vom furniza o altă actualizare până la ora 6:00 PDT sau mai devreme dacă mai multe informații devin disponibile.

6. 17 iulie 2026 la 12:54 UTCresolved

   Continuăm să lucrăm pe mai multe căi de atenuare în paralel pentru a rezolva problema care afectează datele estimate privind costurile și utilizarea afișate în Consola de facturare și gestionare a costurilor, inclusiv Raportul privind costurile și utilizarea. Analizăm reluarea calculelor estimate de facturare, deoarece monitorizarea noastră internă indică faptul că subsistemul de calcul de facturare produce acum estimări exacte. Efectuăm o validare suplimentară înainte de a continua cu această cale. Estimările de facturare afișate nu reflectă utilizarea efectivă și taxele. Nu sunt necesare acțiuni ale clienților în acest moment. Vom furniza o altă actualizare până la ora 8:00 PDT sau mai devreme dacă mai multe informații devin disponibile.

7. 17 iulie 2026 la 14:53 UTCresolved

   Continuăm să lucrăm pentru a rezolva problema care afectează costurile estimate și datele de utilizare afișate în Consola de facturare și de gestionare a costurilor, inclusiv Raportul costuri și utilizare. Revenirea unei schimbări recente nu a rezolvat problema și continuăm să investigăm mai multe căi de atenuare. Actualizările estimate ale facturilor rămân întrerupte. Suntem în proces de revenire la ultimele date exacte estimate de facturare. Estimările de facturare afișate nu reflectă utilizarea efectivă și taxele. Nu sunt necesare acțiuni ale clienților în acest moment. Ne așteptăm ca această atenuare să dureze câteva ore pentru a finaliza în timp ce lucrăm prin rezumarea datelor estimate privind facturarea. Vom furniza o altă actualizare până la ora 10:00 PDT sau mai devreme dacă mai multe informații devin disponibile.

8. 17 iulie 2026 la 16:59 UTCresolved

   Am identificat cauza principală și am atenuat problema care stă la baza problemei care a determinat afișarea incorectă a datelor de cost și utilizare în Consola de facturare și gestionare a costurilor, precum și a rapoartelor privind costurile și utilizarea. Am început backfilling date pentru a corecta datele de cost pentru toți clienții. Ne așteptăm ca unii clienți să înceapă să vadă recuperare în următoarele trei ore, și recuperarea completă pentru toți clienții până la 18 iulie 12:00 PM PDT. Până când backfill este completă, unii clienți pot vedea încă date incorecte de cost și utilizare. Estimările de facturare afișate nu reflectă utilizarea efectivă și taxele. Nu sunt necesare acțiuni ale clienților în acest moment. Vom furniza o altă actualizare până la ora 1:00 PM, sau mai devreme dacă informațiile devin disponibile.

9. 17 iulie 2026 la 19:56 UTCresolved

   Eforturile noastre de a acoperi costurile și datele de utilizare corectate sunt încă în curs de desfășurare. Progresăm mai lent decât am anticipat. În timp ce vedem unele conturi recupera cu date corecte de cost și utilizare, ne așteptăm ca toate conturile afectate să fie recuperate până la 19 iulie 12:00 PDT. Până când backfill este completă, unii clienți pot vedea încă date incorecte de cost și utilizare. Estimările de facturare afișate nu reflectă utilizarea efectivă și taxele. Nu sunt necesare acțiuni ale clienților în acest moment. Vom furniza o altă actualizare până la ora 7:00 PM, sau mai devreme în cazul în care informațiile devin disponibile.

10. 18 iulie 2026 la 01:38 UTCresolved

    Continuăm să facem progrese constante către rezolvarea problemei care afectează costurile estimate și datele de utilizare afișate în Consola de facturare și gestionare a costurilor. Eforturile noastre de a completa datele corectate rămân în curs de desfășurare și ne așteptăm ca toate conturile afectate să fie recuperate complet până la 19 iulie, ora 12:00 PDT. Până când backfill-ul este complet, unii clienți pot observa încă date incorecte de cost și utilizare în Billing și Cost Management Console și Cost și Rapoarte de utilizare. Aceste estimări nu reflectă utilizarea sau taxele reale. Clientii care si-au configurat Raportul de cost si utilizare cu optiunea "Suprascrie" nu necesita actiune Clientii care si-au configurat raportul de cost si utilizare cu optiunea "Crea noi versiuni de raport" retin toate livrarile de rapoarte anterioare in galeata S3. Versiunea raportului furnizată în timpul ferestrei afectate poate conține date incorecte. Odată ce backfill-ul de date este complet, o versiune de raport corectată va fi livrată în cadrul unei noi adunăriId. Clienții care utilizează această configurație ar trebui să actualizeze orice proces din aval (tabele Athena, conducte Redshift, Amazon QuickSight, sau ETL personalizate) pentru a face trimitere la ultima asamblareId pentru perioada de facturare afectată, și pot șterge sau arhiva versiunea raportului de impact pentru a preveni prelucrarea datelor vechi. Pentru a identifica cel mai recent raport, clienții pot urma pașii din <a href="https://docs.azon.com/cur/latest/userguide/view-ultrest-cur.html Vom furniza o altă actualizare până la 18 iulie, ora 1:00 PDT, sau mai devreme dacă devin disponibile informații suplimentare.

11. 18 iulie 2026 la 08:05 UTCresolved

    Continuăm să facem progrese substanţiale în soluţionarea problemei care afectează costurile estimate şi datele de utilizare afişate în Consola de facturare şi gestionare a costurilor. Eforturile noastre de atenuare funcţionează conform aşteptărilor şi observăm un număr tot mai mare de conturi care reflectă date corecte privind costurile şi utilizarea. Ne aşteptăm ca toate conturile afectate să fie recuperate complet până la 19 iulie, ora 12:00 PDT. Până când backfill-ul este complet, unii clienți pot observa încă date incorecte de cost și utilizare în Billing și Cost Management Console și Cost și Rapoarte de utilizare. Aceste estimări nu reflectă utilizarea sau taxele reale. Vom furniza o altă actualizare până la 18 iulie, ora 7:00 PDT, sau mai devreme dacă devin disponibile informații suplimentare.

12. 18 iulie 2026 la 13:57 UTCresolved

    În perioada 16 iulie la ora 7:38 PM PDT şi 18 iulie la ora 6:00 AM PDT, am început să afişăm date de facturare incorecte estimate în Consola de facturare şi management al costurilor, inclusiv Raportul costuri şi utilizare. Este posibil ca clienții să fi primit alerte de detectare a anomaliei în buget și costuri eronate și să fi observat date estimate privind costurile și utilizarea. Pe 16 iulie, la 7:46 PM PDT, alarmele noastre au detectat anomalii ale costurilor, dar nu au reuşit să oprească procesul de generare a facturilor sau să alerteze echipele noastre de inginerie. Am fost atenţionaţi cu privire la această problemă la 17 iulie, la 12:19 AM PDT, prin escaladarea clienţilor şi imediat am început să investigăm. Am informat mai întâi clienții prin AWS Health pe 17 iulie la 1:33 AM. La 8:24 AM PDT am oprit actualizările către datele estimate de facturare şi am oprit bugetul şi am costat anomalia ca măsură de precauţie. Am identificat cauza pe 17 iulie la ora 12:00 PDT ca o schimbare de configurare a sistemului nostru de calcul al facturilor. Acest sistem se bazează pe datele de conversie ale unității pentru a calcula tarifele de element pe linie. Modificarea configurației a dus la eșecul actualizărilor datelor de conversie a unității, ceea ce a dus la creșterea costurilor elementului de linie, care s-a propagat către consola de facturare și gestionare a costurilor și a declanșat alertele privind bugetul și costul anomaliei. Am redus problema la 17 iulie la 12:30 PM PDT care a corectat configurația de conversie a unității, și a început reprocesarea costurilor și a datelor de utilizare pentru toate conturile clienților. Am început să observăm recuperarea la 4:19 PM PDT, iar majoritatea conturilor au fost recuperate complet până la 18 iulie la ora 6:00 AM PDT. Există un număr mic de conturi încă de procesare și vom posta actualizări pentru aceste conturi pe Dashboard de sănătate personală. Ne-am corectat alarmele pentru a opri imediat procesarea și să notifice echipele noastre de inginerie atunci când apar anomalii. Ne cerem scuze pentru alarma pe care acest incident a cauzat-o clienţilor noştri şi realizăm o retrospectivă amănunţită pentru a preveni reapariţia unor astfel de evenimente, precum şi pentru a ne îmbunătăţi răspunsul la incidentele de facturare. Problema a fost rezolvată și toate serviciile AWS funcționează în mod normal.

Traducere automată din actualizarea oficială a incidentului.

1. 16 iulie 2026 la 08:44 UTCresolved

   Investigăm creșterea erorilor 5xx pentru clienții Cloudfront care utilizează conectivitatea VPC Origins.

2. 16 iulie 2026 la 09:21 UTCresolved

   Începând de la 12:45 AM PDT, ne confruntăm cu erori 5xx crescute pentru clienții CloudFront care utilizează conectivitatea VPC Origins. Am confirmat că clienții care utilizează alte tipuri de origine nu sunt afectați de această problemă. Inginerii noştri sunt angajaţi şi lucrează activ pentru a atenua impactul. Ca un workaround, clienții care nu necesită origini VPC pot schimba tipul lor de origine pentru a rezolva erorile. Vom furniza o altă actualizare până la 3:15 AM PDT, sau mai devreme dacă mai multe informații devin disponibile.

3. 16 iulie 2026 la 10:18 UTCresolved

   Continuăm să lucrăm pentru a rezolva erorile 5xx crescute pentru clienții CloudFront care utilizează conectivitatea VPC Origins. Clienții care utilizează alte tipuri de origine rămân neafectați de această problemă. Pe baza investigaţiei noastre, credem că cauza principală este legată de un subsistem de procesare a pachetelor responsabil cu direcţionarea cererilor din locaţiile de pe marginea CloudFront către resursele din interiorul VPC-urilor clienţilor. Continuăm să recomandăm clienților care sunt capabili să facă acest lucru să-și schimbe temporar tipul de origine pentru a rezolva erorile. Vom furniza o altă actualizare până la 4:15 AM PDT, sau mai devreme în cazul în care informațiile suplimentare devin disponibile.

4. 16 iulie 2026 la 11:16 UTCresolved

   Continuăm să lucrăm pentru a rezolva erorile 5xx crescute pentru clienții CloudFront care utilizează conectivitatea VPC Origins. Clienții care utilizează alte tipuri de origine rămân neafectați de această problemă. Am extins în continuare problema până la capacitatea de tabel de rutare în cadrul subsistemului de procesare a pachetelor responsabil pentru direcţionarea cererilor de la locaţiile de pe marginea CloudFront către resursele din cadrul VPC-urilor clienţilor. Am identificat și testăm în prezent o strategie de atenuare a problemei. Odată ce testarea este completă, vom implementa atenuarea într-o abordare progresivă. Pe baza rezultatelor acestor teste, vom oferi un timp estimat mai clar pentru rezoluție în următoarea actualizare. Continuăm să recomandăm clienților care sunt capabili să facă acest lucru să-și schimbe temporar tipul de origine pentru a rezolva erorile. Vom furniza o altă actualizare până la 5:15 AM PDT, sau mai devreme în cazul în care informațiile suplimentare devin disponibile.

5. 16 iulie 2026 la 11:27 UTCresolved

   Vedem semne iniţiale de recuperare şi continuăm să lucrăm spre o recuperare completă.

6. 16 iulie 2026 la 11:57 UTCresolved

   Continuăm să vedem semne semnificative de redresare ca urmare a eforturilor noastre de atenuare, cu recuperarea totală preconizată în următoarele 45 de minute.

7. 16 iulie 2026 la 12:21 UTCresolved

   Între 12:45 AM și 4:18 AM PDT, am experimentat erori 5xx crescute pentru clienții CloudFront care utilizează conectivitatea VPC Origins. Inginerii noştri au fost angajaţi automat şi au început imediat investigarea cauzei. Până la 2:57 AM PDT, am identificat cauza principală a problemei ca o constrângere internă asupra flotei care gestionează conexiunile cu origini private VPC. Atunci când această constrângere a fost atinsă, sistemul responsabil pentru distribuirea configurației de rutare către procesoarele de rețea nu a reușit să încarce corect datele de configurare actualizate, afectând rutarea conexiunilor VPC Origin. La 3:52 AM PDT, am luat mai multe măsuri de atenuare care au dus la recuperarea completă la 4:18 AM PDT. Acum că problema a fost atenuată, clienţii care şi-au schimbat temporar originea pot reveni în siguranţă la aceste schimbări. Clienții care utilizează alte tipuri de origine nu au fost afectați de această problemă. Problema a fost rezolvată, iar serviciul funcționează normal.

Traducere automată din actualizarea oficială a incidentului.

1. 15 iulie 2026 la 23:11 UTCresolved

   Investigăm probleme de conectivitate ridicate cu o singură zonă de evaluare (euc1-az2) în regiunea UE-CENTRAL-1.

2. 15 iulie 2026 la 23:36 UTCresolved

   Vedem semne timpurii de recuperare şi continuăm să lucrăm la soluţionarea completă. Vom continua să oferim actualizări.

3. 16 iulie 2026 la 01:24 UTCresolved

   Între 2:56 PM și 6:07 PM PDT, am avut probleme de conectivitate la un subset de cazuri CE2 într-o singură zonă de disponibilitate (euc1-az2) în regiunea UE-CENTRAL-1. În acest timp, este posibil ca și clienții să fi înregistrat rate de eroare crescute și latențe pentru noile lansări de instanță în zona afectată, împreună cu unele AWS API care utilizează cazurile CE2 afectate. Unele servicii AWS au avut, de asemenea, probleme de conectivitate și rate de eroare crescute în zona afectată. Inginerii au fost angajaţi automat şi au început imediat investigaţiile. Ca parte a efortului nostru de recuperare, am îndepărtat traficul de zona de disponibilitate afectată la ora 3:04 PM. La ora 3:05 PM am identificat cauza principală a unei schimbări recente în rețea care cauzează impactul. Inginerii au început imediat să refacă această schimbare care s-a încheiat la 4:28 PM. Acest lucru a dus la restabilirea conectivității rețelei la zona afectată la 4:30 PM. Am continuat să lucrăm până când am recuperat complet impactul la ora 6:07 PM. Nu ne aşteptăm ca această problemă să reapară. Problema a fost rezolvată, iar serviciul funcționează normal.

Traducere automată din actualizarea oficială a incidentului.

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

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

4. 6 iulie 2026 la 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 iunie 2026 la 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 iunie 2026 la 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 iunie 2026 la 21:29 UTCresolved

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

4. 30 iunie 2026 la 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 iunie 2026 la 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 iunie 2026 la 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 iunie 2026 la 04:24 UTCresolved

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

1. 22 mai 2026 la 23:38 UTCresolved

   We are investigating increased error rates for Route53 API calls.

2. 23 mai 2026 la 00:13 UTCresolved

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

1. 8 mai 2026 la 00:25 UTCresolved

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

2. 8 mai 2026 la 00:53 UTCresolved

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

3. 8 mai 2026 la 01:47 UTCresolved

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

4. 8 mai 2026 la 03:06 UTCresolved

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

5. 8 mai 2026 la 05:11 UTCresolved

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

6. 8 mai 2026 la 06:38 UTCresolved

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

7. 8 mai 2026 la 08:32 UTCresolved

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

8. 8 mai 2026 la 10:54 UTCresolved

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

9. 8 mai 2026 la 13:51 UTCresolved

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

10. 8 mai 2026 la 15:58 UTCresolved

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

11. 8 mai 2026 la 16:30 UTCresolved

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

12. 8 mai 2026 la 18:12 UTCresolved

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

13. 8 mai 2026 la 19:29 UTCresolved

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

14. 8 mai 2026 la 23:00 UTCresolved

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

15. 9 mai 2026 la 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 aprilie 2026 la 11:27 UTCresolved

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

2. 27 aprilie 2026 la 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 martie 2026 la 19:53 UTCresolved

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

2. 7 martie 2026 la 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 martie 2026 la 20:28 UTCresolved

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

4. 7 martie 2026 la 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 martie 2026 la 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 martie 2026 la 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 martie 2026 la 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 martie 2026 la 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 martie 2026 la 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 martie 2026 la 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 martie 2026 la 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 martie 2026 la 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 martie 2026 la 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 martie 2026 la 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 martie 2026 la 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 martie 2026 la 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 aprilie 2026 la 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 septembrie 2026 la 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.