Orta Doğu’da bulut altyapısı deyince çoğu kişinin aklına ilk olarak hız, ölçek ve “nasıl olsa her şey yedekli” rahatlığı geliyor. Ama işin aslı biraz daha sert. Bölgedeki jeopolitik gerilim, özellikle de İran bağlantılı İHA saldırıları gibi fiziksel tehditler devreye girdiğinde, o parlak ekranların arkasındaki veri merkezleri bir anda gündemin tam ortasına oturuyor. AWS’nin Orta Doğu operasyonlarında yaşanan sıkıntılar da tam bu noktada önem kazanıyor — valla güzel iş çıkarmışlar —
Açık konuşayım — ben bu tür haberleri okuduğumda önce yazılım tarafını düşünürüm. Sonra birden kendimi enerji hatlarına, soğutma sistemlerine ve yedekli ağ omurgalarına bakarken buluyorum. Çünkü bulut dediğimiz şey sadece “sunucu kiralama” değil; elektrikten fiziksel güvenliğe kadar uzanan, her halkası birbirine kenetlenmiş koca bir zincir. Bir halka kopunca mesele büyüyor. Hem de beklediğinizden çok daha hızlı.
Peki neden?
Geçen yıl 2025’in Kasım ayında, Dubai’de çalışan bir ekip arkadaşımla yaptığım sohbeti hâlâ hatırlıyorum. Bir fintech projesinde bölgesel gecikme sorunlarını tartışıyorduk; adam bana “Kağıt üstünde multi-region tamam ama gerçek hayatta fiber kesilirse tablo değişiyor” demişti. İşte tam da o cümle bugün doğrulanıyor. Bulut var diye dünya güllük gülistanlık olmuyor.
Asıl mesele: Bulutun zayıf karnı bazen beton oluyor
Bak şimdi. Bulut hizmetleri genelde soyut anlatılır; sanki her şey havada duruyormuş gibi bir his var. Oysa veri merkezi dediğin yer betonarme bina, jeneratör, UPS, soğutma sistemi ve birden fazla güvenlik katmanından oluşan, çok somut ve elle tutulur bir yapı. İHA saldırıları gibi olaylar bu fiziksel katmana dokunduğunda AWS’nin ya da başka herhangi bir sağlayıcının işi bir anda zorlaşıyor.
Durun, bir saniye.
Şöyle söyleyeyim, Kritik nokta şu: Bir servis çöktüğünde yalnızca tek müşteri etkilenmiyor (yanlış duymadınız). Ödeme sistemleri, lojistik panelleri, API kapıları ve (belki yanılıyorum ama) hatta müşteri destek araçları aynı anda tökezleyebiliyor. Yani problem “site açılmadı” değil. Arkasında domino taşı gibi dizilmiş onlarca bağımlılık var.
Şöyle söyleyeyim, Ben 2024 yazında İstanbul’da küçük bir SaaS firmasının felaket kurtarma planını incelerken bunu net gördüm. Ekip sanıyordu ki iki farklı bölgede sunucu tutmak yeterli olacak. Değildi tabii — — ki bu tartışılır — DNS yönlendirmesi gecikince kullanıcılar eski IP’ye dönüyordu, log toplama sistemi ayrı dert çıkarıyordu, alarm kuralları ise bildirim yağmuruna dönüşmüştü. Yedeklilik güzel laf. Ama test edilmediyse yarım kalıyor, hepsi bu.
Durun, bir saniye.
Bulutta en pahalı hata çoğu zaman kapasite eksikliği değil… yanlış varsayım oluyor.
AWS neden bu kadar kritik?
AWS Orta Doğu’da yalnızca barındırma vermiyor. Bankacılıktan medya akışına kadar pek çok — ki bu tartışılır — sektör için fiilen omurga görevi görüyor; böyle olunca bölgede yaşanan her sarsıntı zincirleme etki yaratıyor. Mesela düşük gecikme isteyen uygulamalar için Orta Doğu lokasyonları cazip olduğundan şirketler veriyi merkeze yakın tutmayı seçiyor.
Ama burada ince bir denge var. Veriyi kullanıcıya yaklaştırdıkça performans artıyor — tamam, bunu herkes biliyor. Gel gelelim siyasi risk ya da fiziksel güvenlik riski de o masaya geliyor. Küçük startup’lar çoğu zaman bunu göz ardı ediyor çünkü ilk hedef hızlı çıkmak oluyor; anlaşılır bir şey bu (inanın bana). Enterprise tarafta ise mevzu daha ağır: regülasyon, uyumluluk ve sözleşmesel SLA baskısı işi iyice sıkıştırıyor.
İnanın, Bunu kendi editör masamda da hissettim desem yeridir. 2026 Şubat’ında netmerkezi.com için hazırladığım başka bir içerikte kurumsal erişim katmanlarını incelerken AWS ile benzer mimariler arasında gidip geldim durdum — özellikle gateway mantığı kafamı epey meşgul etti. Kağıt üzerinde temiz duran tasarımlar saha şartlarında bambaşka davranabiliyor. Hani ne farkı var diyorsunuz, değil mi? O meşhur “test ortamında çalıştı” cümlesi var ya, burada pek geçerli olmuyor.
Küçük ekipler ne yapmalı?
Garip gelecek ama, En büyük tuzak şu: aşırı karmaşa kurmak. Her şeyi üç bölgeye yaymaya kalkınca maliyet uçuyor, yönetim zorlaşıyor ve ekip gece yarısı alarm peşinde koşuyor. Daha sade ama iyi test edilmiş yedekleme planı çoğu zaman çok daha faydalı.
Mesela temel yaklaşım şu olabilir: ana bölge + ikinci bölge + düzenli geri dönüş testi + otomatik failover senaryosu + açık iletişim planı. Basit görünüyor. İş görüyor mu? Çoğunlukla evet. Bu konuyla ilgili İran’ın Kripto Ticareti: Hürmüz’den Geçen Yeni Yol yazımıza da göz atmanızı tavsiye ederim.
Kurumsal yapılarda tablo nasıl?
Enterprise tarafta durum farklı çünkü tek hedef süreklilik değil; denetlenebilirlik de gerekiyor. Bu yüzden loglama politikaları, kimlik erişimi, şifreleme anahtarları ve servis sınırları baştan tasarlanıyor. Aksi halde kriz anında teknik sorun çözülse bile uyumluluk tarafında yeni dertler çıkıyor.
Büyük kurumlarda ben olsam şunu sorardım: Veri nerede tutuluyor? Kim erişebiliyor? Bölgesel kesintide trafik hangi sırayla taşınacak? Ve en önemlisi — bunu gerçekten son altı ay içinde tatbik ettiniz mi?
Neleri değiştirmek gerekir?
Böyle dönemlerde ilk bakılması gereken şeylerden biri trafik yönlendirme politikaları. Kullanıcıyı tek noktaya bağlayan yapı artık riskli olduğu kesin. DNS TTL değerlerini düşürmek bazen hayat kurtarıyor; bazen de gereksiz sorgu yükü yaratıyor. Sihir yok, yani. Bu konuyla ilgili Huawei ICT Day 2026: Dijital Dönüşümün Nabzı yazımıza da göz atmanızı tavsiye ederim.
Bir diğer konu gözlemleme araçları. Eğer alarm sistemi doğru kurulmadıysa sorun çıktığını siz değil müşteriniz söylüyor olur. Bu benim en sevmediğim senaryo. 2023’te Ankara’daki orta ölçekli bir e-ticaret projesinde aynısını yaşamıştık; ödeme servisi durmuştu ama dashboard hâlâ yeşildi. Sonra ne oldu dersiniz? Kullanıcı şikâyeti gelmeden fark edemediler (en azından benim deneyimim böyle) Bu konuyla ilgili X’te otomatik çeviri nasıl kapatılır? Gizli ayar rehberi yazımıza da göz atmanızı tavsiye ederim.
| Konu | Acil Etki | Daha Sağlam Yaklaşım |
|---|---|---|
| Trafik yönlendirme | Bölgesel kesintiyle site düşer | Çoklu bölge + otomatik failover |
| Gözlemleme | Sorun geç fark edilir | Metrik + log + trace birlikte izlenir |
| Veri replikasyonu | Kayıp riski artar | Zamanlanmış senkronizasyon ve test geri dönüşü |
| Erişim kontrolü | Krizde yetki karışır | Sıkı IAM politikaları ve acil durum rolleri |
Peki fayda neydi, dezavantaj ne?
Size bir şey söyleyeyim, AWS gibi devlerin en güçlü yani ölçeklenebilirlik. Trafiğiniz patladığında kaynak eklemek nispeten kolay. Ama işin kötü tarafı — küresel markanın gücü sizi tamamen korumaz. Bölgesel fiziksel risk varsa servis katmanı kadar altyapının bulunduğu coğrafya da belirleyici oluyor. Bu kısmı insanlar bazen unutuyor (şaşırtıcı ama gerçek)
- Avantaj: Hızlı ölçeklenme ve hazır servis ekosistemi
- Avantaj: Çoklu bölge tasarımıyla yüksek dayanıklılık ihtimali
- Dezavantaj: Bölgesel jeopolitik risklerin sıfırlanamaması
- Dezavantaj: Karmaşık mimarinin işletme maliyetini artırması
- Dikkat: Test edilmeyen yedeklilik gerçek yedeklilik sayılmaz!
Bakın şimdi, bazı ekipler tüm umudunu sağlayıcıya bırakıyor. “AWS büyük şirket kardeşim, halleder” diye düşünüyorlar. Evet, halleder belki. Ama sizin mimari yanlışsa o büyük şirket size sihir yapmaz.
Benzer haberlere bakınca Claude Code Gateway: Kurumsal Erişimde Fark Yaratan Katman, kurumsal tarafta erişim katmanlarının ne kadar önemli olduğunu güzel gösteriyor aslında.
Hani, Ha bu arada LLM maliyeti neden görünmez olur? OpenTelemetry ile çözüm, gözlemlemenin niye lüks değil ihtiyaç olduğunu anlatan iyi örneklerden biri.
Bir dakika, şunu da ekleyeyim: G42’nin Sessiz Hamlesi: AI Kampüsü Yolda Kalıyor, bölgesel teknoloji yatırımlarının siyasetten bağımsız olmadığını görmek için fena olmayan bir referans.
Neyin peşinden koşmalı?
E tabi herkes hemen “ne yapmalıyız?” sorusuna geliyor. Cevap basit değil ama birkaç sağlam ilke var. Önce bağımlılık haritasını çıkarın — hangi servis hangi bölgede çalışıyor, hangi API dış ülkeye gidiyor, hangi DNS kaydı tek noktaya bağlı? Bunlar cevaplanmadan alınacak aksiyon yarım kalır.
Kriz anında işe yarayan pratik adımlar
# Basit felaket anı kontrol listesi
1) Trafiği alternatif bölgeye çevir
2) DNS cache sürelerini kontrol et
3) Kritik mikroservisleri önceliklendir
4) Log ve metrik akışını doğrula
5) Müşteriye durum sayfasıyla bilgi ver
6) Geri dönüş testini kayıt altına al
}Sıkça Sorulan Sorular
AWS Orta Doğu’daki kesintilerden tamamen korunabilir mi?
Tamamen korunmak zor dersem abartmış olmam. Çoklu bölge tasarımı riski azaltır ama fiziksel tehditleri sıfırlamaz.
Böyle durumlarda ilk ne yapılmalı?
Hani, Trafik yönlendirme ve kritik servis öncelikleri hemen kontrol edilmeli. Ardından loglar ile sağlık kontrolleri eşleştirilmeli.
Küçük şirketler pahalı DR planlarına ihtiyaç duyar mı?
Evet,ama hepsi devasa olmak zorunda değil. Basit yedekleme,geri dönüş testi ve net iletişim akışı çoğu küçük ekip için yeterince iyi başlangıçtır.
Bölgesel savaş haberleri bulutu gerçekten etkiler mi?
Bence, Etkiler,çünkü veri merkezi sadece dijital değil fiziksel bir yapıdır. Elektrik,soğutma,ulaşım ve güvenlik zinciri bozulursa hizmet kalitesi hemen düşer.
Kaynaklar ve İleri Okuma
AWS News BloguAWS Resmi DokümantasyonuAWS Global Infrastructure Sayfası
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
