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

Bulut sağlayıcı seçimi, altyapı maliyetinizi ve sisteminizin arıza anında nasıl davranacağını doğrudan belirler. Yerli bulut seçeneklerinde teknik detaylar (bant genişliği, ölçeklenebilirlik, yedekleme politikası, erişim güvenliği) fiyat tabelosunun çok ötesine geçer. Bu rehberde yerli bulut sağlayıcıyı karşılaştırırken kullanacağınız somut kriterleri ve her madde için uygulanabilir kontrol listesini bulacaksınız.

1) Mimari uyumu: Hangi iş yükü için hangi bulut modeli?

Yerli bulut sağlayıcıyı değerlendirirken ilk hedef, sunulan modelin sizin çalışma şeklinize uygun olup olmadığını netleştirmektir.

IaaS mi PaaS mı?

• IaaS (Infrastructure as a Service): VM, ağ, disk, yük dengeleyici gibi bileşenleri siz yönetirsiniz. Uygulama ekibi altyapı yönetimini yapıyorsa uygundur.
• PaaS (Platform as a Service): Veritabanı, uygulama servisleri gibi katmanları sağlayıcı yönetir. Sürüm güncellemesi ve güvenlik patch süreçleri için ekip yükünü azaltır.

Kontrol: Sağlayıcı, ihtiyaç duyduğunuz katmanda yönetimi nasıl paylaşıyor? - Kullanım senaryonuz “kendi Docker/VM orkestrasyonum var” ise IaaS tercih edin. - “Veritabanı ve ölçekleme otomatik olsun” diyorsanız PaaS veya yönetilen veritabanı sunan bir model arayın.

Bölgesel yedeklilik ve servis seviyesi

Bulutun sadece “uçtan uca çalışması” değil, arıza anında kurtarma süresi (RTO) ve kayıp süresi (RPO) önemlidir. - RTO: Sisteminizin tekrar çalışmaya başlaması için hedef süre - RPO: Yedekleme aralığı nedeniyle oluşabilecek veri kaybı hedefi

Net kontrol: Sağlayıcının yedeklilik yaklaşımı ve kurtarma hedefleri yazılı mı? “24/7 izleme” demek tek başına yetmez.

2) Performans kriterleri: CPU/RAM değil, beklenen gecikme ve tutarlılık

Bulutta performans çoğu zaman “anlık hız”tan çok “istikrarlı gecikme” ve “paylaşımlı kaynak etkisi” ile anlaşılır.

Ağ ve bant genişliği: İnce ama kritik

Şu üç değeri arayın ve tekliflerle yan yana koyun: 1. Giden/gelen trafik limitleri (aylık veya saatlik kota) 2. Bant genişliği türü: garanti mi yoksa burst mi? 3. Latens (gecikme) beklentisi: özellikle DB ve uygulama konuşuyorsa önemli olur

Kontrol listesi: - Büyük dosya transferi veya medya servisiniz varsa “saatlik değil aylık” kotayı görün. - CDN kullanmayacaksanız inter-region (bölge arası) trafik ücretini netleştirin.

Depolama: IOPS ve gecikme üzerinden okuyun

Disk performansı için tek satır “SSD” ifadesi yerine şu detayları isteyin: - IOPS (saniye başına giriş/çıkış) - Throughput (MB/s veya GB/s) - Diskin ölçekleme modeli: kapasite artınca performans artıyor mu?

Uygulama ipucu: - Log ve küçük veri yazmaları varsa düşük/orta IOPS yeterli olabilir. - Gerçek zamanlı işleme (ör. arama indeksleri, yoğun DB) yapan sistemlerde IOPS/throughput belirleyicidir.

Performans testini teklif aşamasında yapın

Bir sağlayıcıyı seçmeden önce test edilebilir bir plan belirleyin. - 1-2 uygulama endpoint’i ile gerçekçi yük testi - DB için basit okuma/yazma profili - Aynı saat aralığında en az 30-60 dakikalık test

Kontrol: Sağlayıcı test sürecinde kaynak ayırmayı nasıl yapıyor? “Paylaşımlı” altyapı her zaman kötü değildir; ama kabul kriterinizi net koymalısınız.

3) SLA ve uptime gerçekçiliği: Metni değil ölçümü tartın

Uptime garantisi ve SLA (Service Level Agreement) dokümanı, sunucunun yalnızca “çalıştığı” günleri değil, arıza anında nasıl telafi edildiğini anlatmalıdır.

%99.9 ne demek? Takvim karşılığı

• %99.9 aylık pratik sınır: yaklaşık 43 dakika kesinti.

Kontrol: SLA metninde “planlı bakım” nasıl sayılıyor? Planlı bakımın saatleri ve sınırları açık mı?

SLA kredisi ve muafiyetler

Bazı SLA’larda telafi mekanizması vardır ama şu durumlar muaf tutulur: - Müşteri taraflı yanlış yapılandırma - Ağ hatası/DB erişimi müşteri kaynaklı denir - Üçüncü parti bağımlılıklar

Net kontrol soruları: - SLA ihlalinde telafi kredi mi yoksa ücret iadesi mi? - Telafi tutarı hangi formülle hesaplanıyor? - Telafi almak için süreç ve kanıt gereksinimi ne?

4) Veri konumu, uyumluluk ve yedekleme: Taşınabilirliği ölçün

Yerli bulut seçerken “veri Türkiye’de” ifadesi tek başına yeterli değildir. Dosyanın nerede tutulduğu, yedeklerin nasıl üretildiği ve geri dönüş sürecinin ne kadar zaman aldığı önemlidir.

Veri merkezi konumu ve kopyalama

• Veri ve yedeklerin aynı bölgede mi yoksa farklı bölgede mi kopyalandığı
• Bu kopyanın senaryosu: failover var mı?

Kontrol: Sağlayıcı, veri yerini ve çoğaltma yaklaşımını açıklıyor mu?

Yedekleme (backup) politikası

Aşağıdaki parametreler yazılı olmalıdır: - Yedek sıklığı (ör. her 15 dk / her saat) - Saklama süresi (ör. 7 gün / 30 gün / 1 yıl) - Geri dönüş (restore) süresi ve prosedür

Net örnek hedefler (senaryo bazlı): - Kritik veriler için saatlik yedek + hızlı restore beklemek makul bir hedef olabilir. - Geliştirme ortamı için günlük yedekle ilerlemek çoğu zaman yeterlidir.

Şifreleme ve anahtar yönetimi

Şifreleme iki noktada değerlendirilir: - Disk/saklama şifreleme (at-rest) - Trafik şifreleme (in-transit)

Kontrol: Şifreleme “varsayılan” mı yoksa “seçilebilir” mi? Anahtarlar kime ait: sağlayıcı mı, siz mi (customer-managed keys)?

5) Güvenlik ve erişim: Sisteminizin kontrolünü sizde tutun

Bulutta güvenlik, yalnızca sağlayıcı uygulamalarıyla bitmez; erişim modeli ve yapılandırma sorumlulukları netleşmelidir.

Erişim kontrolü (IAM) ve en az ayrıcalık

Sağlayıcının sunduğu erişim katmanı şu özellikleri desteklemelidir: - Rol tabanlı erişim (role-based access control) - MFA (çok faktörlü doğrulama) - Audit log (kim ne zaman hangi kaynağı oluşturdu/sildi?)

Kontrol: Hesaplarda “tek admin” yaklaşımı var mı, yoksa kurumsal RBAC uygulanabiliyor mu?

Ağ güvenliği: Güvenlik grupları ve segmentasyon

Aşağıdaki bileşenler net olmalıdır: - Güvenlik grubu (security group) mantığı - İnternete açık servislerin sınırlandırılması - Özel ağ (private network) seçenekleri

Uygulama ipucu: - DB’yi internete kapatın. - Uygulama sunucusu ile DB arasındaki erişimi kaynak bazlı tanımlayın.

DDoS, bot ve katmanlı koruma

Bulutta DDoS koruması varsa şu sorulara net yanıt arayın: - Koruma hangi katmanda (L3/L4/L7)? - Trafik filtreleme nasıl ölçülüyor? - Faturalandırma nasıl etkileniyor?

6) Maliyet: Birim fiyat değil toplam işletim maliyeti

Bulut maliyetini hesaplarken tek satırlık “aylık ücret” yerine gerçek kullanım senaryosunu baz alın.

Fiyat kalemlerini ayırın

En sık maliyet kalemleri: - Hesaplama (VM vCPU/RAM) - Depolama kapasitesi + performans (IOPS) - Trafik (ingress/egress) - Yük dengeleyici/ek servis ücretleri - Yedekleme ve snapshot maliyetleri

Kontrol: Aşağıdaki belirsizlikleri teklif üzerinde netleştirin: - Egress trafik ücretsiz mi, ücretli mi ve birimi ne? - Snapshot/backup kotaları var mı?

Taşınabilirlik ve exit planı

İyi bir seçim, “sonradan çıkınca da kontrol sende” yaklaşımı sağlar. - VM disklerini export edebilme - Yedeklerden restore edebilme (süre ve veri kaybı) - Konfigürasyon/otomasyon arayüzleri (API, Terraform uyumu)

Kontrol: Çıkış planı için en az bir teknik senaryo çıkarın. Örn: - Veritabanını nasıl taşırım? - VM imajlarını nasıl aktarırım? - Yedek dosyalarını nasıl restore ederim?

7) Seçim süreci: 10 maddelik NetKıyas tarzı karar şablonu

Aşağıdaki kontrol listesini sağlayıcı görüşmelerinde birebir kullanın.

Sunucu ve ağ

• [ ] Teklif edilen VM tipi, beklenen iş yükü için CPU/RAM oranını karşılıyor mu?
• [ ] Network performansı: burst mi garanti mi?
• [ ] Egress/ingress kota ve ünite (GB/TB) net mi?

Depolama ve veri katmanı

• [ ] Disk için IOPS ve throughput değerleri belirtildi mi?
• [ ] Kapasite artırınca performans artıyor mu?

SLA ve bakım

• [ ] SLA uptime hesabı planlı bakım dahil mi hariç mi?
• [ ] SLA ihlali telafisi (kredi/iade) yazılı mı?

Yedekleme ve kurtarma

• [ ] Yedekleme sıklığı ve saklama süresi açık mı?
• [ ] Restore süresi hedefi var mı?

Güvenlik

• [ ] IAM RBAC + MFA + audit log var mı?
• [ ] Ağ segmentasyonu (private network) uygulanabiliyor mu?

Maliyet ve çıkış

• [ ] Trafik ve yedekleme maliyeti toplam fiyata nasıl yansıyor?
• [ ] Exit planı için export/restore seçenekleri net mi?

Sonuç: Kısa listeyi yapın, sonra test edin

Yerli bulut sağlayıcı seçimini fiyatla başlatıp SLA, yedekleme ve çıkış planıyla bitirmek gerekir. En hızlı doğru karar, önce 10 maddelik kontrol listesini doldurmak, ardından yalnızca şartları karşılayan 2 sağlayıcıya 30-60 dakikalık performans ve restore testleri uygulatmaktır. Bu iki adımı uyguladığınızda “en ucuz” ile “en sorunsuz” arasındaki farkı net şekilde görürsünüz; aksiyon olarak sağlayıcı tekliflerini madde madde karşılaştırın ve teknik test takvimi çıkarın.