Yerli Bulut Sağlayıcı Seçiminde Kriterler (Net Kontrol Listesi)

Bulut sağlayıcı seçimi, yalnızca “aylık fiyat” meselesi değildir. Türkiye’de erişim gecikmesi, veri egemenliği, yedekleme (backup) güvenilirliği ve operasyonel süreçler, toplam maliyeti doğrudan etkiler. Bu rehberde yerli bulut sağlayıcıları değerlendirirken kullanabileceğiniz ölçülebilir kriterleri; VDS/VPS tarafında alıştığınız kontrol mantığına paralel şekilde ele alacağız. Sonunda da kısa bir kontrol listesiyle doğru kararı hızlandıracaksınız.

1) Veri merkezi konumu ve veri egemenliği: “Türkiye içi” ne demek?

Yerli bulutun ilk avantajı, veriye erişim ve yasal süreçlerde netliktir. Ancak “Türkiye’de” ifadesi tek başına yetmez; aşağıdaki detayları istemelisiniz.

Konum doğrulama kontrolü

• Veri merkezi ülke/şehir bilgisi: Sağlayıcının adres veya en azından şehir düzeyinde lokasyon vermesi gerekir.
• Ağ çıkış noktaları: İç hatlarda mı dış hatlarda mı yönlenme olduğu (ASN/peering bilgisi) önemlidir.
• Bölge/zone mimarisi: Tek lokasyon yerine birden fazla bölge varsa felaket senaryolarında (disaster recovery) daha net plan yapılır.

Hangi senaryoda hangi kriter öne çıkar?

• Türkiye’de kullanıcı kitlesi: İstanbul/Ankara gibi lokasyonlara yakınlık genelde daha düşük gecikme sağlar.
• Regülasyon hassasiyeti (KVKK/özel veri): Veri konumuna dair yazılı garanti ve saklama politikası talep edin.
• Uluslararası entegrasyon: Avrupa/ABD’ye veri akışı varsa, bölgeler arası (cross-region) egress maliyetini ayrıca inceleyin.

2) SLA ve operasyonel sorumluluk: Hizmet kesintisini sayıyla isteyin

Bulut seçerken “yüksek erişilebilirlik” gibi ifadeler yerine ölçüm talep edin. SLA (Service Level Agreement) pratikte şu sorulara cevap vermelidir.

Asıl bakmanız gereken SLA kalemleri

• Uptime hedefi: Tipik hedef %99.9 veya üzeridir; sağlayıcı uptime tanımını nasıl ölçüyor belirtilmeli.
• Bakım pencereleri: Planlı bakım saatleri ve ön bilgilendirme süresi net olmalı.
• Kurtarma/aksiyon süreleri: Olay (incident) durumunda ne kadar sürede yanıt ve çözüm planı var?
• İade/kompanzasyon: SLA ihlalinde servis kredisi veya ücret iadesi formülü yazılı olmalıdır.

SLA’yı nasıl doğrularsınız?

• Daha önceki olay raporları (postmortem) veya şeffaf incident geçmişi: En azından son 6-12 ayda örnek paylaşımı değerlendirin.
• İzleme metrikleri: Sağlayıcının hangi metrikleri (CPU, network, disk latency, packet loss) SLA içine dahil ettiğini kontrol edin.

3) Ağ kalitesi (latency, jitter, packet loss) ve throttling politikası

Bulutta performansın büyük kısmı hesap gücünden çok ağla ilgilidir. Yerli sağlayıcı seçerken “trafik yoğunluğu” veya “adil kullanım” ifadeleri alt metin gibi kalmamalı.

Ölçüm yapmadan karar vermeyin: İstenecek metrikler

• Gecikme (latency): Ortalama ve 95. persentil değerleri.
• Paket kaybı (packet loss): Özellikle VoIP, canlı yayın, oyun veya gerçek zamanlı API’lerde kritik.
• Jitter: Zaman bazlı akışlarda dalgalanmayı gösterir.

Network throttling nedir? Satıcıdan net politika isteyin

Network throttling, belirli koşullarda trafiğin performansının sınırlanmasıdır. Sağlayıcı, bunu genellikle “adil kullanım” veya “aşırı kullanım” gerekçesiyle uygular.

Değerlendirme soruları: - Throttling hangi eşiğe göre uygulanır? (ör. belli saatlerde belli egress/IO sınırı) - Eşik aşıldığında ne olur? (band genişliği düşer, gecikme artar, hız sabitlenir) - İhlal süresi nasıl hesaplanır? (günlük mi saatlik mi) - İstisna: Özel planlarda farklı sınırlama var mı?

4) Yedekleme ve kurtarma (backup & DR): RTO/RPO ile karar verin

Bulutta “yedek var” demek yetmez. Yedeklemenin sıklığı ve geri dönüş süresi (restore) operasyonu belirler.

RPO ve RTO’yu netleştirin

• RPO (Recovery Point Objective): Son kayıp veri miktarı. Örn. 15 dk RPO hedefi.
• RTO (Recovery Time Objective): Sistemin geri gelme süresi. Örn. 2 saat RTO.

İstenen teknik detaylar

• Yedek türü: Anlık (snapshot) mı dosya tabanlı mı? Crash-consistent veya application-consistent ayrımı.
• Saklama süresi: 7/14/30/90 gün gibi seçenekler.
• Şifreleme: Yedeklerin at-rest (storage üzerinde) şifrelenmesi.
• Kimin kontrolü: Yedek geri yükleme işlemini sağlayıcı mı yapar, müşteri mi?

5) Hesap & maliyet kontrolü: Cloud’da sürprizi önleyen başlıklar

Yerli bulutla toplam maliyet; sadece VM fiyatı değil, kullanılan kaynakların “birim maliyeti” ile belirlenir. Bu yüzden aşağıdaki kalemleri tek tek çıkarın.

Toplam maliyeti oluşturan ana giderler

• Compute (CPU/RAM): VDS/VM saatlik veya aylık fiyatı.
• Depolama (storage): Disk boyutu + disk performans seviyesi (IOPS/throughput) varsa ek maliyet.
• Yedekleme: Snapshot/backup saklama süresi ve geri yükleme opsiyonları.
• Network egress: İnternete giden trafik (çıkış) çoğu zaman sürprizin ana kaynağıdır.
• Load balancer veya ek servisler: WAF, DDoS koruması, yönetilen veritabanı vb.

Egress maliyeti için pratik yöntem

Aşağıdaki yaklaşımı kullanın: - Son 30 gün trafik raporunuzu alın (özellikle outbound/egress). - Ay içi dağılımı kontrol edin (pik saatler var mı?). - Bulut sağlayıcının egress birim fiyatıyla çarpın. - 2 senaryo çıkarın: “Normal” ve “Pik” maliyeti.

6) Güvenlik: Erişim yönetimi, şifreleme ve ağ segmentasyonu

Bulutta güvenlik, “antivirüs var” değil; erişim ve ağ tasarımı ile ilgilidir. Yerli sağlayıcı seçerken aşağıdakileri yazılı şekilde doğrulayın.

Minimum beklentiler

• IAM (Identity & Access Management): Yetki seviyeleri (role) ve MFA desteği.
• SSH anahtar zorlaması: Parola ile giriş yerine anahtar tabanlı erişim.
• Ağ güvenliği: Security Group/Firewall kuralları ile kaynak seviyesinde kural yönetimi.
• Şifreleme: Depolama şifrelemesi (at-rest) ve veri iletimi için TLS.

İzleme ve log tutma

• Sağlayıcı tarafı loglar: Konsol üzerinden erişim, olay logları.
• Müşteri tarafı: VM içinde erişim logları (audit log) ve uygulama logları.
• Dışa aktarım: Logları dış depolama veya SIEM’a gönderebilme.

7) Ölçeklenebilirlik ve taşınabilirlik: Vendor lock-in’i azaltın

Seçtiğiniz sağlayıcı büyümenizde avantaj sağlayacak mı, yoksa sonradan maliyet duvarı mı oluşturacak? Bu soruya “taşınabilirlik” yanıt vermeli.

Ölçeklenme seçenekleri

• Vertical scaling: VM’i daha büyük kaynağa yükseltmek.
• Horizontal scaling: Birden fazla VM ile ölçeklemek.
• Otomasyon: Ölçekleme için yönetilen servisler veya en azından API/CLI desteği.

Taşımayı kolaylaştıran pratik şartlar

• Ekran/konfigürasyon mantığı: Aynı mimariyi başka sağlayıcıda da kurabilmeniz.
• Görüntü (image) ve snapshot yaklaşımı: Standart format veya erişilebilir yedekleme.
• Versiyon ve işletim sistemi desteği: Güncel Linux dağıtımları ve sürüm politikası.

Yerli bulut için net karar matrisi (kısa skor)

Aşağıdaki tablo, sağlayıcıları hızlı karşılaştırmak için tasarlanmıştır. Her maddeyi 0-5 arası puanlayın (5 en iyi). Toplam puan tek başına karar değildir; fakat “nerede zayıf kaldığını” gösterir.

Satın almadan önce isteyeceğiniz 10 somut doküman

Satış konuşması yerine aşağıdaki listeyi talep edin. Bu belgeler geliyorsa sağlayıcının operasyon olgunluğu yüksektir. - SLA metni (ölçüm yöntemi ve ihlal kompanzasyonu) - Yedekleme politikası (snapshot/restore, saklama, şifreleme) - RPO/RTO hedefleri ve örnek restore süresi - Ağ politikası (egress, adil kullanım, throttling eşiği) - Veri merkezi konum bilgisi ve bölge/zone yaklaşımı - Güvenlik dokümanı (IAM, firewall, loglama) - Performans hedefleri veya benchmark örnekleri - Ölçekleme limitleri (maximum VM/instance sayısı) - Faturalama dokümanı (egress, storage tier, snapshot ücretleri) - Incident iletişim süreci (olay halinde SLA dışı iletişim)

Sonuç: 2 haftalık net test planı ve aksiyon

Yerli bulut sağlayıcı seçimini “fiyat” üzerinden değil, SLA + yedekleme (RPO/RTO) + ağ başlıkları üzerinden karar verilecek şekilde yapın. İlk adım olarak 2 haftalık bir doğrulama testi uygulayın: Aynı uygulama yükünü test ortamında çalıştırın, ölçümlerinizi (latency, hata oranı, restore denemesi) kaydedin ve egress/backup maliyetini senaryolayın. En sonunda, yukarıdaki karar matrisiyle en yüksek puanı alan sağlayıcıyı seçin; seçtiğiniz sağlayıcının SLA ve yedekleme metriklerini sözleşme/teknik dokümanla kesinleştirmeyi aksiyon olarak tamamlayın.