VPS ve Bulut Sunucu Maliyetlerini Azaltmak

VPS veya bulut sunucu maliyetlerinin gittikçe arttığını fark edip detaylı bir maliyet analizi yaptığınızda, çoğu zaman faturanın önemli bir kısmının aslında kullanılmayan kaynaklardan geldiğini görürsünüz. Gereğinden büyük seçilmiş sunucular, mesai saatleri dışında açık duran test ortamları, hiç silinmeyen snapshot’lar ve planlanmamış büyümeler… Hepsi tek tek küçük görünür, ama ay sonunda ciddi bir bütçeye dönüşür. Biz DCHost tarafında hem kendi altyapımızda hem de müşterilerimizin projelerinde şunu net biçimde görüyoruz: Doğru boyutlandırma, akıllı rezervasyon (taahhüt) ve otomatik kapatma stratejileri bir araya geldiğinde, performanstan ödün vermeden %20–50 arası tasarruf mümkün.

Bu yazıda, sadece genel tavsiyelerle değil, pratikte uygulayabileceğiniz bir yol haritası ile ilerleyeceğiz. Hangi metriklere bakarak sunucunuzu küçültüp büyüteceğinizi, ne zaman uzun süreli taahhütlerin mantıklı olduğunu, hangi tür iş yüklerinde otomatik kapatma ile ciddi tasarruf yakalayabileceğinizi adım adım anlatacağım. Amacımız: Hem teknik ekip hem de iş tarafı için anlaşılır, uygulanabilir ve DCHost altyapısında doğrudan hayata geçirilebilir bir maliyet optimizasyon rehberi ortaya koymak.

VPS ve Bulut Maliyetlerini Stratejik Yönetmek Neden Bu Kadar Kritik?

VPS ve bulut sunucuların en büyük avantajı esneklik; ancak plansız kullanıldıklarında bu esneklik maliyet sürprizine dönüşebiliyor. Özellikle SaaS, e‑ticaret ve ajans projelerinde şunları çok sık görüyoruz:

• Başlangıçta “güvende olalım” diyerek gereğinden büyük seçilen sunucuların hiç küçültülmemesi
• Load test, staging, demo ve kısa süreli kampanya sunucularının iş bittikten sonra açık unutulması
• Depolama tarafında eski snapshot ve yedeklerin temizlenmemesi, ucuz disk yerine hep en pahalı katmanın kullanılması
• Mevsimsel projelerde (örneğin kampanya siteleri) uzun süreli taahhüt yapılmaması veya tam tersine gereksiz uzun taahhütlere girilmesi

Bu problemler, yalnızca teknik tarafta değil bütçe toplantılarında da kendini gösteriyor. Yönetim maliyetleri düşürmek istediğinde, çoğu zaman nereden başlayacağını bilemiyor. Oysa daha önce yayınladığımız hosting maliyetlerini düşürme rehberinde de anlattığımız gibi, doğru kapasite planlama ve görünürlük ile çok kısa sürede somut kazanımlar elde edilebiliyor.

Adım 1: Doğru Boyutlandırma (Right Sizing) Temelleri

Yanlış Boyutlandırmanın Gerçek Maliyeti

Yanlış boyutlandırma çoğu zaman “gereğinden büyük sunucu” demek. Örneğin:

• Orta ölçekli bir WordPress sitesi için 8 vCPU, 16 GB RAM’li VPS açıp, aylarca CPU kullanımı %10’un altındaysa…
• Küçük bir API servisi için yüksek IOPS’lu büyük NVMe disk alıp, diskin %20’si bile dolmuyorsa…

Bunların hepsi doğrudan cebinizden çıkan para. Tersi de mümkün: Kaynakları fazla kısarsanız, performans sorunları yüzünden kaybettiğiniz ziyaretçi ve gelir, tasarruf ettiğinizi sandığınız paradan çok daha büyük olabilir. Bu yüzden boyutlandırmada hedef; “maksimum küçüklük” değil, “konforlu ve ölçülebilir bir güven payı” olmalı.

WordPress, WooCommerce ve SaaS uygulamaları için tipik CPU/RAM ihtiyaçlarını daha önce WordPress, WooCommerce ve SaaS için kaç CPU, ne kadar RAM gerekir? yazımızda detaylı anlattık. Buradaki tabloları, yeni bir VPS veya bulut sunucu açarken başlangıç noktası olarak kullanabilirsiniz.

CPU ve RAM Boyutlandırma Mantığı

CPU ve RAM, fatura kaleminizde en çok gözüken iki başlık. Doğru boyutlandırma için şu yaklaşım pratik çalışır:

• CPU: Normal yoğunlukta %40–60 arası kullanım hedefleyin. Kısa süreli spike’larda %80–90’a çıkıp sonra geri inmesi makuldür.
• RAM: Kararlı halde %60–75 arası kullanım idealdir. %90 üzerine sürekli çıkıyorsanız RAM artırmayı, %40’ın altında sabit gidiyorsanız azaltmayı düşünebilirsiniz.
• Headroom: Özellikle e‑ticaret ve kampanya sitelerinde CPU ve RAM tarafında %20–30 pay bırakmak, ani trafik artışlarında hayat kurtarır.

Bu oranları sağlamak için top, htop, vmstat gibi temel araçlar yeterli olsa da, bir süre sonra daha ayrıntılı izleme ihtiyacı doğar. Bu noktada VPS kaynak kullanımı izleme rehberimizde anlattığımız htop, Netdata ve Prometheus gibi araçlar işinizi çok kolaylaştırır.

Disk, IOPS ve Trafik Boyutlandırma

Disk kapasitesi seçerken sadece “kaç GB?” sorusuna odaklanmak, maliyet tarafında sık yapılan bir hata. Asıl sorular şunlar olmalı:

• Uygulamanız yüksek IOPS (saniyedeki giriş/çıkış işlemi) istiyor mu, yoksa daha çok sıralı okuma/yazma mı yapıyor?
• Log’lar, yedekler ve geçici dosyalar için ayrı bir daha yavaş/ucuz disk katmanı kullanabilir misiniz?
• Büyük medya dosyalarını (görsel, video) gerçekten VPS üzerinde mi tutmalısınız?

Örneğin WooCommerce gibi disk ve IOPS hassasiyetinin yüksek olduğu projeler için, WooCommerce kapasite planlama rehberimizde NVMe, IOPS ve disk kullanım karakteristiğini detaylandırdık. Buradaki prensipleri yalnızca WooCommerce değil, benzer IO yükü olan tüm projelere uyarlayabilirsiniz.

Adım 2: Ölç, İzle ve Sonra Küçült/Büyüt

Boyutlandırmaya Verisiz Başlamayın

Elinizde tarihsel veri yoksa, ilk seferde birebir doğru boyutlandırma yapmak çoğu zaman mümkün değil. Bizim önerimiz, özellikle kritik projelerde şu adımlar:

1. Projeyi makul bir güven payı ile biraz büyükçe bir VPS veya bulut sunucuda başlatın.
2. En az 2–4 hafta boyunca CPU, RAM, disk IO ve ağ trafiğini ayrıntılı kaydedin.
3. Ziyaretçi pik saatleri, kampanya dönemleri ve batch işlerinin (cron, queue, rapor) yoğun olduğu zamanları işaretleyin.
4. Bu verilere bakarak daha küçük veya daha büyük bir plana geçip geçemeyeceğinize karar verin.

Bu yaklaşım, “kafadan tahmin” ile sunucu seçmenin önüne geçer ve birazdan anlatacağımız rezervasyon (taahhüt) kararlarını da çok daha sağlıklı hale getirir.

İzleme Araçları ve Okumanız Gereken Metrikler

Temel araçlarla başlayıp zamanla daha gelişmiş sistemlere geçmek en mantıklı yol. Örnek bir katmanlı yaklaşım:

• Seviye 1: top, htop, free -m, iostat, vnstat
• Seviye 2: Netdata gibi tek sunuculuk, kurulumu kolay izleme çözümleri
• Seviye 3: Prometheus + Grafana veya benzeri merkezi izleme sistemleri

İzlerken özellikle şu metriklere dikkat edin:

• CPU load ve gerçek CPU kullanım yüzdesi
• RAM kullanımı ve swap aktivitesi (swap’e sık sık düşüyorsanız RAM mutlaka gözden geçirilmeli)
• Disk bekleme süresi (await) ve IO queue derinliği
• Ağ trafiği pikleri (beklenmeyen çıkış trafiği, beklenen ama kapasiteyi zorlayan kampanya pikleri)

Bu metrikleri düzenli takip edip alarmlar kurmayı öğrenmek için, VPS izleme ve alarm kurulumu rehberimiz size iyi bir başlangıç noktası sunar.

Ne Zaman Küçültmeli, Ne Zaman Büyütmeli?

Veri elinizdeyken iş karar vermeye kalıyor. Pratik birkaç eşik değeri şöyle düşünebilirsiniz:

• CPU kullanımınızın büyük kısmı gün içinde %30’un altında, nadiren %60’a çıkıyorsa: Bir alt plana inmek genelde güvenlidir.
• RAM sürekli %80–90 bandında, swap’e düşmeler başlıyorsa: RAM’i artırmak neredeyse şarttır.
• Disk IO “await” değerleriniz yoğun saatlerde yüksekse (örneğin >20–30 ms): Daha hızlı disk veya ayrı veritabanı/önbellek sunucusu düşünebilirsiniz.

Büyütme/küçültme kararını tek seferde radikal yapmak yerine, %20–30’luk adımlarla ve izleme eşliğinde yapmak her zaman daha güvenli. Örneğin 4 vCPU’dan doğrudan 1 vCPU’ya inmek yerine önce 2 vCPU’ya inip birkaç hafta gözlemlemek çok daha sağlıklı bir yol.

Adım 3: Rezervasyon (Taahhüt), Süre ve Planlama Stratejisi

Kısa Vadeli Esneklik vs Uzun Vadeli İndirim Dengesi

Birçok altyapıda, VPS veya bulut sunucuları kısa süreli (aylık) ya da daha uzun süreli (3, 6, 12 ay) taahhütlerle kullanmak mümkün. Uzun vadeli taahhütler genelde birim fiyatı düşürür, ama esnekliğinizi azaltır. Burada kritik soru şudur: “Bu iş yükü gerçekten ne kadar süre bu kapasiteye ihtiyaç duyacak?”

DCHost tarafında gördüğümüz iyi pratiklerden bazıları:

• Çekirdek iş yükleri: Sürekli çalışacak, öngörülebilir trafiği olan kurumsal siteler, API’ler ve SaaS uygulamaları için 6–12 aylık taahhütler çoğu zaman mantıklıdır.
• Sezonluk projeler: Seçim siteleri, kampanya landing page’leri gibi 2–3 ayda yoğunlaşıp sonra kapanan işlerde kısa süreli planlar daha doğrudur.
• Henüz keşif aşamasında olan projeler: Trafik ve gelir modeli tam netleşmemişse öncelik esneklik olmalı; izleme verileri oturana kadar uzun taahhütlere girmemek en sağlıklısıdır.

Taahhüde Girmeden Önce Kontrol Listesi

Uzun süreli bir VPS veya bulut sunucu taahhüdü düşünüyorsanız, şu soruları mutlaka netleştirmenizi öneririz:

• Son 2–3 ayın CPU, RAM, disk ve trafik grafikleri istikrarlı mı?
• Önümüzdeki dönemde mimari değişiklik (örneğin monolitten mikroservise geçiş) planınız var mı?
• Regülasyon, KVKK/GDPR gibi konular nedeniyle veri lokasyonunu değiştirme ihtimaliniz bulunuyor mu?
• Uygulamanız büyüme veya küçülmeye ne kadar esnek uyum sağlayabiliyor?

Bu soruların cevabını netleştirmeden yapılacak taahhütler, maliyet avantajı yerine “kilitlenmiş kapasite” riskine dönüşebilir. Özellikle orta ve büyük projelerde, mimari planlamayı ölçeklendirme yol haritası perspektifiyle ele almak, hem teknik hem finansal tarafta büyük rahatlık sağlar.

Rezerve Kapasiteyi Dinamik Kapasite ile Birlikte Kullanmak

Sık gördüğümüz verimli bir model şöyle çalışıyor:

• Temel, sürekli ihtiyaç duyulan kapasite için DCHost üzerinde daha uzun süreli ve indirimli VPS/bulut sunucu planları kullanılıyor.
• Yoğun kampanya dönemleri veya özel etkinlikler için, kısa süreli ek VPS’ler devreye alınıp iş bitince kapatılıyor.

Böylece, altyapınızın omurgasını oluşturan sunucular için daha düşük birim maliyet yakalarken, ani ihtiyaçlarda sadece kullandığınız kadar ödüyorsunuz. Özellikle yüksek sezon/ düşük sezon dalgalanmaları olan e‑ticaret sitelerinde, bu modelle çok ciddi tasarruf elde edildiğini sahada defalarca gördük.

Adım 4: Otomatik Kapatma ve Zamanlama Stratejileri

Her Sunucu 7/24 Açık Olmak Zorunda Değil

Üretim (canlı) ortamlar için 7/24 kesintisiz erişim tabii ki şart; ancak tüm VPS ve bulut sunucularınız canlı olmayabilir. Özellikle:

• Geliştirme ve test sunucuları
• Demo ortamları
• Kısa süreli POC (Proof of Concept) sistemleri
• Sadece gece çalışan batch iş sunucuları

Bu tür sunucuların mesai dışında otomatik kapatılması, ay sonunda ciddi bir fark yaratır. Örneğin günde 10 saat çalışan bir test VPS’ini 24 saat yerine 12 saat açık tutarak, teorik olarak sunucu maliyetinizi neredeyse yarıya indirebilirsiniz.

Cron, systemd Timer ve API ile Otomasyon

Otomatik kapatma ve açma işlemlerini birkaç farklı yöntemle planlayabilirsiniz:

• Sunucu içinden zamanlama: VPS içinde cron veya systemd timer kullanarak belirli saatlerde kendini kapatmasını sağlayabilirsiniz.
• Harici orkestrasyon: Bir yönetim sunucusundan veya CI/CD hattından API çağrıları yaparak ilgili VPS’leri açıp kapatabilirsiniz.

Cron ile systemd timer arasındaki farkları ve hangi senaryoda hangisinin daha iyi olduğunu merak ediyorsanız, cron mu systemd timer mı? yazımız tam size göre. Daha büyük yapılarda ise Terraform ve Ansible gibi araçlarla, VPS yaşam döngüsünü tamamen otomatik yönetmek mümkün. Bunun için de Terraform ve Ansible ile VPS otomasyonu rehberimize göz atabilirsiniz.

Yanlış Kapatma Riskini Azaltmak

Otomatik kapatma ile ilgili en büyük çekince, yanlış sunucunun kapanmasıdır. Bu riski azaltmak için:

• Sunucularınızı “ortam” (prod, staging, dev, demo) ve “kritiklik” (yüksek, orta, düşük) etiketleriyle sınıflandırın.
• Otomasyon betiklerinin sadece belirli etiketlere sahip sunucularda çalışmasına izin verin.
• Her kapatma öncesi log’a anlamlı bir kayıt düşüp e‑posta veya Slack bildirimi gönderin.
• Otomatik kapanan sunucular için “sabah açılış” zamanlamasını da aynı şekilde otomatikleştirin.

Böylece hem insan hatasını minimize etmiş hem de “Açmayı unuttuk, ekip sabah işe başlayamadı” türü operasyonel sorunların önüne geçmiş olursunuz.

Adım 5: Depolama, Yedek ve Trafik Tarafında Tasarruf Fırsatları

Her Şey En Pahalı Diskte Durmak Zorunda Değil

Depolama maliyetleri, özellikle büyük medya dosyaları, log’lar ve yedekler söz konusu olduğunda hızla şişebiliyor. Burada birkaç temel prensip ciddi tasarruf sağlar:

• Uygulama ve veritabanı için hızlı ve düşük gecikmeli disk (örneğin NVMe) kullanırken, arşiv niteliğindeki log ve eski yedekler için daha ucuz depolama katmanı kullanın.
• Gereksiz snapshot ve eski yedekleri düzenli temizleyin; 1 yıl önceki test ortamı snapshot’ını saklamanın çoğu zaman gerçek bir değeri yok.
• Büyük medya dosyalarını (özellikle görüntü ve video) mümkün olduğunca object storage ve lifecycle policy ile yönetin.

Ayrıca VPS tarafında log’ların diski doldurmasını önlemek için logrotate ayarlarını doğru yapılandırmak kritik önem taşır. Bu konuda detaya girmek isterseniz, VPS disk kullanımı ve logrotate rehberimiz pratik örneklerle neler yapmanız gerektiğini anlatıyor.

Trafik ve Bant Genişliği Maliyetini Yönetmek

Yüksek trafikli sitelerde, özellikle yurt dışı ziyaretçilerin yoğun olduğu durumlarda bant genişliği önemli bir maliyet kalemi olabilir. Şu stratejilerle maliyeti kontrol altında tutabilirsiniz:

• Statik içerikleri (CSS, JS, görsel) CDN üzerinden servis edip origin (VPS) trafiğini azaltmak
• Gzip/Brotli sıkıştırmayı düzgün ayarlayarak gereksiz veri transferini düşürmek
• Dinamik sayfalarda tam sayfa önbellekleme kullanarak tekrarlayan istekleri minimize etmek

Bu tarafta hem bant genişliği maliyetini hem de TTFB’yi birlikte iyileştirmek için, önbellek ve CDN odaklı yazılarımızı da gözden geçirmenizi öneririz.

Adım 6: Organizasyonel Pratikler – Tagging, Bütçe ve Alarmlar

Tag’lenmeyen Kaynak Yönetilemez

Maliyet optimizasyonunun önemli bir kısmı teknik olsa da, organizasyonel disiplin olmadan sürdürülebilir değil. Özellikle birden fazla ekip ve proje aynı altyapıyı kullanıyorsa, her VPS ve bulut sunucusunun en azından şu bilgileri etiket olarak taşıması büyük fark yaratır:

• Proje adı
• Sorumlu ekip veya kişi
• Ortam türü (prod, staging, dev, demo)
• Kritiklik seviyesi
• Planlanan kapanış tarihi (POC, kampanya vb. için)

Bu etiketler sayesinde aylık maliyet raporlarınızı proje ve ekip bazlı hazırlayabilir, hangi bölümün ne kadar kaynak tükettiğini net olarak görebilirsiniz. Aynı zamanda “üç ay önce açılmış ama kimse hatırlamıyor” türü hayalet sunucuların tespitini de çok kolaylaştırır.

Bütçe Limitleri ve Uyarı Mekanizmaları

İyi bir maliyet optimizasyonu, sadece mevcut harcamayı kısmakla değil, gelecekteki sürprizlerin önünü almakla da ilgilidir. Bunun için:

• Aylık veya proje bazlı bütçe limitleri belirleyin.
• Bant genişliği, disk kullanımı ve CPU saatleri için uyarı eşikleri tanımlayın.
• Bu eşikler aşıldığında teknik ekibe ve gerekiyorsa finans tarafına otomatik bildirim gönderin.

DCHost ortamında, bu tür uyarı ve raporlama mekanizmalarını izleme ve faturalama verileri ile birleştirerek daha da görünür hale getirebilirsiniz. Böylece maliyet artışları “ay sonu faturasında sürpriz” olmaktan çıkar, daha yolun başında fark edilir.

DCHost ile Uygulanabilir Maliyet Optimizasyon Planı

Anlattığımız tüm stratejileri tek tek okumak bir şey, bunları sahada uygulanabilir bir plana dönüştürmek ise ayrı bir adım. DCHost ekibi olarak, müşterilerle yaptığımız kapasite planlama oturumlarında tipik olarak şu yol haritasını izliyoruz:

1. Mevcut tüm VPS ve bulut sunucuların envanterini ve etiketlerini (proje, ortam, kritiklik) netleştirmek
2. CPU, RAM, disk ve trafik metriklerini en az 2–4 hafta boyunca toplayıp analiz etmek
3. Her iş yükü için boyutlandırma önerisi hazırlayıp “küçült, olduğu gibi bırak, büyüt” kararlarını netleştirmek
4. Canlı ortamlara dokunmadan önce test/staging üzerinde küçültme senaryolarını denemek
5. Geliştirme, test ve demo ortamları için otomatik açma/kapatma ve yaşam döngüsü politikaları tasarlamak
6. Temel, sürekli kapasite için daha avantajlı DCHost planlarına geçmek; sezonluk yükler için esnek ek sunucular tanımlamak

Böyle ilerlediğinizde, “tek seferlik bir maliyet düşürme operasyonu” yerine, sürekli kendini iyileştiren bir maliyet optimizasyon kültürü oluşturmuş olursunuz. VPS ve bulut tarafında hem performansı yüksek hem de bütçesi öngörülebilir bir mimari kurmak istiyorsanız, DCHost üzerindeki mevcut altyapınızı birlikte gözden geçirebilir, size özel bir optimizasyon planı çıkarabiliriz.

Özetle: Önce ölçün, sonra doğru boyutlandırın, akıllıca taahhüt verin ve otomasyonu devreye alın. Geri kalanı, düzenli takip ve küçük adımlarla gelir. DCHost olarak tam da bu yolculukta yanınızda olmak için buradayız.