AWS, Azure, Google Cloud: Türkiye’de hangisi mantıklı? (Net rehber)

Türkiye’den bir uygulamayı bulut üzerinde çalıştırırken en kritik mesele, sadece “fiyat” değil; gecikme (latency), veri işleme ve servis uyumluluğu ile yönetim maliyetinin toplamıdır. Türkiye’de kullanıcılarınıza hizmet eden ekipler, AWS, Azure ve Google Cloud arasında seçim yaparken çoğu zaman tek bir kriterle (ör. RAM/CPU fiyatı) hareket eder. Bu rehberde; Türkiye için pratik karar vermenizi sağlayacak şekilde üç bulutu; ağ mimarisi, servis ekosistemi, operasyonel kontrol ve maliyet unsurlarıyla net bir çerçevede karşılaştırıyoruz.

Aşağıdaki tablo, “hangi senaryoda hangisi daha mantıklı?” sorusuna doğrudan cevap vermek için hazırlanmıştır. Ardından, seçim yapmadan önce mutlaka kontrol edilmesi gereken maddeleri ekledim.

Türkiye senaryosu için hızlı seçim haritası

Aşağıdaki eşleştirme, tipik kullanım senaryolarında hangi bulutun daha rasyonel olacağını göstermek içindir. “En iyi” tekil bir cevap yok; seçim, iş yükünüzün doğasına göre şekillenir.

Senaryo	Daha mantıklı başlangıç	Neden (net gerekçe)
Kurumsal entegrasyon + Microsoft ekosistemi (AD/Entra, Windows odaklı süreçler)	Azure	Kurumsal kimlik entegrasyonu, yönetim arayüzleri ve mevcut Microsoft süreçleriyle uyum daha hızlı kurulur.
Gelişmiş veri/analitik ve geniş OSS (open source) ekosistem	Google Cloud	Büyük veri/analitik tarafında servislerin birlikte çalışması sık tercih edilir; altyapı optimizasyonu veri işleme maliyetini etkiler.
Global ölçekte olgun servis ekosistemi + olgun otomasyon	AWS	Servis çeşitliliği ve ekosistem olgunluğu yüksektir; otomasyon (IaC/CI-CD) kurgusu hızlı oturur.
Türkiye’de düşük gecikme şart (kullanıcı odaklı web/app)	Bulut + bölge stratejisi birlikte	Bulutun kendisinden ziyade “bölge seçimi + CDN + mimari” gecikmeyi belirler.
Regülasyon/uyumluluk hassas (log, denetim, şifreleme)	Hepsi, doğru mimariyle	Her üçünün güçlü IAM ve şifreleme araçları var; asıl fark; log toplama/denetim ve politika uygulama disiplininde.
Hızlı MVP + yönetimi minimum tutma	Google Cloud / AWS	Kullanım senaryosuna göre yönetilen servisler (managed services) kurulum eforunu azaltır.
Kurumsal SLA ve operasyonel süreçlerin standardizasyonu	Azure / AWS	Dokümantasyon olgunluğu ve kurumsal yapılandırma kalıplarıyla entegrasyon hızlanır.

Not: Türkiye’de doğrudan “Türkiye içi bölge” her zaman tek başına belirleyici değildir. Uygulama mimarisinde CDN ve cache davranışı doğru kurulduğunda, bölge gecikme etkisi pratikte azalır.

Gecikme (latency) ve kullanıcı deneyimi: sadece bölge değil

Türkiye’den kullanıcıya hizmet eden bir web uygulamasında gecikmeyi etkileyen temel bileşenler şunlardır:

Uygulama katmanı: API sunucusunun bulunduğu bölge ve ölçekleme davranışı
Önbellekleme: CDN (Content Delivery Network) ve cache TTL ayarları
DNS: Kullanılan çözüm (özellikle failover tasarımı)
TLS/HTTP: Sertifika yönetimi, yeniden el sıkışma (TLS handshake) maliyeti

Pratik kontrol: “Gerçek RTT” testi nasıl yapılır?

Her bulutta aynı kodu çalıştırmak pahalı olabilir. Bunun yerine şu yaklaşım uygulanır:

Uygulamanın kritik endpoint’lerini (ör. /health, /login, /search, görsel/JS/CSS dosyaları) belirleyin.
CDN’i devreye alarak statik içerik endpoint’lerinde cache etkisini izleyin.
Sunucu tarafı için uygulama loglarından istek süresi dağılımını (p50/p95/p99) çıkarın.
Aynı ölçümü, farklı saatlerde yapın: özellikle paket kaybı ve yoğunluk kaynaklı anomali yakalanır.

Bu test sonunda şu kararı netleştirin: “Sorun gecikme mi, yoksa CPU/DB darboğazı mı?”

Servis kapsamı: hangisi daha hızlı kurulum sağlar?

AWS, Azure ve Google Cloud arasındaki seçimde “servis çeşitliliği” tek başına yeterli değildir. Önemli olan; seçtiğiniz servislerin beraber çalışırken operasyon yükünü azaltmasıdır.

En sık kullanılan bileşenler ve tipik eşleşmeler

Aşağıdaki maddeler, Türkiye’de en çok kullanılan mimari parçaların mantıksal karşılığıdır:

Kimlik ve erişim: IAM (Identity and Access Management) / rol tabanlı erişim
Ağ: VPC/VNet benzeri izolasyon, güvenlik grupları, private connectivity
Veritabanı: managed PostgreSQL/MySQL, ölçekleme ve yedekleme
Log ve izleme: merkezi log toplama, metrikler, alarm (alert) yönetimi
Otomasyon: Infrastructure as Code (IaC), CI-CD entegrasyonu

Bu noktada karar kriteri şudur: Hangi bulut, sizin mevcut toolchain’inize (CI/CD, izleme, kimlik altyapısı) daha az “çevrim içi araç değişikliği” bindiriyor?

Maliyet: görünür fiyat + gizli operasyon maliyeti

Bulut maliyetini hesaplarken tek yaklaşım “saatlik CPU/RAM” değildir. Türkiye’de operasyon ekibi olan firmalar için toplam maliyeti artıran gizli kalemler şunlardır:

Egress (çıkış) trafiği: Özellikle CDN yanlış kurgulanırsa maliyeti hızla büyütür
Log depolama ve analiz: log retention uzadıkça maliyet artar
Yedekleme/restore: yanlış RPO/RTO hedefleri gereksiz masrafa yol açar
Ölçekleme dalgalanmaları: otomatik ölçekleme hatalı tanımlanırsa kapasite boşa yanar
Şebeke ayarları: NAT/peering benzeri ek bileşenler maliyeti etkiler

Net maliyet formülü (uygulanabilir)

Tek bir teklif/planla karar vermek yerine şu yaklaşımı kullanın:

1) Uygulama için beklenen aylık istek sayısı
2) Ortalama yanıt boyutu (KB/MB)
3) Statik içerik oranı ve CDN cache hit oranı
4) Veritabanı saatlik CPU/IO ihtiyacı
5) Log retention (kaç gün) ve metrik/trace maliyeti

Bu parametrelerle her bulutta aynı mimariyi (benzer kaynaklar + benzer log/retention) kurup “aylık tahmini toplam” çıkarın.

Güvenlik ve uyumluluk: seçimden önce mimariyi yazın

Üç bulut da güvenlik araçlarında güçlüdür; fark genellikle “politika tasarımı ve denetim” tarafında çıkar.

Net güvenlik kontrol listesi

Aşağıdaki başlıklar, herhangi bir bulut seçmeden önce dokümante edilmelidir:

Şifreleme: At-rest ve in-transit (TLS) zorunluluğu
Anahtar yönetimi: Kendi anahtarınız (BYOK) gerekip gerekmediği
IAM politikaları: En az ayrıcalık (least privilege) prensibi
Ağ izolasyonu: Public erişimin azaltılması, private path tercihleri
Loglama: Kritik aksiyonların denetlenebilir olması (kim/ne zaman/neyi yaptı)
Alarm: CPU, disk, anormal istek artışı, hata oranı (error rate) eşiklerinin tanımlanması

Bu maddeler için “hangi bulut daha iyi?” sorusundan önce “hangi bulutta bu politikayı en az eforla standardize ediyorum?” sorusu daha doğru sonuç verir.

Türkiye’de uygulama tasarımı: en çok farkı yaratan 5 karar

Aşağıdaki kararlar, bulut markasından daha çok kullanıcı deneyimini etkiler:

CDN stratejisi: Statik içerik ve cache TTL
DB tasarımı: bağlantı havuzu, indeksler, okuma/yazma ayrımı
Autoscaling: ölçekleme eşikleri ve bekleme süreleri
Geçici hatalara dayanıklılık: retry/backoff ve circuit breaker
Log ve izleme: dağıtık izleme (distributed tracing) + p95/p99 görünürlüğü

Karar verirken yapılacak 7 test (buluttan bağımsız)

Seçimi hızlandırmak için üç bulutta da küçük ölçekli doğrulama yapın. Bu testler, “konsept kanıtı (PoC)” düzeyinde kalmalıdır.

Test 1: Aynı endpoint ölçümü
CDN açık/kapalı karşılaştırın.
p95 gecikmeyi hedefleyin.
Test 2: Cache davranışı
HTTP cache header’ları ve CDN invalidation süresi.
Test 3: Veritabanı yük testi
Okuma ağırlıklı mı yazma ağırlıklı mı ölçün.
Test 4: Otomatik ölçekleme
Anlık artışta toparlanma süresi (scale-in/scale-out).
Test 5: Yedekleme/geri dönüş süresi
Restore süresini deneyin (tam değil, örnek veri ile).
Test 6: Log/alert doğruluğu
404/500 artışını yakalayabilen alarm kuralı var mı?
Test 7: Maliyet sapması
Log retention ve egress yüzünden beklenmedik artış oluyor mu?

Örnek senaryolar: Türkiye için net öneriler

1) Kurumsal yapı + Microsoft yoğun ekip

Başlangıç tercihi: Azure
Net avantaj: Entra/AD tabanlı kimlik akışı ve kurumsal yönetim süreçleri daha az sürpriz üretir.
Kritik nokta: Ağ izolasyonu ve private endpoint tasarımını baştan kurgulayın.

2) Veri analitiği ve veri mühendisliği ağırlığı

Başlangıç tercihi: Google Cloud
Net avantaj: Veri işleme/analitik tarafında servislerin birlikte çalışması pratik sonuç verir.
Kritik nokta: Veri transfer (özellikle egress) planını netleştirin.

3) Global ölçekte servis olgunluğu + hızlı otomasyon

Başlangıç tercihi: AWS
Net avantaj: Geniş ekosistem ve otomasyon seçenekleri, farklı ekiplerin aynı “standart workflow” ile ilerlemesini kolaylaştırır.
Kritik nokta: Maliyet için log retention ve trafik ölçümünü baştan ayarlayın.

“Hangisi?” sorusunun tek cevabı neden yok? (Türkiye gerçekliği)

Türkiye’de kararınızı belirleyen tek parametre genelde “bulut hangisi” değil; şu iki faktör birlikte çalışır:

Mimari: CDN, DB tasarımı, ölçekleme, retry politikaları
Operasyon disiplini: loglama, alarm, yedekleme denetimi, IAM doğruluğu

Bu iki faktör doğru kurulduğunda üç bulutta da başarılı sonuç almak mümkündür. Bu yüzden PoC sırasında sadece performansı değil; operasyon yükünü de ölçün.

Sonuç: 14 gün içinde net karar alın

Önce bir hedef belirleyin: Türkiye’de kullanıcılarınıza hizmet eden kritik endpoint’ler için p95 gecikmeyi ve aylık toplam maliyeti tahmin edin. Ardından üç bulutta da küçük ölçekli PoC yürütün; CDN etkisi, DB yükü, ölçekleme toparlanması ve log/alert doğruluğunu ölçün. Eğer kurumunuz Microsoft ekosistemiyle ilerliyorsa Azure ile başlayın; veri/analitik ağırlığı varsa Google Cloud ile başlayın; otomasyon ve servis çeşitliliği kritikse AWS ile başlayın. En doğrusu, “tek şirketin en iyi olduğu” varsayımını değil; kendi endpoint’lerinizle yaptığınız ölçümü kararın merkezine koymaktır.

Aksiyon önerisi: 1 haftada mimariyi yazın, 1 haftada PoC ölçümlerini alın. Sonuç tablona (p95 gecikme, egress, log maliyeti, restore süresi) göre tek bulutu seçip üretime geçin.