AWS CloudFront kesintisi CDN mimarinize ne öğretiyor?

Kesintide tam olarak ne oldu?

CloudFront, AWS'nin içerik dağıtım ağı; dünyaya yayılmış uç noktalarda (edge) durur, kullanıcıdan gelen isteği karşılar ve önbelleğinde yoksa arkadaki kaynağa — origin'e — gider. VPC Origins ise 2024 sonunda gelen bir özellik: origin'inizin herkese açık bir adrese sahip olma zorunluluğunu kaldırıyor. Uygulama sunucunuz ya da yük dengeleyiciniz özel bir alt ağda, internete kapalı durabiliyor; CloudFront ona doğrudan VPC içinden ulaşıyor. Güvenlik açısından oldukça mantıklı bir tasarım: arka uç yüzeyiniz internete hiç çıkmıyor.

Kırılan da tam olarak bu bağlantı yolu oldu. AWS'nin açıklamasına göre özel VPC origin'lerine giden bağlantıları yöneten filodaki bir iç sınır (internal constraint) doldu; bu sınıra ulaşıldığında yönlendirme yapılandırmasını ağ işlemcilerine dağıtan sistem güncel veriyi doğru yükleyemedi. Sonuç: CloudFront isteği alıyor ama arkadaki origin'e nasıl gideceğini bilemiyor ve istemciye 5xx dönüyor. Kaydadeğer ayrıntı, kök nedenin Frankfurt (eu-central-1) bölgesindeki tek bir kullanılabilirlik alanına (euc1-az2) kadar izlenmiş olması — ama etkinin dünya geneline yayılması.

07:45  ilk 5xx dalgası — VPC Origins'e giden istekler düşüyor
09:21  AWS doğruluyor: yalnızca VPC Origins etkileniyor
09:57  kök neden: yapılandırma yükleme hatası
11:18  tam kurtarma

# toplam etki: 3 sa 33 dk
# diğer origin tipleri (S3, genel ALB) etkilenmedi

Tek bir özellik neden bu kadar geniş bir alanı durdurdu?

Buradaki asıl ders "AWS çöktü" değil. Etkilenen servislerin listesine bakınca daha ilginç bir şey görünüyor: bir kimlik sağlayıcı (Frontegg), bir AI platformu (Hugging Face), bir veritabanı servisi (TigerData), iki eğitim platformu (Canvas ve Blackboard), bir doküman aracı (Coda), bir ağ donanımı üreticisi (Ubiquiti). Ortak yanları yok — ortak bağımlılıkları var. Hepsi trafiğini aynı uç katmanından, o katmanın da aynı görece yeni özelliğinden geçiriyordu.

Kırılanın veri düzlemi (data plane) değil control plane olması bu yüzden kritik. Uç sunucular ayakta, ağ sağlıklı, origin'ler çalışıyordu; bozulan tek şey "hangi isteği nereye yönlendireceğim" bilgisini dağıtan mekanizmaydı. Yapılandırma dağıtımı doğası gereği merkezîdir ve küreseldir — tam da bu yüzden bir bölgedeki hata dakikalar içinde her yere yayılabilir. 2025'in büyük bulut kesintilerinde de tekrar eden desen buydu: hatalı ya da eksik bir yapılandırma değişikliğinin küresel olarak yayılması. Bulut altyapısında yedeklilik denince akla önce sunucu ve bölge gelir; oysa pratikte en kırılgan bağımlılık çoğu zaman yapılandırmanın kendisidir.

Yeni özellikleri benimserken neye dikkat etmeli?

VPC Origins iyi bir özellik ve kullanmamak için bir sebep değil bu kesinti. Ama olgunluk farkını hatırlatıyor: CloudFront'un S3 ya da genel yük dengeleyici origin'leri yıllardır milyonlarca dağıtımda yıpranmış yollar. VPC Origins ise 2024 sonunda geldi ve bu kesintide etkilenen tek origin tipi oldu — diğerlerini kullananlar günü fark etmeden geçirdi.

Bu, yeni özellikleri kritik yola koyarken bir soru sormayı gerektiriyor: bu özellik bozulursa geri dönebileceğim bir yol var mı? CloudFront örneğinde vardı — kesinti sırasında origin tipini geçici olarak değiştiren ekipler servislerini ayağa kaldırabildi (AWS kurtarma sonrası bu değişikliklerin güvenle geri alınabileceğini duyurdu). Ancak bu ancak önceden düşünülmüşse dakikalar içinde yapılabilen bir hamledir; kesinti anında ilk kez denenen bir şeyse saatler alır.

CDN katmanınızı nasıl dayanıklı kurarsınız?

Kendi altyapınızda bu tür bir günü daha az acılı geçirmek için üzerinde çalışabileceğiniz birkaç somut başlık var:

• Uç katmanı atlayan bir kaçış yolu tanımlayın — origin'inize doğrudan (ya da ikinci bir uç sağlayıcı üzerinden) giden, DNS düzeyinde devreye alınabilen bir yol hazır dursun. Bunun için DNS kayıtlarınızın TTL değerlerini önceden makul seviyeye çekmek gerekir; kesinti anında 24 saatlik bir TTL'i kısaltmak işe yaramaz.
• Yapılandırma değişikliğini kod gibi yönetin — origin tipini, davranışları ve önbellek kurallarını elle panelden değil sürüm kontrollü tanımlardan yönetin. Geri alma (rollback) bir tıklama olduğunda kriz anındaki karar süresi dakikalara iner.
• İzlemeyi dışarıdan yapın — sağlık kontrolleriniz yalnızca uygulama sunucusuna bakıyorsa bu kesintide her şey yeşil görünürdü. Gerçek kullanıcının gittiği yoldan, dış bir noktadan ölçen kontroller şart. Gözlemlenebilirlik tarafında uç katmanın döndürdüğü durum kodlarını ayrı bir sinyal olarak takip edin.
• Bozulmayı zarif kılın — statik varlıkları uzun süreli önbellekle, kritik olmayan çağrıları zaman aşımıyla sınırlayın ve tam çalışmayan bir sayfa yerine kısıtlı ama açık bir sayfa gösterin. Sekiz servisin aynı anda tamamen düşmesi ile yavaşlaması arasındaki fark genelde bu ayrıntılarda saklıdır.

Bu kesintiden kim ne kadar etkilendi?

Dikkat çeken bir nokta daha var: Canvas (Instructure) ve Blackboard, Ekim 2025'teki büyük AWS kesintisinde de aynı şekilde etkilenmişti. Aynı servislerin aynı desenle iki kez düşmesi, kesintinin bulut sağlayıcının bir talihsizliği olmaktan çok, o servislerin mimarisinde çözülmemiş bir bağımlılığa işaret ettiğini gösteriyor. Kesintiler kaçınılmazdır; tekrar eden kesintiler ise bir tasarım tercihidir.

Buradaki pratik ölçüt basit: son 12 ayın kesintilerinde siz de listede miydiniz? Eğer öyleyse, o kesintiden sonra mimaride ne değişti sorusunun somut bir cevabı olmalı. Felaket kurtarma planlarının çoğu veri kaybına odaklanır; oysa modern kesintilerin büyük bölümü veri kaybı değil, erişilemezlik üretir — ve bu senaryonun tatbikatı ayrıca yapılmalıdır.

Peki geriye ne kalıyor?

Üç buçuk saat, bir sabahı kaybetmek için yeterince uzun ama altyapı tarihinde iz bırakacak kadar değil. Kalıcı olan, kesintinin gösterdiği şekil: internetin büyük bölümü birkaç uç katmanın arkasında duruyor ve bu katmanlardaki tek bir özelliğin yapılandırma hatası, aralarında hiçbir ilişki olmayan onlarca servisi aynı dakikada durdurabiliyor. Bunu tersine çevirmek elimizde değil — ama kendi sistemimizin o katmana ne kadar sıkı bağlandığını seçmek elimizde.

Konunun temellerine yakından bakmak isterseniz Bilgi Merkezi · CDN & Edge, Cloud & Altyapı ve Yedekleme & Felaket Kurtarma rehberlerimize göz atabilirsiniz. Kesintinin ayrıntıları için The Register'ın haberine bakabilirsiniz.