Olayın Başlangıcı

20 Ekim 2025 tarihinde, modern internet ekosisteminin can damarı olan Amazon Web Services (AWS) altyapısında yaşanan kesinti, dijital dünyada “zincirleme bir erimeye” yol açtı. Bu olayı basit bir teknik aksaklıktan ayıran unsur, AWS’nin küresel ekonomideki devasa ağırlığıdır. Geçen yıl 108 milyar dolar gelir elde eden ve Amazon’un toplam kârının büyük çoğunluğunu oluşturan bu platformun durması, milyarlarca dolarlık finansal riski de beraberinde getirmektedir. Kesinti, sadece web sitelerine erişimi engellemekle kalmamış; pasaport işlemlerinden bankacılık sistemlerine kadar devletlerin ve dev şirketlerin operasyonel kabiliyetlerini felç etmiştir. Bu durum, modern dijital mimarinin ne denli merkezi bir yapıya bağımlı olduğunu ve bu bağımlılığın küresel ölçekte bir krize nasıl dönüşebileceğini açıkça kanıtlamıştır.

Kesintiden Etkilenen Kritik Platformlar

Kategori	Etkilenen Uygulama ve Servisler
Bankacılık & Finans	Lloyds Bank, Halifax, Coinbase
Kamu Hizmetleri	HMRC (Vergi Dairesi), GOV.UK (Vize ve Pasaport İşlemleri)
Eğlence & Oyun	Snapchat, PlayStation, Roblox, Fortnite, Wordle, Pokémon Go
İş & Yaşam Tarzı	Slack, Canva, Xero, My Fitness Pal, Strava, Hinge, Duolingo
Altyapı & Amazon	Amazon Alexa, Ring Güvenlik, Prime Video, BT, EE, National Rail

Bu dijital felaketin boyutlarını anladıktan sonra, olayın zaman çizelgesine odaklanarak krizin nasıl derinleştiğini inceleyelim.

Krizin Kronolojik Akışı

Kriz yönetimi perspektifinden bakıldığında, AWS ekiplerinin sorunu teşhis etmesi için geçen 78 dakikalık süre, sistemin karmaşıklığının bir göstergesidir. Kesintinin başlangıcından tam iyileşmeye kadar olan süreç şu şekilde gelişmiştir:

• 08:00 (GMT): Hata Tespiti ve Raporlama. Downdetector verilerinde ani bir artışla birlikte küresel çapta bağlantı sorunları raporlanmaya başlandı.
• 08:50 (GMT): Operasyonel Sorun İlanı. AWS Health Dashboard üzerinden Virginia’daki (US-EAST-1) sunucularda performans düşüklüğü ve “operasyonel sorun” (operational issue) resmi olarak onaylandı.
• 10:00 (GMT): Kök Nedenin Belirlenmesi. AWS, sorunun US-EAST-1 bölgesindeki DynamoDB API uç noktasının DNS çözünürlüğü ile ilgili olduğunu teknik olarak teşhis etti.
• 10:30 (GMT): İyileşme Belirtileri. Müdahale stratejilerinin uygulanmasıyla sistemlerde “belirgin iyileşme sinyalleri” (significant signs of recovery) görüldüğü duyuruldu.
• 12:00 (GMT): Tam İyileşme. Servislerin büyük çoğunluğunun normale döndüğü ve hataların minimize edildiği raporlandı.

Zaman çizelgesi, krizin hızını gösterse de asıl teknik sorun sistemin derinliklerinde yatıyordu.

Teknik Kök Neden Analizi: DNS ve DynamoDB İlişkisi

Bir bulut mimarı olarak bu vakayı analiz ettiğimizde, karşımıza bir “bağımlılık paradoksu” çıkar. Sorun, AWS’nin en eski ve “varsayılan” (default) bölgesi olması nedeniyle en yoğun trafiği barındıran US-EAST-1 (Kuzey Virginia) lokasyonunda patlak vermiştir.

Bilgi Kutusu: Teknik Kavramlar

• DNS Çözünürlüğü (DNS Resolution): Uygulamaların bir servise ulaşmak için kullandığı “adres rehberi” sorgulama sürecidir. İsim çözülemediğinde trafik hedefe yönlendirilemez.
• DynamoDB API Uç Noktası (Endpoint): Uygulamaların veritabanına veri yazmak veya okumak için konuştuğu kapıdır.
• Hata Oranları (Error Rates): Sistemin gelen isteklere cevap verememe yüzdesidir; bu vakada “increased error rates” olarak tanımlanmıştır.

Krizin Teknik Aşamaları:

1. İsim Çözümleme Hatası: AWS altyapısındaki bir arıza nedeniyle DynamoDB servisinin DNS adresleri çözümlenemedi.
2. Erişim Blokajı: Uygulamalar veritabanına bağlanmak istediklerinde adres bilgisini alamadıkları için bağlantı zaman aşımına uğradı.
3. Zincirleme Etki: DynamoDB, AWS ekosistemindeki diğer pek çok servisin (ve dolayısıyla son kullanıcı uygulamalarının) temel veri saklama katmanı olduğundan, bu tekil noktadaki arıza Snapchat’ten HMRC’ye kadar tüm üst katman servisleri işlevsiz bıraktı.

Sorunun kaynağı netleştikten sonra, mühendislerin bu hatayı nasıl kontrol altına aldıklarına bakabiliriz.

“İyileşme Belirtileri” Aşaması

AWS mühendisleri, kriz anında zamana karşı yarışırken “paralel yollarla iyileştirme” (multiple parallel paths) stratejisini benimsemişlerdir. Bu yaklaşım, sadece tek bir düzeltmeye güvenmek yerine, hem DNS katmanında hem de ağ yönlendirme seviyesinde eşzamanlı onarımlar yürütmeyi ifade eder.

AWS Health Dashboard üzerinden sunulan şeffaf iletişim, krizin ciddiyetini şu şekilde yansıtmıştır:

“Hata oranları için potansiyel bir kök neden belirledik. İncelemelerimiz, sorunun US-EAST-1 bölgesindeki DynamoDB API uç noktasının DNS çözünürlüğü ile ilgili olduğunu doğrulamaktadır. İyileşmeyi hızlandırmak için paralel çözüm yolları üzerinde çalışmaya devam ediyoruz.”

Saat 10:30 sularında görülen “belirgin iyileşme sinyalleri”, mühendislerin DNS trafiğini alternatif yollarla yönlendirmeyi başardığını göstermiştir. Bu aşamada “increased error rates” (artan hata oranları) yerini kademeli olarak stabilize olan bir veri akışına bırakmıştır.

Sistemsel onarım tamamlanırken, bu vaka geleceğin bilişim uzmanları için önemli dersler barındırıyor.

Temel Çıkarımlar

Bu vaka, modern bir sistem mühendisinin sadece kod yazmayı değil, sistemler arasındaki karmaşık bağımlılıkları ve Hizmet Seviyesi Anlaşmaları (SLA) yönetmeyi bilmesi gerektiğini kanıtlamıştır. Geleceğin mimarları için mühendislik prensipleri şunlardır:

• [ ] Tasarımda Tekil Hata Noktalarını (SPOF) Ortadan Kaldırın: Kritik veritabanı işlemlerinde sadece tek bir bölgeye (Region) güvenmek yerine, “Multi-region” mimarileri tasarlayarak felaket anında otomatik geçiş (failover) mekanizmaları kurgulayın.
• [ ] Gerçek Zamanlı Gözlemlenebilirlik (Observability) Kültürü Oluşturun: AWS Health Dashboard veya Downdetector gibi araçları proaktif olarak izleyin. Sorunun sizden mi yoksa altyapı sağlayıcınızdan mı kaynaklandığını anlamak, müdahale süresini (MTTR) radikal şekilde düşürür.
• [ ] Altyapı Bağımlılığını ve SLA Risklerini Analiz Edin: Kullandığınız her üçüncü taraf servisin (SaaS/PaaS) kendi iş süreçlerinizi nasıl etkileyeceğini simüle edin ve bu servislerin sunduğu SLA taahhütlerini iş sürekliliği planlarınıza dahil edin.

Bu analiz, modern internet altyapısının ne kadar hassas ama aynı zamanda ne kadar hızlı toparlanabilir olduğunu kanıtlamaktadır.