IPv4 Adres Maliyetlerini Neler Etkiliyor?
IPv4 adresleri, barındırma ve ağ bütçesinde ayrıca değerlendirilmesi gereken bir kaynaktır. Gider; adres sayısına, tahsis veya kiralama koşullarına ve hizmet paketine göre değişir. Güncel bütçe için aynı kaynak ve sözleşme koşullarını kapsayan tarihli teklifler alın; farklı dönemlerdeki ilan fiyatlarını doğrudan karşılaştırmayın.
IPv4 maliyetlerini etkileyen arz ve talep koşullarını, adres bloğu satın alma ile kiralama arasındaki farkları ve operasyonel giderleri ele alacağız. Ardından SNI, reverse proxy, özel ağlar, paylaşımlı çıkış ve IPv6 seçeneklerini inceleyerek hangi adreslerin gerçekten gerekli olduğunu belirleyeceğiz. Hedef, erişim ve işletim gereksinimlerini koruyarak toplam maliyeti değerlendirmek.
Eğer siz de “Her yeni VPS veya dedicated sunucuya IP ekledikçe fatura neden bu kadar şişiyor?” diye düşünüyorsanız, ya da elinizde sınırlı sayıda IPv4 ile onlarca, hatta yüzlerce projeyi servis etmek zorundaysanız, bu rehberde IP kullanımını azaltmaya yönelik yaklaşımları bulacaksınız.
IPv4 Piyasasının Temelleri: Maliyeti Belirleyen Etkenler
IPv4 Adres Alanının Sınırı
IPv4, 32 bitlik adres alanıyla yaklaşık 4,3 milyar farklı adres değeri sağlar. Bunların tamamı genel İnternet kullanımı için ayrılmamıştır. Ayrıca her telefon, sunucu veya mikroservisin ayrı bir genel IPv4 adresine ihtiyacı yoktur; özel ağlar ve uygun ortak giriş/çıkış noktaları adres paylaşımını mümkün kılar.
Adreslerin bir kısmı özel ağlar (NAT için kullanılan 10.0.0.0/8, 192.168.0.0/16 gibi bloklar) ve özel amaçlar için ayrıldığı için, gerçek anlamda global yönlendirilebilen IPv4 adres havuzu çok daha sınırlı. Bölgesel İnternet Kayıtları (RIR’ler) – RIPE NCC, ARIN vb. – üzerinden tahsis olanakları bölgeye ve programa göre değişiyor. Geri dönen adreslerin yeniden tahsisi, toplam IPv4 adres alanını büyütmüyor. Sınırlı arz fiyatlar üzerinde baskı yaratabilse de piyasaya sunulan blok miktarı ve talep zamanla değişebilir.
IPv4 tükenmesinin tarihsel arka planı adres arzını anlamak için ek bağlam sunar. Bu tarihsel açıklamayı güncel satın alma ve kiralama teklifleriyle birlikte değerlendirin.
İkincil Pazar ve Blok Ticareti
Adres bloğu satın alma, ilgili bölgesel kayıt kuruluşunun (RIR) transfer kuralları kapsamında kayıtlı kaynak sahibinin değişmesini gerektirir; satış sözleşmesi tek başına transfer onayı değildir. Örneğin ARIN, gönderen ve alıcının uygunluğu, yetkili başvuru, gerekli belgeler ve uygulanabilir ücretler için kendi kurallarını yayımlar. Diğer RIR’lerin koşulları farklı olabilir. Satıcının kayıtlı yetkisini, kaynak üzerindeki uyuşmazlıkları, sağlayıcının yönlendirme kabulünü ve gerekli RPKI/ROA ile IRR kayıtlarını işlemden önce doğrulayın.
Kiralama, sözleşmede belirtilen süre ve koşullarla kullanım sağlar; kiracıyı kendiliğinden kayıtlı kaynak sahibi yapmaz. Rota duyurusunu kimin yapacağını, kayıtlı sahibin yönlendirme kayıtlarını nasıl koordine edeceğini, yenileme ücretini ve sözleşme bittiğinde adres değiştirme planını netleştirin. Satın alma peşin sermaye ve uygulanabilir kayıt/bakım ücretleri gerektirebilir; kiralama ise dönemsel ücret ve yenileme riskini öne çıkarır. Teklifleri aynı planlama döneminde, mühendislik ve taşıma giderleriyle birlikte karşılaştırın. Yüksek talep sürekli değer artışı veya belirli bir yatırım getirisi garanti etmez.
Veri Merkezi, Bulut ve AI İş Yüklerinin Adres İhtiyacı
Video, oyun, SaaS ve yapay zekâ iş yükleri; dış API’ler, kullanıcı erişimi veya karşı tarafın IP izin listeleri nedeniyle genel IPv4 gerektirebilir. Bu, her yeni sunucu veya konteynere ayrı bir genel adres atanması gerektiği anlamına gelmez. Özel ağ, ortak uç noktalar ve IPv6 uyumluluğu gerçek ihtiyacı belirler.
Veri merkezi kapasitesi ve AI iş yükleri ağ ve sunucu planlamasına ilişkin ek bir rehberdir. Bir iş yükünün büyümesinden, piyasa genelindeki IPv4 fiyatlarına ne kadar etki ettiği sonucunu çıkarmak için ayrıca veri gerekir.
IPv4 Ücretlerinin Hosting ve İşletme Bütçesine Etkisi
VPS, Dedicated ve Colocation’da IP Giderini Ayırmak
Bir IPv4 adresi sunucu paketine dahil olabilir veya ayrı ücretlendirilebilir. Dahil adres sayısını, ek adres ücretini, kurulum giderini, sözleşme süresini ve adres iade koşullarını kaydedin. Pakete dahil adresin ayrı bedeli belirtilmiyorsa bu bileşeni bilinmeyen olarak işaretleyin; toplam ücrete ikinci kez eklemeyin. Adresi bırakmak, paket bedeli değişmiyorsa faturayı azaltmayabilir. Proxy veya NAT tasarımını değerlendirirken ağ geçidi, yedeklilik, trafik, taşıma, izleme ve devam eden işletim giderlerini de hesaba katın.
Adres sayısı ve ücretlendirme koşulları özellikle şu yapılarda incelenebilir:
- Her müşteri için ayrı dedicated IPv4 isteyen ajanslar ve SaaS sağlayıcıları
- Çok sayıda IP gerektiren e-posta altyapıları (IP havuzları, IP ısıtma vb.)
- Her test ortamı ve her mikroservis için ayrı IP tahsis eden yapılar
- Eski alışkanlıkla “her domain’e bir IP” veren klasik hosting yaklaşımları
Bu tasarımlar bazı uyumluluk veya itibar gereksinimlerini karşılayabilir. Her tahsisin gerekçesi ve faturaya etkisi belgelenmezse gereksiz adresleri ayırt etmek zorlaşır; tek başına adres sayısından maliyet veya verimsizlik sonucu çıkarmayın.
Çoklu IP Kullanan Projelerde Risk ve Gereksiz Harcama
Varsayımsal bir e-ticaret projesinde canlı, staging ve test ortamlarının web ve API uçlarına ayrı IPv4’ler atandığını düşünelim. E-posta ve raporlama servisleri de eklenince tahsis sayısı büyüyebilir. Uyumlu HTTP/S servislerini bir reverse proxy ve sanal host yapısında toplamak adres ihtiyacını azaltabilir; taşıma öncesinde TLS, kapasite, yetkilendirme, müşteri izin listeleri ve kesinti/geri dönüş gereksinimleri test edilmelidir.
Çok kiracılı SaaS projelerinde ayrı IP; müşteri izin listeleri, protokol veya lisanslama gereksinimi nedeniyle gerekebilir. Böyle bir zorunluluk yoksa SNI destekleyen istemciler ve doğru TLS sunucu yapılandırmasıyla birden fazla HTTPS alan adı aynı IP’yi kullanabilir. Bu, kiracı izolasyonunu kendiliğinden sağlamaz; uygulama yetkileri, veri ayrımı ve sertifika doğrulaması ayrıca korunmalıdır. Kaç sitenin taşınabileceği kapasite ve iş yüküne bağlıdır.
IPv4 Tasarrufu İçin Teknik Stratejiler
Tek IP’de Çok Site: SNI, Reverse Proxy ve Sanal Host’lar
Yeni tahsis istemeden önce mevcut adreslerin hangi gereksinimleri karşıladığını inceleyin. Uygun HTTP/S iş yükleri için şu seçenekler değerlendirilebilir:
- HTTP reverse proxy: Uyumlu web sitelerini ortak ön uçta karşılayıp doğru arka uçlara yönlendirmek; kapasite, erişim kontrolü ve yedekliliği ölçmek.
- SNI ile TLS: İstemci ve sunucu desteğiyle aynı IP üzerinde farklı alan adlarına uygun sertifikaları sunmak.
- İç ağda özel adresler: RFC 1918’deki 10.0.0.0/8, 172.16.0.0/12 veya 192.168.0.0/16 aralıklarını, ağlar arasında çakışmayacak biçimde planlamak; dış erişim gereken yerde uygun giriş/çıkış ağ geçidi kullanmak.
Bu tasarım uygun servislerde genel IPv4 ihtiyacını azaltabilir. Özel IP, NAT veya ortak proxy; kimlik doğrulama, güvenlik duvarı ve iş yükü izolasyonunun yerine geçmez. Proxy’nin IPv6 arka uç bağlantısı ve uygulama uyumluluğu doğrulanırsa sonraki IPv6 geçişinde de kullanılabilir.
E-posta Altyapısında IP Havuzunu Optimize Etmek
E-postada adres kararı yalnız gönderim hacmine göre verilmez. Paylaşımlı çıkış aynı IP itibarını da paylaşır; işlemsel e-posta ile kampanya trafiğinin ayrımı, alıcı ağların kabul koşulları ve kötüye kullanım yönetimi birlikte değerlendirilmelidir.
Pratikte yapılabilecekler:
- Gönderim akışlarını ve itibar sorumluluğunu belirleyerek hangi trafiğin ortak IP kullanabileceğini değerlendirin.
- Paylaşımlı ve özel IP seçeneklerini gönderim hacmi, alıcı beklentileri ve kötüye kullanım riskiyle karşılaştırın; tek bir hacim eşiği herkes için geçerli değildir.
- Yeni IP’ye geçerken gönderim davranışını ve alıcı geri bildirimlerini izleyin; ısıtma veya ek IP tek başına teslimat garantisi değildir.
E-posta itibarı ve IP ısıtma rehberi gönderim planlamasına; SPF, DKIM, DMARC ve rDNS rehberi ise kimlik doğrulama ve teslimat kontrollerine yardımcı olur. Adres sayısını artırmadan önce mevcut sorunların kaynağını belirleyin.
NAT, CGNAT ve Paylaşımlı Çıkış Senaryoları
İç sistemlerin paket indirme, güncelleme ve dış API bağlantıları uygun NAT tasarımıyla ortak IPv4 çıkışı kullanabilir. Genel İnternet’ten gelen bağlantıları karşılamak ayrı bir gereksinimdir; gereken protokole göre proxy, VPN ağ geçidi veya açıkça tanımlanmış port eşlemesi planlanır.
- İstemcilerin başlattığı web/API bağlantıları için gereken giriş uçlarını ve protokol desteğini tanımlayın.
- İç sistemlerin dışarıya başlattığı bağlantılarda paylaşımın izin listesi, itibar ve kapasite gereksinimlerine uyup uymadığını değerlendirin.
Ortak çıkışta port/oturum kapasitesini, bağlantı hatalarını, dış servislerin IP bazlı limitlerini ve ortak itibar etkisini ölçün. Bir oturumu kaynak servise bağlamak gerekiyorsa protokol, iç kimlik, çevrilmiş kaynak IP/port ve zaman bilgisini uygun erişim/saklama koşullarıyla kaydedin; ortak IP tek başına servisi tanımlamaz. Ağ geçidinin arızası ve geri dönüşü için de plan gerekir. Kullanılabilecek NAT veya proxy desteğini seçilen hizmet için sağlayıcıyla doğrulayın.
IPv6 Geçişi: Uyumluluk ve Adres İhtiyacı
Geçiş Kararını Kendi Ağınızla Ölçmek
IPv6 seçeneğini kullanıcı ağları, uygulama bağımlılıkları ve sağlayıcının sunduğu bağlantıyla değerlendirin. Geçiş önceliğini genel bir benimseme oranından önce kendi erişim ve adres ihtiyaçlarınızla belirleyin. Bir pilotta IPv4 ve IPv6 erişimini, hata oranlarını ve gecikmeyi ayrı ölçmek, kendi ortamınız için karar vermenizi sağlar.
IPv6 benimsemesi ve geçiş planı pilot kapsamını belirlemek için ek rehber sunar. IPv6, artık gerekmeyen ücretli IPv4 tahsislerini bırakabildiğiniz ölçüde adres giderini azaltabilir; dual-stack tek başına bu tahsisleri veya ücretleri ortadan kaldırmaz.
Dual-Stack ve IPv6-Only + NAT64/DNS64 Senaryoları
İhtiyaca göre üç yaklaşım değerlendirilebilir:
- Dual-stack: Servisin hem IPv4 hem IPv6 üzerinden çalışması. İki yolun da erişim, güvenlik ve izleme gereksinimleri yönetilir; IPv4 tahsisi devam eder.
- IPv6-only arka uç: Uyumlu iç servislerin IPv6 kullanması. IPv4 ziyaretçiler için IPv4 girişi ve IPv6 arka uç bağlantısı destekleyen ayrı bir reverse proxy veya CDN gerekir.
- IPv6-only istemci ve NAT64/DNS64: DNS64’ün sentezlediği AAAA yanıtı ve NAT64 çevirisiyle uyumlu IPv4 hedeflerine giden bağlantı kurulması. Yaygın düzen IPv6’dan başlatılan erişim içindir; IPv4 ziyaretçileri kendiliğinden IPv6-only web sunucusuna ulaştırmaz.
IPv6-only VPS ve NAT64/DNS64 seçenekleri konuyu ayrıntılandırır. Geçişten önce gerçek uygulamaları hedef resolver ve çeviri yolu üzerinden test edin: sabit IPv4 adresleri DNS64 sorgusunu kullanmaz; IPv4 varsayan kütüphaneler veya protokoller ayrıca ele alınmalıdır. DNSSEC doğrulamasının nerede yapıldığını belirleyin ve imzalı alan adlarını sınayın; DNSSEC’i genel çözüm olarak kapatmayın.
DNS ve Uygulama Katmanında Dikkat Edilecekler
AAAA kaydı bir alan adını IPv6 adresine bağlar; kaydı yayımlamak servisi yapılandırmaz. Yanlış veya hazır olmayan hedefe yönelen kayıt, IPv4 yolu çalışsa bile bazı istemcilerin bağlantısını bozabilir.
DNS tarafında dikkat etmeniz gerekenler:
- Yalnız yayımlanacak servis adları için, IPv6 yönlendirmesi, dinleyici, TLS, güvenlik duvarı ve uygulama bağımlılıkları doğrulandıktan sonra AAAA kaydı ekleyin.
- Gereken IPv6 PTR kayıtlarını, özellikle e-posta için, adresi yöneten tarafla yapılandırın ve ileri/ters çözümlemeyi kontrol edin.
- DNSSEC kullanıyorsanız A ve AAAA yanıtlarının imzalama/doğrulama zincirini kontrol edin. Geçiş ve geri dönüşte DNS önbellek sürelerini hesaba katın; kaydı silmek önbellekteki yanıtları veya kurulmuş bağlantıları hemen sonlandırmaz.
A, AAAA, CNAME, MX, TXT, SRV ve CAA kayıtları rehberi kayıt türlerinin görevlerini açıklar. Yayımlanacak ad ve adresleri uygulamanın gerçek erişim yollarıyla eşleştirin.
E-posta ve IPv6: Sadece IP Değil, İtibar Meselesi
E-posta için IPv6 geçişini web erişiminden ayrı test edin. Alıcı ağların IPv6 kabulü, gönderici kimliği ve itibar koşulları teslimatı etkiler; ek adres ailesinin bulunması tek başına yeterli değildir.
IPv6 üzerinden e-posta göndermek istiyorsanız:
- Gönderim IPv6’sı için PTR ve HELO/EHLO adını, ileri çözümlemeyi ve alıcı gereksinimlerini doğrulayın.
- Kullanılan SPF yetkilendirmesinin yeni gönderim IPv6’sını kapsadığını denetleyin; doğrudan adres ağı tanımlanacaksa ip6 mekanizması bu amaç içindir.
- DKIM imzasını ve DMARC hizalamasını test edin. Yalnız IPv6’ya geçmek DKIM anahtarını veya DMARC politikasını değiştirme zorunluluğu doğurmaz; imzalama veya alan adı düzeni değişirse bunları ayrıca değerlendirin.
- İlgili engel listeleri ve alıcı sonuçlarını izleyin; IPv4-only alıcılar için gereken teslimat yolunu koruyun.
Bu detayları IPv6 ile e-posta teslimini rayına oturtma rehberimizde adım adım anlattık. IPv6, e-posta için IPv4 gereksinimini tamamen kaldırmaz; yalnızca IPv4 destekleyen posta sunucularıyla iletişim için IPv4 erişimi gerekir.
IP Envanteri ve Bütçe Yönetimi
Kullanılmayan IPv4’leri Bulup Serbest Bırakmak
Varsayımsal bir işletmede, yıllar önce açılmış test ve proje ortamlarına ait adreslerin envanterde sahipsiz kaldığını düşünelim. Trafik azlığı, bir adresin bırakılabileceğini kanıtlamaz; adres seyrek çalışan işlere, müşteri izin listelerine veya kurtarma erişimine hizmet ediyor olabilir.
Yapılabilecekler:
- Tüm VPS, dedicated ve colocation ortamları için tahsis edilen, kullanılan ve ücretlendirilen adresleri ayrı kaydedin.
- Her IP’ye servis sahibi, müşteri/proje, ortam ve erişim gereksinimi atayın.
- Bırakma adaylarının DNS, dinleyici, NAT, erişim listesi, e-posta, izleme ve kurtarma bağımlılıklarını kontrol edin; kalan kullanımı taşıyıp test etmeden adresi iade etmeyin.
- Geri dönüş yolunu ve sağlayıcının iade sürecini planlayın. Tahsis azaltmanın paket/lease ücretine gerçekten yansıyıp yansımadığını doğrulayın.
Envanter, gereksiz yeni tahsisleri önlemeye yardımcı olabilir. Mevcut bir adresi yeniden kullanmak ile ücretli tahsisi iptal edip nakit gideri azaltmak farklı sonuçlardır; ikisini bütçede ayrı gösterin.
IP Planlama, Dokümantasyon ve Otomasyon
IP adreslerini bir Excel dosyasında takip edip, her değişiklikte manuel güncellemek bir yere kadar iş görüyor. Ölçek büyüdükçe hata yapma riski artıyor ve kullanılmayan IP’leri fark etme şansınız azalıyor.
Daha sağlıklı yaklaşımlar:
- IPAM (IP Address Management) araçları veya en azından merkezi bir envanter sistemi kullanmak
- Terraform, Ansible gibi araçlarla yeni sunucu kurulurken IP atamasını ve DNS kayıtlarını otomatize etmek
- Faturalandırma sistemiyle IP envanterini entegre ederek, “hangi proje ne kadar IP maliyeti yaratıyor” sorusuna hızlı cevap verebilmek
Otomasyonun yararı, atama ve bırakma işlemlerinin kayıtla birlikte güncellenmesidir. Sağlayıcı API’sinin ve kullanılan araçların desteklediği işlemleri doğrulayın; otomasyonu önce test edin ve beklenmeyen DNS ya da adres değişikliğine karşı geri dönüş kaydı tutun.
Altyapı Seçiminde IP Verimliliği
IP Verimliliği Odağında VPS, Dedicated ve Colocation
Ağ mimarisi tasarlanırken IPv4 adres kıtlığı bir tasarım parametresi olarak ele alınabilir. Değerlendirilebilecek seçenekler:
- Paylaşımlı web hosting ve pek çok VPS senaryosunda, tek IPv4 üzerinden çoklu domain yayınlamayı değerlendirmek.
- Dedicated IPv4 tahsisinde gerçekten gerekli IP sayısını analiz etmek.
- Colocation için kendi IP bloklarınızın yönlendirme koşullarını ve güvenlik sorumluluklarını sağlayıcıyla netleştirmek.
Amaç, gerekçesi olmayan tahsisleri azaltırken gerekli müşteri erişimini ve işletim sorumluluklarını korumaktır. Seçtiğiniz sağlayıcının desteklediği özellikleri ve danışmanlık kapsamını ayrıca doğrulayın.
IPv6 Desteği ve Gelecek Odaklı Mimariler
Yeni altyapılarda sağlayıcının IPv6 desteği ve uygulamaların uyumluluğu değerlendirilerek dual-stack planlanabilir.
Sağlayıcı desteği ve uygulama uyumluluğu doğrulandığında şu hedefler değerlendirilebilir:
- Uygun iş yüklerinde genel IPv4 ihtiyacını azaltmak.
- Çalışan IPv6 bağlantısı olan istemcilere yerel IPv6 erişimi sunmak.
- Her iki yolun gecikmesini, hata oranını ve işletim maliyetini ölçerek tasarımı geliştirmek.
IPv4 tahsisleri ancak kalan bağımlılıklar kaldırılıp adresler geri alındığında azalır. Dual-stack, tek başına bir tasarruf sonucu değil, uyumluluk seçeneğidir.
Önümüzdeki 3-5 Yıl: Ne Beklemeli, Nasıl Hazırlanmalı?
Önümüzdeki birkaç yıl için IPv4 fiyatlarının yönü kesin değil; sınırlı arz tek başına fiyat artışını garanti etmez. Dolayısıyla, işletmelerin ve geliştiricilerin kendilerine şu soruyu sorması gerekiyor: “IPv4’ü sınırsız, ucuz ve her projeye bolca dağıtabileceğim bir kaynak değil, kıymetli ve kısıtlı bir varlık olarak yeniden nasıl konumlandırırım?”
Bu yazıda anlattığımız stratejiler – IP tasarrufu, reverse proxy ve SNI ile tek IP’de çok site yayımlama, e-posta IP havuzunu optimize etme, IPv6 geçişini hızlandırma, IP envanteri ve otomasyonu ciddiye alma – aslında aynı sorunun pratik cevapları. Mimari tasarımda IP planlamasını CPU, RAM ve depolama ile birlikte değerlendirmek gerekir.
Yeni proje veya kapasite artışı için DCHost’tan ya da başka bir sağlayıcıdan teklif alırken adres listesini, erişim gereksinimlerini ve planlama dönemini paylaşın. Dahil/ek IP ücretlerini, IPv6 kullanılabilirliğini, yönlendirme koşullarını ve sunulabilecek desteğin kapsamını yazılı olarak netleştirin. Son kararı yalnız IP sayısıyla değil, geçiş ve işletim giderleri dahil toplam maliyetle verin.
