Son AWS kesintisinden ne öğrenebiliriz ve bu dersleri kendi altyapımıza nasıl uygulayabiliriz?
Ne oldu?
Açık 20 Ekim 2025AWS, internette (ve sosyal medyada) yayılan ve Zoom, Microsoft Teams, Slack ve Atlassian gibi yaygın olarak kullanılan hizmetleri etkileyen büyük bir kesinti yaşadı. Sorun tek bir veri merkezinden veya müşteri iş yükünden değil, EC2 bulut sunucuları, DynamoDB tabloları ve IAM rolleri gibi kaynakların nasıl çalıştığını koordine eden yönetim katmanı olan AWS kontrol düzleminden kaynaklanıyordu.
İlk tetikleyicinin, ABD-Doğu-1 bölgesindeki DynamoDB API uç noktası etrafındaki bir DNS hatası olduğu görülüyor ve buna ağ yük dengeleyicilerini izleyen alt sistemdeki bir arıza da ekleniyor. Bu sağlık izleme hizmetleri aynı zamanda ABD-Doğu-1’de de çalıştığından AWS, alt sistemi geri yüklerken yeni EC2 bulut sunucusu başlatmalarını kısıtladı.
AWS, bölgelerini bağımsız güç ve soğutmaya sahip izole veri merkezleri kümeleri olarak pazarlasa da bu olay, temel kontrol düzlemi işlevlerinin merkezi kaldığını ve küresel olarak art arda yayılabilen gizli bağımlılıklar yarattığını gösterdi.
Temel Neden: Tek Bölgeli Kontrol Düzlemi
Analistler, US-EAST-1’in AWS’nin bir dizi küresel hizmeti destekleyen ortak kontrol düzlemine ev sahipliği yaptığını hemen belirledi. Avrupa veya Asya’da çalışan iş yükleri aslında ABD-DOĞU-1’e veya ABD-Doğu-1’e giden API çağrılarına dayanıyor; dolayısıyla buradaki başarısızlığın küresel sonuçları oldu.
Bölgenin DNS ve sağlık kontrolü alt sistemleri başarısız olduğunda, bu kontrol düzlemi çağrıları dünya çapında durdu. Sonuçta, diğer bölgeler teknik olarak “sağlıklı” olmasına rağmen EC2 lansmanlarında, yapılandırma güncellemelerinde ve kimlik doğrulamada küresel bir yavaşlama oldu.
AWS’nin kendi tasarım kılavuzu, müşterilerin esneklik için iş yüklerini erişilebilirlik alanlarına dağıtmasını teşvik eder, ancak müşteriye yönelik bu esneklik mekanizmaları sonuçta aynı merkezi kontrol düzlemine bağlıdır. Başka bir deyişle, veri düzlemi yalıtımı tasarlandığı gibi çalıştı ancak kontrol düzlemi yalıtımı işe yaramadı.
Bu model sadece AWS’de değil, daha önce de ortaya çıkmıştı. Cloudflare, Microsoft ve Google’ın tümü, küresel olarak yayılan kontrol düzlemi veya yapılandırma hatalarının tetiklediği kesintilerden muzdaripti. Buradan alınacak ders, modern dağıtılmış sistemlerde kontrol düzlemi kırılganlığının tek bir başarısızlık noktası haline gelebileceğidir.
[Image: Timeline of Outages]
Altyapı Mimarları İçin Öğrenilen Dersler
AWS’deki gibi büyük kesintileri anlamak ve analiz etmek altyapı mühendisleri için çok önemlidir. Her olay, tasarım varsayımları ile gerçek dünyadaki karmaşıklık arasındaki boşlukları ortaya çıkarır, aksi takdirde fark edilmeyebilecek zayıf noktaları ortaya çıkarır ve sonuçta hizmet kullanılabilirliğini etkileyebilir. Mimarlar neyin başarısız olduğunu, neden başarısız olduğunu ve kurtarmanın nasıl ilerlediğini inceleyerek altyapılarını ve sistemlerini hataya daha dayanıklı ve dayanıklı olacak şekilde geliştirebilirler. Bu sürekli öğrenme zihniyeti, bir sonraki kesinti meydana geldiğinde kullanıcılar ve iş operasyonları üzerindeki etkinin en aza indirilmesini sağlar. Peki buradaki temel dersler nelerdir?
1. Gerçek anlamda çok bölgeli, aktif-aktif operasyon için tasarım. Kontrol trafiği ona ulaşamıyorsa, bekleme bölgesi yeterli değildir. Bir kaynağın veya bölgenin kaybının hizmeti devre dışı bırakmaması için etkin-etkin bir yapılandırmada çalıştırın.
2. Tek bölgeli kontrol düzlemlerinden kaçının: Şimdi bunu söylemek açık görünüyor, ancak yapılandırma ve meta veri hizmetleri ya tamamen yerel olmalı ya da küresel olarak kopyalanmalıdır. Koordinasyon için tek bir bölgenin DNS’sine, yük dengeleyicilerine veya diğer sistemlere bağımlı olan herhangi bir sistem, küresel bir risk oluşturur.
3. Kontrol düzlemini veri düzleminden ayırın: AWS olayı kontrol düzleminde başladı ancak hızla veri düzlemine yayıldı. Sistemleri, çalışma zamanı trafiğinin yapılandırma veya provizyon sistemlerinden bağımsız olarak devam edebileceği şekilde tasarlayın.
4. DNS ve önbellekleme katmanlarını dağıtın: Uzun TTL’lere sahip çok sağlayıcılı DNS, kontrol düzlemiyle ilgili çözümleme hatalarının etkisini azaltabilir. Önbelleğe alınmış veya bölgesel okuma kopyaları, kaynağa ulaşılamadığında uygulamaları kısmen işlevsel tutar.
5. Devre kesicileri ve bölme izolasyonunu uygulayın: Sistemler hızlı ve sorunsuz bir şekilde arızalanmalıdır. Devre kesiciler, arızalı bir uç noktaya zarar vermek yerine işlevselliği yeniden yönlendirebilir veya azaltabilir. Bölme yalıtımı, arızaların bileşenler arasında yayılmasını sınırlar.
6. Arıza senaryolarını sürekli olarak test edin: Düzenli “kaos” testleri, yedeklilik, DNS yük devretme ve RTO/RPO hedeflerinin pratikte çalıştığını doğrular. AWS’nin kendi Resilience Hub’ı bu testleri teşvik eder ancak alınan ders tüm bulut veya hibrit dağıtımlar için geçerlidir. Örnek olarak Netflix’in 2011 yılında tanıttığı Chaos Monkey’i inceleyin.
7. Çoklu bulut veya hibrit esnekliği planlayın: Çoklu kullanılabilirlik bölgesi yedekliliği, kontrol düzlemi sorunlarına karşı koruma sağlamaz. Birden fazla bulut sağlayıcısı arasında dağıtım yapmak veya şirket içi ayak izini minimum düzeyde tutmak, tek bir sağlayıcının yönetim sistemlerine tamamen bağımlı olmayı önler.
8. Kapasiteyi yük devretme mantığından ayırın: AWS, yeni bulut sunucusu lansmanlarını azaltarak dayanıklılık yerine zaman kazandırarak kesintiyi azalttı. İşlemi ikincil bölgelerde önceden ayırın, ancak yük devretme mantığının kontrol düzleminden bağımsız olarak çalıştığından emin olun.
Güvenlik Uç Noktası: Öğrenilen Dersler Uygulamalı
Security Edge mimarisini tasarlarken bu spesifik zorlukların birçoğunu ele almak istedik. Bugün, Wallarm’ın Security Edge’i tasarımı itibariyle bu ilkelerin çoğunu bünyesinde barındırıyor. AWS kesintisinin ortaya çıkardığı tek sağlayıcının kırılganlığını önlemek için özel olarak tasarlandı. Güvenlik Kenarı şunları içerir:
- Aktif-aktif, çoklu bulut mimarisi: Security Edge, AWS, Azure ve diğer sağlayıcılar genelinde etkin-aktif bir yapılandırmada uygulama düğümlerini çalıştırır. Bir sağlayıcıda bozulma yaşanırsa trafik anında yeniden yönlendirilebilir. Bu çoklu bulut dağıtımı, AWS’yi etkileyen tek bölge veya tek sağlayıcı riskini ortadan kaldırır.
- Müşteri altyapısından ayrılmış: Security Edge, müşteri ortamlarına yerleşik bir bileşen olarak değil, yönetilen, bulutta yerel bir güvenlik katmanı olarak çalışır. Filtreleme ve uygulama düğümleri API kenarına yakın konumlandırılmıştır ancak müşterinin kendi veri düzleminden izole edilmiştir. Başka bir deyişle, müşterinin bulutu veya sağlayıcısı arızalansa bile Wallarm koruma katmanı çalışır durumda kalır.
- Otomatik yük devretme ile her zaman açık kullanılabilirlik: Wallarm’ın mimarisi, herhangi bir bulut sağlayıcısından veya CDN’den bağımsız olarak otomatik küresel yük devretme ve yüksek kullanılabilirlik sağlar. Müşteriler, temel altyapı kesintiye uğradığında bile güvenlik sürekliliğinden yararlanır.
- Düşük gecikme süreli, uç noktaya yakın uygulama: Security Edge, filtreleme düğümlerini müşterinin API uç noktalarının yakınına yerleştirerek, derin inceleme ve telemetri sağlarken düşük gecikmeyi korur. Dağıtılmış ayak izi, sağlayıcı kesintisi sırasında bile meşru trafiğin verimli bir şekilde akmaya devam etmesini sağlar.
- API yerel ve protokol uyumlu: Platform, REST, GraphQL, gRPC, Web Sockets ve eski protokolleri destekleyerek dayanıklılığın uyumluluktan ödün vermemesini sağlar.
- Tasarım gereği güvenli. Karşılıklı TLS (mTLS), düzenlemeye tabi endüstriler için gerekli olan tüm düğümler arasında güvenli, kimliği doğrulanmış bağlantılar sağlar.
- Basitleştirilmiş dağıtım ve yönetim: Security Edge bir DNS değişikliği yoluyla sağlandığı için ekiplerin kontrol düzlemi bağımlılıklarını veya altyapı güncellemelerini yönetmesi gerekmez. Müşteri ortamlarında veya belirli bölgelerde kesinti yaşansa bile güvenlik katmanı çalışır durumda kalır.
Daha Geniş Model
AWS şu anda ilgi odağı olabilir ancak sektör geneline baktığımızda neredeyse tüm büyük bulut veya CDN sağlayıcılarının (AWS, Cloudflare, Microsoft, Google) son beş yılda kontrol düzlemiyle ilgili kesintiler yaşadığını görüyoruz. Bunlara nadiren saldırılar neden olur; daha sıklıkla rutin operasyonel değişikliklerden, yanlış yapılandırmalardan veya merkezi hizmet bağımlılıklarından kaynaklanırlar.
Ekim 2025’teki AWS kesintisi, hiçbir bulut sağlayıcının bu durumdan muaf olmadığını gösteriyor. En iyi savunma mimaridir: riski dağıtın, bağımlılıkları ayırın ve zarif bir bozulma için tasarım yapın.
Wallarm’ın Security Edge’inin bu derslerin proaktif olarak nasıl uygulanabileceğini göstermesinden gurur duyuyoruz. API korumasını çoklu bulut, aktif-aktif uç yapısına dönüştürerek kuruluşlar yalnızca saldırılara karşı değil, aynı zamanda en büyük sağlayıcıların bile zaman zaman karşılaştığı altyapı arızalarına karşı da dayanıklılık kazanır.
Sırada Ne Var?
Bu AWS kesintisi ve dayanıklılık mimarisi hakkında derinlemesine bir sohbet için 23 Ekim Perşembe günü Wallarm’ın Saha CTO’su Tim Ebbers’a katılın.