ABD Doğu (Kuzey Virginia, US-East-1) bölgesinde yaşanan Amazon DynamoDB hizmet kesintisinin özeti

• 19–20 Ekim 2025'te AWS N. Virginia bölgesinde (us-east-1) Amazon DynamoDB dahil birçok kritik hizmet uzun süreli kesinti yaşadı
• Kesinti, DynamoDB'nin otomatik DNS yönetim sistemi içindeki gizli bir yarış durumu (race condition) nedeniyle hatalı boş bir DNS kaydının oluşturulmasıyla başladı
• Bunun sonucunda EC2 instance oluşturma hataları, Network Load Balancer (NLB) bağlantı hataları, Lambda·ECS·Redshift dahil çok sayıda hizmette API gecikmeleri ve hatalar zincirleme şekilde ortaya çıktı
• AWS, sorunun kök nedenini DynamoDB DNS Enactor'ları arasındaki anormal eşzamanlı güncelleme çakışması olarak belirledi ve manuel kurtarma ile 20 Ekim saat 14:20 civarında tam toparlanma sağladı
• Bu olay, AWS içindeki otomasyon sistemleri arasındaki karşılıklı bağımlılıkların karmaşıklığını ortaya koyarken, gelecekte DNS·EC2·NLB dayanıklılığını güçlendirmeye yönelik yapısal iyileştirmelerin geleceğine işaret ediyor

---

Olay özeti

• Kesinti 19 Ekim 2025 saat 23:48'de (PDT) başladı ve 20 Ekim saat 14:20'de (PDT) sona erdi
  • Üç ana etki dönemi vardı:
    1. 19 Ekim 23:48 ~ 20 Ekim 02:40: DynamoDB API hata oranında keskin artış
    2. 20 Ekim 05:30 ~ 14:09: NLB bağlantı hatalarında artış
    3. 20 Ekim 02:25 ~ 10:36: EC2 yeni instance oluşturma hataları ve ağ bağlantı sorunları
• Kesinti, DynamoDB DNS yönetim sistemindeki bir kusurla başladı ve EC2, NLB, Lambda, Redshift gibi çok sayıda hizmete yayıldı

DynamoDB kesintisinin nedeni ve etkileri

• DynamoDB'nin otomatik DNS yönetim sistemindeki gizli bir kusur tetiklendi ve dynamodb.us-east-1.amazonaws.com için DNS kaydı yanlışlıkla boş duruma güncellendi
  • Sistem iki bileşene ayrılıyor:
    • DNS Planner: yük dengeleyici durumunu izler ve yeni DNS planı oluşturur
    • DNS Enactor: değişiklikleri Route53'e uygular
• Üç Availability Zone'a (AZ) bağımsız şekilde dağıtılmış DNS Enactor'lar arasında yarış durumu (race condition) oluştu
  • İlk Enactor gecikmeli durumda eski planı uyguladı
  • İkinci Enactor güncel planı uyguladıktan sonra eski planı silince tüm IP adresleri kaldırıldı ve sistem tutarsız duruma geçti
  • Otomatik kurtarma başarısız olduğu için manuel müdahale (manual intervention) gerekti
• Saat 23:48'de kesinti başladıktan hemen sonra, DynamoDB'ye bağımlı tüm hizmetler ve müşteri trafiği bağlantı hataları yaşamaya başladı
  • Global Tables kullanan müşteriler isteklerini diğer bölgelerdeki kopyalara yönlendirebildi, ancak replikasyon gecikmesi (replication lag) oluştu
• 00:38'de AWS mühendisleri sorunun nedeninin DNS durumu olduğunu doğruladı
  • 01:15'te geçici kurtarma adımıyla bazı iç hizmet bağlantıları geri geldi
  • 02:25'te DNS bilgileri tamamen geri yüklendi, 02:40'ta tüm bağlantılar normale döndü

Amazon EC2 etkisi ve kurtarma süreci

• 19 Ekim 23:48 ~ 20 Ekim 13:50 arasında EC2 API hata oranı arttı, instance oluşturma başarısız oldu ve gecikmeler yükseldi
  • Hâlihazırda çalışan instance'lar etkilenmedi
• EC2 instance yönetiminde iki alt sistem kullanılıyor: DropletWorkflow Manager (DWFM) ve Network Manager
  • DWFM fiziksel sunucuların ('droplet') durumunu yönetir ve periyodik sağlık kontrolleri yapar
  • Network Manager instance ağ yapılandırmasını yayar
• DynamoDB kesintisi nedeniyle DWFM'nin durum kontrolleri başarısız olunca droplet kiraları (lease) sona erdi
  • 02:25'te DynamoDB geri geldikten sonra DWFM yeniden bağlanmayı denedi, ancak çok sayıdaki droplet nedeniyle congestive collapse yaşandı
  • 04:14'te mühendisler seçici olarak DWFM host'larını yeniden başlatarak kuyruğu temizledi ve toparlanmayı ilerletti
  • 05:28'de tüm droplet lease'leri geri yüklendi ve yeni instance oluşturma yeniden başladı
• Ardından Network Manager gecikmiş ağ durumu yayılımı backlog'unu işlerken ağ bağlantısı gecikmeleri yaşandı
  • 10:36'da ağ yayılım süresi normale döndü
  • 11:23'te istek sınırlamasını (throttling) gevşetme başladı, 13:50'de EC2 tamamen toparlandı

Network Load Balancer (NLB) etkisi

• 20 Ekim 05:30 ~ 14:09 arasında bazı müşteriler NLB bağlantı hatalarında artış yaşadı
  • NLB çok kiracılı bir yapıda çalışır ve trafiği arka uç EC2 instance'larına yönlendirir
• Sorunun nedeni ağ durumu yayılım gecikmesi yüzünden health check başarısızlıklarıydı
  • Yeni eklenen EC2 instance'larının ağ yapılandırması tamamlanmadığı için health check'ler başarısız oldu
  • Health check sonuçları kararsız biçimde tekrarlandığından NLB düğümleri DNS'ten çıkarılıp yeniden geri dönüyordu
• 06:52'de izleme sistemi sorunu algıladı ve mühendisler müdahaleye başladı
  • Health check alt sistemindeki yük artışı nedeniyle otomatik AZ DNS failover tetiklendi
  • 09:36'da otomatik failover devre dışı bırakılarak tüm sağlıklı düğümler geri getirildi
  • 14:09'da EC2 toparlandıktan sonra otomatik failover yeniden etkinleştirildi

Diğer AWS hizmetlerine etkiler

• AWS Lambda:
  • 19 Ekim 23:51 ~ 20 Ekim 14:15 arasında API hataları ve gecikmeler
  • DynamoDB kesintisi nedeniyle fonksiyon oluşturma/güncelleme başarısız oldu, SQS/Kinesis olay işleme gecikti
  • 07:04'te NLB health check başarısızlığı nedeniyle iç sistem küçüldü, eşzamansız çağrılar sınırlandı
  • 14:15'te tüm backlog işlendi ve hizmet normale döndü
• ECS, EKS, Fargate:
  • 19 Ekim 23:45 ~ 20 Ekim 14:20 arasında container çalıştırma hataları ve cluster ölçekleme gecikmeleri
• Amazon Connect:
  • 19 Ekim 23:56 ~ 20 Ekim 13:20 arasında çağrı·sohbet·vaka işleme hataları
  • DynamoDB toparlandıktan sonra işlevlerin çoğu normale döndü, ancak 07:04 sonrasında NLB ve Lambda etkileri yüzünden yeniden hatalar oluştu
  • 13:20'de tam toparlanma sağlandı
• AWS STS:
  • 19 Ekim 23:51 ~ 20 Ekim 09:59 arasında kimlik doğrulama API hataları ve gecikmeler
  • DynamoDB toparlandıktan sonra geçici olarak normale döndü, NLB sorunu nedeniyle yeniden hatalar görüldü
• IAM oturum açma ve Identity Center:
  • 19 Ekim 23:51 ~ 20 Ekim 01:25 arasında kimlik doğrulama başarısızlıklarında artış
  • DynamoDB toparlandıktan sonra normale döndü
• Amazon Redshift:
  • 19 Ekim 23:47 ~ 20 Ekim 02:21 arasında sorgu ve cluster değişikliği başarısızlıkları
  • DynamoDB toparlandıktan sonra bazı cluster'lar EC2 kesintisi nedeniyle hâlâ anormal durumdaydı
  • 21 Ekim 04:05'te tam toparlanma sağlandı
  • IAM API bağımlılığı nedeniyle global bölgede de geçici sorgu hataları görüldü
• Diğer hizmetler:
  • Managed Workflows for Apache Airflow, Outposts, AWS Support Center gibi hizmetler de etkilendi

Olay sonrası önlemler ve iyileştirme planı

• DynamoDB DNS Planner ve Enactor otomasyonu tamamen devre dışı bırakıldı; yeniden etkinleştirmeden önce yarış durumu düzeltilecek ve koruma mekanizmaları eklenecek
• NLB: health check başarısız olduğunda tek bir NLB'nin kaldırabileceği kapasiteyi sınırlayan bir rate control mekanizması devreye alınacak
• EC2:
  • DWFM kurtarma iş akışını da içeren yeni bir test suite oluşturulacak
  • Veri yayılım sisteminde daha akıllı throttling iyileştirmeleri ile bekleme kuyruğu boyutuna göre istek sınırlama özelliği eklenecek
• AWS, hizmetler arasındaki tüm karşılıklı bağımlılıkları analiz ederek kurtarma süresini kısaltma ve benzer olayları önleme yöntemlerini ayrıca gözden geçiriyor

Sonuç ve özür

• AWS, bu olayın müşteriler üzerindeki etkisi için resmî olarak özür diledi
• Kendi hizmetlerinde yüksek erişilebilirliği koruduklarını, ancak bu kesintinin müşteri işlerine ciddi etki ettiğini kabul etti
• Bu olaydan ders çıkararak otomasyon sistemlerinin dayanıklılığını ve kesinti müdahale süreçlerini güçlendirme sözü verdi

[shakespeares]

Kıdemli çalışanları işten çıkarmanın artçı etkisi olduğu söyleniyordu... doğru mu?

[GN⁺]

Hacker News görüşleri

• Bu konuda hep aynı şeyi söyleyen kişilerden biriyim. Eğer hâlâ Richard Cook'un yazısını okumadıysanız, bu postmortemi şimdi durdurup önce How Complex Systems Fail yazısını okumanızı öneririm. Karmaşık sistem arızaları üzerine yazılmış en iyi teknik metinlerden biri. Cook, “kök neden (root cause)” kavramının kendisini reddediyor; bence bu olayda da haklı

  • Cook'un yazısı iyi ama aslında biraz sezgisel iddiaların sıralanması gibi hissettiriyor. Gerçekten derinlemesine anlamak için kaynakçadaki metinlerin tamamını okumak gerekebilir. MIT'nin 6.033 sistem dersinde de benzer konular için 1962 tarihli bir makale ve başka bir klasik makale okutuluyor. Sonuçta bu tür sorunlar “wicked problem” düzeyinde bir karmaşıklığa ulaşıyor diye düşünüyorum
  • Cook'un yazısında beni en çok etkileyen noktalardan biri, bir kazadan sonra sistemi “daha güvenli” hâle getirme çabasının tersine güvenliği azaltabilmesi oldu. İnsan hatasını engellemek için alınan önlemler sistemin bağlılığını ve karmaşıklığını artırıyor, böylece potansiyel arıza noktaları çoğalıyor ve bunları tespit etmekle engellemek daha zorlaşıyor
  • Başka bir bakış açısı da “Normal Accidents” teorisi. Bileşenler ne kadar sıkı bağlıysa, etkileşimler ne kadar karmaşıksa ve arızanın sonuçları ne kadar ağırsa, sistem o kadar doğası gereği riskli hâle geliyor. Bkz. Normal Accidents wiki
  • İki belgeyi de tamamen bitirmiş değilim ama sistem yalnızca karmaşık diye bir arızanın kök nedeninin tanımlanamayacağı iddiasına katılmıyorum. Sporda da sayı birçok etkenin sonucudur ama sonuçta bir “skoru yapan” vardır. Geniş açı faydalı ama ana nedeni işaret etmek de pratiktir
  • Ben oncall nöbeti tutan bir yükleniciyim. Çoğu şirket oncall işini ciddiye almıyor. Dokümantasyon yetersiz, başkasının karmaşık kodunu okumak için de zaman verilmiyor. AWS gibi oncall'u öğrenmenin ve sorumluluğun parçası sayan bir kültürü gerçekten deneyimlemek isterdim

• İnternet giderek merkezileşmiş tek bir ağ (mononet) hâline geliyor. Soğuk Savaş döneminde dağıtık ağ olarak doğan internet, artık tek bir deployment hatasıyla dünyanın dört bir yanında bankacılığı, alışverişi ve seyahati durdurabilecek bir yapıya dönüştü. Bulut metaforu çoktan sınırlarını aştı.
  Startup'lar veya Ar-Ge için hâlâ yararlı olabilir ama büyüme aşamasındaki şirketler ve devletler kendi sunucularına, kendi bulutlarına ve kendi çekirdek servislerine sahip olmalı. Bunun için teknoloji de insan kaynağı da var

• AWS'nin postmortemindeki kesin zaman çizelgesi görselleştirmesi çok etkileyiciydi. GDC'deki efsanevi “I Shot You First” konuşmasında olduğu gibi zaman akışını eğik oklarla gösterip “gecikme tam olarak nerede oluştu?” diye sormak çok faydalıydı.
  Ama beni daha çok şaşırtan şey, EC2 düğüm kira yönetim servisinin bir kurtarma prosedürüne (runbook) sahip olmamasıydı. AWS'nin çekirdek servislerinden birinde neredeyse her istisna durum için hazırlık vardır diye düşünürdüm

  • Böyle durumlar korkulacak şeyler değil, karmaşık sistemlerin özsel örüntüsü olarak görülmeli. Potansiyel arızalar fraktal gibi her yerde vardır; her olası durum için bir runbook yazmak imkânsızdır

• Bu olayın özü, DNS sistemlerindeki cache invalidation sorununun bir türevi gibi görünüyor. İki DNS Enactor farklı zamanlamalarla planı uygulayınca bir race condition oluşmuş ve eski plan yenisinin üzerine yazmış

  • Bu sadece kamuya yönelik açıklama. İçeride ise olay çözüldükten sonra yeniden yaşanma olasılığı değerlendirilir ve azaltıcı önlemler için runbook yazılır. Sonrasında da organizasyon genelinde öğrenme ve paylaşım süreci gelir
  • Bana göre bu race condition'ın kendisi kök neden. O bug olmasaydı olay da yaşanmazdı
  • DNS Planner ile Enactor neden ayrılmış diye merak ediyorum. Tek bir servis olsaydı bu yarış durumu daha açık biçimde ortaya çıkardı. Bu, mikroservislerin aşırı kullanımının karmaşıklığı artırmasının bir sonucu olabilir
  • Benzer bir sorunu yaşamıştım; nedeni JVM GC gecikmesi ve arızalı donanımdı. Burada da öyle bir ihtimal olabilir
  • Ama AWS, bu tür gecikmeler tekrar yaşanırsa buna karşı hangi önleyici tedbirlerin alınacağını belirtmedi

• Enactor, yeni değeri uygulamadan önce mevcut kaydın sürümünü karşılaştıran bir CAS yapmalıydı. Verim biraz düşse bile bu temel bir güvenlik önlemidir. Hatta bunu DynamoDB'nin kendisi halledebilirdi

• DynamoDB'nin bölge başına yüz binlerce DNS kaydını yönettiği açıklaması beni şaşırttı. dynamodb.us-east-1.amazonaws.com adresinin yüz binlerce IP'ye çözümlenebilmesi, Route53'ün sınırlarını aşan bir ölçekte gibi görünüyor. Muhtemelen TTL düşük tutulup her seferinde yalnızca bir kısmı güncelleniyordur

  • AWS DNS'i gerçekten de böyle çalışıyor. Route53, resource record set (RRSet) düzeyinde çalışır ve health check ya da gecikme tabanlı seçim mantığıyla uygun seti döndürür
  • CDN'ler de benzer şekilde çalışır. Sistem metriklerini toplayıp ağ bazında en uygun PoP'u hesaplarlar. bunny.net SmartEdge bunun iyi bir örneği
  • Ben de S3 üzerinde test ettim; birkaç saniye içinde yüzlerce farklı IP aldım. Tek bir bölgede bile bu kadar çeşitlilik var

• Bug'lar her zaman vardır. Biçimsel doğrulama (formal verification) zordur ve düşük olasılıklı bug'lar ancak yıllar sonra ortaya çıkabilir.
  Bu yüzden sistemlerin mutlaka arızalanacağını varsaymalı ve zararı sınırlayan yapılar tasarlamalısınız. Hücre tabanlı mimari, kademeli rollout ve izole zone'lar bunun örnekleri.
  AWS de hücre tabanlı yaklaşımı deniyor ama özellikle us-east-1'de eski çapraz bağımlılıklar hâlâ duruyor. Uzun vadede bölgeler tamamen bağımsız olacak şekilde tasarlanmalı.
  Bu tür işler üst düzey yönetici desteği olmadan ilerlemez ama hissedar açısından şirketin varlığını riske atan unsurları azaltan temel bir yatırımdır

• Raporda UTC yerine PT saat dilimi kullanılması şaşırtıcıydı

  • Bu yüzden “epoch fail?” diye şaka yapılacak kadar ilginç ama müşterilerin çoğu ABD merkezliyse PT daha sezgisel olabilir
  • Belki de gece müdahalesinin zorluğunu vurgulamak istemişlerdir

• endpoint başına sürüm yönetimi ya da 2PC, tek writer lease gibi örüntülerin olmaması şaşırtıcıydı. Yine de AWS'nin bunu bu kadar şeffaf biçimde paylaşmasını takdir ediyorum

  • Aslında DNS değişiklik API'si CAS yapıyor ama birden fazla asenkron writer mantıksal bir sıralama olmadan yarışınca sorun çıkıyor. Sıralamayı serileştirmek için zone serial ya da sentinel record kullanılmalıydı

• Bana göre bu olayın doğrudan nedeni, DynamoDB DNS yönetim sistemindeki gizli bir race condition'dı. Eski plan en güncel planın üzerine yazdı ve bölgesel endpoint'in DNS kayıtları boş kaldı

  • Ama “kök neden” kavramına dikkat etmek gerekir. Bu olay bir metastable collapse idi ve asıl mesele kurtarma prosedürünün (runbook) olmamasıydı.
    Referans: How Complex Systems Fail