AWS, Avrupa egemen bulutunu kendi ağından kopardı: Bu tatbikat kendi sistemlerimiz hakkında ne söylüyor?

Bulut dünyasında "egemenlik" (sovereignty) son iki yılın en çok konuşulan kavramlarından biri. Ama çoğu zaman sözleşmeler, hukuki yapılar ve pazarlama sunumları üzerinden konuşuluyor. AWS ise bu ay farklı bir yol seçti: European Sovereign Cloud'u 24 Ekim 2026 Cumartesi günü birkaç saatliğine AWS'nin küresel omurga ağından koparıp gerçekten bağımsız çalışabildiğini göstermeyi planladığını duyurdu.

Bu yazıda tatbikatın ne olduğunu, neyi kanıtlayıp neyi kanıtlamadığını ve asıl önemlisi, bizim kendi altyapılarımız için ne anlama geldiğini konuşalım.

Ne yapıldı?

AWS European Sovereign Cloud, Ocak 2026'da genel kullanıma açılmıştı. İlk bölgesi Almanya'nın Brandenburg eyaletinde, bölge kodu eusc-de-east-1. En önemli teknik ayrıntı şu: Bu bulut ayrı bir partition olarak çalışıyor (aws-eusc). Yani kendine ait IAM'i, faturalandırması, konsolu ve endpoint'leri var; diğer AWS bölgeleriyle VPC peering veya Transit Gateway peering gibi partition'lar arası özellikler kullanılamıyor.

AWS Security Blog'daki duyuruya göre tatbikatta iki şey devre dışı bırakılıyor:

• AWS Global Network bağlantısı: Normalde AWS'nin operasyonel trafiğini taşıyan özel omurga ağı kesiliyor. Bu trafik, Avrupa'daki internet servis sağlayıcılarından alınan özel bağlantılar üzerinden genel internete yönlendiriliyor.
• Kontrollü veri aktarım sistemi: AB dışına sınırlı operasyonel veri gönderen, kaynak kod aynalama ve yazılım güncellemelerini içeri alan ayrı bir sistem tamamen kapatılıyor.

Tatbikatı yalnızca AB'de yaşayan çalışanlardan oluşan operasyon ekibi, egemen bulutun kendi donanım ve yazılımıyla yürütüyor. AWS, egemen bulutta, diğer bölgelerde ve Direct Connect bağlantılarında hizmet erişilebilirliğinin etkilenmeyeceğini söylüyor. Yalnızca başlangıçta ve bitişte, rotalar yeniden yakınsarken kısa bağlantı kesintileri yaşanabileceği belirtilmiş.

Şirket, sonuçları tatbikat sonrasında müşteriler ve düzenleyicilerle paylaşacağını açıkladı. Bu yazı hazırlanırken kamuya açık bir sonuç raporu henüz yayımlanmamıştı.

Neden önemli?

İlk bakışta bu, Avrupa'daki kamu kurumlarını ve bankaları ikna etmeye yönelik bir gösteri gibi duruyor. Kısmen öyle de. AWS, tatbikatın AB Komisyonu'nun Cloud Sovereignty Framework'ü ve Almanya'daki BSI'nin C3A kriterleriyle uyumlu olacak şekilde tasarlandığını söylüyor, ama bir sertifika iddiasında bulunmuyor.

Bence asıl ilginç olan, bir hyperscaler'ın kendi bölgesini bilerek dünyadan koparmayı bir mühendislik testi olarak kamuya açık şekilde yapması. Bulut sağlayıcılarının büyük kesintilerinde sık sık aynı hikâyeyi dinledik: Bir bölgedeki sorun, o bölgeye bağlı "küresel" bir servis yüzünden başka yerleri de etkiledi. Egemen bir bölgenin bu tür gizli bağımlılıklardan arınmış olduğunu göstermek, aslında dayanıklılık (resilience) iddiası da demek.

Zamanlama da dikkat çekici. 20 Ekim'de Google Cloud'un Londra bölgesinde (europe-west2), tek bir erişilebilirlik bölgesini etkileyen ve üçüncü taraf bir tesisteki güç olayından kaynaklanan kesinti, Revolut başta olmak üzere bazı bankaların dijital hizmetlerini aksattı. İngiltere ve AB düzenleyicileri hemen bilgi istedi. Kısacası düzenleyiciler artık "bulutunuz ne kadar bağımsız ve dayanıklı?" sorusunu kanıt isteyerek soruyor.

Neyi kanıtlamıyor?

InfoQ'nun derlediği yorumlarda öne çıkan eleştiriler, bu tatbikatı doğru okumak için önemli:

• Teknik bağımsızlık, hukuki bağımsızlık değil. AWS'nin ana şirketi ABD'de. Birkaç saatlik bir kopuş, hukuki yetki alanı tartışmalarını çözmüyor. Bunu AWS de zaten iddia etmiyor.
• Birkaç saat yeterli mi? Bir yorumcunun haklı sorusu: Sertifikalar, token'lar ve lisanslar dış bir kontrol düzlemine bağlıysa, bir bölge kaç gün sonra sorun yaşamaya başlar? Saatler ile haftalar arasında büyük fark var.
• Küresel servisler belirsiz. Duyuru; DNS, IAM gibi küresel nitelikteki bileşenlerin kopuş sırasında nasıl davrandığını ayrıntılı açıklamıyor.
• Testi yapan da puanlayan da AWS. Bağımsız bir doğrulama yok; sonuçlar AWS'nin kendi raporuna dayanacak.

Pratikte bizim için anlamı

Çoğumuz egemen bir bulut bölgesinde çalışmıyoruz. Ama tatbikatın arkasındaki soru herkes için geçerli: Sistemimiz, dışarıdaki bir bağımlılık kesildiğinde ne yapar?

1. Gizli bağımlılıklarınızın haritasını çıkarın

Uygulamanızın "Frankfurt'ta çalışıyor" olması, tüm bağımlılıklarının orada olduğu anlamına gelmiyor. Sık rastlanan örnekler:

• Kimlik doğrulama için kullanılan harici bir SaaS (Auth0, Okta vb.)
• Başka bölgede duran bir container registry veya paket deposu
• Sertifika yenileme, lisans doğrulama ve feature flag servisleri
• Kod içinde sabitlenmiş bir bölge veya global endpoint

Basit bir tarama bile çoğu zaman sürpriz çıkarır:

grep -rnE "us-east-1|arn:aws:|\.amazonaws\.com" infra/ src/ config/

2. Partition'ı varsayımlarınızdan çıkarın

Egemen bulut ayrı bir partition olduğu için arn:aws:... şeklinde sabitlenmiş ARN'ler orada çalışmaz. Aynı durum AWS'nin Çin ve GovCloud partition'ları için de geçerli. Terraform'da data "aws_partition", CloudFormation'da ${AWS::Partition} kullanmak, kodunuzu yarın başka bir ortama taşımayı ciddi ölçüde kolaylaştırır.

3. Kopuşu kendiniz test edin

AWS'nin yaptığının küçük ölçekli bir versiyonunu staging ortamında yapabilirsiniz: Bir bağımlılığa giden trafiği güvenlik grubu veya ağ politikasıyla kesin ve neyin bozulduğunu izleyin. Burada önemli olan yalnızca "ayakta kaldı mı?" değil, ne kadar süre ayakta kaldığı. Önbellekteki token'ların ve sertifikaların ömrü, gerçek dayanıklılık sınırınızı belirler.

4. Tek erişilebilirlik bölgesi de bir bağımlılıktır

Google'ın Londra kesintisi tek bir zonla sınırlıydı, ama bazı kurumların hizmetleri yine de aksadı. Çok bölgeli (multi-AZ) mimari kâğıt üzerinde vardır ama veritabanı, kuyruk veya durum bilgisi tek zonda kalmışsa pratikte işe yaramaz.

Sonuç

AWS'nin tatbikatı, egemenlik tartışmasını slaytlardan çıkarıp ölçülebilir bir mühendislik testine çevirmesi açısından değerli. Sonuç raporunun ne kadar ayrıntılı olacağını ve özellikle küresel servislerin nasıl ele alındığını göreceğiz. Bizim açımızdan ders ise daha basit: Bağımsızlık ve dayanıklılık bir mimari diyagramla değil, bir şeyi bilerek kapatıp neyin bozulduğunu görerek kanıtlanır. Bunu düzenli olarak yapmayan ekipler, gizli bağımlılıklarını genellikle en kötü anda, gerçek bir kesinti sırasında öğreniyor.