AWS us-east-1 Bölgesinde Birçok Hizmette Arıza

• AWS'nin us-east-1 bölgesindeki çeşitli hizmetlerinde arıza meydana geldi
• Bu arıza nedeniyle bulut altyapısı kullanan şirketlerde kesinti yaşandı
• API Gateway, Lambda gibi kritik hizmetlerde kullanılabilirlik sorunu rapor edildi
• Mühendisler yedek geçiş yolu oluşturma ve acil durum önlemelerini değerlendirme gereğini gündeme getirdi
• AWS Health Dashboard üzerinden gerçek zamanlı arıza bilgisi ve güncelleme paylaşıldı

---

AWS us-east-1 Bölge Arıza Özeti

• 2025 yılının 21 Ekim tarihinde AWS Health Dashboard'da us-east-1 bölgesine ait çeşitli hizmetlerde arıza tespit edildi
• Özellikle API Gateway, Lambda, S3 gibi kritik hizmetlerin etkilenmesi nedeniyle birçok müşteri kesinti yaşadı
• Arıza anından itibaren AWS, sorunu fark eder etmez neden analizi ve kurtarma çalışmalarına başladı
• İlgili bölgeye bağımlı SaaS, startup ve IT şirketlerinde hizmet gecikmesi ve duruş süresi olayları rapor edildi
• Mühendisler ve IT yöneticileri, acil yedek geçiş yolları ve kritik hizmetlerin çok bölgeli (multi-region) dağıtım stratejisinin önemini vurguladı

Arıza Etkileri ve Müdahale

• us-east-1 bölgesi, küresel bulut altyapısı içinde en yoğun trafiğe sahip bölgelerden biri olduğu için arıza durumunda etkisi çok geniş oluyor
• Farklı müşterilerde hizmet sunum durması, API yanıt gecikmesi, veri işleme arızası gibi sorunlar aynı anda görüldü
• AWS, Health Dashboard üzerinden gerçek zamanlı durumu paylaştı ve destek dokümantasyonu ile güncellemeler sundu
• Müşteri BT ekipleri arızayı izleme, geçici geçiş ve kullanıcı bilgilendirme ile zararı azaltmak için çalışmalar yaptı

Mühendisler İçin Çıkarımlar

• Arıza durumunda izleme sistemleri ve arıza bildirimi mekanizmalarının önemi bir kez daha vurgulandı
• Çoklu bölge dağıtımı, otomatikleştirilmiş arıza müdahalesi ve yedekleme stratejileri gibi dayanıklı mimari tasarımın değeri öne çıktı
• AWS Health Dashboard, arıza durumunda hızlı bilgi edinimi ve karar verme için kritik bir destek aracı olarak kullanıldı

Sonuç

• Büyük ölçekli bulut servis sağlayıcılarının hizmet kesinti riskine yönelik hazırlık planı oluşturması zorunludur
• Arıza anında hızlı kurtarma süreci, şeffaf iletişim ve etkili altyapı arıza yanıt kapasitesinin önemi bir kez daha netleşti

[GN⁺]

Hacker News yorumu

• Bugün gerçekten çok ilginç bir gündü. Gece 03:00'ten itibaren olay müdahale köprüsündeydim. Sistemlerin çoğu toparlandı ama back-office tarafında hâlâ kaynak yetersizliğiyle boğuşan bir ekip var. Bizde en büyük hata, multi-region çalışacak şekilde tasarlamamıza rağmen failover sürecini çalıştıramamış olmamızdı. Bunun nedeni, güvenlik ekibimizin bizi Identity Center'a taşımış olması ve bunu us-east-1'e yerleştirerek şirketin tamamını AWS kontrol düzlemine tamamen kilitlemiş olmamızdı. Kök kimlik bilgilerini kasadan çıkardığımızda sistem zaten neredeyse tamamen toparlanmıştı. Bu olay bir kez daha zayıf halkaların toplam dayanıklılığı belirlediğini gösterdi
  • Birkaç yıl önce Google'ın Paris veri merkezinin su baskınından sonra çıkan yangınla altüst olduğu olayı hatırlattı. Oraya doğrudan compute kaynağı koymamıştık ama işlem AWS EU bölgesindeydi ve Google servisleri için DNS çözücüleri Paris'te barındırıldığı için trafik öncelikli olarak Paris'e yönleniyordu. Geçici çözüm oldukça ilginçti. O zaman Kubernetes'te dağıtılmış olarak /etc/hosts dosyasını kolayca değiştirebildiğimizi ilk kez fark ettik ve gerçekten böyle yapmak zorunda kaldığımız için bunu deneyimledik. Normalde bunu bu amaçla /etc/hosts ile yapmayız ama geçici bir yama için harika bir soyutlama oldu
  • Facebook'un BGP güncelleme hatasıyla kasa erişimini tamamen mümkün olmaktan çıkardığı benzer bir örnek geldi aklıma. Kimlik doğrulama yolu döngüselse DNS bir kez bozulduğunda hiçbir şey yapamazsınız
  • Sonunda birinin bir donanım token'ı alıp başka bir veri merkezine uçup gidip, dünya çapındaki sistemleri çalıştıran kritik ekipmanı sıfırlaması gereken bir an gelir
  • Identity Center'ı us-east-1'de tek başına tutmanın mümkün olup olmadığını merak ettim. Son kontrole göre yalnızca tek bir bölgede kullanılabiliyordu ve taşımak için önce silinmesi gerekiyordu
  • Fazla güvenlik bariyeri insanı kilitli bırakıyor. Bu durumdan güvenlik ekibinin sorumluluk üstleneceğini düşünüyor musunuz? Bundan sonra tüm projelerin yavaşlayacağını hissediyorum. Güvenlik ekibi bu konuda biraz fazla hızlı davranmış gibi görünüyor. Denetçiyi denetleyen kim?
• Hâlâ ana kesinti devam ediyormuş gibi görünüyor. Durum 4 saat önceye göre daha da kötü. Ben bir veri mühendisi olarak Redshift ve Airflow (AWS yönetilen servisi) tamamen dağılmış durumda
  • Bu kesinti oldukça uzun sürüyor; kaç tane dokuzun gittiğini merak ediyorum. 365 gün * 24 saat * 0.0001 yaklaşık 8 saat eder, bu da 99.99% kullanılabilirliğin zaten kaybedildiği anlamına geliyor
  • Neden hala bu kadar çok şirket us-east-1'i ısrarla seçiyor anlamıyorum. Arıza sıklığı açısından bakıldığında rakipsiz şekilde en kötü bölge. Şirketimiz eskiden us-east-1'i bir kenara bırakıp sadece diğer bölgeleri kullanmaya karar vermişti. Elbette ürün 'global' olarak geçse de pratikte us-east-1 anlamına geldiği için bazen fayda etmiyor
  • Lambda'nın create-function kontrol düzlemi işlemleri hâlâ InternalError ile başarısız oluyor. Diğer servisler (Lambda, SNS, SQS, EFS, EBS, CloudFront) toparlandı. Ben bu yüzden bulut kullanılabilirliği üzerine CS yüksek lisans tezimi inceliyorum; birden fazla AWS test hesabında deneyerek kesinti zaman çizelgesini ve etkisini derlediğim yazıyı paylaştım. analiz yazısı
  • Down Detector, AWS kesintisinin hâlâ ciddi boyutta sürdüğünü gösteriyor. Amazon tarafında “service recovery” denilse de Amazon.com'da bile ürün araması çalışmıyor. AWS Health sayfası
  • Down Detector'a göre 12:52 AM Pacific (3:53 Eastern) saatlerinde AWS için 5.755 rapor vardı; 4:22 AM Pacific (7:22 Eastern) saatinde 1.190'a düşünce de, 9:32 AM Pacific (12:32 Eastern) saatinde 9.230'a tekrar tırmandı. Batı ABD'nin ayağa kalkmasıyla rapor artışı da olmuş olabilir ama AWS hâlâ net şekilde durumu kontrol edmedeyi beceremiyor gibi görünüyor
• Bu kesinti günlük hayatımı doğrudan etkiledi. New York Hudson Yards Whole Foods'da bir çikolata barı almaya çalışırken Prime indirimi uygulanmadı. Bu yüzden almadım ve şu an çikolata stoğum bayağı düştü
  • Bugün sabah "alexa kahve makinesini aç" bile çalışmıyordu. Kafam allak bullak oldu
  • Öğlen Hot Bar'da yiyecek alıp self-checkout denedim; Whole Foods barkodlarının neden çalışmadığını uzun süre düşündüm. 20 saniye sonra bunun kesintiden olduğunu anladım
  • Güzel bir örnek paylaştığın için teşekkürler. Bu arada AWS kesintisi sırasında Amazon Go'da bulunanlar ne oldu diye merak ediyorum
• Bugün AWS hesap sahibiyle toplantım var. Bundan sonra “All in on AWS” yaklaşımını bırakıp iş yüklerini dağıtma politikamızı anlatacağım. Ana sebep, çekirdek servislerin inovasyon hızının yavaşlaması ve AI servislerinin de rakiplerinin çok gerisinde olması. AWS ekibi her zaman AWS'in olağanüstü dayanıklılığı nedeniyle çoklu bölgede dağıtmamayı öneriyor. Bugünkü toplantıyı merakla bekliyorum
  • AWS, Cloudflare, Google Cloud, Akismet... nereye bakarsak bakın bir yerde bir arıza yaşanıyor. Her seferinde on-premise'e dönmeyi de düşünüyoruz. Sonra geri dönüp çalıştırıyoruz. Sonuç benzer olduğu için daha fazla çaba harcamanın anlamı yok gibi
  • Geçen çeyrekte Andy Jassy'nin AWS'nin yenilikte geride kaldığı eleştirisine karşı öne sürdüğü argüman güvenilirlik, dayanıklılık ve dayanıklılığın kalıcılığıydı. Fakat mevcut durumda bu mazeret geçmiyor
  • us-east-1 dışındaki diğer bölgeler şu an oldukça stabil. Bizim şirket de çoğunlukla sadece eu-west-1'deyse, hiçbir büyük olay olmadan iyi gidiyor
  • AWS uzun vadede çöküşte. Şu an sadece mevcut servisleri korumaya odaklanmış gibi görünüyor. İçeriye sızan yenilikçi çalışanlar, bürokrasi ve performans baskısıyla eziliyor; bu yüzden AI tarafında da geride kalınıyor
  • AWS'in olağanüstü dayanıklı olduğu iddiası baştan yanlış. Eskiden farklı cloud ve bare metal ile multicloud izleme kurduğumuzda hangi platformun önce bozulduğunu net bir şekilde görebiliyorduk. O sonuçlar AWS'in sürekli birinci olmadığını gösteriyordu. Net sonuçlar netcraft.com verileriyle neredeyse aynıydı
• Bugün Premier League'in de AWS kesintisi nedeniyle VAR ve otomatik ofsayt karar sistemi sınırlı çalışacak gibi görünüyor. Gerçekten garip bir zamandayız BBC linki
  • Bulutta (arıza) bile olumlu bir tarafı olabileceğini hissettim
• us-east-1'i ana bölge seçerseniz, kesinti olduğunda herkes birden etkilenir, yalnızca birinin çile çektiği bir şey olmaz. Diğer ABD bölgelerinde bu ayrıcalık yok
  • AWS'ye geçerken veri merkezlerinden beklenmedik bir fayda şuydu: Bölge tamamen düştüğünde müşteriler çok daha anlayışlı oluyor. Herkes aynı anda rahatsız olduğunda, bunu doğal karşılıyorlar
  • Bazen herkesin bir kere teknik downtime yaşaması gerekiyor
  • Tamam, hep birlikte US-East-1'e altyapı koyalım
  • Kurumsal dünyada gerçekten önemli olanın anlaşılması epey zaman alıyor. Aslında kullanılabilirlikten daha kritik olan, suçlama yapacak kimsenin olmaması. Bir çalışan hatasıyla yılda 5 dakikalık kesinti olursa CTO sorumlu olur; AWS kesintisiyle 5 saatlik arıza olursa herkesin aynı anda mağdur olduğu için 'yapılamaz bir şeyler oldu' muamelesi görür. AWS, Crowdstrike vb. için sonunda sistemin sağlamlığı, maliyet-etkinliği veya risk yönetimi değil, başkalarının da aynı anda acı çektiği an daha önemli. Rahatsız edici ama gerçek böyle. Teknolojinin düzgün çalışmasını seven biri olarak bu gerçekten sinir bozuyor
  • Tokyo bölgesi şu anda iyi çalışıyor! Sadece bazı özellikler, örneğin konsol girişi tarafında hâlâ sorun var
• “Araştırmaya göre, sorun US-EAST-1 DynamoDB API uç noktasının DNS çözümlemesiyle ilişkili görünüyor. Kurtarma hızını artırmak için paralel yollarla çalışıyoruz” şeklinde bir duyuru vardı. Yine de kök sorun yine DNS'ti
  • Bu olay gerçekten DNS çözümleme sorunu mu, yoksa DNS sunucularının iç ayar/veri deposu kaynaklı mıydı? İkinci ihtimal daha olası
  • Daha sonra kesinti duyurusunda ağ yük dengeleyici arızasının nedeni olduğu yazıldı. DNS bunun yalnızca bir semptomu. DNS, health check'i bozmuş olabilir ama bence asıl kök sebep ağ tarafı
  • BGP, DNS sorunu gibi sakatlanmış da olabilir
  • Neden hep us-east-1
  • DNS olmasa da sonuçta DNS'tir
• Tasarımımız dayanıklılık odaklıydı. CloudFront ile çoklu bölge statik site origin'ları kurmuş ve bu kesintiden etkilenmedik. Kontrol düzlemi de yerel olmayan çoklu bölge mimarisine sahip, birçok servise bağımlı ama kullanılabilirliği koruyor. Her bölge bağımsız çalışıyor ve veri replikasyonu var; us-east-1 replikasyonu yapılamasa bile etkilenmiyoruz. Servis zaten çok katmanda (DNS, routing, hedef seçimi) çoklu bölge ve failover uygulanarak kurulmuş. Tabii bu model de kusursuz değil, hata açığı çok; ancak bu sefer iyi çalıştı, hoşuma gitti. Benim yaptığım şey roket bilim değil, pahalı da değil ama alışılmışın dışında bir yöntem. Sorular varsa çekinmeden sorun
  • CloudFront ile çoklu bölge statik origin kurup kesintiyi atlarsanız, 2025'te bu standart olmalı, yine de hâlâ takdir edilen bir şey olabiliyor
  • active/active yapı mı, veri yığınının nasıl olduğu mu; özellikle bu kısmın zor olduğunu düşünüyorum
  • Anahtarlar ve sertifikalar için hata toleranslı kimlik doğrulama nasıl uygulanmış
• Büyük bir sorun da IAM/kimlik doğrulama tarafındaki sistemin aşırı yüklenmesi veya çökmesi nedeniyle artçı arızalar olmasıydı. DynamoDB'nin neden olduğundan bahsediliyor; IAM içinde Dynamo'ya bağımlı olup olmadığını merak ediyorum. Büyük ölçekli karmaşık sistemlerde çok sayıda bağımlılık birbirine dolaşır ve Auth/IAM global tek bir giriş noktası olma riskini taşır, bu yüzden bağımlılıkları en aza indirmek isteriz. Ama ölçeklenebilirlik, tutarlılık vb. önemli olduğundan doğrulanmış DB kullanılmak zorunludur. Sonuçta bağımlılıklar karmaşıklaşıyor ve sistem düştüğünde bunları ayağa kaldırmak için karmaşık bir bootstrap süreci gerekmiyor mu? Nasıl çözüyorsunuz
  • 2017 civarında bir kez büyük bir DynamoDB kesintisi oldu. EC2 sunucu listesi DynamoDB'de saklanıyordu; DynamoDB çökünce EC2 de durdu. DynamoDB'nin EC2 üzerinde çalışması nedeniyle EC2 örneklerini yeniden başlatıp kurtarmak mümkün olmadı. Bu yüzden birkaç gün boyunca el ile örnek açarak kurtarma yapıldı. O zamandan beri S3, DynamoDB, EC2 gibi birinci sınıf sistemler arasındaki bağımlılıkları mümkün olduğunca ayırmaya çalışıyoruz. Tamamen kusursuz olması kolay değil
  • Birçok AWS müşterisi yanlış retry politikaları nedeniyle bir sistem devre dışı kaldığında diğerini de aşırı yükleyebiliyor. DynamoDB kesintisi, IAM'da da yük artışına yol açtı
  • Amazon içinde DynamoDB'den farklı bağımsız bir Dynamo KV-store platformu var. Bu nedenle temel neden DNS yönlendirme ya da node dağıtım sorunu da olabilir. Bu tip meseleler büyük kesinti post-mortemlerinde sürekli tekrar ediyor
  • AWS'de çalışırken IAM'ın Dynamo'ya bağımlı olmadığını biliyordum. Şimdi değişmiş olabilir ama emin değilim. Büyük ölçekli ağ etkisinin daha olası olduğunu düşünüyorum. Auth/IAM global tek erişim noktası olmamalı, bu yüzden bağımlılıkları minimuma indirecek şekilde tasarlanmış. IAM her bölgede kendi salt okunur önbelleğine sahip ve AWS SigV4 de bölgesel çalışmayı hedef alacak şekilde tasarlanmıştır. (ilgili belge)
  • Son GCP kesintisinin de benzer bir neden taşıyor olması ilginç
• AWS, saat 3:03 AM PT'de kurtarma sürecinde olduğunu açıkladı. Sonrasında durum iyice kötüleşti. 9:13 AM PT'de yine nedeni araştırılıyor denildi. AWS'in bile tam sebebi bilmemesi endişe verici
  • Bu olay Diwali (Hindistan'ın en büyük festivali) haftasında gerçekleşti; Hintli mühendislerin tatilde olmasının da bunda payı olmuş olabilir. Gerçekten şanssızlık