Toplu Hosting Alımı: Şirket Bütçesi Planlama Rehberi (2026)

Toplu hosting alımı bir “adet artırma” işi değildir; doğru plan yapılmazsa aynı ay içinde kapasite açığı, yedekleme maliyeti ve destek/SLA giderleri nedeniyle bütçe sapar. Bu rehberde şirketiniz için toplu hosting alımını kaynak ve risk odaklı ele alacaksınız. 12 aylık bütçeyi, senaryo bazlı nasıl çıkaracağınızı; CPU/RAM/disk, yedekleme, bant genişliği ve yönetim işçiliklerini hangi kalemlerle hesaplayacağınızı net biçimde göreceksiniz.

Toplu hosting alımı neyi değiştirir? (Bütçe etkisi)

Tek tek hosting almak yerine paketli/cluster mantığında ilerlediğinizde fiyatlar sadece birim maliyetten ibaret kalmaz. Şirket ölçeğinde asıl farkı yaratan kalemler şunlardır:

• Kaynak ölçümü: “Ne kadar site” değil, her site için gerçek yük profili (CPU/RAM/IO) ve büyüme hızı.
• Operasyon maliyeti: Kurulum, güncelleme, güvenlik yamaları, log analizi ve talep yönetimi.
• Yedekleme (backup) modeli: Snapshot mi, dosya + veritabanı kopyası mı; saklama süresi ve geri dönüş (restore) süresi.
• SLA ve destek: “Hızlı yanıt” talebi bütçede saatlik/dönemsel karşılık bulur.
• Taşınma (migration): İlk kurulum maliyeti çoğu zaman sonraki aylara yayılmaz; proje bütçesine gider.

Bu nedenle toplu alımda hedefiniz şu olmalı: her sunucu/VPS/VDS veya web hosting kümesi için standart birim maliyet + risk primi + operasyon işçilik payı belirlemek.

İlk adım: Varlıkları ve kullanım türünü envanterleyin

Bütçe planlamanın temel girdisi envanterdir. Envanteri aşağıdaki şablonla çıkarın:

• Uygulama türü: WordPress, özel panel, statik site, API, e-ticaret vb.
• Trafik profili: ziyaret sayısı değil, hafta içi/sonu piki saatleri
• Veri profili: kullanıcı verisi, dosya yükleme, veritabanı boyutu
• Yedekleme hassasiyeti: geri dönüş süresi hedefi (RTO) ve veri kaybı kabulü (RPO)
• Yönetim modeli: tamamen yönetilen (managed) mi, yarı yönetimli mi

Bu envanter olmadan “adet” üzerinden bütçe yapmak, proje bitmeden kapasite açığı ve yeniden alım riskini büyütür.

Kaynak bazlı bütçe planı: 4 kalem, net hesap mantığı

Toplu hosting bütçesini 4 ana kalemde toplayın. Her kalem için “en kötü” senaryoyu da düşünün.

1) Barındırma (compute + disk) maliyeti

Hangi teklifleri karşılaştıracağınız net olmalı. Sunucu/instance için minimum veri seti:

• vCPU (CPU çekirdeği)
• RAM
• SSD/NVMe disk tipi ve IO performansını etkileyen sınırlar
• Disk kapasitesi + büyüme payı (ör. yıllık %30)

Bütçe formülünü basitleştirelim: - Aylık barındırma = (kullandığınız instance adedi) × (birim aylık fiyat)

Burada “kullandığınız instance adedi” kritik: birden çok site tek kaynağa bindirilirse (multi-site) kaynak paylaşımı maliyet düşürür, ama izolasyon zayıflar.

2) Bant genişliği ve transfer (transfer) maliyeti

Şirket sitelerinde bant genişliği iki nedenle sapar: - SEO büyümesiyle trafik artışı - Dosya indirme/yükleme (medya, log, kurulum dosyaları)

Karşılaştırmada sadece “GB” yazısına bakmayın. Şunları sorgulayın:

• Outbound transfer (çıkış) nasıl hesaplanıyor?
• Trafik piki saatlerinde throttle (kısıtlama) var mı?
• CDN kullanacaksanız origin egress nasıl etkileniyor?

Bütçeye ekleyin: - Aylık bant = beklenen outbound × birim fiyat (veya paket)

3) Yedekleme (backup) maliyeti ve saklama süresi

Toplu alımda yedekleme en sık bütçe sürprizidir çünkü saklama süresi uzadıkça maliyet artar.

Net plan için şu kriterleri belirleyin:

• Yedekleme sıklığı: günlük / saatlik
• Saklama süresi: 7/14/30/90 gün
• Saklama türü: dosya + veritabanı mı, sadece snapshot mu
• Restore (geri yükleme) SLA: “kaç dakikada ayağa kalkar”

Bütçe kalemi: - Aylık yedek = (yedekleme paketi) + (ek saklama/ek geri yükleme opsiyonları)

Önemli kontrol: Snapshot ile “gerçek backup” her zaman aynı şey değildir. Dosya düzeyinde geri dönüş, veritabanı tutarlılığı ve test gereksinimleri netleştirilmelidir.

4) Yönetim, güvenlik ve destek (managed hizmetler)

Bütçede görünmeyen ama toplam maliyeti belirleyen kalem işçilik ve destek kalitesidir.

Şu başlıkları tekliflerde yazılı hale getirin:

• Güvenlik güncellemeleri: OS + uygulama yamaları kim yapacak?
• WAF/Brute force koruması var mı?
• İzleme ve alarmlar: CPU/RAM/disk/servis down logları kim takip edecek?
• Incident yönetimi: “kırmızı durum” eskalasyon planı

Bütçeye ekleyin: - Aylık yönetim = (managed paket) veya (destek SLA bedeli) + (ek danışmanlık/kurulum)

Teklifleri aynı metrikle kıyaslayın: kontrol listesi

Toplu alımlarda sağlayıcılar “fiyatı düşük” gösterip farklı sınırlar koyabilir. Aşağıdaki kontrol listesiyle karşılaştırmayı standartlaştırın.

SLA ve performans kıyasındaki net soru seti

• CPU kullanımında limit ve burst var mı?
• “Paylaşımlı kaynak” varsa gürültü (noisy neighbor) yönetimi nasıl?
• Storage için IOPS/throughput limiti var mı?
• Ağ tarafında paket kaybı ve latency takibi nasıl yapılır?

Yedekleme ve geri dönüş için net şartlar

• Yedekler hangi noktada saklanıyor (aynı DC içinde mi, farklı lokasyon var mı)?
• Restore testi sunuluyor mu veya nasıl doğrulanıyor?
• Restore süresi RTO hedefinize uyuyor mu?

Bütçeyi koruyan madde: ölçeklenebilirlik

• Ek kaynak eklendiğinde birim fiyat aynı mı artıyor?
• Taşınma (migration) hizmeti fiyata dahil mi?
• İlk 30-60 gün “geçiş” izlenebilirliği var mı?

Bu soruların yanıtı, toplu alımda “en ucuz” teklif yerine “en düşük toplam maliyet” seçimini sağlar.

Senaryo bazlı bütçe: 3 planla karar verin

Aynı şirket içinde farklı büyüklükte iş yükleri olacağı için 3 senaryo hazırlayın. Böylece teklif geldiğinde tek sayıya değil, aralığa karar verirsiniz.

Senaryo A: Temkinli (düşük büyüme)

• Trafik artışı aylık %10
• Yedekleme: günlük + 14 gün saklama
• Yönetim: yarı yönetimli (kritik yamalar sağlayıcıda)

Bütçe için pratik yaklaşım: - Mevcut kaynaklar × 1.0 - Yedekleme saklama 1 seviye - Bant için paket/limit marjı %15

Senaryo B: Dengeli (orta büyüme)

• Trafik artışı aylık %20
• Yedekleme: saatlik kritik servis + günlük genel + 30 gün
• Yönetim: tamamen yönetilen (managed) veya güçlü SLA

Bu senaryoda maliyeti büyüten başlık: - Yedek saklama süresi ve geri yükleme ek yükü - Managed destek saatleri veya SLA primi

Senaryo C: İleri (piki yüksek ve büyüme hızlı)

• Trafik artışı aylık %30-40
• Yedekleme: saatlik + 90 gün (uygulama ve veri kritikse)
• Mimari: cache/CDN + origin izolasyonu

Burada hosting bedelinden çok operasyon ve ağ maliyeti artabilir. Toplu alım için en kritik nokta: - Kaynak izolasyonu (tek instance üzerinde çok iş yükü sıkıştırmamak)

Örnek toplu alım modeli: karar ağacı (net)

Aşağıdaki karar ağacı, “hosting türü” seçimini bütçeyle birlikte düşünmenizi sağlar.

Hızlı seçim kuralı

• Tek uygulama / net kaynak ihtiyacı: VDS/VPS (veya VDS) ile ölçek
• Birden çok site aynı işletim mantığında: yönetimi kolaylaştırmak için panel + kurumsal yapı
• Yüksek izolasyon ve kapasite kontrol: dedicated veya güçlü managed VDS

Ne zaman toplu alım paket kârlıdır?

Toplu alım şu durumda bütçeyi düşürür: - Sunucu konfigürasyonları benzer iş yükleri için standartlaştırılabiliyorsa - Yedekleme planı aynıysa (14/30/90 gün) - Taşınma süreçleri aynı migrasyon aracılığıyla yapılabiliyorsa

Standartlaştırma yoksa “farklılık maliyeti” artar ve en ucuz birim fiyat avantajını kaybedersiniz.

12 aylık bütçe tablosu şablonu

Aşağıdaki tabloyu doldururken “adet” ve “birim maliyet”i sağlayıcının verdiği teklif formatıyla yazın. Bu çalışma NetKıyas benzeri karşılaştırma yaparken de aynı şekilde kullanılır.

12 ay sonunda kontrol metriği

• İlk 1-2 ay: kaynak kullanım raporu çıkarın (CPU peak, RAM peak, IO)
• 3-6 ay: yedekleme restore süresi test edin
• 6-12 ay: bant genişliği gerçek değerleriyle plan güncelleyin

Böylece başlangıç bütçesi “tahmin” değil “ölçümle doğrulanmış” hale gelir.

Satın alma öncesi “paha biçilemez” 6 test

Toplu alımda karar vermeden önce sağlayıcıdan veya kendi test ortamınızdan doğrulayın.

1. CPU/RAM test senaryosu: aynı yük profilini 30-60 dakika çalıştırın
2. Disk IO testi: veritabanı veya dosya yoğun senaryoda gecikme ölçün
3. Yedekleme testi: snapshot/backup alındıktan sonra restore işlemini doğrulayın
4. Restore süresi: RTO hedefinize uyuyor mu bakın
5. Latency ölçümü: hedef kullanıcı lokasyonlarına göre ısınmış ölçüm alın
6. Güvenlik olayı simülasyonu: brute force denemesinde WAF/ban davranışı kontrol edin

Bu testler bütçenin sadece maliyet değil, risk maliyeti açısından doğru olmasını sağlar.

Sonuç: Aksiyon planı (hemen yapılacaklar)

Bugün toplu hosting alımı için en doğru yaklaşım, bütçeyi “adet × fiyat” ile değil kaynak + yedekleme + bant + yönetim/SLA kalemleriyle çıkarmaktır. İlk olarak envanterinizi çıkarın, senaryo A/B/C için 4 ana kalemi tabloya yerleştirin ve teklifleri aynı kontrol listesiyle kıyaslayın. Sonrasında ilk 1-2 ay için ölçüm planı (CPU/RAM/IO, bant, yedek restore süresi) ekleyin; 3. aydan itibaren bütçe güncellemesi yapın. Böylece toplu alımda hedefiniz tek seferde düşük fiyat değil, 12 ay boyunca kontrol edilebilir toplam sahip olma maliyeti olur.