7 puan yazan GN⁺ 2025-10-23 | 3 yorum | WhatsApp'ta paylaş
  • Dünyanın en büyük AWS bulut hizmeti arızası nedeniyle binlerce web sitesi ve uygulama durdu ve internet altyapısının çok az sayıda şirkete aşırı bağımlı kaldığına dair bir uyarı doğdu
  • Snapchat, Roblox, Signal, Duolingo gibi öne çıkan platformların yanı sıra, Lloyds Bank, Ring, HMRC gibi kamu ve finans kurumları da kesinti alanına dâhil oldu
  • AWS, nedeni ABD'nin doğu bölgesindeki bir iç sistem hatası olarak gösterdi ve siber saldırı olasılığını ekarte ederek, birkaç saat içinde çoğu hizmeti geri getirdi
  • Uzmanlar, “Demokratik tartışma ve gazeteciliğin temelleri az sayıdaki şirkete bağlı olmamalı” diyerek, bulut altyapısını çeşitlendirme gereğini vurguladı
  • Büyük bulut şirketleri merkezli yapı, küresel internetin kırılganlığını gözler önüne serdi; kamu altyapısında teknoloji egemenliği tartışmasını tetikledi

Arıza özeti

  • AWS'nin ABD Doğu Bölgesi (US-East-1)'de meydana gelen bir iç hatası nedeniyle küresel çapta büyük ölçekte hizmet kesintisi yaşandı
    • Yerel saatle Pazartesi sabahı 08:00 (İngiltere saatiyle 16:00) civarında arıza başladı
    • Amazon, “API hata oranının ve gecikmenin arttığını” duyurdu
    • Downdetector verilerine göre dünyada yaklaşık 2.000 şirket etkilendi; ABD'de 1,9 milyon, Birleşik Krallık'ta 1 milyon, Avustralya'da 410 binin üzerinde kullanıcı sorun bildirdi
  • AWS, nedeni dahili yük dengeleyici izleme alt sistemindeki bir sorun olarak göstererek siber saldırı olasılığını dışladı
    • AWS'nin DynamoDB ile ilgili bir hatası nedeniyle API yanıtlarının başarısız olduğu bildirildi
    • Trafik artışını önlemek amacıyla istek sayısı limiti geçici olarak devreye alındı
  • AWS, akşam saatlerinde “normal operasyona dönüldüğünü” resmi olarak açıkladı, ancak bazı hizmetlerde kesinti bildirimleri devam etti

Etki alanı

  • Öne çıkan hizmetler: Snapchat, Roblox, Signal, Duolingo, Coinbase, Slack, Wordle, PlayStation Network, Peloton ve daha fazlası
  • Birleşik Krallık içinde Lloyds, Halifax, Bank of Scotland gibi finansal hizmet sağlayıcılarıyla HMRC (Gelir ve Gümrük İdaresi) web sitesi erişiminde kesinti yaşandı
  • Ring Doorbell kullanıcıları, kapı açılma izleme servislerinin durduğunu belirterek şikâyet etti
  • Epic Games, Pokémon Go, Wordle gibi global platformlarda da erişim engeli rapor edildi

Uzman analizi

  • Dr. Corinne Cath-Speth (Article 19): “Demokratik tartışma ve bağımsız medyanın temellerinin az sayıdaki şirketin altyapısına dayanması risklidir; bulut çeşitlendirmesi acilen yapılmalı”
  • Cori Crider (Future of Technology Institute): “Birleşik Krallık, ABD büyük teknoloji şirketlerine bağımlılıktan kurtulmalı. AWS’deki tek noktadaki bir arıza, modern ekonominin tamamını durdurdu.”
  • Madeline Carr (UCL): “Büyük bulut şirketlerinin sermaye gücü sayesinde güvenlik ve ölçeklenebilirlik korunuyor olsa da, dünyanın aynı riske bağlandığı bir yapı oldukça tehlikelidir”
  • Steven Murdoch (UCL): “Bir siber saldırı değil, AWS iç operasyonundaki bir hata olduğu tahmin ediliyor”

Devlet ve düzenleyici yanıt

  • Birleşik Krallık hükümeti, AWS ile acil bir iletişim hattını devreye aldığını ve onarım sürecini takip ettiğini duyurdu
  • Birleşik Krallık Avam Kamarası Maliye Komitesi, AWS'nin finans sektorü için ‘kritik üçüncü taraf’ (critical third party) olarak tanımlanması gerektiğini savundu
    • Böyle bir tanımlama durumunda finansal düzenleyici kurumların denetimine girecek ve finans altyapısı istikrarının sağlanmasına katkı sağlayacak
    • Komite başkanı Meg Hillier, AWS'nin ‘kırılganlığı azaltacağını’ iddia ederken aslında sorunu açığa çıkardığını eleştirdi

Arka plan ve sonuçlar

  • AWS, dünya bulut pazarının %30’dan fazla payı ile ilk sırada yer alıyor
  • Microsoft Azure ve Google Cloud ile birlikte ‘3 büyük bulut hakimiyeti’ oluşma eğiliminde
  • 2024'te CrowdStrike'in yazılım hatası nedeniyle dünya genelinde Windows PC'lerde ‘mavi ekran’ yaşanmıştı
  • Bu olay, dijital altyapının merkezileşmesinin doğurduğu sistem riskini bir kez daha görünür kıldı ve çeşitli ülkelerde teknoloji egemenliği ve bulut dağıtım stratejisi tartışmalarını alevlendirdi

3 yorum

 
chickendreamtree 2025-10-24

Güçlü kal, Naver Cloud!

 
kimjoin2 2025-10-23

"Bulut istemiyorsanız, kendiniz kurup kullanın." denildiğinde bunun üzerinde tartışılacak bir şey var mı?
Çoklu bulut mu? Kurulum ve yönetimi de birinin sizin yerinize yapıp öteye bırakacağı bir iş değil.

 
GN⁺ 2025-10-23
Hacker News Yorumu
  • Şu anda AWS us-east-1'de birçok hizmetin kesintiye düştüğü tartışılıyor ve buna dair uzun bir başlık burada var

  • 2021'deki Fastly kesintisi sırasında da “uzmanlar” benzer eleştirilerde bulunmuştu ama somut bir değişiklik olmadı. Böyle konular bir hafta geçince gazetelerde bile anılmaz. Operasyon ekipleri AWS ölçekte çalıştırmanın ne kadar zor olduğunu biliyor. Bu duruma karşı gerçek önlemler o kadar pahalı ki, çoğu şirket için faydası son derece sınırlı kalıyor. Gerçekten “kritik” bir hizmetse, böyle arızalara dayanacak şekilde tasarlanması gerekir. Fortnite'a giriş yapamamak bile, bunu pratikte ne kadar zor ve maliyetli olabildiğini gösteriyor. Basın da genel olarak çok bölgesel veya çoklu bulutun öneminden bahsetmez; bir olay olduğunda birden bu konuyu konuşur sonra da çabucak unutur. Sonuçta merak edilen şey teknik kökenin ne olduğudur. Sonrasız “uzman” eleştirilerinin pek anlamı yok; asıl önemli olan, takip eden övgü veya suçlama değil, yapıcı bir olay analizi ve suçlayıcı olmadan yapılan bir postmortemdir.

    • Buradaki “uzmanlar” gerçek bir altyapı veya bulut işletimi geçmişi olmayan kişiler. Örneğin Dr Corinne Cath-Speth bir antropolog, Cori Crider bir avukat, Madeline Carr ise siyaset bilimiyle ilgili bir profesör. Yani bunlar sadece makale yazıp medya röportajlarına katılan kişiler; hosting servisi yönetme deneyimleri yok

    • Bulut bağımlılığını eleştirirken sonunda yılda en az 16 saatlik kesintiye razı olma noktasında uzlaşılıyor. Birkaç saatlik bir arıza kişisel olarak çok çarpıcı görünse de, asıl ölümcül etki çoğu zaman kalan 8.742 saatteki performans düşüşünde olur. Eğer yalnızca 16 saatlik kesinti bir şirketi batırıyorsa, ne benim ne de karşı tarafın işi iyi anlamadığını söyleyebiliriz. Ben yüksek kullanılabilirlik, jeo yedeklilik ve dayanıklı sistemlere daha çok önem veririm

    • Her şey için masraflı yatırım yapmaya gerek yok. Her bir hizmetin aynı düzeyde dayanıklılığa ihtiyacı da yok. Farklı sağlayıcılar kullanıldığında herkesin aynı anda etkilenme riski azaltılabilir

    • Basında işlenen çoklu-bölge/çoklu-bulut yedekliliğinin etkinliğinin düşük olduğunu vurguluyorum. Yüzeyde tek bir bölgeden kaynaklanıyormuş gibi dursa da hizmetler çoğu zaman birden fazla bölgeyi etkiliyor. Çoklu-bulut hot standby yaklaşımı inşa edilmesi ne kadar karmaşık olursa olsun ciddi bir maliyet getiriyor. Başlangıçta planlayıp kurmak yerine sonradan eklemek çok zor

    • AWS'nin kendi raporlarına bakıldığında da belirli bir bölge ve belirli bir hizmete (ör. DynamoDB) aşırı odaklanma görülebiliyor. Bu merkezi mimari en az 10 yıldır gözleniyor. Yine de neden değişmediği hâlâ sorusu işaret ediyor. Bu olayda 2.000'in üzerinde hizmet uzun süre kapalı kaldı. AWS durum sayfasına bakın

  • “Cloud” veya “internet” yerine “Virginia'daki depo” diyelim mi? Örneğin “hizmetimiz tamamen Virginia'daki depoda”, “tüm dosyalarım Virginia'daki depoda”, “Virginia'daki depo nükleer savaşa dayanacak şekilde tasarlandı” gibi ifadelerle. Orijinali

    • Gerçekte bu depo (Virginia'daki depo) oldukça iyi bir depo. Bulutla ilgili espriler veya benzetmeler çoğu zaman gerçek alternatifleri görmezden geliyor. Çoğu iş için bulutun pratik alternatifi, ofis koridorundaki bir raftır. Eskiden IT uzmanı gelene kadar birinin kod çekmesi bile şirketi bütünüyle durdurabiliyordu
  • Zaten birçok VPS sağlayıcısı var ve bu alana taşınıp maliyet düşürdüğünü belirten örnekler sürekli geliyor; gerçekte bu durum cloud lock-in ve pazarlama meselesi

    • Günümüzde firmalar temel bir EC2/IaaS yerine DynamoDB, RedShift gibi AWS'in yüksek seviyeli PaaS hizmetlerini kullanıyor. Azure ve Google Cloud'da da benzer. Bu tür yüksek seviyeli hizmetlere bağımlıysanız, Hetzner gibi VPS'ye ya da self-hosting'e geçmek, AWS yığınını baştan kurup yönetmek anlamına gelir; sadece PostgreSQL kurmakla geçilmiyor

    • VPS kullanıp maliyeti azalttığını yazan yazılara her zaman “AWS web ölçeğindedir ve asla düşmez, VPS'de bir ayda sadece 1 gün uptime olur” şeklinde karşılık gelir

    • Amazon da EC2 gibi VPS'ler sunuyor; bu olayda EC2 gerçekten etkilendi mi, merak ediyorum

  • Uzman görüşlerinin çoğu aslında teknikten çok jeopolitik bir bağlama odaklanıyor (ör. bir ülkenin tüm sistemlerinin yabancı şirketlere anlık olarak bağımlı olması). Genelde sıradan bir şirketin tek sağlayıcıya bağımlı olması karmaşıklığı azaltır ve kesinti sıklığı açısından da sorun yaratmaz. Çoklu bulut kullanmaya gerek olmayabilir; tek bulutla çalışmak bile kesinti sıklığını iyileştirebilir

    • Basında adı geçen bu uzmanlar çözüm üretmiyor; olay çıkınca ortaya çıkan kişiler çoğunlukta
  • Tüm sektörün cloud lock-in içinde olduğuna inanıyorum. Bunu nasıl tersine çevirebileceğimize bakmak gerek. Docker da büyük bulut sağlayıcılarıyla birlikte lock-in’in nedeni olan unsurlardan biri gibi görünüyor

    • Üretimde olan bir mühendis veya destek ekibi açısından, gece yarısı 01:00'de AWS genelinin çökmesiyle her şeyin dağıldığını görürken, bu durumu değiştirmek isteyen kimsenin olmaması gerçeği ortada

    • Docker neden sorun çıkarıyor, bunu merak ediyorum

  • Cloud operasyonundan ayrılıp uzun süre geçti ama o sırada temel yapı taşları her sağlayıcıda standartlaşmak üzereydi. Çoklu bulut yedekliliğinin çok pahalı olduğu, teknik farkın çok büyük olduğu veya iş açısından tartışmaya bile gerek olmadığı konularından hangisi geçerlidir merak ediyorum. pets vs cattle slaytları

    • Birden fazla buluta dağıtım ve işletim ekibin yükünü ve bilişsel yükünü çok artırıyor. İki ve daha fazla bulut altyapısında uzmanlık sürdürmek için de daha çok personel gerekir. Küçük ve hızlı ekipler için uygun değil. Tek bulut kullanımının sadeliği doğrudan uptime ile bağlantılı. Büyük şirketlerin çoğu da tek bir bulutta toplu satın alım avantajıyla daha iyi fiyat elde eder; kimse AWS seçti diye işten atılmıyor

    • Başka bir bulut kendi bölgesinde arızalandığında dahi karşılık verememesi nedeniyle çoklu bulutun etkinliği düşük kalıyor. Sağlayıcılar yine de %100 kendi standardını dayatıyor ve kontrol düzlemi de Kubernetes. Sonuçta herkes Kubernetes'te takılıp kaldı

    • Tüm bulutlar compute katmanını ucuz sunuyor ama ağ çıkışını (egress) saçma pahalı yapıyor. Çoklu bulut kurarsanız trafik masrafları fırlar. Bunu kasıtlı buluyorum

    • Gerçekte bulut sağlayıcıları gelirlerini egress ücretlerinden kazanıyormuş gibi görünüyor. Bu yüzden çoklu bulut kurgusu ve hatta tek bulut içinde bölge/az arası yedeklilik, birçok bulut ve uygulamada aşırı pahalı. Tek bir bulutta global bir sistem kesintisi olduğunda bölge yedekliliğinin hiç faydası olmayabiliyor. Ayrıca bir bulut düştüğünde trafiği diğerine taşımak da zor, karşılığında emek çok yüksek. Çoğu uygulama için o birkaç saatlik kesintiyi göze alıp parayı ve emeği başka şeylere harcamak daha iyi

    • Müşterilerin büyük kısmı dosyalarını/veri yükünü bir bulutta tutuyor ve bu veriler başka bir bulutta olursa hizmeti işletmek çok zor olur, müşteri kazanımı da olumsuz etkilenir. Sağlayıcı zamanla pazar standardı olduğundan müşteriler de verilerini aynı bulutta topluyor ve bu nedenle her iki bulutta depolama maliyetini haklı çıkarmak zorlaşıyor. Ben de platformdan bağımsızlaşmaya çalışarak başlamıştım ama pratikte tüm potansiyel müşterilerin aynı bulutu kullandığını görünce karmaşıklığın azaldığını gördüm

  • Bu yıl “AWS us-east-1'in iki basamaklı 9'u bile zor geçeceği” şeklinde bir tahmin yapabilmek mümkün değildi

    • AWS'i yaklaşık 20 yıldır kullanan biri olarak, en yoğun ve kritik trafik alan us-east-1'i özellikle seçmenin bir anlamını göremiyorum. En eski ve en istikrarsız yer bu

    • EC2 gibi örneklerin gerçekten etkilenip etkilenmediği de merak ediliyor

  • Herkesin düşmesiyle sorumluluk biter gibi düşünebilirsin ama sıradan bir müşteri odaklı hizmette bu pratikte işlemiyor

  • Bu arızanın nedeni, ağ yük dengeleyicisinin sağlık kontrolünü yapan dahili bir alt sistemdeki arızaydı. AWS servis durumu sayfası