Tek Bulut mu Çoklu Bulut mu? Maliyet, Güvenlik ve Uyumluluk Karşılaştırması

“tek bulut vs çoklu bulut” sorusu çoğu ekip için aynı anda üç hedefi dengelemek anlamına gelir: maliyet (TCO), güvenlik ve uyumluluk. Tek bir sağlayıcıyla derinleşmek yönetimi basitleştirebilir; birden fazla sağlayıcı ise yetenek seçimi ve tedarik risklerini dağıtma gibi avantajlar sunabilir. Ancak çoklu bulut çoğu zaman daha fazla operasyonel iş, daha karmaşık kimlik ve erişim yönetimi (IAM) ve veri taşıma maliyetleri gibi görünmeyen kalemler getirir.

Bu yazı, genel kitle için pratik bir karar rehberi olarak tasarlandı: hangi durumda tek bulut daha mantıklı, hangi durumda çoklu bulut gerekçelendirilebilir ve karar verirken hangi soruları sormalısınız.

Önce tanım: Tek bulut ve çoklu bulut ne demek?

Tek bulut (single-cloud), iş yüklerinin ve temel platform servislerinin ağırlıklı olarak tek bir bulut sağlayıcıda çalıştırılmasıdır. Burada amaç; tek bir ekosistemde standartlaşmak, eğitim ve operasyon yükünü azaltmak ve mümkünse taahhüt/indirim modellerinden daha iyi yararlanmaktır.

Çoklu bulut (multi-cloud) ise iki veya daha fazla bulut sağlayıcısının birlikte kullanılmasıdır. Bu, her iş yükünün “en iyi” olduğu düşünülen sağlayıcıya taşınması anlamına gelebileceği gibi; felaket kurtarma (DR), veri yerleşimi, birleşme-satın alma veya tedarikçi riskini azaltma gibi gerekçelerle de ortaya çıkabilir. AWS’nin çoklu bulut stratejisi için paylaştığı pratikler, kararın yalnızca teknoloji seçimi olmadığını; organizasyon, yönetişim ve operasyon tasarımı gerektirdiğini vurgular.

Kaynak: AWS Enterprise Strategy Blog

Maliyet (TCO): En sık atlanan kalem “ağ ve veri çıkışı”

TCO (Toplam Sahip Olma Maliyeti) sadece sanal makine veya depolama birim fiyatı değildir. Özellikle çoklu bulutta maliyeti büyüten kalemler çoğu zaman ağ, veri çıkışı (egress), gözlemlenebilirlik (log/metric/tracing) ve ek insan/operasyon maliyetleridir.

1) Egress ücreti: Çoklu bulut mimarilerinde “çapraz bulut trafiği” pahalılaşabilir

Birçok senaryoda verinin bir buluttan dışarı (ör. internete veya başka bir sağlayıcıya) çıkması ücretlidir ve bu, buluttan buluta veri taşıdığınızda veya kullanıcılarınıza farklı bir ağ yolundan servis verdiğinizde maliyeti artırabilir. Bu nedenle “egress varsayımı” ile değil, resmi veri transfer fiyat sayfaları üzerinden senaryo bazlı hesap yapmak daha sağlıklıdır.

• AWS EC2 On-Demand Pricing: Data Transfer (veri transfer kalemleri için doğrudan referans)
• Google Cloud VPC network pricing (genel ağ/veri transfer fiyatlandırması için)

Özel bağlantı (private connectivity) seçenekleri (ör. bulutlar arası özel hatlar) bazı mimarilerde internet egress desenini azaltabilir; ancak bunlar da ayrı ürün/fiyatlandırma kalemleri getirebilir. Özel bağlantı seçenekleri için sağlayıcı fiyat sayfalarını ayrıca inceleyin: Google Cloud Network Connectivity pricing.

Ek olarak, sektörde “beklenmedik depolama/egress ücretleri” algısının yaygın olduğunu gösteren vendor-kaynaklı anket özetleri bulunuyor. Örneğin bir basın özeti, Backblaze’in paylaştığı bir ankette çok yüksek bir oran raporlandığını (özet haberde %95 olarak aktarılıyor) belirtir; bunun vendor tarafından raporlanan bir çalışma olduğunu, örneklem/metodoloji ayrıntılarının özet haberde sınırlı yer aldığını ve sonuçların tüm pazarı temsil etmek zorunda olmadığını not etmek gerekir.

Kaynak: NewscastStudio özeti (Backblaze anketi)

Pratik kontrol: Egress maliyetini hızlıca nasıl “görünür” yaparsınız?

• Uygulama veri akışını çıkarın: Hangi servis hangi veriyi nereye gönderiyor? (bulut içi, buluttan internete, buluttan diğer buluta)
• “Sınır geçişlerini” işaretleyin: Bölge dışı, sağlayıcı dışı, internet çıkışı gibi.
• Aylık veri hacmini ölçün: GB/TB seviyesinde (tahmin değil, mümkünse ölçüm).
• Resmi fiyat sayfasına göre hesaplayın: Liste fiyatları taahhüt/indirimlerle değişebilir; yine de karşılaştırma için baz oluşturur.

2) TCO’yu yalnızca fatura değil, operasyon olarak düşünün

Çoklu bulutta iki ayrı (veya daha fazla) “işletim modeli” oluşur: farklı IAM mantıkları, farklı ağ bileşenleri, farklı izleme/uyarı mekanizmaları ve farklı güvenlik yapılandırmaları. Bu da platform ekibi, güvenlik ekibi ve uygulama ekiplerinin iş yükünü artırabilir. Akademik bir derleme çalışması; çoklu bulut ve hibrit ortamlarda güvenlik ve mahremiyetin (privacy) görünürlük, politika tutarlılığı ve konfigürasyon yönetimi gibi alanlarda daha zorlayıcı olabildiğini tartışır.

Kaynak: Computers & Security (ScienceDirect) derleme

3) TCO şablonu: Tek sayfada karşılaştırma

Aşağıdaki tabloyu kendi sisteminize uyarlayarak tek bulut ve çoklu bulut senaryolarını aynı çerçevede kıyaslayın. Sayıları siz doldurabilirsiniz; burada amaç kalemleri kaçırmamak.

FinOps ile maliyet sürprizlerini azaltma

Çoklu bulutta maliyet yönetimi “ay sonu fatura bakma” seviyesinde kalırsa kontrol zorlaşır. FinOps Foundation materyalleri; etiketleme (tagging), showback/chargeback, bütçe/uyarılar ve optimizasyon pratikleriyle maliyetin operasyonel olarak yönetilmesini öne çıkarır. Bu yaklaşım tek bulutta da değerli olsa da, çoklu bulutta neredeyse zorunlu hale gelir.

Kaynak: FinOps Foundation

Güvenlik: Çoklu bulutta “kontrol tutarlılığı” en büyük mücadele

Tek bulutta bile güvenlik, büyük ölçüde doğru yapılandırmaya dayanır. Çoklu bulutta ise aynı güvenlik niyetini farklı servis adları, farklı politika dilleri ve farklı varsayılan ayarlarla hayata geçirmek gerekir. Akademik derlemeler, görünürlük (visibility), IAM karmaşıklığı ve yanlış yapılandırma riskinin çoklu bulutta büyüyebileceğini tartışır.

Kaynak: Computers & Security (ScienceDirect)

Çoklu bulutta tipik risk alanları

• Kimlik ve yetkilendirme: Rol tanımları, servis hesapları, ayrı dizinler ve farklı MFA/politika yaklaşımları.
• Görünürlük ve kayıtlar: Log formatlarının ve uyarı mantıklarının farklılaşması; korelasyonun zorlaşması.
• Konfigürasyon tutarsızlığı: Bir bulutta “varsayılan kapalı” olan bir özellik diğerinde farklı davranabilir.
• Ağ sınırları: VPC/VNet tasarımları, özel bağlantılar ve DNS yönlendirmeleri karmaşıklaşabilir.

Pratik savunma paketi: Minimum uygulanabilir güvenlik standardı

Aşağıdaki liste, “iki bulutta da aynı güvenlik seviyesini sağlamak” için iyi bir başlangıç çerçevesidir. Her maddeyi politika olarak tanımlayıp otomasyonla doğrulamak, manuel hataları azaltır.

• Merkezi kimlik stratejisi: Tek bir kurumsal kimlik kaynağına dayanan SSO ve yaşam döngüsü (joiner/mover/leaver) süreçleri.
• Asgari yetki (least privilege): Roller, izinler ve servis hesapları için standartlar; düzenli gözden geçirme.
• Şifreleme standartları: Veri-at-rest ve veri-in-transit için zorunlu şifreleme ve anahtar yönetimi ilkeleri.
• Konfigürasyon doğrulama: Bulut yapılandırmalarını sürekli tarayan ve uygunsuzluğu raporlayan kontroller.
• Birleşik telemetri: Kritik log/metric setlerinin ortak bir yerde toplanması ve olay müdahalesi runbook’ları.

Çoklu bulut stratejisi uygulayan ekipler için AWS’nin önerileri, standartların ve yönetişimin erken kurulmasının operasyonel başarıyı artırdığını vurgular.

Kaynak: AWS multicloud pratikleri

Uyumluluk (Compliance): ABD pazarında “kanıt toplama” maliyeti büyüyebilir

Uyumluluk gereksinimleri (sektöre ve müşteri tipine göre) bulut seçiminde belirleyici olabilir. ABD’de özellikle kamu ile çalışan veya kamuya hizmet sağlayan ekosistemlerde FedRAMP gündeme gelir. FedRAMP’in paylaşımları, programın modernizasyon (20x) yaklaşımı ve sürekli izleme/evaluasyon süreçlerindeki değişim yönünü anlamak için birincil referans niteliğindedir.

Kaynak: FedRAMP 20x güncellemesi

Tek bulut vs çoklu bulut: Uyumluluk açısından pratik farklar

• Kontrol eşleme (control mapping): Aynı kontrol (örn. erişim kayıtları) farklı bulutlarda farklı kanıtlarla gösterilebilir.
• Denetim izi ve kanıt: Log saklama, değişiklik yönetimi ve onay süreçleri çoklu sağlayıcıda dağılabilir.
• Paylaşılan sorumluluk: Sağlayıcının sunduğu kontroller ile müşterinin konfigürasyon sorumluluğunu net ayırmak gerekir.

Uyumluluk için uygulanabilir yaklaşım: “İş yükü bazlı” karar

Uyumluluğu tek bir etiket gibi düşünmek yerine, iş yükü bazında ele alın:

1. İş yükünü sınıflandırın: Veri hassasiyeti, erişim modeli, düzenleyici kapsam, saklama süresi.
2. Kontrol setini çıkarın: Kurumunuzun gerekli gördüğü kontrolleri (politikalar, loglar, erişim, yedekleme).
3. Sağlayıcı yeteneklerini eşleyin: Her bulutun hangi yerleşik servislerle bunu desteklediğini belirleyin.
4. Kanıt toplama hattı kurun: Otomatik raporlar, değişiklik kayıtları, erişim incelemeleri.

Bu yaklaşım, “her şeyi çoklu buluta taşıyalım” yerine “uyumluluk gerektiren iş yüklerini doğru yerde çalıştıralım” gibi daha yönetilebilir bir strateji oluşturmanıza yardım eder.

Karar çerçevesi: Ne zaman tek bulut, ne zaman çoklu bulut?

Tek bulut genelde daha uygun olur, eğer…

• Ekip küçük/orta ölçekliyse ve operasyonel basitlik kritikse.
• İş yükleri homojense (benzer mimariler, benzer servis ihtiyaçları).
• Veri akışı tek bir ekosistemde kalabiliyorsa (çapraz bulut trafiği az).
• Standartlaştırılmış güvenlik ve gözlemlenebilirlik daha hızlı kurulmak isteniyorsa.

Çoklu bulut anlamlı olabilir, eğer…

• İş gereksinimi belirli bir sağlayıcının güçlü olduğu bir servisi zorunlu kılıyorsa (ve alternatifleri gerçekçi değilse).
• Dayanıklılık stratejiniz sağlayıcı bağımlılığını azaltmayı içeriyorsa (DR/iş sürekliliği hedefleriyle).
• Birleşme-satın alma gibi nedenlerle farklı bulutlar zaten kuruma girmişse.
• Uyumluluk veya veri yerleşimi iş yüküne göre farklı platformları gerektiriyorsa.

En pratik ara model: “Birincil bulut + sınırlı ikinci bulut”

Birçok organizasyonda en yönetilebilir yaklaşım, bir sağlayıcıyı varsayılan platform ilan edip ikinci sağlayıcıyı yalnızca net tanımlı senaryolarda kullanmaktır (ör. belirli bir analitik iş yükü veya DR). Bu, çoklu bulutun avantajlarını “tam iki kat operasyon”a dönüştürmeden yakalama şansı verebilir.

Uygulama planı: 30-60-90 gün kontrol listesi

İlk 30 gün: Görünürlük ve envanter

• Uygulama envanteri: kritik iş yükleri, veri sınıfları, RTO/RPO hedefleri.
• Maliyet envanteri: en büyük fatura kalemleri, ağ akışları, veri çıkışı noktaları.
• Kimlik envanteri: kullanıcılar, servis hesapları, erişim rollerinin listesi.

60 gün: Standartlar ve otomasyon

• Asgari güvenlik standardı (IAM, şifreleme, log, yedekleme) dokümante edin.
• Tagging standardı ve maliyet raporlama (FinOps) temelini kurun.
• Konfigürasyon doğrulama ve uyarı süreçlerini devreye alın.

90 gün: Sürekli iyileştirme ve kararın “kanıtı”

• İş yükü başına TCO karşılaştırmasını güncelleyin (egress dahil).
• Olay müdahalesi tatbikatı yapın (iki bulut varsa iki bulut senaryosu).
• Uyumluluk kanıtlarının toplanma süresini ölçün ve darboğazları giderin.

Sık yapılan hatalar (ve hızlı düzeltmeler)

• Hata: Çoklu bulutu “sigorta” gibi görüp operasyonu planlamamak.
  Düzeltme: İkinci bulutun hangi iş yükleri için kullanılacağını yazılı kural haline getirin.
• Hata: Egress’i ölçmeden mimariyi kilitlemek.
  Düzeltme: Veri akışını çıkarın; resmi veri transfer fiyat sayfalarıyla senaryo bazlı hesap yapın.
• Hata: IAM ve logları her bulutta ayrı ayrı yönetmek.
  Düzeltme: Merkezi kimlik yaklaşımı ve birleşik telemetri hedefleyin.
• Hata: Uyumluluğu proje sonuna bırakmak.
  Düzeltme: Kontrol eşleme ve kanıt toplama hattını en başta tasarlayın.

Sonuç: “En iyi seçenek” değil, “en iyi gerekçelendirilmiş seçenek”

Tek bulut, çoğu ekip için daha hızlı standartlaşma ve daha düşük operasyonel yük sağlayabilir. Çoklu bulut ise doğru gerekçelerle seçildiğinde esneklik ve risk dağıtımı getirebilir; fakat maliyetin (özellikle egress ve operasyon) ve güvenlik/uyumluluk karmaşıklığının artabileceğini en baştan kabul etmek gerekir.

Kararınızı netleştirmek için şunu hedefleyin: 1) veri akışını ölçün, 2) TCO’yu egress dahil çıkarın, 3) güvenlik ve uyumluluk kontrollerini iş yükü bazında standardize edin, 4) FinOps ile maliyeti operasyonel olarak yönetin.