Tüm yazılar
Altyapı ve DevOps 2 Temmuz 2026 5 dk Eren Tekin

Bulut Sunucu Seçimi: Fatura Neden Tahmin Ettiğinizden Yüksek Geliyor

Bulut maliyetleri sunucu kirasından değil, hesaba katılmayan kalemlerden şişiyor. Doğru boyutlandırma, veri transferi ve yönetilen hizmet kararlarının maliyete etkisi.

Bulut altyapıya geçen işletmelerin çoğu ilk faturayı gördüğünde şaşırıyor. Sebep genelde sunucu kirasının pahalı olması değil; hesaba hiç katılmamış kalemlerin faturada belirmesi.

Bu yazıda, bulut sunucu seçerken hangi kararların maliyeti belirlediğini ve nerede fazladan ödeme yapıldığını anlatıyoruz.

Önce doğru soru: gerçekten buluta mı ihtiyacınız var

Bulutun asıl değeri esnekliktir: yükün değiştiği, hızla büyüyen veya coğrafi olarak dağılmış sistemler için doğru seçimdir.

Buna karşılık trafiği öngörülebilir, sabit bir kurumsal site için bulut çoğu zaman gereksiz karmaşıklık ve gereksiz maliyet demektir. Böyle bir site için paylaşımlı veya yönetilen barındırma hem daha ucuz hem daha az bakım gerektirir.

Karar kriteri şu: yükünüz ay içinde ikiye katlanıyor mu? Katlanmıyorsa, esnekliğin bedelini ödemenize gerek yok.

Faturayı şişiren beş kalem

1. Aşırı boyutlandırma

En yaygın maliyet hatası budur. "Ne olur ne olmaz" diye alınan büyük sunucu, aylarca yüzde on kapasiteyle çalışır ve tam ücreti öder.

Doğru yaklaşım küçük başlayıp ölçüme göre büyütmektir. Bulutun tüm anlamı zaten budur; sonradan büyütmek dakikalar sürer.

2. Giden veri transferi

Buluta veri göndermek genelde ücretsiz, buluttan almak ücretlidir. Görsel ve video ağırlıklı siteler, medya dosyalarını doğrudan sunucudan servis ettiğinde bu kalem hızla büyür.

Çözüm içerik dağıtım ağı kullanmak. Statik dosyalar önbelleğe alınır, sunucuya giden istek azalır, hem maliyet düşer hem site hızlanır.

3. Unutulan kaynaklar

Test için açılmış ve kapatılmamış sunucular, silinmemiş disk görüntüleri, kullanılmayan yedek anlık görüntüleri. Bunların hepsi sessizce faturalanır.

Ayda bir kaynak envanteri çıkarmak, çoğu projede faturanın belirgin bir kısmını geri kazandırıyor. Etiketleme kullanın: her kaynağa hangi proje ve hangi ortam olduğunu yazın, sahipsiz kaynak kalmasın.

4. Yedekleme ve saklama politikası

Günlük yedek almak iyidir; günlük yedeği sonsuza kadar saklamak pahalıdır. Saklama politikası tanımlanmazsa yedek deposu sürekli büyür.

Makul bir başlangıç: son 7 günlük günlük yedek, son 4 haftalık haftalık yedek, son 12 aylık aylık yedek. Bu, geri dönüş ihtiyacının neredeyse tamamını karşılar ve depolama maliyetini sabitler.

5. Yönetilen hizmetlerin gizli konforu

Yönetilen veritabanı, yönetilen önbellek ve benzeri hizmetler, kendi kurduğunuzdan pahalıdır. Ama bu her zaman kötü bir takas değildir.

Karşılaştırmayı yaparken kendi kurulumunuzun gerçek maliyetini de yazın: kurulum süresi, güncelleme bakımı, yedekleme kurulumu ve bir sorun çıktığında harcanacak saatler. Küçük ekiplerde yönetilen hizmet genelde toplamda daha ucuza geliyor.

Karşılaştırma: hangi model kime uygun

ModelUygun olduğu durumDikkat
Paylaşımlı barındırmaKurumsal site, blog, düşük trafikKaynak sınırları, komşu etkisi
Yönetilen barındırmaBakım ile uğraşmak istemeyen ekipÖzelleştirme sınırlı
Sanal sunucu (VPS)Kontrol isteyen, teknik ekibi olanBakım sizin sorumluluğunuzda
Bulut (esnek)Değişken yük, hızlı büyümeMaliyet takibi şart
Konteyner tabanlıÇok servisli, sık dağıtım yapanOperasyonel karmaşıklık

Konteyner tarafına geçmeyi düşünüyorsanız, karar vermeden önce Docker ve Kubernetes yazımıza bakın; küçük ekipler için genelde erken bir adım oluyor.

Konum seçimi: sadece hız değil

Sunucu konumu iki şeyi etkiler: gecikme ve yasal durum.

Kullanıcılarınız Türkiye'deyse, Avrupa bölgeleri makul gecikme sunar. Uzak bölgeler ucuz görünebilir ama her istekte eklenen gecikme, kullanıcı deneyimini ve dolaylı olarak arama performansını etkiler.

Yasal taraf daha kritik. Kişisel veri işliyorsanız, verinin nerede saklandığı KVKK açısından anlamlıdır. Yurt dışına veri aktarımının kendi kuralları vardır ve altyapı kararı verilirken hukuk tarafına danışılmalıdır.

Yasal taraf için tek bir kaynak takip etmek yeterli: kişisel verinin yurt dışına aktarımına ilişkin kurallar KVKK tarafından yayımlanıyor ve altyapı bölgesi seçilmeden önce okunmalı.

Ölçeklendirme: dikey mi yatay mı

Yük arttığında iki yol vardır. Dikey ölçeklendirme, mevcut sunucuyu büyütmektir: basittir, uygulama değişikliği gerektirmez, ama bir tavanı vardır ve büyütme sırasında kesinti olur.

Yatay ölçeklendirme, sunucu sayısını artırmaktır: teorik tavanı yoktur ve kesintisiz yapılabilir, ancak uygulamanın buna hazır olmasını gerektirir. Oturum bilgisi sunucunun belleğinde tutuluyorsa, ikinci sunucu eklendiğinde kullanıcılar rastgele oturum kaybı yaşar.

Pratik tavsiye: küçük ve orta ölçekli projelerde dikey ölçeklendirme yeterlidir. Yatay yapıya geçmeyi, gerçekten ihtiyaç doğduğunda ve uygulama durumsuz hale getirildikten sonra planlayın.

Kesinti ve kurtarma hedefleri

Altyapı kararının teknik olmayan tarafı şudur: sistem ne kadar süre kapalı kalabilir ve ne kadarlık veri kaybı kabul edilebilir?

Bu iki sorunun cevabı doğrudan maliyeti belirler. Sıfır kesinti ve sıfır veri kaybı hedefi, yedekli altyapı ve sürekli çoğaltma gerektirir; maliyeti kat kat artırır. Buna karşılık "en fazla 4 saat kesinti ve en fazla 1 saatlik veri kaybı kabul edilebilir" diyen bir işletme, çok daha basit ve ucuz bir kurulumla yaşayabilir.

Bu hedefleri altyapıyı kurmadan önce yazılı olarak belirleyin. Sonradan konuşulduğunda, karar hep en pahalı seçenekten yana çıkıyor.

Fatura okuma alışkanlığı

Ayda bir faturayı kalem kalem okumak, bulut maliyet yönetiminin en etkili tek alışkanlığıdır. Aradığınız üç şey var: geçen aya göre yüzde on üzerinde artan kalemler, hiç tanımadığınız hizmet adları, ve sıfıra yakın kullanımı olan ama ücretlendirilen kaynaklar.

Üçüncüsü özellikle verimli. Bir sunucunun aylardır yüzde iki işlemci kullanımıyla çalışıyor olması, o sunucunun ya kapatılabileceğini ya da çok daha küçük bir tipe geçirilebileceğini söyler.

İzleme olmadan optimizasyon olmaz

Maliyeti düşürmenin ilk şartı, neyin ne kadar tükettiğini görmek. Asgari olarak şunlar izlenmeli: işlemci ve bellek kullanımı, disk doluluğu, giden veri miktarı ve aylık maliyetin kalem bazlı dağılımı.

Bütçe uyarısı kurun. Çoğu sağlayıcı belirli bir tutar aşıldığında bildirim gönderebiliyor; bu, sürpriz faturaların önündeki en basit engel.

Ne zaman büyütmeli

Yükselen trafik karşısında refleks olarak sunucu büyütmek yaygın ama genelde yanlış ilk adımdır. Çoğu yavaşlık sorunu kaynak yetersizliğinden değil, optimize edilmemiş sorgulardan ve önbelleklenmemiş içerikten kaynaklanır.

Sıra şöyle olmalı: önce ölç, sonra önbellekle, sonra sorguları düzelt, en son büyüt. Bu sırayı atlayıp doğrudan büyütmek, sorunu çözmez yalnızca erteler ve pahalılaştırır.

Veritabanı tarafındaki tipik darboğazlar için veritabanı tasarımı yazımızda ayrıntılı örnekler var.

Taşınma maliyeti ve bağımlılık

Sağlayıcıya özel yönetilen hizmetleri ne kadar çok kullanırsanız, ileride taşınmak o kadar zorlaşır. Bu her zaman kötü değildir; ama karar bilinçli verilmelidir.

Pratik denge: veritabanı ve dosya depolama gibi taşınabilir bileşenleri standart teknolojilerle kurun, sağlayıcıya özel hizmetleri kritik olmayan katmanlarda kullanın.

Özetle

Bulut maliyetinin kontrolü, ucuz sağlayıcı bulmakla değil, doğru boyutlandırma ve düzenli envanterle sağlanır. Küçük başlayın, ölçün, gerektiğinde büyütün ve ayda bir sahipsiz kaynakları temizleyin.

Mevcut altyapınızı gözden geçirmemizi veya doğru modeli birlikte seçmemizi isterseniz bulut sunucu hizmetimize bakabilir ya da doğrudan yazabilirsiniz.

Anahtar Kelimeler

  • bulut sunucu
  • cloud maliyet
  • sunucu seçimi
  • yönetilen hosting
  • veri transfer maliyeti

Yazar

Eren Tekin

Backend Developer

Modern web teknolojileri, backend mimarisi ve mobil uygulama geliştirme konularında yazıyor.

Bu konuda bir projeniz mi var?

Ücretsiz danışmanlık alın