Yerli Bulut Sağlayıcı Seçimi: 2026 Kriterler ve Kontrol Listesi

Bugün web uygulaması, veri platformu veya yedekleme altyapısı kuracak ekiplerin karşılaştığı en büyük soru şu: "Hangi yerli bulut sağlayıcı doğru?" Bu karar, teknik mimariden maliyete kadar her şeyi etkiler. Bu rehberde, NetKıyas’ta sık görülen senaryoları temel alarak SLA, performans, veri konumu, yedekleme (backup), güvenlik, ağ ve faturalama kalemlerini tek tek ele alacağız. Sonunda elinizde uygulanabilir bir kontrol listesi olacak; seçimi hızlandıracaksınız.

1) Veri konumu ve regülasyon uyumu: ilk kontrol

Yerli bulut sağlayıcı seçerken en somut başlangıç noktası, verinizin nerede tutulduğudur. “Türkiye’de hizmet veriyor” ifadesi her zaman yeterli değildir; pratikte şu sorular kritik hale gelir:

• Veri merkezinin (DC) konumu: Uygulama, veritabanı ve yedekler aynı coğrafyada mı?
• Yedek (backup) ve replikasyon: Anlık replikasyon hangi bölgede? Afet durumunda yedek hangi bölgede tutulur?
• Operasyon süreçleri: Destek ekibi erişimi nasıl sağlanır? Loglar nerede tutulur?
• KVKK ve sözleşmesel çerçeve: Sağlayıcı, veri işleme ve saklama süreçlerini yazılı olarak tanımlar mı?

Yerinde talep edilecek kanıtlar

Konu “kâğıt üzerinde” kalmamalı. Satın alma öncesi şunları talep edin:

• Veri merkezi lokasyon bilgisi (adres yerine en azından şehir/region düzeyi)
• Yedek saklama politikası (gün/hafta/ay) ve geri dönüş süresi hedefleri
• Replikasyon/restore prosedürü açıklaması

Bu adımı atlamak, ileride taşıma maliyeti çıkarır. Bulut maliyeti sadece “aylık kiradır” değil; yanlış lokasyon seçimi, yedek ve geri dönüş planını doğrudan etkiler.

2) SLA ve erişilebilirlik: sayıyı metrikle eşleştirin

Bulut sağlayıcı değerlendirmesinde SLA (Service Level Agreement) tek satırlık bir reklam değeri değildir. Uygulamanızın erişilebilirlik hedefi (ör. e-ticaret) ile sağlayıcının SLA kapsamı eşleşmezse problem yaşarsınız.

Aşağıdaki SLA metriklerini karşılaştırın:

• Aylık kullanılabilirlik (uptime) oranı
• Planlı bakım pencereleri ve ön bildirim süresi
• Arıza tespiti ve giderim süresi (MTTR)
• SLA kapsamı: Sanal sunucu mu, yönetilen servisler mi, belirli alanlar mı?
• Tazmin/credit politikası: SLA çiğnenirse kredi nasıl hesaplanıyor?

İpucu: SLA metninde “kapsam dışı” maddeleri bulun

Birçok SLA metni, belirli olayları kapsam dışı bırakır: DDoS olayları, ağ kesintileri, müşterinin yanlış yapılandırması gibi. Sağlayıcının “kapsam dışı” listelediği maddeleri uygulamanızın risk modeliyle eşleştirin.

3) Performans ölçümü: tek testle yetinmeyin

Bulutta performans; CPU throttling (takozlama), disk I/O dalgalanması, ağ gecikmesi ve storage türü gibi etkenlerle değişir. “Yüksek RAM” tek başına performansı garantilemez.

Değerlendirme sırasında şu başlıklarda net veri isteyin:

• CPU modeli ve tahsis: vCPU garantisi var mı?
• Storage tipi: SSD/HDD, “provisioned IOPS” / burst mekanizması
• Disk gecikmesi (latency) ve IOPS sınırları
• Ağ: İnternet çıkışı, ortalama ve kuyruk gecikmesi
• Eşzamanlı bağlantı kapasitesi: Web uygulaması için kritik

Pratik karşılaştırma tablosu (talep edeceğiniz veri)

4) Yedekleme (backup), snapshot ve geri dönüş: asıl maliyet kalemi

Birçok ekip ilk etapta maliyete bakar; ancak yedekleme tasarımı doğru olmazsa “ucuz bulut” pahalıya döner. Yedekleme stratejisini 3 aşamada değerlendirin:

1. Snapshot sıklığı: VM snapshot veya storage snapshot
2. Tam/inkremental yaklaşım: Tam mı inkremental mi?
3. Restore süresi: “Restore RTO” hedefi ne?

30 dakikalık restore gerektiren senaryolar

Örneğin e-ticaret veya CRM gibi canlı sistemlerde amaç, hatadan sonra sistemin geri gelmesini saatlerce bekletmemektir. Sağlayıcıdan şu yanıtları net alın:

• Restore işlemi kaç dakika/hangı adımlarla yapılıyor?
• Restore, aynı VM üzerine mi yoksa yeni bir instance olarak mı?
• Snapshot’lar şifreli mi? Anahtar yönetimi nasıl?

Yedekleri test edin: canlıya basmadan doğrulama

“Snapshot var” demek yetmez. Yedekleri en azından staging ortamına restore ederek doğrulayın. Bu yaklaşım, veri bütünlüğü ve uygulama uyumluluğu risklerini minimize eder.

5) Güvenlik modeli: izleme, kimlik ve erişim

Güvenlik, yalnızca firewall kuralları değildir. Yerli bulut sağlayıcı seçerken güvenlik modelini katman katman değerlendirin:

• Kimlik ve erişim: RBAC (rol bazlı yetkilendirme), MFA (çok faktörlü doğrulama)
• Ağ katmanı: Security Group (SG) mantığı, inbound/outbound kontrolü
• Şifreleme: Veride şifreleme (at rest) ve iletimde şifreleme (in transit)
• İzleme: Log erişimi, alarm, merkezi log (SIEM entegrasyonu)
• DDoS: Korumanın kapsamı (L3/L4/L7), tetikleme ve yönlendirme mekanizması

Kurumsal uygulamalar için “zorunlu” 6 soru

Aşağıdaki sorulara verilen net cevaplar, satın alma kararını hızlandırır:

• Bulut kontrol paneli (panel) üzerinde loglar kaç gün tutulur?
• Erişimler denetleniyor mu (audit log)?
• Anahtar yönetimi müşteri tarafından mı yönetiliyor?
• Özel IP / NAT / SNAT seçenekleri nasıl kurgulanıyor?
• Yama (patch) ve işletim sistemi güncellemelerinde sorumluluk kimde?
• Ortamlar arası (prod/staging) ağ izolasyonu nasıl sağlanıyor?

6) Ağ ve IPv6: performans kadar yönetilebilirlik de belirler

Ağ konusu, hem gecikme hem de yönetim maliyetini etkiler. Yerli bulutta ağ tasarımı değerlendirmesinde özellikle şu başlıklara bakın:

• Public IP tahsisi: Dinamik mi statik mi?
• DNS entegrasyonu: Alan adı yönlendirmesi (A/AAAA) kolay mı?
• IPv6 desteği: Hangi katmanda sunuluyor?
• Load balancer desteği: L4 mü L7 mi, health check nasıl çalışır?

IPv6 kararını testle doğrulayın

IPv6 kullanılacaksa kontrol listesi şöyle olmalı:

• AAAA kaydı doğru mu?
• Uygulama ve eklentiler IPv6 trafiğini destekliyor mu?
• Firewall/SG kuralları IPv6 için de uygulanıyor mu?
• Edge/CDN ile birlikte çalışıyor mu?

Bu maddeler eksik kalırsa “IPv6 açık ama servis hatalı” gibi geri dönüşü zor durumlar çıkar.

7) Fiyatlandırma: saatlik mi aylık mı, hangi kalemler kaçınılmaz?

Bulut maliyetini yalnızca “instance ücreti” üzerinden okumak hatadır. Yerli bulut sağlayıcı fiyatları genelde şu bileşenlerden oluşur:

• VM/instance (vCPU, RAM)
• Storage (GB) + IOPS/IO bant genişliği
• Trafik (ingress/egress) ve yük dengeleme
• Snapshot, yedekleme (backup) ve ek saklama
• Kamu IP, load balancer ve ileri ağ hizmetleri
• Yönetilen servisler (managed DB, Kubernetes vb.)

Saatlik fiyatlandırma avantajdır, ama hesaplamayı şart koşar

Saatlik veya esnek faturalama şu durumda anlamlıdır:

• Geliştirme ortamı (staging) uzun süre açık kalmıyorsa
• İş yükü gün içinde dalgalanıyorsa
• Otomasyonla ölçekleme yapıyorsanız

Aşağıdaki formülle yaklaşık maliyeti çıkarın:

• Günlük maliyet = (Ortalama saat açık * saatlik fiyat) + (storage + trafik sabitleri)
• Aylık maliyet = Günlük maliyet * 30

Bunu her sağlayıcı için aynı kabul ile yapın. “Storage dahil” gibi ifadelerde nelerin dahil olduğunu metinden netleştirin.

8) Migrasyon ve geçiş süresi: taşıma planı olmadan seçim tamamlanmaz

Bulut seçimi, sadece başlangıç değil; geçişin zorluğu ve süresi demektir. Taşıma planında iki metrik belirleyin:

• Veri boyutu: VM diskleri, veritabanı boyutu, log hacmi
• Transfer hızı: İnternet çıkışı bant genişliği ve kısıtlar

Geçişte dikkat edilecekler

• Kesinti (downtime) hedefiniz: Sıfır kesinti mümkün değilse planlı kesinti kabul ediliyor mu?
• DNS geçiş adımı: TTL değerleri ve geri dönüş (rollback) planı
• Uygulama yapılandırması: DSN/connection string değişimleri

9) Son karar: puanlama modeliyle netleştirme

Kararı sezgiye bırakmak yerine puanlama modeli kullanın. Aşağıdaki şablon pratik bir çerçeve sunar.

• SLA ve kapsam: 25 puan
• Yedekleme ve restore: 25 puan
• Performans/limitler: 20 puan
• Güvenlik ve izleme: 20 puan
• Fiyat/şeffaflık: 10 puan

Her sağlayıcı için ilgili maddeleri 0-5 arası puanlayın. “Fiyat ucuz ama restore süresi 6 saat” gibi durumlarda puanlama sistematiği size doğru tercihi yaptırır.

10) Uygulanabilir kontrol listesi (satın alma öncesi)

Aşağıdaki listeyi görüşme öncesi hazırlayın ve dokümantasyonla kanıt isteyin:

• [ ] Veri konumu (DC şehir/region) ve yedek konumu
• [ ] SLA kullanılabilirlik oranı ve kapsam dışı maddeler
• [ ] Storage tipi, IOPS/latency limitleri ve throttling davranışı
• [ ] Restore RTO/RPO hedefleri (snapshot ve backup)
• [ ] Şifreleme (at rest/in transit), anahtar yönetimi modeli
• [ ] RBAC, MFA, audit log ve log saklama süresi
• [ ] Security Group kuralları (inbound/outbound) ve izolasyon
• [ ] Load balancer (L4/L7) health check ve yönlendirme
• [ ] IPv6 desteği ve IPv6 güvenlik kuralları
• [ ] Trafik (egress) ve kamu IP/ek hizmet maliyetleri
• [ ] Migrasyon planı: kesinti ve DNS geri dönüş stratejisi

Sonuç: 1 hafta içinde net karar verin

Yerli bulut sağlayıcı seçimi, “paket adı” yerine SLA + yedekleme/restore + performans limitleri + güvenlik bileşenleriyle netleşir. İlk 3-4 gün içinde veri konumu, SLA kapsamı, yedekleme/restores ve güvenlik modelini doğrulayın; ardından 2-3 gün içinde aynı senaryoda performans ve maliyet hesabını çıkarın. Son adım olarak, seçeceğiniz sağlayıcıyla staging ortamında restore ve temel yük testini çalıştırın. Bu aksiyonlar tamamlandığında kararınız sadece teoride değil, ölçümle doğrulanmış olur.