AWS kesinti geçmişi

1. 3 Eylül 2026 21:49 UTCresolved

   2:12 PM PDT'ye başlayın, STS için API hata oranları yaşadık ve ABD-WEST-2 Bölgesi'nde SAML kullanırken oturum açın. Mühendislik ekibimiz, kök nedenini araştırmaya başlamak için 2:19 PM'de otomatik olarak meşguldü. Bu anda mevcut olan bir iş yoktur. 3:30 PM PDT tarafından başka bir güncelleme sağlayacağız.

2. 3 Eylül 2026 22:26 UTCresolved

   Erken iyileşme belirtileri görüyoruz ve tam iyileşme için izlemeye devam ediyoruz. 4:15 PM'de başka bir güncelleme sağlayacağız ya da daha önce paylaşmak için ek bilgilerimiz varsa.

3. 3 Eylül 2026 23:20 UTCresolved

   STS AssumeRoleWithSAML ve AssumeRoleWithWebIdentity APIsleri için ABD-WEST-2 Bölgesi'nde istikrarlı bir şekilde kurtarmayı sürdürüyoruz. Hata oranları şimdi ön icat seviyelerinin geri döndü ve tam kurtarmayı doğrulamaya devam ediyoruz. 5:15 PM veya daha önce başka bir güncelleme sağlayacağız.

4. 4 Eylül 2026 00:07 UTCresolved

   2:12 PM ve 3:18 PM PDT arasında, STS AssumeRoleWithSAML ve AssumeRoleWithWebIdentity APIs'leri ABD-WEST-2 bölgesinde etkileyen API hata oranları deneyimlendik. Kök nedeni, dış kimlik sağlayıcıları ile iletişimden sorumlu bir STS subsystem ile ilgili bir sorun nedeniyle belirlenir. Bu kimlik federasyon protokollerine güvenen diğer AWS Services de etkilendi. 3:18 PM'de, kurtarma belirtileri gördük ve istikrar ve tam iyileşme sağlamak için izlemeye devam ettik. Sorun çözüldü ve hizmet normalde bu anda çalışıyor.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 21 Ağustos 2026 02:02 UTCresolved

   AP-NORTHEAST-1リージョンにおいて、エラー率が上昇しており、リアルタイムメトリクスに影響が出ています。お客様はリアルタイムメトリクスデータの欠落または遅延を経験する可能性があります。| AP-NORTHEAST-1 bölgesinde gerçek zamanlı ölçümleri etkileyen artan hata oranları yaşıyoruz. Müşteriler eksik veya gecikmiş gerçek zamanlı ölçüm verileri yaşayabilirler.

2. 21 Ağustos 2026 02:40 UTCresolved

   8:58 AM NOR 10:34 AM NORAP-NORTHEAST-1 リージョンにおける Amazon Connect のリアルタイムメトリクスに影響する遅延が増加し、データが欠落する、またはデータが最新の状態に更新されない事象が発生しました。この間、お客様は分析レポート内で一部のデータが反映されない状況を経験した可能性があり、また、コンタクトフロー内でリアルタイムメトリクス ( : 人員の確認ブロック) にアクセスする際に問題が発生した可能性があります。根本原因は、メトリクスイベント配信を担うサブシステムの問題であると特定しました。日本時間 10:13 AM the 10:34 AM . / 4:58 PM ve 6:34 PM PDT arasında, AP-NORTHEAST-1 Bölgesi'nde Amazon Connect için gerçek zamanlı ölçümleri etkileyen gecikmeler yaşadık, eksik veya durgun verilerle sonuçlandı. Bu süre zarfında, müşteriler analiz raporları içinde eksik veriler deneyimlenebilir ve müşteri personelinin kontrol ettiği gibi iletişim Akışları içinde gerçek zamanlı ölçümlere erişerek sorunları gözlemleyebilir. Kökün metrik olay teslimatından sorumlu alt sistemle ilgili bir sorun olduğunu tespit ettik. 6:13 PM'deki davaları uygulamaya başladık ve sorunu 6:34 PM azalttık. Sorun çözüldü ve hizmet normalde çalışıyor.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 19 Ağustos 2026 15:15 UTCresolved

   AB-WEST-2 Bölgesi'nde yeni başlatılan bir işlemde yeni bir EC2 örneği ve kaynakları başlatmanın etkisini araştırıyoruz. Bu süre zarfında, etkilenen müşteriler bölgedeki kaynakları oluştururken sorunlar yaşayabilir veya değiştirebilir. Diğer AWS hizmetleri de etkilenebilir. Acil kurtarma için, müşterilerin alternatif erişilebilirlik bölgeleri kullanması tavsiye ederiz (euw2-az1, euw2-az2 ve euw2-az3 uygulanabilir. Mevcut koşu örnekleri ve kaynakları etkilenmez. 10:00 AM PDT ile başka bir güncelleme sağlayacağız veya daha önce paylaşmak için ek bilgilere sahip olursak.

2. 19 Ağustos 2026 17:03 UTCresolved

   18 Ağustos'ta AB-WEST-2 Bölgesi'nde yeni bir erişilebilir bölge başlattık. Tanıtımtan sonra, varsayılan bir altnet mevcut olmadığı zaman yeni erişilebilir bölgede EC2 örneklerini ortaya çıkarmaya başladık. Mevcut çalışan örneklerin ve kaynakların etkilenmediğini onaylayabiliriz. Bölgedeki erişilebilirlik bölgelerinin bir listesini otomatik olarak alan iş akışları, TanımAvailabilityZones API aracılığıyla ve daha sonra yeni örnekleri başlatmaya veya yeni erişilebilirlik Bölgesindeki kaynakları yaratmaya çalışır. EC2 örneği başlangıç başarısızlıkları için, otomatik olarak varsayılan altnetler oluşturmak için adımlar atıyoruz, biri zaten mevcut değil, EC2 örneği lansmanı yeni erişilebilir Bölgesi hedef alıyor. Müşteriler ve iş akışları için, hemen geri ödeme <a href="https://docs.aws.amazon.com/vpc/latest/userguide/work-with-default-vpc.html #create-default-subnet"> Yeni Kesintisiz Bölgede varsayılan bir altnet</a> oluşturabilirsiniz. Bu, EC2 örneği başarıyla tamamlamak için başlatacaktır. Lambda işlevleri gibi diğer kaynaklar için, yeni erişilebilir bölgenin şu anda desteklenmediği yer, müşterilerin yeni başlatılan bölgeleri dışlamalarını ve bölgedeki diğer erişilebilir bölgeleri kullanarak kaynak oluşturmasını tavsiye ediyoruz. Boşluk çabalarımızın ne kadar süreceği konusunda kesin bir tahminimiz olmasa da, ilerlememiz hakkında sizi güncel tutacağız ve 1:00 PM PDT veya yeni bilgi olarak size başka bir güncelleme sunacağız.

3. 19 Ağustos 2026 18:47 UTCresolved

   18:00 PM ve 19 11:00 AM PDT arasında, AB-WEST-2 Bölgesi'nde yeni başlatılan bir operasyonda EC2 örneklerini başlattık. Yeni Kesintisiz Bölge lansmanından sonra, varsayılan VPC kullanarak hataları deneyimlemeye başladık. 19 Ağustos'ta 9:00'da konunun kök nedenini keşfettik ve sorunu 9:30'da çözmek için bir değişiklik dağıtmaya başladık. Değişim devam ederken, 11 AM'de tam iyileşme ile yeni örnek fırlatmalarda artış görmeye başladık. Mevcut koşu örnekleri ve kaynakları etkilenmedi. Lambda işlevleri veya Aurora veritabanı gibi bazı bölgesel hizmetler, yeni erişilebilir bölgenin başlangıcında mevcut değildi ve hizmet kullanılabilirliği zamanla eklenecektir. Servisler mevcut hale gelmeden önce kaynakları yaratmaya çalışan müşteriler, Kesintisiz Bölgede desteklenmediği bir mesaj raporlaması görecek. Sorun çözüldü ve hizmet normalde çalışıyor.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 15 Ağustos 2026 03:42 UTCresolved

   Artan paket kaybı araştırıyoruz, AWS Direct Connect bağlantısını AB-CENTRAL-1 bölgesinde bazı müşteriler için etkiliyoruz.

2. 15 Ağustos 2026 04:42 UTCresolved

   Doğrudan Connect bağlantılarını AB-CENTRAL-1 Bölgesinde onaylayabiliriz. Mühendisler otomatik olarak meşguldü ve her ikisi de kök nedenini tanımlamaya ve sorunu azaltmak için çok paralel yolları tespit etmeye başladılar. Bu zamanda erken iyileşme belirtileri görüyoruz. 60 dakika içinde başka bir güncelleme sağlayacağız ya da daha önce paylaşmak için ek bilgilerimiz varsa.

3. 15 Ağustos 2026 05:55 UTCresolved

   7:33 PM PDT'den başlayarak, AB-CENTRAL-1 Bölgesi'ndeki bazı müşteriler için AWS Direct Connect bağlantısını etkilemeye başladık. İlerleme kaydettiğimizde, aşağıdaki Doğrudan Connect konumuna bağlantılar hala bozulmaktadır: Equinix FR5, Frankfurt, DEU. Doğrudan Connect yollarıyla yapılandırılan çok yerdeki reddantme sahip müşteriler bu anda etki görmemelidir. Sadece Equinix FR5'te bağlantıları olan müşteriler Frankfurt, DEU konumu bağlantı sorunlarını deneyimlemeye devam edecektir. Etkiyi azaltmak ve tam kurtarmaya çalışmak için aktif olarak çalışıyoruz, ancak tam kurtarmanın birkaç saat uzakta olduğunu bekliyoruz. 90 dakika içinde bir güncelleme sağlayacağız ya da daha önce paylaşmak için ek bilgilerimiz varsa.

4. 15 Ağustos 2026 07:24 UTCresolved

   Doğrudan Connect konumu aracılığıyla bağlantı kurmak için aktif olarak çalışıyoruz: Equinix FR5, Frankfurt, DEU. Sadece Equinix FR5'te bağlantıları olan müşteriler Frankfurt, DEU konumu bağlantı sorunlarını deneyimlemeye devam edecektir. VPN'ye başarısız olmak için mevcut olan bir iş için, kurtarma elde etmek için bunu yapmak önerilir. Doğrudan Connect ağ geçidi ve Transit Gateway kullanan müşteriler için, bir AWS Site-to-Site VPN oluşturmanızı ve Transit Gateway'inize bağlanmanızı tavsiye ederiz, <a href="https://aws.amazon.com/premiumsupport/bilgi-merkez/dx-con-dx-ve-vpn-failover-tgw/">here</a>. Diğer müşteriler için, geçici bir yedekleme yolu olarak bir AWS Site-to-Site VPN kurmayı tavsiye ederiz, adımları <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html Bu sefer olduğu gibi, kurtarmanın birkaç saat uzakta olduğunu umuyoruz. 90 dakika içinde başka bir güncelleme sağlayacağız ya da daha önce paylaşmak için ek bilgilerimiz varsa.

5. 15 Ağustos 2026 09:08 UTCresolved

   AWS Direct Connect bağlantılarını Equinix FR5, Frankfurt, DEU'da kurtarmaya devam ediyoruz. Kök nedeni, ağ altyapısını etkileyen yerde bir tesis altyapı sorunu ile ilgilidir. Sadece bu yerde bağlantıları olan müşteriler, paket kaybı veya bağlantı bozulmasını deneyimlemeye devam edecektir. Diğer yerlerde çok yer veya kırmızı konfigürasyonlu müşteriler etkilenmez. Bir iş için, VPN'ye devretme seçeneğine sahip olan müşterilerin bunu yapması önerilir. Doğrudan Connect ağ geçidi ve Transit Gateway kullanan müşteriler için, bir AWS Site-Site VPN oluşturmanızı ve bunu Transit Gateway'inize bağlamanızı tavsiye ederiz, <a href="https://aws.amazon.com/premiumsupport/bilgi-merkez/dx-configure-dx-and-vpn-failover-tgw/">here</a>. Diğer müşteriler için geçici bir yedekleme yolu olarak bir AWS Site-to-Site VPN kurmayı tavsiye ederiz, <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html"> Bu sefer olduğu gibi, kurtarmanın birkaç saat uzakta olduğunu umuyoruz. 2 saat içinde başka bir güncelleme yapacağız ya da paylaşmak için daha fazla bilgimiz olduğu sürece.

6. 15 Ağustos 2026 11:10 UTCresolved

   AWS Direct Connect bağlantı, Frankfurt, DEU'daki Equinix FR5 konumundaki müşteriler için yetersiz kalıyor. Diğer yerlerde çok yer veya kırmızı konfigürasyonlu müşteriler etkilenmeye devam ediyorlar. Mühendisler bağlantıyı geri yüklemek için aktif olarak çalışıyorlar, birden çok iş akışında devam eden çabaların altında yatan tesisi sorununu çözmek ve etkili ağ ekipmanlarını hizmete geri getirmek. Kurtarmanın birkaç saat uzakta olmasını beklemeye devam ediyoruz. Bir iş için, VPN'ye devre dışı bırakma seçeneği olan müşterilerin bunu yapması önerilir. Doğrudan Connect ağ geçidi ve Transit Gateway kullanan müşteriler için, bir AWS Site-Site VPN oluşturmanızı ve bunu Transit Gateway'inize bağlamanızı tavsiye ederiz, <a href="https://aws.amazon.com/premiumsupport/bilgi-merkez/dx-configure-dx-and-vpn-failover-tgw/">here</a>. Diğer müşteriler için geçici bir yedekleme yolu olarak bir AWS Site-to-Site VPN kurmayı tavsiye ederiz, <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html"> 2 saat içinde başka bir güncelleme yapacağız ya da paylaşmak için daha fazla bilgimiz olduğu sürece.

7. 15 Ağustos 2026 13:17 UTCresolved

   Mühendisler, Frankfurt, DEU'da Equinix FR5 konumunu yeniden yüklemeye devam ediyorlar. Ortak konum ortağımız alt temel tesisi altyapı sorununu çözmeye çalışıyor ve gelişmeler henüz müşteri görünmezken, karara karşı olumlu ilerleme yapıyoruz. Acil kurtarma gerektiren müşteriler için, önceki güncellemelerimizde belirtildiği gibi VPN'ye başarısız olmayı öneriyoruz. 9:30 AM PDT ile başka bir güncelleme sağlayacağız ya da daha önce paylaşmak için ek bilgilere sahip olursak.

8. 15 Ağustos 2026 16:27 UTCresolved

   Co-location ortağımız, Frankfurt, DEU'daki Equinix FR5 lokasyonunda temel tesisi altyapı sorununu çözmeye devam ediyor. Etkilenen bölgeye erişim şu anda güvenlik endişeleri nedeniyle kısıtlanır, bu da ağ ekipmanının fiziksel durumunu değerlendirme ve daha doğru bir kurtarma süresi sağlar. Mevcut bilgilere dayanarak, tam kurtarma yakın vadede beklenmiyor ve bugün ötesine uzatılabilir. AWS Direct Connect bağlantıları bu yerde bozulmamaktadır. Diğer yerlerdeki kırmızı bağlantıları olan müşteriler etkilenmez. Doğrudan Connect ağ geçidi ve Transit Gateway kullanan müşteriler için, bir AWS Site-Site VPN oluşturmanızı ve bunu Transit Gateway'inize bağlamanızı tavsiye ederiz, <a href="https://aws.amazon.com/premiumsupport/bilgi-merkez/dx-configure-dx-and-vpn-failover-tgw/">here</a>. Diğer müşteriler için geçici bir yedekleme yolu olarak bir AWS Site-to-Site VPN kurmayı tavsiye ederiz, <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html"> 3:30 PM PDT ile başka bir güncelleme sağlayacağız veya daha önce paylaşmak için ek bilgilere sahip olursak.

9. 15 Ağustos 2026 22:26 UTCresolved

   Ortak konum ortağımız, Frankfurt, DEU'daki Equinix FR5 konumundaki etkilenen bölgeye güvenli erişim sağlamak için çalışmaya devam ediyor. Güvenli erişim sağlandığında, mühendislerimiz etkilenen ağ cihazlarını değerlendirebilecek. İlerlemeyi yakından takip etmeye devam ediyoruz ve 9:30 PM PDT tarafından bir güncelleme paylaşacağız ya da yeni bilgiler mevcut olacak.

10. 16 Ağustos 2026 04:37 UTCresolved

    Frankfurt, DEU'daki Equinix FR5 konumunu yeniden yüklemek için ortaklarımızla aktif olarak ilgileniyoruz. Son güncellememizden beri, Frankfurt, DEU'daki Equinix FR5 konumundaki etkilenen bölgeye güvenli erişim sağlamak için artan ilerleme kaydettik. paralel olarak, kritik ve yüksek öncelikli rafların restore edileceği siparişe öncelik verdik, masyon çabalarının bir parçası olarak. Mevcut değerlendirmemize dayanarak, tam kurtarma yakın vadede beklenmiyor ve bugün ötesine uzatılabilir. AWS Direct Connect bağlantıları bu yerde bozulmamaktadır. Sadece bu yerde bağlantıları olan müşteriler paket kaybı deneyimlemeye devam edecektir. Diğer Doğrudan Connect lokasyonlarında çoklu yer veya reddant konfigürasyonları olan müşteriler etkilenmez. Bir iş için, VPN'ye devretme seçeneğine sahip olan müşterilerin bunu yapması önerilir. Doğrudan Connect ağ geçidi ve Transit Gateway kullanan müşteriler için, bir AWS Site-Site VPN oluşturmanızı ve bunu Transit Gateway'inize bağlamanızı tavsiye ederiz, <a href="https://aws.amazon.com/premiumsupport/bilgi-merkez/dx-configure-dx-and-vpn-failover-tgw/">here</a>. Diğer müşteriler için geçici bir yedekleme yolu olarak bir AWS Site-to-Site VPN kurmayı tavsiye ederiz, <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html"> İlerlemeyi yakından takip etmeye devam ediyoruz ve 16 3:30 AM PDT tarafından bir güncelleme paylaşacağız ya da yeni bilgiler mevcut olacak.

11. 16 Ağustos 2026 10:25 UTCresolved

    Frankfurt, DEU'daki Equinix FR5 konumunda bağlantı kurmak için ortaklarımızla çalışmaya devam ediyoruz. Son güncellememizden bu yana, etkilenen bölgeye güvenli erişim sağlamak için önemli bir ilerleme kaydettik. Elektrik izolasyon prosedürü şimdi, etkilenen altyapının de enerjilendirilmesini yürüten elektrik odasındaki ekiplerimiz ile devam ediyor. Bir kez izolasyon doğrulandı ve güvenli onaylandıktan sonra, mühendisler gerekli değiştirme kapsamını belirlemek için etkilenen ağ ekipmanının fiziksel bir incelemesine başlayacaktır. Mevcut değerlendirmemize dayanarak, tam kurtarma, ekipmana yapılan potansiyel etki kapsamı nedeniyle yakın vadede beklenmiyor. AWS Direct Connect bağlantıları bu yerde bozulmamaktadır. Sadece bu yerde bağlantıları olan müşteriler paket kaybı deneyimlemeye devam edecektir. Diğer Doğrudan Connect lokasyonlarında çoklu yer veya reddant konfigürasyonları olan müşteriler etkilenmez. Bir iş için, VPN'ye devretme seçeneğine sahip olan müşterilerin bunu yapması önerilir. Doğrudan Connect ağ geçidi ve Transit Gateway kullanan müşteriler için, bir AWS Site-Site VPN oluşturmanızı ve bunu Transit Gateway'inize bağlamanızı tavsiye ederiz, <a href="https://aws.amazon.com/premiumsupport/bilgi-merkez/dx-configure-dx-and-vpn-failover-tgw/">here</a>. Diğer müşteriler için geçici bir yedekleme yolu olarak bir AWS Site-to-Site VPN kurmayı tavsiye ederiz, <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html"> İlerlemeyi yakından takip etmeye devam ediyoruz ve 16 9:30 AM PDT tarafından bir güncelleme paylaşacağız ya da yeni bilgiler mevcut olacak.

12. 16 Ağustos 2026 16:30 UTCresolved

    Frankfurt'ta Equinix FR5'teki elektrik izolasyonu artık tamamlandı ve mühendislerimiz fiziksel olarak etkilenen ağ ekipmanlarını incelemeye başladı. Henüz tam bir çözüm için zamanımız yok, ancak ekipmana etkisini değerlendirmeye devam ediyoruz. Bu yerde doğrudan Connect bağlantıları bozulmamaktadır. Sadece bu yerde bağlantıları olan müşteriler paket kaybı deneyimlemeye devam edecektir. Diğer Doğrudan Connect lokasyonlarında çoklu yer veya reddant konfigürasyonları olan müşteriler etkilenmez. Etkilenen müşterilerin bir sonraki adımlar ve bir kurtarma süresi hakkında daha net olana kadar VPN'e gitmeyi öneriyoruz. Doğrudan Connect ağ geçidi ve Transit Gateway kullanan müşteriler için, bir AWS Site-Site VPN oluşturabilir ve Transit Gateway'inize bağlanabilirsiniz, <a href="https://aws.amazon.com/premiumsupport/bilgi-merkez/dx-configure-dx-and-vpn-failover-tgw/">here</a>. Diğer müşteriler için, geçici bir yedekleme yolu olarak bir AWS Site-to-Site VPN kurmayı tavsiye ederiz, <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html"></a>. 16 5:30 PM PDT tarafından başka bir güncelleme yapacağız ya da yeni bilgiler mevcut olacak.

13. 16 Ağustos 2026 22:51 UTCresolved

    Frankfurt, DEU'daki Equinix FR5 konumundaki etkilenen ağ ekipman değerlendirmemizi tamamladık ve şimdi etki kapsamı hakkında net bir anlayışa sahibiz. Bağlantıyı geri yüklemeye doğru ilerliyoruz ve yeniden aracılık için bir aşama yaklaşımı alacağız. Sadece bu yerde bağlantıları olan müşteriler, remediasyon tamamlanmaya kadar paket kaybı deneyimlemeye devam edecektir. Diğer Doğrudan Connect lokasyonlarında çoklu yer veya reddant konfigürasyonları olan müşteriler etkilenmez. 16 10:30 PM PDT tarafından başka bir güncelleme yapacağız ya da yeni bilgiler mevcut olacak.

14. 17 Ağustos 2026 05:38 UTCresolved

    Frankfurt, DEU'daki Equinix FR5 konumundaki fazımızı iyileştirmeye devam ediyoruz. Son güncellememizden beri, bazı bağımlı ağ altyapısı restore edilmiştir. Kalan altyapının düzeltilmesi devam ediyor, yedek donanımın teslimatına bağlı bir kurtarma parçası ile. Soğutma tamamen restore edilmiştir, normal işletim eşleri içinde çevresel koşullar istikrarlı. Sadece bu yerde bağlantıları olan müşteriler, remediasyon ilerlemeleri olarak paket kaybı deneyimlemeye devam edecektir. Diğer Doğrudan Connect lokasyonlarında çoklu yer veya reddant konfigürasyonları olan müşteriler etkilenmez. Daha önce iletişim kurma rehberliği ve önerileri bu anda değişmeden kalır. 17 4:30 AM PDT tarafından başka bir güncelleme sağlayacağız ya da daha önce remediasyon ilerledikçe.

15. 17 Ağustos 2026 11:22 UTCresolved

    Frankfurt, DEU'daki Equinix FR5 konumundaki fazımızı iyileştirmeye devam ediyoruz. Ağ altyapısı ve bağımlı sistemler, etkilenen donanımı online olarak geri getirdiğimiz gibi gelişmeye devam ediyor. Bazı yedek donanım teslim edildi ve kurulum, bileşenlerin bulunduğu gibi devam ediyor. Paralel olarak, restore edilmiş cihazların online olarak müşterilere hizmet etmesine izin vermek için ağ trafiğini değiştiriyoruz. Kurtarma yoluyla ilerlerken, müşteriler iki aşamada gerçekleşen restorasyonu gözlemleyeceğiz. İlk aşamada, BGP seansları yeniden kurulacaktır, ancak IP ekleri henüz reklamlanmayacak, bu iyileşmenin hala ilerlemede olduğunu ve temel altyapının henüz trafik taşımaya hazır olmadığını gösteriyor. İkinci aşamada, IP prefix reklam özgeçmişi başlayacak, hangi noktada altyapı tamamen remedi ve bağlantı restore edilmiştir. Şu anda tam iyileşme için bir ETA'mız olmasa da, müşteriler için etkisini azaltmak için hızlı ve güvenli bir şekilde çalışmaya devam ediyoruz. 17 10:30 AM PDT tarafından başka bir güncelleme sağlayacağız, ya da daha önce remediasyon ilerledikçe.

16. 17 Ağustos 2026 16:25 UTCresolved

    Frankfurt, DEU'daki Equinix FR5 konumunda kademeli olarak artarak çalışmaya devam ediyoruz. Sorunu tamamen geri almaya devam ederken erken iyileşme belirtileri görüyoruz. Kalan etkilenen donanımı online olarak geri getirmek için aktif olarak çalışıyoruz ve 12:30 PM PDT veya remediasyon ilerlemeleri olarak başka bir güncelleme sağlayacağız.

17. 17 Ağustos 2026 17:59 UTCresolved

    Frankfurt, DEU'daki Equinix FR5 konumunda geniş bir kurtarma belirtisi görüyoruz. Etkilenen donanımın çoğunluğu için bağlantı restore ettik ve bağlantıların çoğu tamamen kurtarılıyor ve istikrarlı. Kalan cihazlar tamamen restore olana kadar etkilenecek küçük sayıda müşteri var. 2:00 PM PDT ile başka bir güncelleme sağlayacağız ya da daha önce remediasyon ilerledikçe.

18. 17 Ağustos 2026 21:00 UTCresolved

    Etkilenen donanımları online olarak geri getirmeye devam ediyoruz. Son güncellememizden bu yana müşteriler için görünür olmayan ilerlemeler yaptık, ancak kurtarma için gereklidir. Tüm cihazları mümkün olduğunca güvenli bir şekilde getirmek için paralel çalışıyoruz. Bu çalışma, tamamlamak ve doğrulamak için birkaç saat almak bekleniyor. İş aralıkları gerektiren müşteriler için, VPN'ye başarısız olduğunuzu düşünmenizi tavsiye ederiz. Doğrudan Connect ağ geçidi ve Transit Gateway kullanan müşteriler için, bir AWS Site-Site VPN oluşturabilir ve Transit Gateway'inize bağlanabilirsiniz, <a href="https://aws.amazon.com/premiumsupport/bilgi-merkez/dx-configure-dx-and-vpn-failover-tgw/">here</a>. Diğer müşteriler için, geçici bir yedekleme yolu olarak bir AWS Site-to-Site VPN kurmayı tavsiye ederiz, <a href="https://docs.aws.amazon.com/vpn/latest/s2svpn/SetUpVPNConnections.html"></a>. 7:00 PM PDT veya yeni bilgiler mevcut olduğu kadar başka bir güncelleme sağlayacaktır.

19. 18 Ağustos 2026 01:50 UTCresolved

    Bu aşamada müşteri bağlantılarının çoğu için önemli bir kurtarma görüyoruz. Henüz tam olarak kurtarılmamış olsak da, restorasyon çabaları Frankfurt'ta Equinix FR5 konumunda beklendiği gibi ilerliyor. Kalan altyapının yeniden düzenlenmesi, donanım yedeklerinin ve trafik doğrulamalarının tamamlanmasını içerir, her ikisi de aktif olarak altındadır. Kalan altyapının hizmete geri getirdiği gibi daha fazla müşteri odaklı kurtarma bekliyoruz. Sadece bu yerde bağlantıları olan müşteriler, remediasyon tamamlanmaya kadar paket kaybı deneyimlemeye devam edecektir. Daha önce iletişim kurma rehberliği ve önerileri bu anda değişmeden kalır. 17 11:00 PM PDT veya daha önce başka bir güncelleme sağlayacağız.

20. 18 Ağustos 2026 04:01 UTCresolved

    14 7:33 PM PDT'den başlayarak, Frankfurt, DEU'daki Equinix FR5 konumundaki müşteriler için AWS Direct Connect bağlantısını etkileyen paket kaybı yaşadık. Mühendisler 14 Ağustos'ta 7:45 PM'de otomatik olarak meşguldü ve hemen masyonları araştırmaya başladılar. 8:30 PM'a göre, FR5 konumundaki ağ ekipmanlarının, kon-lokasyon tesisine giremediği tespit edildi. Sonuç olarak, soğutma sistemi cihazları aşırı ısıtma ve kapatma ile sonuçlandı. Su ayrıca ağ cihazları için gücü devre dışı bırakan güç dağıtım sistemlerini de etkiledi. İlk kurtarma çabaları, mühendislerin etkilenmeden önce gerekli stabilizasyon içinde çevresel koşullar olarak gecikmiştir. 15 Ağustos ve 16 Ağustos boyunca, mühendislerimiz, alt altyapı konusu ele alındıktan sonra engelli ağ cihazlarını geri yüklemek için tesis operatörüyle işbirliği içinde çalıştı. 17 Ağustos'ta 7:26 PM'ye göre, tüm engelli ağ ekipmanları başarıyla restore edildi ve yere bağlantı tamamen devam eden kurtarma ile doğrulandı. Bu sorunu tekrar almayı beklemiyoruz. Diğer Doğrudan Connect lokasyonlarında kırmızı bağlantıları olan müşteriler bu olay boyunca alternatif yollarıyla bağlantı kurdu ve daha fazla eylem gerektirmez. VPN'yi bir iş olarak kullanan müşteriler artık birincil Doğrudan Connect yollarına güvenle geri dönebilirler. Connectivity stabil ve tamamen operasyonel olarak doğrulandı. Daha fazla yardım gerektiren müşteriler AWS Management Console veya <a href="https://console.aws.amazon.com/support">AWS Destek Merkezi</a> ile iletişime geçebilirler.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 31 Temmuz 2026 17:33 UTCresolved

   Yüksek ağ paketi kaybını onaylayabiliriz, AWS Direct Connect bağlantısını AP-SOUTH-1 Bölgesi'nde etkileyebiliriz. Mühendislik ekibimiz sorunu araştırmaya başlamak için otomatik olarak 9:54 AM'de meşguldü. Bu anda mevcut olan bir iş var. 11:30 AM PDT tarafından başka bir güncelleme sağlayacağız.

2. 31 Temmuz 2026 18:27 UTCresolved

   Kök nedeninin cihazlara yol atamaktan sorumlu bir yapılandırma sistemi ile ilgili olduğunu tespit ettik. Çalışmayı AP-SOUTH-1 Bölgesi'ndeki AWS Direct Connect'i etkileyen paket kaybını azaltmaya başladık ve önümüzdeki 30 dakika içinde yavaş yavaş bir şekilde kurtarmayı bekliyoruz. Bu çabalara güven kazandığımız gibi, hız kurtarma çabalarımızı paralelleştirmeye çalışacağız. 12:00 PM PDT tarafından başka bir güncelleme sağlayacağız.

3. 31 Temmuz 2026 18:54 UTCresolved

   9:42 AM ve 11:44 AM PDT arasında, AP-SOUTH-1 Bölgesi'ndeki AWS Direct Connect bağlantısını etkileyen yüksek ağ paket kaybı yaşadık. Mühendislik ekibimiz, araştırmaya başlamak için 9:46 AM'de otomatik olarak meşguldü. 10:51 AM'ye göre, kök neden cihazlara yol atamaktan sorumlu bir sisteme yapılan bir yapılandırma değişikliği olduğunu anladık. Ayrılma adımlarımıza güven kazandığımızda, paket kaybını daha da azaltmak için çabalarımızı paralelleştirdik. Sorun çözüldü ve hizmet normalde çalışıyor.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 24 Temmuz 2026 11:40 UTCresolved

   ABD-WEST-2 Bölgesinde birden fazla AWS hizmeti etkileyen karşılıklılık sorunlarını araştırıyoruz.

2. 24 Temmuz 2026 11:56 UTCresolved

   İlk kurtarma işaretlerini görüyoruz ve tam iyileşmeye devam ediyoruz.

3. 24 Temmuz 2026 12:30 UTCresolved

   ABD-WEST-2 Bölgesindeki çoklu AWS hizmetlerini etkileyen bağlantı sorunları için masyon çabalarımızın bir sonucu olarak kurtarmanın önemli işaretlerini görmeye devam ediyoruz. Kök nedeni, bölgeden Seattle Metro'ya giden ağ yönlendirmesinden sorumlu bir ağ cihazı ile tespit ettik. Mühendisler tüm mitigation işini bitirdiler. Yollar restore edilmeye devam ettikçe, müşteriler etkilenen hizmetlere bağlandığında hata oranları ve zaman aralıklarında sürekli bir azalma görmelidirler. Kurtarmayı yakından takip ediyoruz ve tüm rotalar tamamen restore edilmiş ve hizmet ölçümleri ön aşamalara geri döndükçe çalışmaya devam edeceğiz. Önümüzdeki 30-45 dakika içinde başka bir güncelleme sağlayacağız.

4. 24 Temmuz 2026 13:01 UTCresolved

   3:55 AM ve 4:15 AM PDT arasında, ABD-WEST-2 bölgesine olan bağlantı sorunları yaşadık. Bu, bölgedeki birçok AWS hizmeti etkiledi. Bazı müşteriler de AWS Management Console'a erişim konusunda deneyimli sorunlar olabilir, bağlantı zaman aralıkları ve sorumlu sayfalarla. Bölgedeki bağımlılık etkilenmedi. Mühendislerimiz otomatik olarak 4:01 AM PDT'de meşguldü ve hemen bu konuyu araştırmaya başladı. Kökü tespit ettikten sonra bölgeden Seattle Metro'ya ağ yönlendirmesinden sorumlu ağ cihazlarıyla ilgili bir sorun olarak tespit ettik ve etkiyi azaltmak için birden çok yol üzerinde çalışmaya başladık. 4:15 AM PDT'de ilk kurtarmaya yol açan önlemler aldık. Ağ işlem eylemlerimizi takip etmeye devam ettikçe, 4:47 AM ve 4:59 AM PDT arasında kısa bir yeniden hayal kırıklığı olayı meydana geldi. Bu rekonvergence döneminde, bazı müşteriler bölge ile ağ rotaları yeniden kurulmuştu. 4:59 AM PDT'ye göre, tüm rotalar tamamen restore edilmiş ve hizmet ölçümleri ön aşamalara geri döndü. AWS Direct Connect'i EqSe2, Westin Building Exchange aracılığıyla kullanan müşteriler, Seattle 3:55 AM'den 5:12 AM PDT'ye genişletilmiş bir etki penceresi yaşadı. Bu müşteriler bu özel yol için ağ rotalarına kadar deneyimli bağlantı sorunları 5:12 AM PDT'de tamamen restore edilmiştir. Müşteriler diğer AWS Direct Connect lokasyonları ile bağlantılı olarak bu olay tarafından etkilenmedi. Sorun çözüldü ve tüm AWS hizmetleri normalde çalışıyor.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 17 Temmuz 2026 08:33 UTCresolved

   Tahmin edilen fatura verileri yansıtan Cost Explorer ile ilgili sorunları araştırıyoruz.

2. 17 Temmuz 2026 09:07 UTCresolved

   Temmuz 16 7:38 PM PDT'den başlayarak, Billing ve Cost Management Console'da yanlış tahmin edilen verileri göstermeye başladık. Mühendislik takımlarımız kök nedenini araştırıyor ve araştırıyor. 3:00 AM PDT veya daha fazla bilgi mevcut olursa başka bir güncelleme sağlayacaktır.

3. 17 Temmuz 2026 10:03 UTCresolved

   Billing ve Cost Management Console'da gösterilen tahmini maliyet ve kullanım verilerini etkileyen sorunu çözmeye devam ediyoruz. Kök nedeni tahmin edilen faturalandırma alt sistemi içinde bir birim fiyatlandırması ile tespit ettik ve bir mitigation üzerinde çalışıyoruz. Gösterilen fatura tahminleri gerçek kullanım ve suçlamaları yansıtmaz. Bu zamanda gerekli olan müşteri eylemleri yoktur. Sorun azaltıldıktan sonra, tahmini faturalama verileri ile birlikte çalışmamız için tam bir karar bekliyoruz. 4:00 AM PDT veya daha fazla bilgi mevcut olursa başka bir güncelleme sağlayacaktır.

4. 17 Temmuz 2026 10:52 UTCresolved

   Billing ve Cost Management Console'da gösterilen tahmini maliyet ve kullanım verilerini etkileyen sorunu çözmeye devam ediyoruz. Daha önce paylaşılan gibi, tahmini faturalama alt sistemi içinde birim fiyatlandırma ile ilgili bir sorun olarak kök nedenini tespit ettik. Daha ayrıntılı fatura tahminlerinin görüntülenmesini önlemek için, tahmin edilen fatura hesaplamalarını durdurduk. Şu anda normal fatura tahminlerini gören müşteriler bu tahminleri görmeye devam edecek ve şişmiş tahminleri gören müşteriler, karara doğru çalışırken onları daha da artırmayacaktır. Gösterilen fatura tahminleri gerçek kullanım ve suçlamaları yansıtmaz. Sorunu tamamen azaltmaya devam ediyoruz. Sorun azaltıldıktan sonra, tahmini faturalama verileri ile birlikte çalışmamız için tam bir karar bekliyoruz. Bu zamanda gerekli olan müşteri eylemleri yoktur. 5:00 AM PDT veya daha fazla bilgi mevcut olursa başka bir güncelleme sağlayacaktır.

5. 17 Temmuz 2026 11:58 UTCresolved

   Billing ve Cost Management Console'da gösterilen tahmini maliyet ve kullanım verilerini etkileyen sorunu çözmeye devam ediyoruz. Paralel olarak birden fazla masyon yolunda çalışıyoruz. İlk yol, en son bilinen iyi tahmin edilen fatura hesaplamasına yeniden yol açıyor. Bu yaklaşımla, müşteriler sadece 15 Temmuz'da maliyet ve kullanım verilerini görecek, ancak şişmiş maliyet verileri kaldırılacaktır. İkinci yol, faturalama altsystem'ye son bir değişikliği geri getiriyor. Gösterilen fatura tahminleri gerçek kullanım ve suçlamaları yansıtmaz. Bu zamanda gerekli olan müşteri eylemleri yoktur. Sorun azaltıldıktan sonra, tahmini faturalama verileri ile birlikte çalışmamız için tam bir karar bekliyoruz. 6:00 AM PDT veya daha fazla bilgi mevcut olursa başka bir güncelleme sağlayacaktır.

6. 17 Temmuz 2026 12:54 UTCresolved

   Maliyet ve Kullanım Raporu da dahil olmak üzere Billing ve Cost Management Console'da gösterilen tahmini maliyet ve kullanım verileri etkileyen sorunu çözmek için paralel olarak birden fazla mitigation yolda çalışmaya devam ediyoruz. Tahmin edilen fatura hesaplamalarını değerlendiriyoruz, çünkü iç izlememiz faturalama alt sistemi artık doğru tahminler üretiyor. Bu yolla devam etmeden önce ek doğrulama yapıyoruz. Gösterilen fatura tahminleri gerçek kullanım ve suçlamaları yansıtmaz. Bu zamanda gerekli olan müşteri eylemleri yoktur. 8:00 AM PDT veya daha fazla bilgi mevcut olursa başka bir güncelleme sağlayacaktır.

7. 17 Temmuz 2026 14:53 UTCresolved

   Maliyet ve Kullanım Raporu da dahil olmak üzere Billing ve Cost Management Console'da gösterilen tahmini maliyet ve kullanım verileri etkileyen sorunu çözmeye devam ediyoruz. Son bir değişimin geri dönüşü sorunu çözmedi ve birçok mitigation yollarını araştırmaya devam ediyoruz. Tahmin edilen fatura güncelleştirmeleri duraklanır. Son doğru tahmin edilen fatura verilere yeniden dönme sürecindeyiz. Gösterilen fatura tahminleri gerçek kullanım ve suçlamaları yansıtmaz. Bu zamanda gerekli olan müşteri eylemleri yoktur. Bu mitigation'in tahmin edilen fatura verileri yeniden finanse ederek çalışmak için birkaç saat almasını bekliyoruz. 10:00 AM PDT veya daha fazla bilgi mevcut olursa başka bir güncelleme sağlayacaktır.

8. 17 Temmuz 2026 16:59 UTCresolved

   Temel nedeni tespit ettik ve temel sorunu yanlış tahmin edilen maliyet ve kullanım verileri Billing ve Cost Management Console'da gösteriliyor ve Cost and Use Reports. Tüm müşteriler için doğru maliyet verileri düzeltmek için verileri doldurmaya başladık. Önümüzdeki üç saat içinde kurtarmayı ve tüm müşteriler için 18 12:00 PM PDT tarafından tam kurtarmayı bekliyoruz. Geri dolum tamamlanmaya kadar, bazı müşteriler hala yanlış maliyet ve kullanım verileri görebilir. Gösterilen fatura tahminleri gerçek kullanım ve suçlamaları yansıtmaz. Bu zamanda gerekli olan müşteri eylemleri yoktur. 1:00 PM tarafından başka bir güncelleme sağlayacağız veya bilgi mevcut olursa er.

9. 17 Temmuz 2026 19:56 UTCresolved

   Tahmin edilen maliyet ve kullanım verilerini geri yükleme çabalarımız hala devam ediyor. Tahmin edilenden daha yavaş ilerliyoruz. Bazı hesapları doğru maliyet ve kullanım verileri ile kurtardığımızda, etkilenen tüm hesapların 19 12:00 AM PDT tarafından kurtarılmasını bekliyoruz. Geri dolum tamamlanmaya kadar, bazı müşteriler hala yanlış maliyet ve kullanım verileri görebilir. Gösterilen fatura tahminleri gerçek kullanım ve suçlamaları yansıtmaz. Bu zamanda gerekli olan müşteri eylemleri yoktur. 7:00 PM tarafından başka bir güncelleme sağlayacağız ya da bilgi mevcut olursa er.

10. 18 Temmuz 2026 01:38 UTCresolved

    Billing ve Cost Management Console'da görüntülenen tahmini maliyet ve kullanım verilerini çözmeye yönelik sürekli ilerleme kaydetmeye devam ediyoruz. Tamamlanan verileri geri yükleme çabalarımız devam ediyor ve tüm etkilenen hesapların Temmuz 19, 12:00 AM PDT tarafından tamamen kurtarılmasını bekliyoruz. Geri dolum tamamlanmaya kadar, bazı müşteriler Billing ve Cost Management Console ve Maliyet ve Kullanım Raporlarında yanlış maliyet ve kullanım verileri gözlemleyebilir. Bu tahminler gerçek kullanımı veya suçlamaları yansıtmaz. Maliyetlerini ve Kullanım Raporu'nu "Overwrite" seçeneği ile yapılandıran müşteriler hiçbir eylem gerektirmez - rapor otomatik olarak geri dolum tamamlandıktan sonra düzeltilmiş verilerle güncellenecektir. Maliyetlerini ve Kullanım Raporunu "Yeni rapor versiyonlarını" ile yapılandıran müşteriler, S3 kovasında önceki tüm rapor teslimatlarını korur. Etkilenen pencere sırasında verilen rapor versiyonu, yanlış veri içerebilir. Verileri geri yükleme tamamlandığında, düzeltilmiş bir rapor versiyonu yeni bir assemblyId altında teslim edilecektir. Bu yapılandırmayı kullanan müşteriler, etkilenen fatura dönemi için en son montaj süresini referans etmek için herhangi bir kesinti işlemi güncellemeli ve işlem süresini silmek veya arşivleyebilirler. En son raporu tanımlamak için, müşteriler <a href="https://docs.aws.amazon.com/cur/latest/userguide/view-latest-cur.html">documentation</a> 18 Temmuz 1:00 AM PDT tarafından başka bir güncelleme sağlayacağız veya ek bilgi mevcut olursa er.

11. 18 Temmuz 2026 08:05 UTCresolved

    Billing ve Cost Management Console'da görüntülenen tahmini maliyet ve kullanım verilerini çözmeye yönelik önemli ilerleme kaydetmeye devam ediyoruz. Dava çabalarımız beklendiği gibi çalışıyor ve doğru maliyet ve kullanım verileri yansıtan artan sayıda hesabı görüyoruz. Tüm etkilenen hesapların Temmuz 19, 12:00 AM PDT tarafından tamamen kurtarılmasını bekliyoruz. Geri dolum tamamlanmaya kadar, bazı müşteriler Billing ve Cost Management Console ve Maliyet ve Kullanım Raporlarında yanlış maliyet ve kullanım verileri gözlemleyebilir. Bu tahminler gerçek kullanımı veya suçlamaları yansıtmaz. 18 Temmuz 7:00 AM PDT ile başka bir güncelleme yapacağız ya da ek bilgi mevcut olursa er.

12. 18 Temmuz 2026 13:57 UTCresolved

    16 Temmuz arasında 7:38 PM PDT ve 6:00 AM PDT'de 18 Temmuz arasında, Maliyet ve Kullanım Raporu da dahil olmak üzere Billing ve Cost Management Console'da yanlış tahmin edilen faturalama verilerini göstermeye başladık. Müşteriler hatalı bütçe alabilir ve aomaly algılama uyarılarına mal olabilir ve tahmini maliyet ve kullanım verileri gözlemler. 16 Temmuz'da 7:46 PM PDT'de, alarmlarımız maliyet anomalileri tespit etti, ancak tahmini fatura nesil sürecini durdurma veya mühendislik takımlarımızı uyarmadı. Bu konuyu 17 Temmuz'da 12:19 AM PDT'de müşteri yürüyenleri tarafından uyarıldık ve hemen araştırmaya başladı. İlk önce 17 Temmuz'da AWS Health aracılığıyla müşterileri bilgilendirdik. 8:24 AM PDT, tahmini faturalama verileri için daha fazla güncellemeyi kestik ve bütçeden çıktık ve ihtiyatlı bir önlem olarak anomaly uyarılara mal oldu. 17 Temmuz'da 12 Temmuz'da 12 PM PDT'de fatura hesaplama sistemimizde bir yapılandırma değişikliği olarak tespit ettik. Bu sistem, line item suçlamaları hesaplamak için birim dönüştürme verilerine dayanmaktadır. Yapı değişikliği, birim dönüştürme verilerinin başarısız olmasına neden oldu, bu da Billing ve Maliyet Yönetimi konsoluna yol açan ve bütçeyi tetikledi ve anomali uyarılarına mal oldu. Sorunu 17 Temmuz'da 12:30 PM PDT'de azalttık ve tüm müşteri hesapları için maliyet ve kullanım verileri yeniden işlemeye başladık. Kurtarmayı 4:19 PM PDT'de gözlemlemeye başladık ve hesapların çoğunluğu 18 Temmuz'da 6:00 AM PDT'de tamamen geri alındı. Küçük sayıda hesap hala işlemektedir ve Kişisel Sağlık Dashboard'daki bu hesaplar için güncelleştirmeler yayınlayacağız. Alarmlarımızı hemen işlemeyi durdurmalı ve anomaliler meydana geldiğinde mühendislik takımlarımızı bilgilendirdik. Bu olayın müşterilerimize yol açtığı alarm için özür dileriz ve bunun gibi olayları iptal etmek için kapsamlı bir retrospektif yürütüyoruz, aynı zamanda fatura olayları gerçekleştiğinde yanıtımızı geliştiriyoruz. Sorun çözüldü ve tüm AWS hizmetleri artık normal olarak çalışıyor.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 16 Temmuz 2026 08:44 UTCresolved

   VPC Origins bağlantısını kullanan Cloudfront müşterileri için 5xx hatası araştırıyoruz.

2. 16 Temmuz 2026 09:21 UTCresolved

   12:45 AM PDT'de başlayan, VPC Origins bağlantısını kullanan CloudFront müşterileri için 5xx hata yaşıyoruz. Diğer kaynaklı türleri kullanan müşterilerin bu konu tarafından etkilenmediğini doğruladık. Mühendislerimiz meşgul ve etkiyi azaltmak için aktif olarak çalışmaktadır. Bir iş olarak, VPC Origins gerektirmez müşteriler hataları çözmek için birincil türünü değiştirebilir. 3:15 AM PDT ile başka bir güncelleme sağlayacağız veya daha fazla bilgi mevcutsa erleyeceğiz.

3. 16 Temmuz 2026 10:18 UTCresolved

   BulutFront müşterileri için VPC Origins bağlantısını kullanarak artan 5xx hatalarını çözmeye devam ediyoruz. Diğer kökeni türlerini kullanan müşteriler bu konu tarafından etkilenmez. Araştırmamıza dayanarak, kök nedeninin BulutFront'un kenar konumlarından müşteri VPC'ler içinde kaynaklara yönelik taleplerden sorumlu bir paket işleme alt sistemi ile ilişkili olduğuna inanıyoruz. Bu kadar geçici olarak onların kökeni tipini hataları çözmek için yapabilecek müşterileri tavsiye etmeye devam ediyoruz. 4:15 AM PDT tarafından başka bir güncelleme sağlayacağız veya ek bilgi mevcutsa erteleyeceğiz.

4. 16 Temmuz 2026 11:16 UTCresolved

   BulutFront müşterileri için VPC Origins bağlantısını kullanarak artan 5xx hatalarını çözmeye devam ediyoruz. Diğer kökeni türlerini kullanan müşteriler bu konu tarafından etkilenmez. BulutFront'un kenar yerlerinden müşteri VPC'ler içindeki kaynaklara yönelik taleplerden sorumlu paket işleme alt sistemi içinde masa kapasitesinin tükenmesini daha da kapsamıyoruz. Tanımlandık ve şu anda sorunu çözmek için bir mitigation stratejisi test ediyoruz. Test tamamlandıktan sonra, bir aşamadaki yaklaşımda mitigation dağıtacağız. Bu testlerden elde edilen sonuçlara dayanarak, bir sonraki güncellememizde karar için daha net bir zaman sağlayacağız. Bu kadar geçici olarak onların kökeni tipini hataları çözmek için yapabilecek müşterileri tavsiye etmeye devam ediyoruz. 5:15 AM PDT ile başka bir güncelleme sağlayacağız veya ek bilgi mevcut olursa er.

5. 16 Temmuz 2026 11:27 UTCresolved

   İlk kurtarma işaretlerini görüyoruz ve tam iyileşmeye devam ediyoruz.

6. 16 Temmuz 2026 11:57 UTCresolved

   Önümüzdeki 45 dakika içinde beklenen tam kurtarma sonucunda kurtarmanın önemli belirtileri görmeye devam ediyoruz.

7. 16 Temmuz 2026 12:21 UTCresolved

   12:45 AM ve 4:18 AM PDT arasında, VPC Origins bağlantısını kullanan BulutFront müşterileri için 5xx hata yaşadık. Mühendislerimiz otomatik olarak meşguldü ve hemen kök nedenini araştırmaya başladı. 2:57 AM PDT'ye göre, sorunu özel VPC kökenlerine giden filoda içsel bir kısıtlama olarak tanımladık. Bu kısıtlamaya ulaşıldığında, ağ işlemcilerimiz için routing konfigürasyonunun dağıtılmasından sorumlu sistem, VPC Origin bağlantılarının kullanımını doğru bir şekilde yüklemedi. 3:52 AM PDT'de, 4:18 AM PDT'de tam iyileşmeye yol açan birden fazla işlem eylemi aldık. Şimdi konu azaltıldı, geçici olarak kökeni tiplerini değiştiren müşteriler bu değişiklikleri güvenli bir şekilde revize edebilir. Diğer kaynaklı türleri kullanan müşteriler bu konu tarafından etkilenmedi. Sorun çözüldü ve hizmet normalde çalışıyor.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 15 Temmuz 2026 23:11 UTCresolved

   AB-CENTRAL-1 Bölgesinde tek bir Avalability alanı (euc1-az2) ile yüksek bağlantı sorunlarını araştırıyoruz.

2. 15 Temmuz 2026 23:36 UTCresolved

   Erken iyileşme belirtileri görüyoruz ve tam karara doğru çalışmaya devam ediyoruz. Güncellemeler sunmaya devam edeceğiz.

3. 16 Temmuz 2026 01:24 UTCresolved

   2:56 PM ve 6:07 PM PDT arasında, AB-CENTRAL-1 Bölgesi'nde tek bir erişilebilirlik Bölgesi'ndeki EC2 örneklerinin alt kümesine bağlantı sorunları yaşadık. Bu süre zarfında müşteriler, etkilenen EC2 örneklerini kullanan bazı AWS API'leri ile etkilenen bölgede yeni örnek fırlatmalar için hata oranları ve latencieslarını da deneyimlediler. Bazı AWS Hizmetleri ayrıca etkilenen bölgede bağlantı sorunları yaşadı ve hata oranları arttı. Mühendisler otomatik olarak meşguldü ve hemen araştırmaya başladı. Kurtarma çabamızın bir parçası olarak, 3:04 PM'deki etkilenen hizmetler için etkilenen Erişilebilirlik Bölgesi'nden trafiği değiştirdik. 3:05 PM'de, etkisine neden olan son bir ağ değişikliği olduğunu tespit ettik. Mühendisler, 4:28 PM'de tamamlanan bu değişikliği hemen yeniden düzenlemeye başladılar. Bu, etkilenen bölgeye 4:30 PM ağ bağlantılarının restorasyonuna yol açtı. 6:07 PM'deki etkilerini tamamen geri aldığımıza kadar çalışmaya devam ettik. Bu sorunu yeniden aşılamayı beklemiyoruz. Sorun çözüldü ve hizmet normalde çalışıyor.

Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

1. 6 Temmuz 2026 12:45 UTCresolved

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

2. 6 Temmuz 2026 13:34 UTCresolved

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

3. 6 Temmuz 2026 14:12 UTCresolved

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

4. 6 Temmuz 2026 14:53 UTCresolved

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

1. 30 Haziran 2026 21:02 UTCresolved

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

2. 30 Haziran 2026 21:21 UTCresolved

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

3. 30 Haziran 2026 21:29 UTCresolved

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

4. 30 Haziran 2026 21:53 UTCresolved

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

1. 13 Haziran 2026 01:26 UTCresolved

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

2. 15 Haziran 2026 18:13 UTCresolved

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

1. 6 Haziran 2026 04:24 UTCresolved

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

1. 22 Mayıs 2026 23:38 UTCresolved

   We are investigating increased error rates for Route53 API calls.

2. 23 Mayıs 2026 00:13 UTCresolved

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

1. 8 Mayıs 2026 00:25 UTCresolved

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

2. 8 Mayıs 2026 00:53 UTCresolved

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

3. 8 Mayıs 2026 01:47 UTCresolved

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

4. 8 Mayıs 2026 03:06 UTCresolved

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

5. 8 Mayıs 2026 05:11 UTCresolved

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

6. 8 Mayıs 2026 06:38 UTCresolved

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

7. 8 Mayıs 2026 08:32 UTCresolved

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

8. 8 Mayıs 2026 10:54 UTCresolved

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

9. 8 Mayıs 2026 13:51 UTCresolved

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

10. 8 Mayıs 2026 15:58 UTCresolved

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

11. 8 Mayıs 2026 16:30 UTCresolved

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

12. 8 Mayıs 2026 18:12 UTCresolved

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

13. 8 Mayıs 2026 19:29 UTCresolved

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

14. 8 Mayıs 2026 23:00 UTCresolved

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

15. 9 Mayıs 2026 03:04 UTCresolved

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

1. 27 Nisan 2026 11:27 UTCresolved

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

2. 27 Nisan 2026 12:05 UTCresolved

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

1. 7 Mart 2026 19:53 UTCresolved

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

2. 7 Mart 2026 20:17 UTCresolved

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

3. 7 Mart 2026 20:28 UTCresolved

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

4. 7 Mart 2026 21:04 UTCresolved

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

1. 2 Mart 2026 05:56 UTCresolved

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

2. 2 Mart 2026 07:09 UTCresolved

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

3. 2 Mart 2026 09:03 UTCresolved

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

4. 2 Mart 2026 10:41 UTCresolved

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

5. 2 Mart 2026 14:23 UTCresolved

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

6. 2 Mart 2026 18:52 UTCresolved

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

7. 2 Mart 2026 22:29 UTCresolved

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

8. 3 Mart 2026 00:22 UTCresolved

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

9. 3 Mart 2026 06:27 UTCresolved

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

10. 3 Mart 2026 11:10 UTCresolved

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

11. 3 Mart 2026 14:02 UTCresolved

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

12. 3 Mart 2026 16:40 UTCresolved

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

13. 30 Nisan 2026 07:07 UTCinvestigating

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

1. 1 Mart 2026 12:51 UTCresolved

   We are investigating issues with AWS services in the ME-CENTRAL-1 Region.

2. 1 Mart 2026 13:19 UTCresolved

   We are investigating connectivity and power issues affecting APIs and instances in a single Availability Zone (mec1-az2) in the ME-CENTRAL-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. Targeting new launches using RunInstances in the remaining AZs should succeed. Existing instances in the other AZs are not affected.

3. 1 Mart 2026 14:09 UTCresolved

   We can confirm that a localized power issue has affected a single Availability Zone in the ME-CENTRAL-1 Region (mec1-az2). EC2 Instances, DB Instances, EBS Volumes, and others resources are currently unavailable and will experience connectivity issues at this time. Other AWS Services are also experiencing error rates and latencies for some workflows. We have weighed away traffic for most services at this time. We recommend customers utilize one of the other Availability Zones in the ME-CENTRAL-1 Region at this time, as existing instances in other AZ's remain unaffected by this issue. We are actively working to restore power and connectivity, at which time we will begin to work to recover affected resources. As of this time, we expect recovery is multiple hours away. We will provide an update by 7:15 AM PST, or sooner if we have additional information to share.

4. 1 Mart 2026 15:09 UTCinvestigating

   We wanted to provide some additional information on the isolated power issue. At this time, most AWS Services have weighted away from the affected Availability Zone (mec1-az2) and are seeing recovery for their affected operations and workflows. For EC2 Instances, EBS Volumes, and other resources that are impacted in the affected Zone, we will have a longer tail of recovery. At this time, power has not yet been restored to the affected AZ. For now, we recommend continuing to retry any failed API requests. If immediate recovery is required, we recommend customers restore from EBS Snapshots and/or replace affected resources by launching replacement resources in one of the unaffected zones, or an alternate region. As of this time, recovery is still several hours away. We will provide an update by 8:30 AM PST, or sooner if we have additional information to share.

5. 1 Mart 2026 16:59 UTCinvestigating

   We continue to work toward restoring power in the affected Availability Zone in the ME-CENTRAL-1 Region (mec1-az2). In parallel, we are actively working on improving error rates and latencies that some customers are observing for EC2 Networking and EC2 Describe APIs. Due to increased demand in the unaffected Availability Zones, customers may experience longer than usual provisioning times or may need to retry requests for certain instance types, or pick an alternative instance type. We will provide an update by 10:30 AM PST, or sooner if we have additional information to share.

6. 1 Mart 2026 17:41 UTCinvestigating

   We want to provide some additional information on the power issue in a single Availability Zone in the ME-CENTRAL-1 Region. At around 4:30 AM PST, one of our Availability Zones (mec1-az2) was impacted by objects that struck the data center, creating sparks and fire. The fire department shut off power to the facility and generators as they worked to put out the fire. We are still awaiting permission to turn the power back on, and once we have, we will ensure we restore power and connectivity safely. It will take several hours to restore connectivity to the impacted AZ. The other AZs in the region are functioning normally. Customers who were running their applications redundantly across the AZs are not impacted by this event. EC2 Instance launches will continue to be impaired in the impacted AZ. We recommend that customers continue to retry any failed API requests. If immediate recovery of an affected resource (EC2 Instance, EBS Volume, RDS DB Instance, etc.) is required, we recommend restoring from your most recent backup, by launching replacement resources in one of the unaffected zones, or an alternate AWS Region. We will provide an update by 12:30 PM PST, or sooner if we have additional information to share.

7. 1 Mart 2026 20:14 UTCinvestigating

   We are aware that some customers are experiencing errors when calling EC2 APIs, specifically networking related APIs (AllocateAddress, AssociateAddress, DescribeRouteTable, DescribeNetworkInterfaces). We are actively working on multiple paths to mitigate these issues. For customers experiencing throttling errors on the AllocateAddress APIs, we recommend retrying any failed API requests. We are deploying a configuration change to mitigate the AssociateAddress API errors and expect recovery in the next few hours. DescribeRouteTable and DescribeNetworkInterfaces API calls without specifying zone, Interface or Instance IDs are expected to fail until we restore the impacted zone. We recommend customers to pass these IDs explicitly in these API requests. For customers that can, we recommend considering using alternate AWS Regions. We will provide another update by 3:30 PM PST, or sooner if we have more to share.

8. 1 Mart 2026 22:28 UTCinvestigating

   We are seeing positive signs of recovery for many of the EC2 APIs, such as Describes and AllocateAddress. We recognize that customers are still experiencing errors when attempting to call the AssociateAddress API, and are unable to disassociate addresses from resources that are affected by the underlying power issue. We continue to work on multiple parallel paths to mitigate both of these issues. We recommend continuing to retry requests wherever possible. We expect our current mitigation efforts for these specific issues to complete within the the two to three hours. As we progress with these mitigation efforts, customers will observe higher success rates for these operations. Additionally, we are investigating ways to speed up these specific mitigation efforts, but are ensuring we do so safely. As of this time, power restoration is still several hours away. We will provide another update by 5:30 PM PST, or sooner if we have additional information to share.

9. 2 Mart 2026 00:26 UTCinvestigating

   We are seeing significant signs of recovery for AssociateAddress requests, and continue to work toward fully mitigating this issue. This combined with the earlier recovery of the AllocateAddress API means customers can now successfully create and associate new network addresses in the unaffected AZs. Other AWS Services are also now observing sustained improvement as a result of the EC2 Networking APIs recovery. We are now focusing on implementing a change that will allow customers to Disassociate Elastic IP addresses from resources that are impacted by the underlying power issue. We expect this specific mitigation to take another hour to complete. We do not have an ETA for power restoration at this time. For customers that can, we recommend using alternate Availability Zones or other AWS Regions where applicable. We will provide another update by 6:30 PM, or sooner if we have additional information to share.

10. 2 Mart 2026 02:01 UTCinvestigating

    We confirm the recovery of the AssociateAddress API requests. We have also applied a change that enables customers to disassociate Elastic IP addresses from resources that are impacted by the underlying power issue. With these mitigations, customers can now successfully create and associate new network addresses in the unaffected AZs as well as re-associate Elastic IPs from resources in the affected zone to resources in the unaffected zones. We still do not have an ETA for power restoration at this time. For customers that can, we recommend using alternate Availability Zones or other AWS Regions where applicable. We will provide another update by 10:00 PM, or sooner if we have additional information to share.

11. 2 Mart 2026 05:59 UTCinvestigating

    We are investigating additional connectivity issues and error rates in the ME-CENTRAL-1 Region.

12. 2 Mart 2026 06:46 UTCinvestigating

    We can confirm that a localized power issue has affected another Availability Zone in the ME-CENTRAL-1 Region (mec1-az3). Customers are also experiencing increased EC2 APIs and instance launch errors for the remaining zone (mec1-az1). At this point it is not possible to launch new instances in the region, although existing instances should not be affected in mec1-az1. Other AWS Services, such as DynamoDB and S3 are also experiencing significant error rates and latencies. We are actively working to restore power and connectivity, at which time we will begin to work to recover affected resources. As of this time, we expect recovery is multiple hours away. For customers that can, we recommend failing away to another AWS Region at this time. We will provide an update by 12:00 AM PST, or sooner if we have additional information to share.

13. 2 Mart 2026 08:52 UTCinvestigating

    We continue to work on a localized power issue affecting multiple Availability Zones in the ME-CENTRAL-1 Region (mec1-az2 and mec1-az3). Customers are experiencing increased EC2 API errors and instance launch failures across the region, and it is not currently possible to launch new instances; existing instances in mec1-az1 should not be affected. Amazon DynamoDB and Amazon S3 are also experiencing significant error rates and elevated latencies. We are actively working to restore power and connectivity, after which we will begin recovery of affected resources; full recovery is still expected to be many hours away. We recommend that affected customers failover, and backup any critical data, to another AWS Region. We will provide an update by 2:00 AM PST, or sooner if the situation changes.

14. 2 Mart 2026 10:53 UTCinvestigating

    We wanted to provide more information on Amazon S3 given that there are two impaired Availability Zones (mec1-az2 and mec1-az3) in the ME-CENTRAL-1 Region. Amazon S3 is a regional service and designed to withstand the total loss of a single Availability Zone while maintaining S3's durability and availability. When the mec1-az2 AZ was powered off at approximately 4:00 AM PST on Sunday, March 1, S3 continued to operate normally. As the second AZ became impaired, S3 error rates increased. With two Availability Zones significantly impacted, customers are seeing high failure rates for data ingest and egress. We strongly advise customers to update their applications to ingest S3 data to an alternate AWS Region. As soon as practically possible, we will begin the restoration of our two Availability Zones which will include a careful assessment of data health and any repair of storage if necessary. In addition, we can confirm that the AWS Management Console and command line interface (CLI) are disrupted by the failure of two Availability Zones. We continue to work towards recovery across all services, and we will provide an update by 6:00 AM PST on March 2, or sooner if we have additional information to share.

15. 2 Mart 2026 14:22 UTCinvestigating

    We continue to work towards recovery of the two impaired Availability Zones (mec1-az2 and mec1-az3) in the ME-CENTRAL-1 Region. 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. EC2, Amazon DynamoDB and other AWS Services continue to experience significant error rates and elevated latencies. We recommend customers enact their disaster recovery plans and recover from remote backups into alternate AWS Regions, ideally in Europe. Further, we strongly advise customers to update their applications to ingest S3 data to 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.

16. 2 Mart 2026 17:59 UTCinvestigating

    We continue to work towards recovery of the two impaired Availability Zones (mec1-az2 and mec1-az3) in the ME-CENTRAL-1 Region. The impact is causing elevated errors rates for both the Management Console and CLI. Our current expectation is that recovery will take at least a day to complete. We continue to recommend customers enact their disaster recovery plans and recover from remote backups into alternate AWS Regions. We will continue to provide periodic updates on recovery efforts. Our next update will be by 2:00 PM PST or sooner if new information becomes available.

17. 2 Mart 2026 21:36 UTCinvestigating

    We continue to work towards recovery of the two impaired Availability Zones (mec1-az2 and mec1-az3) in the ME-CENTRAL-1 Region. We have partially restored access to the AWS Management Console, however, some pages will continue to load unsuccessfully until we have recovered core services and power. In parallel to the power and recovery efforts, we are working to restore access to tools and utilities to allow customers to backup and migrate their data. 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 advising customers enact their disaster recovery plans and recover from remote backups into alternate AWS Regions. We will provide you with another update by 6:00 PM PST, or sooner if new information becomes available.

18. 3 Mart 2026 00:19 UTCinvestigating

    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.

19. 3 Mart 2026 05:13 UTCinvestigating

    We continue to work towards recovery of the two impaired Availability Zones (mec1-az2 and mec1-az3) in the ME-CENTRAL-1 Region with a focus on restoring functionality to foundational services. Since our last update we have made incremental progress in recovering the DynamoDB control plane which will not be visible to external customers but are required for the restoration of service. Similarly we have made progress with the S3 control plane. The recovery of these foundational services, when complete, will enable a broad range of dependent AWS services to recover. We still estimate that the recovery time is at least a day before we are able to fully restore power and connectivity. We will provide you with another update by March 3 2:00 AM PST, or sooner if new information becomes available.

20. 3 Mart 2026 09:04 UTCinvestigating

    We are providing an update on the ongoing service disruptions affecting the AWS Middle East (UAE) Region (ME-CENTRAL-1). The overall state of the region remains largely unchanged from our previous update. We continue to work closely with local authorities and are prioritizing the safety of our personnel throughout our recovery efforts. Teams continue to assess the damage to the affected facilities and are working to restore infrastructure impacted by the event. With respect to Amazon S3, we are seeing improvement in PUT and LIST availability. We continue to work on improving GET error rates, but full recovery will be dependent on restoring the affected infrastructure, which our teams continue to work toward. For Amazon DynamoDB, error rates remain elevated and our teams continue to focus on recovery efforts. We have not yet seen meaningful improvement in DynamoDB availability, but expect conditions to improve over the coming hours as recovery work progresses. Amazon EC2 instance launches remain throttled in the ME-CENTRAL-1 Region. We will begin relaxing these throttles as soon as we have fully recovered our foundational services and have sufficient capacity to support new launches safely. The AWS Management Console is now operational, though customers may continue to experience errors on certain pages and operations as the underlying services work through their recovery. We recommend customers continue to retry requests where possible. AWS Lambda, Amazon Kinesis, Amazon CloudWatch, Amazon RDS, and a number of other AWS services that were impacted by this event remain degraded. The availability of these services is dependent on the recovery of our foundational services — primarily Amazon S3 and Amazon DynamoDB — and we expect to see improvement across these services as that recovery progresses. 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 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. We will continue to provide updates as recovery progresses and as the situation evolves. Our next update will be provided by 5:00 AM PST on March 3, or sooner if new information becomes available.

21. 3 Mart 2026 12:58 UTCinvestigating

    We are providing an update on the ongoing service disruptions affecting the AWS Middle East (UAE) Region (ME-CENTRAL-1). The overall state of the region remains largely unchanged, though our teams continue to make progress on recovery efforts across multiple workstreams. For Amazon S3, we are seeing continued improvement in PUT and LIST availability. Newly written objects are now able to be successfully retrieved, and we continue to work on reducing GET error rates for objects written prior to the event. Full recovery of GET operations for pre-existing data remains dependent on restoring the affected infrastructure. For Amazon DynamoDB, error rates remain elevated and our teams continue to focus on recovery; we expect to see improvement over the coming hours. As these foundational services recover, dependent services — including AWS Lambda, Amazon Kinesis, Amazon CloudWatch, and Amazon RDS will follow. Amazon EC2 instance launches remain throttled in the ME-CENTRAL-1 Region and will be relaxed as foundational service recovery and capacity allow. The AWS Management Console is operational, though customers may continue to experience errors on certain pages as underlying services work through their recovery. We recommend that customers continue to retry requests where possible. We 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. We will provide another update by March 3 at 10:00 AM PST, or sooner if new information becomes available.

22. 3 Mart 2026 16:14 UTCinvestigating

    We are providing an update on the ongoing service disruptions affecting the AWS Middle East (UAE) Region (ME-CENTRAL-1). We continue to make progress on recovery efforts across multiple workstreams. For Amazon S3, we are seeing continued improvement in PUT and LIST availability. Newly written objects are now able to be successfully retrieved, and we continue to work on reducing GET error rates for objects written prior to the event. Full recovery of GET operations for pre-existing data remains dependent on restoring the affected infrastructure. For Amazon DynamoDB, error rates remain elevated and our teams continue to focus on recovery; we expect to see improvement over the coming hours. As these foundational services recover, dependent services — including AWS Lambda, Amazon Kinesis, Amazon CloudWatch, and Amazon RDS — will follow. Amazon EC2 instance launches remain throttled in the ME-CENTRAL-1 Region and will be relaxed as foundational service recovery and capacity allow. The AWS Management Console is operational, though customers may continue to experience errors on certain pages as underlying services work through their recovery. 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.

23. 30 Nisan 2026 07:25 UTCinvestigating

    We are providing an update on the ongoing service disruption. The Middle East (UAE) Region (ME-CENTRAL-1) has suffered damage as a result of the conflict in the Middle East and is currently unable to reliably support customer applications. While some workloads continue to function normally, we strongly recommend customers migrate all accessible resources to other Regions and restore inaccessible resources from remote backups as soon as possible. Relevant billing operations are currently suspended while we restore normal operations in this AWS Region. This process is expected to take several months.

1. 25 Şubat 2026 18:14 UTCresolved

   We are experiencing intermittent missing or delayed EC2 instance and status check metrics in the US-EAST-1 Region. Alarms on delayed or missing metrics may transition into an INSUFFICIENT_DATA state. We are taking multiple parallel paths to mitigate this issue. While underlying resources are not affected by this issue, customers with automated actions based off of delayed or missing metric data may see their automations start. EC2 APIs are not impacted and therefore EC2 AutoScaling will not be affected by this issue.

2. 25 Şubat 2026 19:28 UTCresolved

   We can confirm issues with intermittent missing and/or delayed EC2 instance metrics and status checks in the US-EAST-1 Region. While existing instances are unaffected by this issue and operating normally, metrics and status checks may be delayed or reporting INSUFFICIENT_DATA. We have identified the issue to be in an underlying subsystem responsible for publishing EC2 metric data to CloudWatch. Engineers were automatically engaged, and continue to investigate multiple paths to mitigate the issue in parallel. We recommend customers treat the INSUFFICIENT_DATA state as missing data instead of an alarm breach, especially when configuring the alarm to stop, terminate, reboot, or recover an instance. More information is available <a href="https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UsingAlarmActions.html">here</a>. While we do not have a firm ETA for resolution, we will provide another update by 12:30 PM, or sooner if we have additional information to share.

3. 25 Şubat 2026 20:10 UTCresolved

   We are seeing early signs of recovery and continue to work toward full resolution. We will continue to provide updates.

4. 25 Şubat 2026 20:33 UTCresolved

   We can confirm significant signs of recovery, and continuing to monitor to ensure stability. At this time, missing/delayed metrics and instance status checks are recovered. We are actively working to backfill delayed data.

5. 25 Şubat 2026 20:51 UTCresolved

   Between 7:00 AM and 12:05 PM PST, we experienced errors while publishing EC2 instance metrics and status checks in the US-EAST-1 Region. This issue resulted in metrics and status checks to be delayed or report INSUFFICIENT_DATA. EC2 APIs and instances were unaffected by this issue and continue to operate normally. We were automatically engaged at 7:05 AM and began identifying multiple parallel paths to mitigate the issue. By 7:20 AM, we identified that the issue was related to an underlying subsystem responsible for publishing EC2 metric data to CloudWatch. By 12:03 PM, we completed our mitigation efforts and observed full recovery at 12:05 PM. New metrics are being published as expected. Delayed metrics are in the process of backfilling and may take a few hours to fully complete. The issue has been resolved and the service is operating normally.