Amazon Web Services driftsforstyrrelser

1. 4. oktober 2026 kl. 16.14 UTCresolved

   Vi undersøger forhøjet pakketab i EU-SOUTH-2-regionen.

2. 4. oktober 2026 kl. 16.36 UTCresolved

   Vi oplever forhøjet pakketab med en enkelt tilgængelighedszone (eus2-az1) i EU-SOUTH-2-regionen. Dette spørgsmål er også resulterer i forhøjede API latesser og fejlrater for andre arbejdsgange og AWS Services. Ingeniører blev automatisk engageret og arbejder på at identificere den grundlæggende årsag og at afbøde problemet. Vi vil give dig en anden opdatering inden 10: 15 AM PDT eller før som nye oplysninger bliver tilgængelige.

3. 4. oktober 2026 kl. 17.06 UTCresolved

   Vores bestræbelser på at afbøde det forhøjede pakketab med en enkelt tilgængelighedszone (eus2- az1) i EU-SOUTH-2-regionen er stadig i gang. Vi ser nogle tegn på forbedringer som følge af flere parallelle bestræbelser. Vi fortsætter med at arbejde for at bekræfte rodårsagen og fuldt ud mindske problemet. Mens vi i øjeblikket ikke har et skøn over, hvor lang tid vores handlinger vil tage, vil vi holde dig informeret om vores fremskridt og give dig en anden opdatering senest 11: 00 AM PDT eller før nye oplysninger bliver tilgængelige.

4. 4. oktober 2026 kl. 17.56 UTCresolved

   Vi har identificeret den grundlæggende årsag og er i øjeblikket fokuserer vores afbødende indsats for at drive fuld genopretning. Mens vi ikke har en præcis vurdering af, hvor lang vores nuværende indsats vil tage, vi forventer at se trinvise forbedringer som vores indsats fortsætter. Vi vil give dig en anden opdatering ved 11: 45 AM PDT, eller tidligere, hvis nye oplysninger bliver tilgængelige.

5. 4. oktober 2026 kl. 18.45 UTCresolved

   Vi ser tidlige tegn på bedring. Vi vil give dig en anden opdatering inden 12: 00 PM PDT.

6. 4. oktober 2026 kl. 18.56 UTCresolved

   Mellem 8: 48 og 11: 28 AM PDT oplevede vi et forhøjet pakketab inden for en enkelt tilgængelighedszone (eus2-az1) i EU- SOUTH-2-regionen. Dette spørgsmål resulterede i forhøjede API latesser og fejlrater for flere arbejdsgange og AWS Services. Vi blev automatisk advaret om problemet kl. 8: 54 AM, og straks begyndte arbejdet med at identificere den grundlæggende årsag, mens du tager flere parallelle stier til at afbøde problemet. Ved 10: 00, vores afbødning indsats havde ført til nogle forbedringer. Ved 10: 38 AM, vi identificerede den grundlæggende årsag som relateret til en netværkskonfiguration ændring, som vi var i stand til at vende den ændring, der førte til fuld afbødning ved 11: 28 AM. Problemet er løst, og tjenesten fungerer normalt.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 21. september 2026 kl. 23.26 UTCresolved

   Vi undersøger øgede API fejlrater i US- EAST-1 Region.

2. 21. september 2026 kl. 23.44 UTCresolved

   Vi kan bekræfte øgede fejlrater, der påvirker nye cases lanceringer, herunder forhøjede API fejlrater for RunInstances, CreateFleet, og relaterede EC2 lancering arbejdsgange i US- EAST-1 Region. Kunder, der forsøger at lancere nye EC2 tilfælde kan opleve lancering fejl eller forhøjet API respons latency. Vores ingeniører er aktivt engagerede og arbejder på at finde ud af problemet. Vi ser tegn på bedring. Eksisterende tilfælde er ikke berørt. Vi anbefaler at prøve igen mislykkedes RunInstances og CreateFleet API opkald. Vi vil give en opdatering kl. 17.30 PDT eller tidligere.

3. 22. september 2026 kl. 00.24 UTCresolved

   Mellem kl. 15: 49 og kl. 17: 06 oplevede vi øgede fejlrater, der påvirkede nye opsendelser i US- EAST-1-regionen. I løbet af denne tid, kunder kan have oplevet forhøjede fejlrater, når de forsøger at lancere nye EC2 tilfælde gennem RunInstances, CreateFleet, og relaterede EC2 lancering arbejdsgange. Kommissionen bemærker, at LuxSCS ikke er en markedsøkonomisk aktør, da LuxSCS ikke er en virksomhed, der er en virksomhed. Vi identificerede den grundlæggende årsag som en nylig implementering til et delsystem inden for EC2-tjenesten, der er ansvarlig for behandling instans lancering anmodninger. Vi indledte en rollback af den problematiske implementering og begyndte at observere indledende tegn på helbredelse kl. 16.44. Eksisterende tilfælde er ikke berørt. Problemet er løst, og tjenesten fungerer normalt.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 3. september 2026 kl. 21.49 UTCresolved

   Start på 2: 12 PM PDT, vi begyndte at opleve øgede API fejlrater for STS og Log ind, når du bruger SAML i US- WEST-2 regionen. Vores ingeniørhold blev automatisk optaget kl. 14.19 for at undersøge årsagen. Der er ikke noget arbejde til rådighed på nuværende tidspunkt. Vi giver endnu en opdatering kl. 15.30 PDT.

2. 3. september 2026 kl. 22.26 UTCresolved

   Vi ser tidlige tegn på bedring og fortsætter med at overvåge for fuld genopretning. Vi vil give en anden opdatering kl. 16.15, eller før, hvis vi har yderligere oplysninger at dele.

3. 3. september 2026 kl. 23.20 UTCresolved

   Vi fortsætter med at se helbredelse holde fast for STS AssumeRoleWithSAML og AssumeRoleWithWebIdentity API 'er i US- WEST-2 regionen. Fejlrater er nu tilbage til præ-begivenhed niveauer, og vi fortsætter aktivt overvåge for at bekræfte fuld inddrivelse. Vi vil give en anden opdatering kl. 17.15 eller tidligere.

4. 4. september 2026 kl. 00.07 UTCresolved

   Mellem 2: 12 og 3: 18 PM PDT oplevede vi øgede API fejlrater, der påvirkede STS AssumeRoleWithSAML og AssumeRoleWithWebIdentity API 'er i US- WEST-2 regionen. Den grundlæggende årsag blev besluttet at skyldes et problem med et STS-delsystem, der er ansvarligt for kommunikationen med eksterne identitetsudbydere. Andre AWS Services, der er afhængige af disse identitetsprotokoller føderation blev også påvirket. Kl. 15: 18 observerede vi tegn på bedring og fortsatte med at overvåge for at sikre stabilitet og fuld bedring. Problemet er løst, og tjenesten fungerer normalt på nuværende tidspunkt.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 21. august 2026 kl. 02.02 UTCresolved

   Det er det, vi skal gøre. Vi oplever øgede fejlrater, der påvirker realtidsmålinger i AP- NORTHEAST-1-regionen. Kunder kan opleve manglende eller forsinkede realtidsdata.

2. 21. august 2026 kl. 02.40 UTCresolved

   Det er det samme som det her. 10: 13 er lig med 10: 34 er lig med 10: 34 er lig med 6: 34 PM PDT, vi oplevede øgede forsinkelser påvirker realtidsmålinger for Amazon Connect i AP- NORTHEAST-1 Region, hvilket resulterer i manglende eller gamle data. I løbet af denne tid, kunder kan have oplevet manglende data i analytics rapporter, og kan have observeret problemer, hvis adgang realtime målinger i kontakt Flows, såsom kontrol agent personale. Vi identificerede årsagen til at være et problem med delsystemet ansvarlig for metrisk begivenhed levering. Vi begyndte at anvende afbødninger kl. 18.13 og afbødede spørgsmålet kl. 18.34. Problemet er løst, og tjenesten fungerer normalt.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 19. august 2026 kl. 15.15 UTCresolved

   Vi undersøger et problem, der påvirker lanceringen af nye EC2-tilfælde og ressourcer i en nyligt lanceret tilgængelighedszone (euw2- az4) i EU-WEST-2-regionen. I løbet af denne periode kan berørte kunder opleve problemer, når de opretter eller ændrer ressourcer i regionen. Andre AWS-tjenester kan også blive påvirket. For øjeblikkelig helbredelse anbefaler vi, at kunderne bruger alternative tilgængelighedszoner (euw2- az1, euw2- az2 og euw2- az3), hvor det er relevant. Eksisterende løbende instanser og ressourcer berøres ikke. Vi vil give en anden opdatering ved 10: 00 AM PDT, eller tidligere, hvis vi har yderligere oplysninger at dele.

2. 19. august 2026 kl. 17.03 UTCresolved

   Den 18. august lancerede vi en ny tilgængelighedszone (euw2- az4) i EU- WEST-2-regionen. Efter lanceringen, vi begyndte at opleve fejl lancering EC2 tilfælde i den nye tilgængelighed Zone, når en standard subnet er ikke til stede. Vi kan bekræfte, at eksisterende løbende tilfælde og ressourcer ikke berøres. Arbejdsgange, der automatisk får en liste over tilgængelighedszoner i regionen via Beskriv AvailabilityZones API og derefter forsøge at starte nye tilfælde eller skabe ressourcer i den nye tilgængelighed Zone kan støde på fejl. For EC2 instans lancering fejl, vi tager formildende skridt til automatisk at oprette standard subnets, hvor man ikke allerede er til stede, når en EC2 instans lancering er rettet mod den nye tilgængelighed Zone. For kunder og arbejdsgange, der kræver øjeblikkelig oprensning < a HURF = "https: / / docs.awazon.com / vpc / nyeste / userguide / work- with- default- vpc.html # create- default- subnet" > du kan oprette en standard subnet < / a > i den nye Tilgængelighed Zone. Dette vil gøre det muligt EC2 instans lancerer til at gennemføre med succes. For andre ressourcer, såsom Lambda funktioner, hvor den nye tilgængelighed Zone er i øjeblikket ikke understøttet, anbefaler vi kunder opdatere deres arbejdsgange for at udelukke den nyligt lancerede tilgængelighed Zone og fortsætte ressourceskabelsen ved hjælp af de andre tilgængelighed Zoner i regionen. Mens vi ikke har et nøjagtigt skøn over, hvor lang tid vores afbødende indsats vil tage, vil vi holde dig ajour med vores fremskridt og give dig en anden opdatering ved 1: 00 PM PDT eller før nye oplysninger bliver tilgængelige.

3. 19. august 2026 kl. 18.47 UTCresolved

   Mellem august 18 5: 00 og august 19 11: 00 PDT, oplevede vi forhøjede fejl lancering EC2 tilfælde i en nyligt lanceret Tilgængelighed Zone (euw2- az4) i EU- WEST-2 regionen. Efter den nye tilgængelighed Zone lanceringen, begyndte vi at opleve fejl, når du bruger en standard VPC. Vi opdagede årsagen til problemet den 19. august kl 9: 00 og begyndte at implementere en ændring for at løse problemet kl 9: 30. Mens ændringen var i gang, begyndte vi at se trinvise forbedringer i nye tilfælde lancerer, med fuld bedring på 11: 00 AM. Eksisterende løbende instanser og ressourcer blev ikke påvirket. Nogle regionale tjenester, såsom Lambda funktioner eller Aurora databaser, var ikke tilgængelige ved lanceringen af den nye tilgængelighed Zone og service tilgængelighed vil blive tilføjet over tid. Kunder, der forsøger at skabe ressourcer, før tjenesterne bliver tilgængelige, vil se en meddelelse, der rapporterer, at det ikke er understøttet i Tilgængelighed Zone. Problemet er løst, og tjenesten fungerer normalt.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 15. august 2026 kl. 03.42 UTCresolved

   Vi er ved at undersøge øget pakketab, påvirker AWS Direct Connect forbindelse for nogle kunder i EU-CENTAL-1 Region.

2. 15. august 2026 kl. 04.42 UTCresolved

   Vi kan bekræfte pakketab, der påvirker Direct Connect-forbindelserne i EU- CENTAL-1-regionen. Ingeniører blev automatisk engageret og straks begyndte at arbejde for både at identificere roden årsag, og identificere flere parallelle stier til at afbøde problemet. På dette tidspunkt ser vi tidlige tegn på bedring. Vi vil give en anden opdatering om 60 minutter, eller før, hvis vi har yderligere oplysninger at dele.

3. 15. august 2026 kl. 05.55 UTCresolved

   Fra kl. 7: 33 PDT begyndte vi at opleve et øget pakketab, der påvirkede AWS Direct Connect konnektivitet for nogle kunder i EU- CENTAL-1-regionen. Mens vi har gjort fremskridt, er forbindelserne til følgende Direct Connect placering stadig svækket: Equinix FR5, Frankfurt, DEU. Kunder, der har flere-site redundans konfigureret med deres Direct Connect stier bør ikke observere indvirkning på dette tidspunkt. Kunder, der kun har forbindelser på Equinix FR5, Frankfurt, DEU placering vil fortsætte med at opleve forbindelsesproblemer. Vi arbejder aktivt på at afbøde virkningen og arbejde mod fuld genopretning, men forventer fuld genopretning er flere timer væk. Vi vil give en opdatering om 90 minutter, eller før, hvis vi har yderligere oplysninger at dele.

4. 15. august 2026 kl. 07.24 UTCresolved

   Vi arbejder aktivt på at genoprette forbindelsen gennem Direct Connect: Equinix FR5, Frankfurt, DEU. Kunder, der kun har forbindelser på Equinix FR5, Frankfurt, DEU placering vil fortsætte med at opleve forbindelsesproblemer. For en workout påvirket kunder, der har mulighed for at svigte til VPN anbefales at gøre det for at opnå opsving. For kunder, der bruger Direct Connect gateway og Transit Gateway, anbefaler vi at oprette en AWS Site- to- Site VPN og vedhæfte den til din Transit Gateway, henvises til trin < a HURF = "https: / / aws.amazon.com / premiumsupport / viden- center / dx- Share- dx- and- vpn- failover- tgw /" > her < / a >. For andre kunder anbefaler vi at oprette en AWS Site- to- Site VPN som en midlertidig backup sti, henvise trin < a HURF = "https: / / docs.aws.amazon.com / vpn / nyeste / s2svpn / SetUpVPNConnections.html" > her < / a >. Fra denne tid, forventer vi, at helbredelse er flere timer væk. Vi vil give en anden opdatering om 90 minutter, eller før, hvis vi har yderligere oplysninger at dele.

5. 15. august 2026 kl. 09.08 UTCresolved

   Vi fortsætter med at arbejde hen imod genoprettelse af forbindelse til AWS Direct Connect-forbindelser hos Equinix FR5, Frankfurt, DEU. Den grundlæggende årsag er relateret til en facilitet infrastruktur spørgsmål på det sted, der påvirker netværksinfrastruktur. Kunder med forbindelser udelukkende på dette sted vil fortsætte med at opleve pakketab eller konnektivitet forringelse. Kunder med multisite eller overflødige konfigurationer på tværs af andre steder er ikke påvirket. For en workout, ramte kunder, der har mulighed for at svigte til VPN anbefales at gøre det. For kunder, der bruger Direct Connect gateway og Transit Gateway, anbefaler vi at oprette en AWS Site- to- Site VPN og vedhæfte den til din Transit Gateway, henvises til trin < a HURF = "https: / / aws.amazon.com / premiumsupport / viden- center / dx- Share- dx- and- vpn- failover- tgw /" > her < / a >. For andre kunder anbefaler vi at oprette en AWS Site- to- Site VPN som en midlertidig backup sti, se trin < a HURF = "https: / / docs.aws.amazon.com / vpn / nyeste / s2svpn / SetUpVPNConnections.html" > her < / a >. Fra denne tid, forventer vi, at helbredelse er flere timer væk. Vi vil give en anden opdatering inden for 2 timer eller så snart vi har mere information at dele.

6. 15. august 2026 kl. 11.10 UTCresolved

   AWS Direct Connect tilslutningsmuligheder er fortsat forringet for kunder med forbindelser på Equinix FR5-området i Frankfurt, DEU. Kunder med flere steder eller overflødige konfigurationer på tværs af andre steder er fortsat upåvirket. Ingeniører arbejder aktivt på at genoprette konnektivitet, med bestræbelser i gang på tværs af flere arbejdsstrømme for at løse den underliggende facilitet problem og bringe det påvirkede netværksudstyr tilbage i drift. Vi forventer stadig, at helbredelsen er flere timer væk. For en workout, ramte kunder, der har mulighed for at svigte til VPN anbefales at gøre det. For kunder, der bruger Direct Connect gateway og Transit Gateway, anbefaler vi at oprette en AWS Site- to- Site VPN og vedhæfte den til din Transit Gateway, henvises til trin < a HURF = "https: / / aws.amazon.com / premiumsupport / viden- center / dx- Share- dx- and- vpn- failover- tgw /" > her < / a >. For andre kunder anbefaler vi at oprette en AWS Site- to- Site VPN som en midlertidig backup sti, se trin < a HURF = "https: / / docs.aws.amazon.com / vpn / nyeste / s2svpn / SetUpVPNConnections.html" > her < / a >. Vi vil give en anden opdatering inden for 2 timer eller så snart vi har mere information at dele.

7. 15. august 2026 kl. 13.17 UTCresolved

   Ingeniører fortsætter arbejdet med at genoprette forbindelsen på Equinix FR5 placering i Frankfurt, DEU. Vores samarbejdspartner arbejder på at løse problemet med den underliggende facilitet infrastruktur, og mens forbedringerne endnu ikke er synlige for kunden, gør vi positive fremskridt i retning af løsning. For kunder, der kræver øjeblikkelig inddrivelse, anbefaler vi at fejle over til VPN, som skitseret i vores tidligere opdateringer. Vi vil give en anden opdatering af 9: 30 AM PDT, eller tidligere, hvis vi har yderligere oplysninger at dele.

8. 15. august 2026 kl. 16.27 UTCresolved

   Vores co-location partner fortsætter med at arbejde på at løse den underliggende facilitet infrastruktur problem på Equinix FR5 placering i Frankfurt, DEU. Adgangen til det berørte område er i øjeblikket begrænset på grund af sikkerhedsproblemer, som påvirker vores evne til at vurdere netværkets udstyrs fysiske tilstand og give en mere præcis tidsplan for nyttiggørelse. Baseret på aktuelle oplysninger, er fuld genopretning ikke forventes på nær sigt og kan strække sig ud over i dag. AWS Direct Connect forbindelser på dette sted forbliver forringet. Kunder med overflødige forbindelser gennem andre steder forbliver upåvirkede. For kunder, der bruger Direct Connect gateway og Transit Gateway, anbefaler vi at oprette en AWS Site- to- Site VPN og vedhæfte den til din Transit Gateway, henvises til trin < a HURF = "https: / / aws.amazon.com / premiumsupport / viden- center / dx- Share- dx- and- vpn- failover- tgw /" > her < / a >. For andre kunder anbefaler vi at oprette en AWS Site- to- Site VPN som en midlertidig backup sti, se trin < a HURF = "https: / / docs.aws.amazon.com / vpn / nyeste / s2svpn / SetUpVPNConnections.html" > her < / a >. Vi vil give en anden opdatering af 3: 30 PM PDT, eller tidligere, hvis vi har yderligere oplysninger at dele.

9. 15. august 2026 kl. 22.26 UTCresolved

   Vores samarbejdspartner arbejder fortsat på at genoprette sikker adgang til det berørte område på Equinix FR5-stedet i Frankfurt, DEU. Når sikker adgang er sikret, vil vores ingeniører være i stand til at vurdere de berørte netværk enheder. Vi fortsætter med nøje at spore fremskridt og vil dele en opdatering ved 9: 30 PM PDT, eller før nye oplysninger bliver tilgængelige.

10. 16. august 2026 kl. 04.37 UTCresolved

    Vi er aktivt engageret i vores co-location partner til at genoprette forbindelse på Equinix FR5 placering i Frankfurt, DEU. Siden vores seneste opdatering har vi gjort gradvise fremskridt med at genoprette sikker adgang til det berørte område på Equinix FR5 i Frankfurt, DEU. Samtidig har vi prioriteret den rækkefølge, hvori kritiske og højt prioriterede stativer vil blive genoprettet som en del af afbødningsindsatsen. Baseret på vores nuværende vurdering, er fuld genopretning ikke forventes på nær sigt og kan strække sig ud over i dag. AWS Direct Connect forbindelser på dette sted forbliver forringet. Kunder med forbindelser udelukkende på dette sted vil fortsætte med at opleve pakketab. Kunder med multisite eller overflødige konfigurationer på tværs af andre Direct Connect steder forbliver upåvirket. For en workout, ramte kunder, der har mulighed for at svigte til VPN anbefales at gøre det. For kunder, der bruger Direct Connect gateway og Transit Gateway, anbefaler vi at oprette en AWS Site- to- Site VPN og vedhæfte den til din Transit Gateway, henvises til trin < a HURF = "https: / / aws.amazon.com / premiumsupport / viden- center / dx- Share- dx- and- vpn- failover- tgw /" > her < / a >. For andre kunder anbefaler vi at oprette en AWS Site- to- Site VPN som en midlertidig backup sti, se trin < a HURF = "https: / / docs.aws.amazon.com / vpn / nyeste / s2svpn / SetUpVPNConnections.html" > her < / a >. Vi fortsætter med nøje at spore fremskridt og vil dele en opdatering inden August 16 3: 30 AM PDT, eller før nye oplysninger bliver tilgængelige.

11. 16. august 2026 kl. 10.25 UTCresolved

    Vi fortsætter med at arbejde med vores co-location partner til at genoprette forbindelse på Equinix FR5 placering i Frankfurt, DEU. Siden vores seneste opdatering, har vi gjort betydelige fremskridt i retning af at genoprette sikker adgang til det berørte område. Den elektriske isolationsprocedure er nu i gang, med vores hold på stedet i det elektriske rum udfører deenergisering af den berørte infrastruktur. Når isolationen er bekræftet og bekræftet sikker, ingeniører vil begynde en fysisk inspektion af den ramte netværk udstyr til at bestemme omfanget af udskiftning kræves. Baseret på vores nuværende vurdering, er fuld genopretning ikke forventes på nær sigt på grund af omfanget af potentielle påvirket af udstyr. AWS Direct Connect forbindelser på dette sted forbliver forringet. Kunder med forbindelser udelukkende på dette sted vil fortsætte med at opleve pakketab. Kunder med multisite eller overflødige konfigurationer på tværs af andre Direct Connect steder forbliver upåvirket. For en workout, ramte kunder, der har mulighed for at svigte til VPN anbefales at gøre det. For kunder, der bruger Direct Connect gateway og Transit Gateway, anbefaler vi at oprette en AWS Site- to- Site VPN og vedhæfte den til din Transit Gateway, henvises til trin < a HURF = "https: / / aws.amazon.com / premiumsupport / viden- center / dx- Share- dx- and- vpn- failover- tgw /" > her < / a >. For andre kunder anbefaler vi at oprette en AWS Site- to- Site VPN som en midlertidig backup sti, se trin < a HURF = "https: / / docs.aws.amazon.com / vpn / nyeste / s2svpn / SetUpVPNConnections.html" > her < / a >. Vi fortsætter med nøje at spore fremskridt og vil dele en opdatering inden August 16 9: 30 AM PDT, eller før nye oplysninger bliver tilgængelige.

12. 16. august 2026 kl. 16.30 UTCresolved

    Den elektriske isolering i Equinix FR5 i Frankfurt, DEU er nu færdig, og vores ingeniører er begyndt fysisk at inspicere det ramte netværksudstyr. Vi har endnu ikke en tidsplan for en fuldstændig løsning, mens vi fortsætter med at vurdere omfanget af indvirkningen på udstyr. Direkte Connect forbindelser på dette sted forbliver svækket. Kunder med forbindelser udelukkende på dette sted vil fortsætte med at opleve pakketab. Kunder med multisite eller redundante konfigurationer på tværs af andre Direct Connect steder påvirkes ikke. Vi anbefaler, at ramte kunder failover til VPN, indtil vi har mere klarhed på næste trin og en inddrivelse tidslinje. For kunder, der bruger Direct Connect gateway og Transit Gateway, kan du oprette en AWS Site- to- Site VPN og vedhæfte den til din Transit Gateway, se trin < a HURF = "https: / / aws.amazon.com / premiumsupport / viden- center / dx- Share- dx- and- vpn- failover- tgw /" > her < / a >. For andre kunder anbefaler vi at oprette en AWS Site- to- Site VPN som en midlertidig backup sti, se trin < a HURF = "https: / / docs.aws.amazon.com / vpn / nyeste / s2svpn / SetUpVPNConnections.html" > her < / a >. Vi vil give en anden opdatering inden august 16 5: 30 PM PDT, eller før nye oplysninger bliver tilgængelige.

13. 16. august 2026 kl. 22.51 UTCresolved

    Vi har afsluttet vores vurdering af netværksudstyret på Equinix FR5 i Frankfurt, DEU og har nu en klar forståelse af påvirkningens omfang. Vi gør fremskridt i retning af at genoprette forbindelse og vil tage en trinvis tilgang til oprensning. Kunder med forbindelser udelukkende på dette sted vil fortsætte med at opleve pakketab, indtil oprydning er afsluttet. Kunder med multisite eller redundante konfigurationer på tværs af andre Direct Connect steder påvirkes ikke. Vi vil give en anden opdatering inden august 16 10: 30 PM PDT, eller før nye oplysninger bliver tilgængelige.

14. 17. august 2026 kl. 05.38 UTCresolved

    Vi fortsætter med at gøre fremskridt i vores trinvise oprydning på Equinix FR5-stedet i Frankfurt, DEU. Siden vores seneste opdatering, er nogle afhængige netværk infrastruktur blevet genoprettet. Udbedring af resterende infrastruktur er i gang, med en del af inddrivelse afhængig af levering af udskiftning hardware. Køling er blevet fuldstændig genoprettet, og miljøforholdene er stabile inden for normale driftstærskler. Kunder med forbindelser udelukkende på dette sted vil fortsætte med at opleve pakketab som oprensning skrider frem. Kunder med multisite eller redundante konfigurationer på tværs af andre Direct Connect steder påvirkes ikke. Tidligere meddelte afbødningsvejledninger og anbefalinger forbliver uændrede på dette tidspunkt. Vi vil give en anden opdatering inden august 17 4: 30 AM PDT, eller før som oprensning skrider frem.

15. 17. august 2026 kl. 11.22 UTCresolved

    Vi fortsætter med at gøre fremskridt i vores trinvise oprydning på Equinix FR5-stedet i Frankfurt, DEU. Netværksinfrastruktur og afhængige systemer bliver ved med at blive bedre, efterhånden som vi får den berørte hardware online igen. Nogle udskiftning hardware er blevet leveret, og installationen fortsætter som komponenter ankommer on-site. Parallelt, er vi ved at flytte netværkstrafik for at tillade gendannede enheder til at begynde at betjene kunder, som de kommer online. Efterhånden som vi kommer videre gennem inddrivelse, vil kunderne observere restaurering sker i to faser. I første fase vil BGP-sessioner blive genetableret, men der vil endnu ikke blive offentliggjort præfikser for IP, hvilket tyder på, at genopretningen stadig er i gang, og at den underliggende infrastruktur endnu ikke er klar til at beflyve trafikken. I anden fase vil IP-præfiks-annoncen blive genoptaget, og på hvilket tidspunkt infrastrukturen er fuldt renset og forbindelsen genoprettes. Mens vi ikke i øjeblikket har en ETA for fuld genopretning, vi fortsætter med at arbejde så hurtigt og sikkert som muligt for at afbøde virkningen for kunderne. Vi vil give en anden opdatering inden august 17 10: 30 AM PDT, eller før som oprensning skrider frem.

16. 17. august 2026 kl. 16.25 UTCresolved

    Vi arbejder fortsat på trinvis oprydning i Equinix FR5-området i Frankfurt, DEU. Vi ser tidlige tegn på bedring, mens vi fortsætter med at opklare problemet fuldt ud. Vi arbejder aktivt på at bringe den resterende berørte hardware tilbage online, og vi vil give en anden opdatering ved 12: 30 PM PDT, eller før som oprensning skrider frem.

17. 17. august 2026 kl. 17.59 UTCresolved

    Vi ser store tegn på bedring på Equinix FR5 i Frankfurt, DEU. Vi har genoprettet forbindelse til størstedelen af de berørte hardware og de fleste af de forbindelser er fuldt genvundet og stabil. Der er et lille antal kunder, der vil forblive påvirket, indtil de resterende enheder er fuldt restaureret. Vi vil give en anden opdatering ved 2: 00 PM PDT, eller før som oprensning skrider frem.

18. 17. august 2026 kl. 21.00 UTCresolved

    Vi fortsætter med at arbejde på at bringe påvirket hardware tilbage online. Siden vores seneste opdatering har vi gjort fremskridt, der ikke vil være synlige for kunderne, men er nødvendig for inddrivelse. Vi arbejder parallelt på at bringe alle enheder online så sikkert som muligt. Dette arbejde forventes at tage flere timer at fuldføre og validere. For kunder, der kræver workarounds, anbefaler vi, at du overvejer at svigte til VPN. For kunder, der bruger Direct Connect gateway og Transit Gateway, kan du oprette en AWS Site- to- Site VPN og vedhæfte den til din Transit Gateway, se trin < a HURF = "https: / / aws.amazon.com / premiumsupport / viden- center / dx- Share- dx- and- vpn- failover- tgw /" > her < / a >. For andre kunder anbefaler vi at oprette en AWS Site- to- Site VPN som en midlertidig backup sti, se trin < a HURF = "https: / / docs.aws.amazon.com / vpn / nyeste / s2svpn / SetUpVPNConnections.html" > her < / a >. Vi vil give en anden opdatering ved 7: 00 PM PDT eller før som nye oplysninger bliver tilgængelige.

19. 18. august 2026 kl. 01.50 UTCresolved

    Vi ser en betydelig bedring for de fleste kundeforbindelser på dette tidspunkt. Selv om vi endnu ikke er helt genoprettet, er genopbygningsbestræbelserne i gang som forventet på Equinix FR5-lokaliteten i Frankfurt, DEU. Udbedring af den resterende infrastruktur indebærer færdiggørelse af udstyrsudskiftninger og trafikvalidering, som begge er i gang. Vi forventer yderligere customer-synlige opsving som den resterende infrastruktur er bragt tilbage i drift. Kunder med forbindelser udelukkende på dette sted vil fortsætte med at opleve pakketab, indtil oprydning er afsluttet. Tidligere meddelte afbødningsvejledninger og anbefalinger forbliver uændrede på dette tidspunkt. Vi vil give en anden opdatering inden 17 August 11: 00 PM PDT eller tidligere.

20. 18. august 2026 kl. 04.01 UTCresolved

    Fra august 14 7: 33 PM PDT oplevede vi et øget pakketab, der påvirkede AWS Direct Connect konnektivitet for kunder med forbindelser på Equinix FR5 i Frankfurt, DEU. Ingeniører blev automatisk engageret kl. 19.45 den 14. august og straks begyndte at undersøge lempelser. Kl. 20.30 identificerede vi, at netværksudstyr på FR5-lokaliteten var svækket på grund af vandindtrængning i anlægget. Som følge heraf blev kølesystemet svækket, hvilket resulterede i overophedning og lukning. Vand har også påvirket eldistributionssystemer, der har deaktiveret strømmen til netværksenhederne. Den første genopretningsindsats blev forsinket, da miljøforholdene i anlægget krævede stabilisering, før ingeniører kunne sikkert få adgang til det berørte område. I hele august 15 og 16, arbejdede vores ingeniører i koordinering med anlægget operatør for at genoprette beskadigede netværk enheder, mens den underliggende infrastruktur problem blev behandlet. Klokken 19.26 den 17. august blev alt nedsat netværksudstyr restaureret med succes, og forbindelsen til stedet blev verificeret som fuldt operationelt med vedvarende opsving. Vi forventer ikke, at dette spørgsmål gentager sig. Kunder med overflødige forbindelser på tværs af andre Direct Connect steder opretholdt forbindelse gennem deres alternative stier under hele denne begivenhed og kræver ingen yderligere handling. Kunder, der implementerede VPN failover som en workout kan nu sikkert vende tilbage til deres primære Direct Connect stier. Forbindelsen er blevet bekræftet som stabil og fuldt operationel. Kunder, der har brug for yderligere assistance, kan kontakte AWS Support via AWS Management Console eller < a HURF = "https: / / console.aws.amazon.com / support" > AWS Support Center < / a >.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 31. juli 2026 kl. 17.33 UTCresolved

   Vi kan bekræfte forhøjet tab af netværkspakke, hvilket påvirker AWS Direct Connect-forbindelse i AP- SOUTH-1 Region. Vores ingeniørhold blev automatisk optaget kl 9: 54 for at begynde at undersøge problemet. Der er ingen arbejdsområder til rådighed på nuværende tidspunkt. Vi vil give endnu en opdatering ved 11: 30 AM PDT.

2. 31. juli 2026 kl. 18.27 UTCresolved

   Vi har identificeret den grundlæggende årsag til at være relateret til en ændring foretaget til et konfigurationssystem, der er ansvarlig for tildeling ruter til enhederne. Vi har påbegyndt arbejdet med at reducere pakketabet, der påvirker AWS Direct Connect i AP- SOUTH-1-regionen, og vi forventer, at inddrivelse vil finde sted gradvist i løbet af de næste 30 minutter. Efterhånden som vi får tillid til disse bestræbelser, vil vi forsøge at sidestille vores bestræbelser på at fremskynde genopretningen. Vi vil levere endnu en opdatering kl 12: 00 PDT.

3. 31. juli 2026 kl. 18.54 UTCresolved

   Mellem 9: 42 og 11: 44 AM PDT, oplevede vi forhøjede netværkspakken tab påvirker AWS Direct Connect forbindelse i AP- SOUTH-1 regionen. Vores ingeniørhold blev automatisk optaget kl. 9.46 for at undersøge. Ved 10: 51 AM, vi forstod den grundlæggende årsag til at være en konfiguration ændring lavet til et system, der er ansvarlig for at tildele ruter til enheder. Da vi fik tillid til vores afbødende skridt, vi paralleliserede vores bestræbelser på yderligere at reducere pakkens tab. Problemet er løst, og tjenesten fungerer normalt.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 24. juli 2026 kl. 11.40 UTCresolved

   Vi undersøger forbindelsesspørgsmål, der påvirker flere AWS-tjenester i US- WEST-2-regionen.

2. 24. juli 2026 kl. 11.56 UTCresolved

   Vi ser tegn på bedring og fortsætter med at arbejde hen imod fuld bedring.

3. 24. juli 2026 kl. 12.30 UTCresolved

   Vi fortsætter med at se betydelige tegn på genopretning som følge af vores afbødning af problemer med forbindelse påvirker flere AWS-tjenester i US- WEST-2 regionen. Vi har identificeret årsagen som et problem med en netværksenhed, der er ansvarlig for netværksrouting fra regionen til Seattle Metro. Ingeniørerne har afsluttet alt afbødende arbejde. Da ruterne fortsat er genoprettet, bør kunderne se en fortsat reduktion i fejlrater og timeouts, når de tilslutter sig de berørte tjenester. Vi overvåger fremskridt i inddrivelsen nøje og vil fortsætte med at arbejde indtil alle ruter er blevet fuldt restaureret og service målinger vender tilbage til præ-begivenhed niveauer. Vi vil levere endnu en opdatering i de næste 30-45 minutter.

4. 24. juli 2026 kl. 13.01 UTCresolved

   Mellem kl. 3: 55 og kl. 4: 15 oplevede vi problemer med forbindelse, der påvirkede forbindelsen til US- WEST-2-regionen. Dette påvirkede flere AWS-tjenester i regionen. Nogle kunder kan også have oplevet problemer adgang til AWS Management Console, med forbindelse timeouts og ulydhøre sider. Regionens forbindelser blev ikke påvirket. Vores ingeniører blev automatisk engageret kl 4: 01 PDT, og straks begyndte at undersøge dette spørgsmål. Vi identificerede årsagen som et problem med netværksudstyr, der er ansvarlige for netværksrouting fra regionen til Seattle Metro, og begyndte at arbejde parallelt på flere stier for at afbøde virkningen. Vi traf afbødende foranstaltninger, der førte til første helbredelse på 4: 15 AM PDT. Da netværket fortsatte med at stabilisere efter vores afbødende handlinger, en kort reconvergence begivenhed fandt sted mellem 4: 47 AM og 4: 59 AM PDT. I denne rekonvergensperiode kan nogle kunder have oplevet intermitterende konnektivitet over for regionen, efterhånden som netruterne blev genetableret. Ved 4: 59 AM PDT, alle ruter var blevet fuldt restaureret og service målinger returneres til præ-begivenhed niveauer. Kunder, der bruger AWS Direct Connect gennem EqSe2, Westin Building Exchange, Seattle oplevede et udvidet slagvindue fra 3: 55 til 5: 12 AM PDT. Disse kunder ville have oplevet konnektivitet problemer, indtil netruter for denne specifikke vej blev fuldt restaureret på 5: 12 AM PDT. Kunder, der blev tilsluttet via andre AWS Direct Connect steder, blev ikke påvirket af denne begivenhed. Problemet er løst, og alle AWS-tjenester fungerer normalt.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 17. juli 2026 kl. 08.33 UTCresolved

   Vi undersøger problemer med Cost Explorer afspejler unøjagtige estimerede fakturering data.

2. 17. juli 2026 kl. 09.07 UTCresolved

   Begynder den 16 juli 7: 38 PM PDT, vi begyndte at vise forkert estimerede fakturering data i fakturering og omkostninger management konsol. Vores ingeniørhold undersøger årsagen. Vi vil give en anden opdatering ved 3: 00 AM PDT eller tidligere, hvis mere information bliver tilgængelig.

3. 17. juli 2026 kl. 10.03 UTCresolved

   Vi fortsætter med at arbejde på at løse problemet, der påvirker anslåede omkostninger og brug data vises i fakturering og omkostningsstyring konsol. Vi har identificeret årsagen som et problem med enhedspriser inden for det estimerede faktureringsdelsystem, og vi arbejder på en afbødning. De viste faktureringsestimater afspejler ikke faktisk brug og gebyrer. Der kræves ingen kundehandlinger på nuværende tidspunkt. Når spørgsmålet er blevet mildnet, forventer vi fuld opløsning til at tage flere timer, som vi arbejder gennem recomputing de anslåede fakturering data. Vi vil give en anden opdatering ved 4: 00 AM PDT eller tidligere, hvis mere information bliver tilgængelig.

4. 17. juli 2026 kl. 10.52 UTCresolved

   Vi fortsætter med at arbejde på at løse problemet, der påvirker anslåede omkostninger og brug data vises i fakturering og omkostningsstyring konsol. Som tidligere nævnt har vi identificeret den grundlæggende årsag som et problem med enhedspriser inden for det estimerede faktureringsdelsystem. For at undgå yderligere unøjagtige faktureringsestimater, har vi sat estimerede faktureringsberegninger på pause. Kunder, der i øjeblikket ser normale bill estimater vil fortsætte med at se disse estimater, og kunder, der ser oppustede estimater vil ikke se dem stige yderligere, mens vi arbejder mod opløsning. De viste faktureringsestimater afspejler ikke faktisk brug og gebyrer. Vi fortsætter med at arbejde på fuldt ud at mindske problemet. Når spørgsmålet er blevet mildnet, forventer vi fuld opløsning til at tage flere timer, som vi arbejder gennem recomputing de anslåede fakturering data. Der kræves ingen kundehandlinger på nuværende tidspunkt. Vi vil give en anden opdatering ved 5: 00 AM PDT eller tidligere, hvis mere information bliver tilgængelig.

5. 17. juli 2026 kl. 11.58 UTCresolved

   Vi fortsætter med at arbejde på at løse problemet, der påvirker anslåede omkostninger og brug data vises i fakturering og omkostningsstyring konsol. Vi arbejder aktivt på flere afbødende veje parallelt. Den første sti indebærer at vende tilbage til den sidste kendte gode estimerede regning beregning. Med denne tilgang, vil kunderne kun se omkostninger og brug data gennem juli 15, men de oppustede omkostninger data vil blive fjernet. Den anden sti består i at rulle en nylig ændring tilbage til delsystemet fakturering. De viste faktureringsestimater afspejler ikke faktisk brug og gebyrer. Der kræves ingen kundehandlinger på nuværende tidspunkt. Når spørgsmålet er blevet mildnet, forventer vi fuld opløsning til at tage flere timer, som vi arbejder gennem recomputing de anslåede fakturering data. Vi vil give en anden opdatering ved 6: 00 AM PDT eller tidligere, hvis mere information bliver tilgængelig.

6. 17. juli 2026 kl. 12.54 UTCresolved

   Vi fortsætter med at arbejde på flere afbødende stier parallelt for at løse problemet påvirker anslåede omkostninger og brug data vises i Billing og Cost Management Console, herunder omkostninger og brug rapport. Vi er ved at evaluere de estimerede faktureringsberegninger, da vores interne overvågning indikerer, at delsystemet fakturering nu producerer nøjagtige estimater. Vi foretager yderligere validering, før vi går videre med denne vej. De viste faktureringsestimater afspejler ikke faktisk brug og gebyrer. Der kræves ingen kundehandlinger på nuværende tidspunkt. Vi vil give en anden opdatering ved 8: 00 AM PDT eller tidligere, hvis mere information bliver tilgængelig.

7. 17. juli 2026 kl. 14.53 UTCresolved

   Vi fortsætter med at arbejde for at løse problemet, der påvirker de anslåede omkostninger og brugsdata, der vises i fakturerings- og omkostningsstyringskonsollen, herunder omkostnings- og brugsrapporten. Tilbagetrækningen af en nylig ændring løste ikke problemet, og vi fortsætter med at undersøge flere afbødende veje. Anslåede lovopdateringer er stadig sat på pause. Vi er i færd med at vende tilbage til de sidste nøjagtige estimerede faktureringsdata. De viste faktureringsestimater afspejler ikke faktisk brug og gebyrer. Der kræves ingen kundehandlinger på nuværende tidspunkt. Vi forventer denne afbødning til at tage flere timer at fuldføre, som vi arbejder gennem recomputing de anslåede fakturering data. Vi vil give en anden opdatering ved 10: 00 AM PDT eller tidligere, hvis mere information bliver tilgængelig.

8. 17. juli 2026 kl. 16.59 UTCresolved

   Vi har identificeret den grundlæggende årsag og mindsket det underliggende problem forårsager forkert estimerede omkostninger og brug data, der skal vises i Billing og Cost Management Console, og omkostninger og brug rapporter. Vi er begyndt at huske data for at korrigere omkostningsdata for alle kunder. Vi forventer nogle kunder til at begynde at se inddrivelse inden for de næste tre timer, og fuld inddrivelse for alle kunder i juli 18 12: 00 PM PDT. Indtil backfill er færdig, nogle kunder kan stadig se forkerte omkostninger og brug data. De viste faktureringsestimater afspejler ikke faktisk brug og gebyrer. Der kræves ingen kundehandlinger på nuværende tidspunkt. Vi vil give en anden opdatering ved 13: 00 PM, eller tidligere, hvis oplysninger bliver tilgængelige.

9. 17. juli 2026 kl. 19.56 UTCresolved

   Vores bestræbelser på at efterfylde korrigerede anslåede omkostninger og brugsdata er stadig i gang. Vi går langsommere end forventet. Mens vi ser nogle konti inddrive med korrekte omkostninger og brugsdata, forventer vi alle berørte konti skal inddrives i juli 19 12: 00 PDT. Indtil backfill er færdig, nogle kunder kan stadig se forkerte omkostninger og brug data. De viste faktureringsestimater afspejler ikke faktisk brug og gebyrer. Der kræves ingen kundehandlinger på nuværende tidspunkt. Vi vil give en anden opdatering kl. 19: 00, eller før, hvis oplysninger bliver tilgængelige.

10. 18. juli 2026 kl. 01.38 UTCresolved

    Vi fortsætter med at gøre konstante fremskridt i retning af at løse problemet påvirker anslåede omkostninger og brug data vises i Billing og Cost Management Console. Vores indsats for at efterfylde korrigerede data er stadig i gang, og vi forventer, at alle berørte konti vil blive fuldt tilbagebetalt i juli 19, 12: 00 PDT. Indtil backfill er færdig, nogle kunder kan stadig observere forkerte omkostninger og brug data i Billing og Cost Management Console og omkostninger og brug rapporter. Disse estimater afspejler ikke faktisk brug eller gebyrer. Kunder, der konfigurerede deres Cost and Usage Report med "Overskriv" valgmulighed kræver ingen handling - deres rapport vil automatisk blive opdateret med korrigerede data, når backfill afsluttet. Kunder, der konfigurerede deres Cost and Usage Report med "Opret nye rapport versioner" valgmulighed bevarer alle tidligere rapport leverancer i deres S3 spand. Den rapportversion, der leveres under det ramte vindue, kan indeholde unøjagtige data. Når datamanglen er færdig, vil en korrigeret rapportversion blive leveret under en ny assembleId. Kunder, der bruger denne konfiguration, bør opdatere eventuelle downstream processer (Athena tabeller, Redshift rørledninger, Amazon QuickSight, eller brugerdefinerede ETL) for at henvise til den nyeste assembleId for den berørte faktureringsperiode, og kan slette eller arkivere den påvirkede rapport version for at forhindre behandling af stade data. For at identificere den seneste rapport, kan kunderne følge trinene i vores < a HRF = "https: / / docs.aws.amazon.com / cu / nyeste / userguide / view- latest- cur.html" > dokumentation < / a >. Vi vil give en anden opdatering inden 18 juli, 1: 00 AM PDT, eller tidligere, hvis yderligere oplysninger bliver tilgængelige.

11. 18. juli 2026 kl. 08.05 UTCresolved

    Vi fortsætter med at gøre betydelige fremskridt i retning af at løse problemet påvirker anslåede omkostninger og brug data vises i Billing og Cost Management Konsole. Vores afbødende indsats fungerer som forventet, og vi ser et stigende antal regnskaber, der afspejler korrekte omkostninger og brugsdata. Vi forventer, at alle berørte konti bliver fuldt tilbagebetalt inden den 19. juli kl. 12. Indtil backfill er færdig, nogle kunder kan stadig observere forkerte omkostninger og brug data i Billing og Cost Management Console og omkostninger og brug rapporter. Disse estimater afspejler ikke faktisk brug eller gebyrer. Vi vil give en anden opdatering inden 18 juli kl. 7: 00 PDT, eller før, hvis yderligere oplysninger bliver tilgængelige.

12. 18. juli 2026 kl. 13.57 UTCresolved

    Mellem 16 juli kl. 7: 38 PM PDT og 18 juli kl. 6: 00 PDT, begyndte vi at vise forkerte estimerede faktureringsdata i fakturerings- og omkostningsstyringskonsollen, herunder omkostnings- og brugsrapporten. Kunderne kan have modtaget forkerte budget og omkostninger anomali afsløring indberetninger, og observerede oppustede anslåede omkostninger og brug data. Den 16. juli kl. 7: 46 PDT, vores alarmer opdaget omkostninger anomalier, men undlod at stoppe den anslåede bill generering proces eller advare vores ingeniørhold. Vi blev advaret om dette spørgsmål den 17. juli kl 12: 19 AM PDT af kundeeskaleringer, og straks begyndte at undersøge. Vi først informeret kunder via AWS Sundhed den 17. juli kl 1: 33 AM. Kl. 8.24 holdt vi pause med yderligere opdateringer til estimerede faktureringsdata og slukkede for budget- og omkostningsanomali som en sikkerhedsforanstaltning. Vi identificerede årsagen den 17. juli kl 12: 00 PDT som en konfiguration ændring i vores regning beregningssystem. Dette system er baseret på enhedsdata om konvertering til beregning af gebyrer for linjeposter. Konfigurationsændringen forårsagede, at opdateringer til enhedskonverteringsdataene mislykkedes, hvilket resulterede i oppustede omkostninger til linjeposter, som blev spredt til konsollen for fakturering og omkostningsstyring og udløste budget- og omkostningsanomali. Vi afbødede spørgsmålet den 17. juli kl. 12: 30 PDT som korrigerede enhedens konvertering konfiguration, og begyndte oparbejdning omkostninger og brugsdata for alle kundekonti. Vi begyndte at observere opsvinget kl. 16.19, og de fleste konti blev fuldt ud inddrevet i juli 18 kl. 18.00. Der er et lille antal konti stadig behandling, og vi vil sende opdateringer til disse konti på Personal Health Dashboard. Vi har rettet vores alarmer til straks at stoppe behandling og underrette vores ingeniørhold, når anomalier opstår. Vi undskylder for alarmen denne hændelse forårsagede vores kunder og udfører en grundig retrospektiv for at forhindre begivenheder som dette fra at gentage, samt forbedre vores reaktion, når fakturering hændelser opstår. Problemet er løst, og alle AWS-tjenester fungerer nu normalt.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 16. juli 2026 kl. 08.44 UTCresolved

   Vi undersøger øget 5xx fejl for Cloudfront kunder ved hjælp af VPC Origin forbindelse.

2. 16. juli 2026 kl. 09.21 UTCresolved

   Start på 12: 45 AM PDT, vi oplever øgede 5xx fejl for CloudFront kunder, der bruger VPC Origin-forbindelse. Vi har bekræftet, at kunder, der udnytter andre oprindelsestyper, ikke påvirkes af dette spørgsmål. Vores ingeniører er engagerede og arbejder aktivt på at afbøde virkningerne. Som en workout, kunder, der ikke kræver VPC Origin kan ændre deres oprindelse type til at løse fejlene. Vi vil give en anden opdatering af 3: 15 AM PDT, eller tidligere, hvis mere information bliver tilgængelig.

3. 16. juli 2026 kl. 10.18 UTCresolved

   Vi fortsætter med at arbejde på at løse de øgede 5xx fejl for CloudFront kunder, der bruger VPC Origin-forbindelse. Kunder, der benytter andre oprindelsestyper, er ikke berørt af dette problem. Baseret på vores undersøgelse, mener vi, at den grundlæggende årsag er relateret til en pakke behandling delsystem er ansvarlig for routing anmodninger fra CloudFronts kant steder til ressourcer i kunde VPC 'er. Vi fortsætter med at anbefale, at kunder, der er i stand til at gøre det midlertidigt ændre deres oprindelse type til at løse fejlene. Vi vil give en anden opdatering ved 4: 15 AM PDT, eller tidligere, hvis yderligere oplysninger bliver tilgængelige.

4. 16. juli 2026 kl. 11.16 UTCresolved

   Vi fortsætter med at arbejde på at løse de øgede 5xx fejl for CloudFront kunder, der bruger VPC Origin-forbindelse. Kunder, der benytter andre oprindelsestyper, er ikke berørt af dette problem. Vi har yderligere undersøgt problemet ned til routing tabel kapacitet inden for pakke behandling delsystemet ansvarlig for routing anmodninger fra CloudFronts kant steder til ressourcer inden kunde VPC 'er. Vi har identificeret og afprøver i øjeblikket en afbødningsstrategi for at løse problemet. Når testen er færdig, vil vi anvende afbødningen i en trinvis tilgang. På baggrund af resultaterne af disse test vil vi give en klarere estimeret tid til løsning i vores næste opdatering. Vi fortsætter med at anbefale, at kunder, der er i stand til at gøre det midlertidigt ændre deres oprindelse type til at løse fejlene. Vi vil give en anden opdatering af 5: 15 AM PDT, eller hurtigere, hvis yderligere oplysninger bliver tilgængelige.

5. 16. juli 2026 kl. 11.27 UTCresolved

   Vi ser tegn på bedring og fortsætter med at arbejde hen imod fuld bedring.

6. 16. juli 2026 kl. 11.57 UTCresolved

   Vi ser fortsat betydelige tegn på bedring som følge af vores afbødende indsats, med fuld genopretning forventes inden for de næste 45 minutter.

7. 16. juli 2026 kl. 12.21 UTCresolved

   Mellem 12: 45 og 4: 18 AM PDT, oplevede vi øgede 5xx fejl for CloudFront kunder ved hjælp af VPC Origin forbindelse. Vores ingeniører blev automatisk engageret og straks begyndte at undersøge den grundlæggende årsag. Ved 2: 57 AM PDT, vi identificeret den grundlæggende årsag til problemet som en intern begrænsning på flåden, der styrer forbindelser til private VPC oprindelser. Da denne begrænsning blev nået, kunne det system, der var ansvarligt for at distribuere routing-konfigurationen til vores netværksprocessorer, ikke indlæse de opdaterede konfigurationsdata korrekt, hvilket påvirkede routing af VPC Origin-forbindelser. Klokken 3.52 tog vi flere afbødende foranstaltninger, der førte til fuld helbredelse kl. 4.18. Nu hvor problemet er blevet mildnet, kan kunder, der midlertidigt ændrede deres oprindelse type sikkert vende disse ændringer. Kunder, der benyttede andre oprindelsestyper, var ikke berørt af dette problem. Problemet er løst, og tjenesten fungerer normalt.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 15. juli 2026 kl. 23.11 UTCresolved

   Vi er ved at undersøge forhøjede konnektivitet problemer med en enkelt Avalability zone (euc1- az2) i EU-CENTAL-1 Region.

2. 15. juli 2026 kl. 23.36 UTCresolved

   Vi ser tidlige tegn på bedring og fortsætter med at arbejde hen imod fuld løsning. Vi vil fortsat levere opdateringer.

3. 16. juli 2026 kl. 01.24 UTCresolved

   Mellem 2: 56 og 6: 07 PDT oplevede vi problemer med forbindelse til en delmængde af EC2-tilfælde i en enkelt tilgængelighedszone (euc1- az2) i EU- CENTAL-1-regionen. I løbet af denne tid, kunder kan også have oplevet øgede fejlrater og latesser for nye instans lancerer i den berørte zone, sammen med nogle AWS API 'er, der bruger de berørte EC2 tilfælde. Nogle AWS Services også oplevet konnektivitet problemer og øgede fejlrater inden for den berørte zone. Ingeniører blev automatisk engageret og straks begyndte at undersøge. Som en del af vores opsving indsats, flyttede vi trafik væk fra den ramte tilgængelighed Zone for berørte tjenester på 03: 04 PM. Kl. 15: 05 identificerede vi årsagen til, at det var en nylig netværksændring, der forårsagede virkningen. Ingeniører straks begyndte at vende denne ændring, som afsluttet kl. 16.28. Dette resulterede i genoprettelse af netværksforbindelse til den berørte zone kl. 16.30. Vi fortsatte med at arbejde, indtil vi fuldt ud genvundet virkningerne på 6: 07 PM. Vi forventer ikke, at dette spørgsmål gentager sig. Problemet er løst, og tjenesten fungerer normalt.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 6. juli 2026 kl. 12.45 UTCresolved

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

2. 6. juli 2026 kl. 13.34 UTCresolved

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

3. 6. juli 2026 kl. 14.12 UTCresolved

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

4. 6. juli 2026 kl. 14.53 UTCresolved

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

1. 30. juni 2026 kl. 21.02 UTCresolved

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

2. 30. juni 2026 kl. 21.21 UTCresolved

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

3. 30. juni 2026 kl. 21.29 UTCresolved

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

4. 30. juni 2026 kl. 21.53 UTCresolved

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

1. 13. juni 2026 kl. 01.26 UTCresolved

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

2. 15. juni 2026 kl. 18.13 UTCresolved

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

1. 6. juni 2026 kl. 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. maj 2026 kl. 23.38 UTCresolved

   We are investigating increased error rates for Route53 API calls.

2. 23. maj 2026 kl. 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. maj 2026 kl. 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. maj 2026 kl. 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. maj 2026 kl. 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. maj 2026 kl. 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. maj 2026 kl. 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. maj 2026 kl. 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. maj 2026 kl. 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. maj 2026 kl. 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. maj 2026 kl. 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. maj 2026 kl. 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. maj 2026 kl. 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. maj 2026 kl. 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. maj 2026 kl. 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. maj 2026 kl. 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. maj 2026 kl. 03.04 UTCresolved

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

1. 27. april 2026 kl. 11.27 UTCresolved

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

2. 27. april 2026 kl. 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. marts 2026 kl. 19.53 UTCresolved

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

2. 7. marts 2026 kl. 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. marts 2026 kl. 20.28 UTCresolved

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

4. 7. marts 2026 kl. 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. marts 2026 kl. 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. marts 2026 kl. 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. marts 2026 kl. 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. marts 2026 kl. 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. marts 2026 kl. 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. marts 2026 kl. 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. marts 2026 kl. 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. marts 2026 kl. 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. marts 2026 kl. 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. marts 2026 kl. 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. marts 2026 kl. 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. marts 2026 kl. 16.40 UTCresolved

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

13. 30. april 2026 kl. 07.07 UTCinvestigating

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

14. 15. september 2026 kl. 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.