CDN Trafik Maliyetleri: Origin, Önbellek ve Bölgeler

CDN faturası yalnızca ziyaretçi sayısına bağlı değildir. Yanıt boyutları, istek hacmi, önbellek davranışı ve bölgesel tarifeler toplam gideri değiştirebilir. Özellikle medya ve e-ticaret projelerinde maliyet analizi yaparken CDN’nin kullanıcıya teslim ettiği veriyi, origin sunucunun CDN’ye aktardığı veriden ayrı ölçün.

CDN’in yanlış yapılandırılması gereksiz maliyet oluşturabilir. İncelenecek başlıca etkenler; origin pull trafiğinin kontrolsüz kalması, cache hit ratio’nun (CHR) düşük olması ve bölgesel fiyatlandırma farklarının planlanmaması olarak sıralanabilir. Bu yazıda, bu üç başlığı birlikte ele alıp gerçekçi, uygulanabilir bir maliyet kontrol stratejisi çıkaracağız.

Bu rehber, CDN trafik raporlarını ve faturalarını birlikte okuyup hangi değişikliğin hangi gideri etkileyebileceğini anlamanıza yardımcı olur. WordPress, WooCommerce, Laravel ve medya projelerine uygulanabilen örnekler ile varsayımsal bir tasarruf hesabı içerir; sonuçları kendi trafiğiniz ve tarifenizle doğrulamanız gerekir.

CDN Trafik Maliyetini Neler Artırır?

CDN trafik maliyetlerini değerlendirirken içerik boyutları, coğrafi dağılım ve sağlayıcının fiyatlandırma modeli birlikte ele alınmalıdır:

• Yanıt boyutu: Büyük görseller ve video dosyaları gerçekten indirildiklerinde daha çok veri tüketebilir; aktarımı çözünürlük etiketi yerine ölçülen boyutla değerlendirin.
• Trafiğin dağılımı: Bölgesel ücret varsa farklı teslimat bölgelerinin payı maliyeti değiştirir. Uzak bölge otomatik olarak pahalı bölge değildir.
• Tarife: GB başına ücret, dahil kota, istek bedeli, ek özellik ve aşım ücretleri sağlayıcıya ve pakete göre değişir.

Bu noktada kritik olan, “CDN pahalı” demek değil; hangi trafikten para ödediğinizi kalem kalem anlamak. Bunun için önce faturayı oluşturan ana bileşenlere bakmamız gerekiyor. CDN’lerin genel çalışma mantığını hatırlamak isterseniz, temel kavramları CDN nedir ve web siteniz için avantajları nelerdir başlıklı yazımızda detaylı olarak da anlattık.

CDN Trafik Faturasını Oluşturan Temel Kalemler

CDN kullanımının toplam maliyetini kabaca üç ana kalemde düşünebilirsiniz; origin çıkış trafiği sunucu sağlayıcınızın faturasında yer alabilir:

• Kullanıcıya (edge’ten son kullanıcıya) giden trafik
• Origin pull trafiği (istek: CDN → origin; içerik aktarımı: origin → CDN)
• İstek (request) sayısı ve varsa ek özellikler (WAF, log, görüntü işleme vb.)

Kullanıcıya Giden Trafik

Bazı CDN’ler bölgesel veri aktarımı fiyatlandırması uygular. Bölge grupları ve ücretler sağlayıcıya göre değişmekle birlikte, şu tür ayrımlar görülebilir:

• Sağlayıcının tanımladığı teslimat bölgeleri ve bu bölgelerde ölçülen trafik
• Her bölgedeki birim fiyat, hacim kademesi ve dahil trafik kotası
• Varsa seçilebilir ağ sınıfı, sabit plan bedeli ve ek hizmet ücretleri

Faturanızda GB/TB başına birim ücret bölgeye göre ciddi farklılıklar gösterebilir. Bu yüzden:

• Trafiğinizin coğrafi dağılımı
• Hangi bölgenin ne kadar tüketim yaptığı
• Bu bölgelerin birim ücretleri

Bu üç bilgiyi birlikte değerlendirmek maliyet analizinin ilk adımıdır. Birim fiyat farkı yeterince büyükse, toplam trafiğin küçük bir kısmı faturada orantısız bir pay oluşturabilir.

Origin Pull Trafiği (İçerik: Origin → CDN)

Origin pull, kullanılabilir bir yanıtı önbellekten karşılayamayan CDN’nin içeriği asıl sunucudan istemesidir. Arada shield gibi üst önbellekler bulunabilir; her edge miss origin’e ulaşmaz. Süresi dolan içeriğin değişmediği doğrulanırsa tam gövde yerine daha küçük bir doğrulama yanıtı alınabilir. Gerçek origin trafiğini şu iki faturayla birlikte inceleyin:

• CDN tarafında: Bazı sağlayıcılar origin pull trafiğini ayrıca ölçer veya paketler buna göre şekillenir.
• Origin tarafında: VPS/dedicated/colocation sunucunuzda outbound bant genişliği tüketirsiniz; bu da paketinizin trafik kotasına ve aşım ücretlerine bağlı olarak sunucu maliyetinizi artırabilir.

Cache hit ratio’nuz düşükse, isteklerin daha büyük bir kısmı edge önbelleğinden karşılanmıyor demektir. Arada başka bir önbellek katmanı yoksa origin yükü ve çıkış trafiği artabilir. Maliyet etkisi, aktarılan veri boyutuna ve ücretlendirme modeline bağlıdır; kullanıcıya giden CDN trafiği cache hit durumunda da ücretlendirilebilir.

İstek Sayısı, Loglama ve Ek Özellikler

Bazı CDN modellerinde:

• HTTP isteği başına ücret
• Gelişmiş loglama (real-time log streaming, long-term storage)
• WAF, bot koruması, görüntü optimizasyonu, edge compute

gibi kalemler de faturaya yansır. Trafik maliyeti tartışırken genellikle bant genişliğine odaklanırız, ancak çok yüksek istek hacmine sahip dinamik projelerde request bazlı ücretler de ciddi bir kalem olabilir. Bu yazıda odağımız bant genişliği olacak; fakat bu kalemde tasarruf için ücretlendirilen istek sayısının azalması gerekir. Edge önbellek isabetini artırmak origin isteklerini azaltabilir, ancak kullanıcıdan CDN’e gelen istek sayısını tek başına azaltmaz.

Origin Pull Trafiğini Azaltmak: Doğru Mimari ve Teknikler

Origin pull trafiğini azaltmak, origin yükünü ve çıkış trafiğini düşürebilir. Faturadaki tasarruf ise origin trafiğinin ayrıca ücretlendirilmesine veya paket kotasını aşmasına bağlıdır. Bunu üç katmanda düşünebilirsiniz:

1. HTTP cache-control stratejisi
2. Mimari ayrıştırma (statik/dinamik)
3. Ortam ve depolama mimarisi

Cache-Control Başlıklarını Doğru Kullanmak

HTTP Cache-Control başlıkları, yanıtın depolanması ve yeniden kullanılması için önemli sinyallerdir. CDN’nin yanıt başlıklarını nasıl uyguladığını ve varsa override kurallarını doğrulayın; herkese açık varlıklarla özel yanıtları ayırın:

• İçerik değiştiğinde URL’si de değişen, herkese açık statik dosyalarda Cache-Control: public, max-age=31536000, immutable gibi uzun süreli politika kullanılabilir. Aynı sürümlü URL’de farklı içerik yayımlamayın; immutable yalnızca tazelik süresi boyunca geçerlidir.
• s-maxage, CDN dahil paylaşımlı önbellekler için tarayıcıdan farklı bir tazelik süresi belirleyebilir. Bu bir gizlilik veya yetkilendirme kontrolü değildir.
• Yalnızca aynı cache anahtarındaki herkese aynı yanıtı sunan HTML için, içeriğin kabul edilebilir eskiliğine göre kısa süreler seçin. 60–300 saniye sadece örnektir; hesap, sepet, ödeme, kimlik doğrulanmış ve diğer kişiye özel yanıtları paylaşımlı önbellekten hariç tutun.

Bu politikaların etkisini hit ve miss yanıtlarında kontrol edin. CDN önbellekleme, Cache-Control ve edge kuralları rehberi WordPress ve WooCommerce için ek bağlam sağlar. Yanlışlıkla önbelleğe alınmış özel içeriği yalnızca yeni bir kısıtlayıcı başlık ekleyerek temizlenmiş saymayın; mevcut kopyaları ve CDN kurallarını da ele alın.

Statik ve Dinamik Trafiği Ayrıştırmak

Statik dosyaları dinamik uygulama sunucusundan ayırmak, uygulama yükünü azaltmaya yardımcı olabilir. Ancak ayrı bir domain veya depolama kullanmak tek başına toplam origin pull trafiğini azaltmaz; bunun için önbellek kuralları da gerekir. Örneğin:

• Herkese açık WordPress medyasını içeren wp-content/uploads kaynaklarını uygun bir domain/subdomain üzerinden sunmak; özel müşteri dosyalarını erişim denetimi olmadan açmamak
• Görsel, PDF ve videolar için uygun S3 uyumlu depolamayı değerlendirmek; taşıma sırasında URL, yedek ve erişim kurallarını korumak
• CSS/JS gibi derlenmiş varlıkları içerik hash’i taşıyan dosya adlarıyla sürümlemek ve uygun uzun önbellek süresi kullanmak

Ayrı depolama uygulama sunucusunun I/O ve CPU yükünü hafifletebilir; net gideri depolama, istek, çıkış trafiği, yedek ve işletim maliyetleri belirler. Ayrı subdomain kendiliğinden çerezsiz değildir; üst domain çerezlerinin kapsamını kontrol edin. Aynı URL’den kişiye özel dosya sunuluyorsa yetki denetimi cache hit sırasında da geçerli olmalı, origin doğrudan erişimle atlanamamalıdır.

Origin Shield ve Katmanlı Önbellekleme

CDN’niz destekliyorsa origin shield veya katmanlı önbellekleme şu şekilde çalışabilir:

• Etkinleştirildiğinde, kapsama giren edge cache miss istekleri doğrudan origin yerine bir üst önbellek katmanına yönlendirilir.
• Bu katman, sağlayıcının mimarisine göre bölgesel veya merkezi bir shield noktası olabilir.
• Üst katman da isteği önbellekten karşılayamazsa origin’e başvurulur.

Bu yaklaşımın avantajları:

• Farklı edge noktalarının aynı içeriği istemesi halinde origin’e giden istek sayısı azalabilir.
• Origin konumu, shield noktasına bağlantı gecikmesi ve çıkış ücretleri birlikte değerlendirilerek seçilebilir; özel bağlantı seçenekleri sağlayıcı desteğine bağlıdır.

Paylaşılan shield, aynı varlığın farklı edge noktalarından tekrar alınmasını azaltabilir. Farklı shield’lar, yanıt varyantları, süre dolması veya tahliye nedeniyle origin’den yeniden aktarım yine gerekebilir; dosyanın yalnızca bir kez çekileceğini varsaymayın. Shield ücretini ölçülen origin trafiği ve işlem yükü tasarrufuyla karşılaştırın.

Görsel Optimizasyonu ile Byte Tasarrufu

Görsel optimizasyonu, her bir istekte kullanıcıya taşınan veri boyutunu küçültebilir. Küçültülmüş dosyalar origin’den sunuluyorsa origin pull trafiği de azalabilir; dönüşüm yalnızca CDN’de yapılıyorsa orijinal dosyanın origin’den aktarım boyutu değişmeyebilir. Bunun için:

• WebP/AVIF dahil uygun biçimleri, görsel kaliteyi ve dosya boyutunu karşılaştırarak seçmek
• Ekran ve yerleşime uygun çözünürlükler sunmak; desteklenmeyen istemciler için uygun alternatif sağlamak
• Gerekli renk profili, yön ve hak bilgilerini koruyarak gereksiz meta verileri temizlemek
• Biçim aynı URL’de Accept başlığına göre seçiliyorsa, JPEG/PNG alternatifi dahil tüm ilgili yanıtlarda Vary: Accept ile mevcut Vary boyutlarını korumak ve CDN cache anahtarını doğrulamak; sabit biçimli ayrı URL’leri bundan ayırmak

Görüntü optimizasyonu ve CDN maliyetleri rehberi biçim, boyut ve önbellek tasarımını birlikte ele alır. Metin yanıtlarında uygun Gzip/Brotli sıkıştırması da byte tasarrufu sağlayabilir: Content-Encoding gövdeyle eşleşmeli, Vary: Accept-Encoding veya eşdeğer CDN işleyişi sıkıştırılmış ve sıkıştırılmamış yanıtları güvenle ayırmalıdır. Origin–CDN aktarımı sıkışmıyorsa yalnız edge dönüşümü origin çıkışını küçültmez; origin ve edge üzerinde hit/miss durumlarını farklı istemci tercihlerinde kontrol edin.

Cache Hit Ratio’yu (CHR) Yükseltmek: İçeriğe Göre Hedef Belirlemek

İstek bazlı Cache Hit Ratio (CHR), ölçülen isteklerin yüzde kaçının cache hit sayıldığını gösterir. Rapora bypass ve yeniden doğrulamanın dahil olup olmadığını öğrenin. Üst önbellek katmanları nedeniyle hit olmayan her istek origin’e gitmeyebilir; ayrıca byte hit oranını ve gerçek origin byte toplamını ölçün. Birkaç büyük miss, çok sayıda küçük hit’ten daha fazla trafik üretebilir. İstek bazlı temel formül:

CHR = (Hit isteği sayısı / Toplam istek sayısı) × 100

CHR hedefini içerik sınıfı ve başlangıç ölçümleriyle belirleyin; aşağıdaki yüzdeler evrensel standart değil, uygun trafik koşullarında değerlendirilebilecek örneklerdir:

• Sık istenen, kararlı statik varlıklarda %98 gibi yüksek oranlar hedeflenebilir; uzun kuyruk, dağıtım, tahliye ve az kullanılan dosyalar oranı düşürebilir.
• Herkese açık HTML için %80 örnek hedefi bile güncellik gereksinimi ve istek dağılımına göre uygun olmayabilir.
• Statik trafiğin baskın olduğu bir sitede %90 toplam hedef düşünülebilir; kişiselleştirilmiş sitelerde düşük oran doğru bypass kurallarının sonucu olabilir. Gizliliği veya güncelliği sırf oranı artırmak için bozmayın.

CHR’yi Düşüren Yaygın Hatalar

CHR’yi düşürebilen başlıca yapılandırma sorunları şunlardır:

• Herkese açık statik içerikte gereksiz kısıtlayıcı başlıklar: no-store, private veya çok kısa max-age değerleri. Özel içerikte gereken kısıtlamaları sırf CHR için kaldırmayın.
• Her istekte değişen sürüm parametresi: ?v=123 gibi içerik sürümüyle birlikte değişen, arada sabit kalan bir değer geçerli cache busting olabilir. ?v=timestamp şablonundan her istekte yeni zaman damgası üretmek, içerik aynıyken parametre cache anahtarına dahilse gereksiz kopyalar yaratır. Parametreyi yok saymadan önce içerik veya erişim yetkisini değiştirmediğini doğrulayın.
• Çerez nedeniyle parçalanma veya bypass: Çerezlerin cache anahtarına dahil edilmesi ya da atlama kuralını tetiklemesi gerçek CDN politikasına bağlıdır. Aynı domain tek başına düşük CHR nedeni değildir.
• Yanlış path kuralları: /api/ ile /assets/ için yanıtın içeriği ve gizliliği incelenmeden aynı politika uygulanması.

WordPress ve WooCommerce Örneği

WordPress ve WooCommerce için üç katmanı, gerçek oturum ve yanıt davranışını test ederek değerlendirin:

1. Statik varlıkların agresif cache’lenmesi: Tema ve eklenti CSS/JS dosyalarını versiyonlandırıp uzun süreli edge cache.
2. HTML için tam sayfa önbellek: Giriş yapmamış ve kişiselleştirilmiş oturum içeriği almayan kullanıcılar için CDN veya sunucu tarafı tam sayfa cache.
3. Sepet/checkout gibi hassas sayfalarda bypass: Sepet, ödeme ve hesap sayfalarını; ayrıca oturum veya çerez nedeniyle kişiye özel yanıt üreten diğer istekleri paylaşımlı cache dışında bırakmak.

Bu yapıyı nasıl kuracağınızı detaylarıyla anlattığımız WordPress için CDN önbellek kuralları rehberimizde hem CDN hem de uygulama katmanı için örneklerle anlattık. Ayrıca sunucu tarafında Nginx FastCGI cache veya LiteSpeed Cache gibi çözümlerle tam sayfa önbellekleme yapmak isterseniz, WordPress’te tam sayfa önbellekleme rehberine de göz atabilirsiniz.

CHR’yi Yükseltmek İçin Pratik Adımlar

Projelerinizde hemen uygulayabileceğiniz bazı adımlar:

• CDN raporlarından içerik/path bazlı istek ve byte hit oranını çekin; örneğin /uploads/, /static/, /api/.
• Güvenle paylaşılabilen yanıtlar arasında büyük byte hacmi ve gereksiz miss üreten URL’leri önceliklendirin.
• Cache-Control, Vary, çerez, query string ve kimlik doğrulama davranışını hem hit hem miss üzerinde kontrol edin.
• Cache anahtarından yalnız yanıtı veya erişim yetkisini etkilemediğini doğruladığınız boyutları çıkarın. Dil, para birimi, cihaz veya görüntü biçimi farklarını gerektiği gibi ayırın.
• Güncellenen sabit URL’leri path/tag bazlı temizleyin; yeni sürümlü URL yayımlamak her dağıtımda tüm CDN’yi temizlemeyi gerektirmez. Eski varlıkları geri dönüş ve eski sayfa referansları için gerektiği sürece koruyun.

Bu düzenlemeler, güvenle önbelleklenebilen içerikte CHR’yi yükseltip origin pull trafiğini azaltabilir. Purge ise güncellik içindir; önbelleğin yeniden dolması sırasında origin isteklerini artırabilir. İstek bazlı CHR artışı, aktarılan byte miktarının aynı oranda azalacağını göstermez.

Bölgesel Fiyatlandırma ve Trafik Yönlendirme Stratejileri

CDN trafik maliyetlerini yönetirken bölgesel fiyatlandırma farklarını da değerlendirin. Sağlayıcı ve tarifeye göre 1 GB trafiğin fiyatı bölgeden bölgeye değişebilir; dolayısıyla:

• Kullanıcılarınız nerede?
• Hangi bölgelerde hız kritik, hangilerinde “makul” hız yeterli?
• Hangi bölgeler fiyatta sıçrama yaratıyor?

gibi soruların cevabı önemlidir.

Coğrafi Trafik Analizi

İlk adım, CDN veya analitik araçlarınızdan şu raporları çıkarmaktır:

• Bölge / ülke bazlı trafik tüketimi (GB/TB)
• Bölge bazlı ortalama gecikme süresi (latency)
• Bölge bazlı hata oranları (4xx/5xx)

Bu veriyi CDN sağlayıcınızın fiyat tablosu ile yan yana koyarak şu noktaları kontrol edin:

• Türkiye, Avrupa ve Orta Doğu trafiğinin hangi faturalama bölgelerine girdiğini ve bu bölgelerin birim fiyatlarını ayrı ayrı inceleyin.
• Güney Amerika veya Uzak Doğu gibi bölgelerde trafik payını fatura payıyla karşılaştırın; küçük bir trafik payı, yüksek birim fiyat varsa daha büyük bir maliyet payı yaratabilir.

Yüksek Maliyetli Trafikte İçerik Boyutunu Azaltmak

Tarife ve kullanım raporunda yüksek maliyet üreten trafiği belirledikten sonra ürün gereksinimleriyle uyumlu seçenekleri test edin:

• Görsel kaliteyi karşılaştırarak daha küçük dosya veya uygun çözünürlük sunmak
• Kritik olmayan arka plan videosunu isteğe bağlı yüklemek ya da daha hafif içerikle değiştirmek
• Varsa farklı ağ sınıflarının fiyatını, kapsamını ve performansını gerçek kullanıcı ağlarında karşılaştırmak
• Bölgeye göre yanıt değişiyorsa ayrı varlık URL’si veya doğrulanmış cache anahtarı boyutu kullanarak varyantların birbirine karışmasını önlemek

Daha düşük çözünürlük veya kaldırılmış medya kalite ve işlev kaybı yaratabilir. Tasarrufu yükleme süresi, hata oranı ve kullanıcı deneyimiyle birlikte değerlendirin; coğrafi uzaklığı tek başına ücret veya uygun kalite göstergesi saymayın.

Sunucu Lokasyonu ve CDN Etkileşimi

Origin sunucunuzun bulunduğu veri merkezi lokasyonu, CDN maliyetlerinizi dolaylı olarak etkiler. Örneğin kullanıcı kitleniz ağırlıklı Avrupa ve Türkiye ise:

• Origin gecikmesini coğrafi mesafe yerine CDN’nin gerçek fetch yolu ve varsa shield noktası üzerinden ölçün. DCHost’ta kullanılabilir lokasyonları seçilen ürün için doğrulayın.
• Origin çıkış tarifesi, kota, aşım, CDN origin ücretleri ve ek barındırma giderlerini birlikte hesaplayın. Origin taşımak kullanıcıya teslimatın faturalandırıldığı bölgeyi değiştirmek zorunda değildir.
• CDN kesintisinde alternatif hizmet yolu için DNS/yönlendirme, TLS, kapasite ve güvenlik kontrollerini önceden test edin. Yedek yol erişim, kimlik doğrulama veya WAF gereksinimlerini atlamamalıdır.

Sunucu konumunun performans ve SEO etkilerini detaylı anlattığımız sunucu lokasyonu ve doğru hosting bölgesi seçimi rehberinde bu konuyu daha geniş bir perspektiften ele aldık.

Gelişmiş DNS ve Çok Bölgeli Mimariler

Birden fazla origin ancak gecikme, kapasite veya kurtarma hedefi ek maliyeti gerekçelendiriyorsa değerlendirilmelidir. DNS ve CDN origin seçiminin birbiriyle uyumunu doğrulayın:

• Geo DNS sorgusu son kullanıcı yerine CDN resolver veya shield konumunu yansıtabilir. Ağırlıklı DNS ise trafiği oranlarla dağıtır; kendiliğinden coğrafi seçim yapmaz.
• DNS ile istediğiniz edge noktasını seçebileceğinizi varsaymayın; origin ve edge yönlendirmesinin hangi kısmını sağlayıcının kontrol ettiğini öğrenin.
• Ek origin için barındırma, replikasyon, depolama ve yönetim giderlerini dahil edin. Veri tutarlılığı, sağlıklı hedef tespiti, sertifikalar ve failover sırasında güvenliği planlayın.
• DNS önbellekleri ve mevcut bağlantılar nedeniyle geçiş anlık değildir. Yedek origin’i test edilmiş kurtarma planı ve bağımsız yedeklerle birlikte tasarlayın.

Bu tür senaryoları DNS seviyesinde nasıl kurgulayabileceğinizi gelişmiş DNS yönlendirme rehberimizde anlattık. Ayrıca küresel projeler için çok bölgeli mimari ve felaket dayanıklılığı planlıyorsanız, çok bölgeli mimariler nasıl kurulur yazımız da size yol gösterecektir.

Örnek Senaryo: 3 Adımda CDN Trafik Tasarrufunu Hesaplamak

Aşağıdaki hesap tamamen varsayımsaldır; oranlar ölçülmüş sonuç veya tasarruf garantisi değildir. Hit ve miss yanıtlarının ortalama boyutunu eşit, üst katman ve yeniden doğrulama etkileriyle diğer origin transferlerini ihmal edilebilir kabul ediyoruz. Bu basit modelde istek CHR’si ile byte hit oranı eşittir; gerçek raporlarda bu eşitlik beklenmemelidir:

• Aylık toplam CDN trafiği: 50 TB
• Ortalama CHR: %70
• Origin pull trafiği: 15 TB
• Pahalı bölgeler: Toplam trafiğin %10’u, kullanıcıya çıkış için hacim bazlı CDN ücretinin %25’i; sabit ücretler ve diğer kalemler hesap dışında

Adım 1: CHR’yi %70’ten %90’a Çekmek

Önce en düşük CHR’ye sahip path’leri analiz ediyoruz. Statik varlıklar için:

• İçerik değişince URL’si değişen, herkese açık dosyalarda uzun süreli cache-control (max-age=31536000, immutable)
• Eski dosya URL’sini farklı içerikle değiştirmeden sürümlü dosya adları
• Gereksiz çerezlerin bypass veya varyant üretmesini önlemek; gerekirse ayrı subdomain’de çerez kapsamını ayrıca ayarlamak

HTML için yalnızca giriş yapmamış ve kişiselleştirilmiş oturum içeriği almayan kullanıcılara micro-cache (60–120 saniye) uyguladığımızı varsayalım; sepet, ödeme ve diğer kişiye özel yanıtlar bypass kapsamında kalır. Bu düzenlemeler sonrasında örnek hedefe ulaşıldığını kabul edersek:

• CHR %70 → %90 seviyesine çıkıyor.
• Aynı toplam trafikte, origin pull trafiği 15 TB → ~5 TB seviyesine iniyor.

Bu adımda kullanıcıya giden 50 TB değişmez; dolayısıyla bu çıkışa ait CDN ücreti sırf CHR arttığı için düşmez. Origin çıkışı ve varsa origin pull için hacim bazlı ücretler azalabilir; paket kotaları ve sabit ücretler nedeniyle faturadaki etki farklı olabilir.

Adım 2: Görsel Optimizasyonu ve Byte Tasarrufu

İkinci adımda görseller üzerinde çalışıyoruz:

• Görsellerin uygun WebP/AVIF sürümlerini kalite ve boyut açısından karşılaştırdığımızı; desteklenmeyen istemciler için alternatif koruduğumuzu varsayıyoruz.
• Yerleşim ve cihaza uygun çözünürlükler seçiyoruz.
• Gerekli renk/yön/hak bilgisini koruyarak gereksiz meta verileri temizliyoruz.

Görseller 50 TB çıkışın %80’ini, yani 40 TB’ını oluştursun ve ortalama boyutları %30 küçülsün. Tasarruf 12 TB, yeni CDN çıkışı 38 TB olur; diğer 10 TB değişmez. Küçültülmüş dosyaların origin’den de bu boyutlarda aktarıldığını ve byte hit oranının %90 kaldığını varsayarsak origin pull 3,8 TB olur. Yalnız edge’de dönüşüm yapılırsa origin için bu sonucu çıkaramayız. Sonraki hesapta görsel payı ve küçülme oranını tüm bölgelerde aynı kabul ediyoruz.

Adım 3: Bölgesel Trafik Azalmasının Ücrete Etkisi

Son adımda, pahalı bölgelerdeki trafiği inceliyoruz. Bu bölgelerde:

• Otomatik video oynatmayı devre dışı bırakıyoruz veya daha düşük bitrate kullanıyoruz.
• Yüksek çözünürlüklü arka plan videolarını daha hafif görsellerle değiştiriyoruz.
• Görseller için de önceki adıma ek olarak daha küçük boyutlu veya daha düşük çözünürlüklü bölgesel varyantları test ediyoruz; ayrı URL veya doğrulanmış cache anahtarıyla varyantları ayırıyoruz. Önceki varsayımlara göre kalan trafiğin yaklaşık %73,7’si görseldir; yalnız videoları azaltmak sonraki %40–50 toplam trafik azalması varsayımına ulaşamaz.
• CDN tarafında mümkünse “standart ağ” seçip, premium ağdan çıkıyoruz.

Bu adımın pahalı bölgelerde kalan trafiği ayrıca %40–50 azalttığını varsayalım. Birim fiyatları ve diğer bölgelerin kalan trafiğini sabit tutarak, ağ sınıfı değişiminden olası ek indirimi hesaba katmadan:

• Kullanıcıya çıkışın hacim bazlı CDN ücreti başlangıca göre %31,6–33,5 azalır. Pahalı bölgede %40 azalma için kalan ücret 0,76 × (0,75 + 0,25 × 0,60) = 0,684; %50 azalma için 0,76 × (0,75 + 0,25 × 0,50) = 0,665 olur. Bu, tüm faturanın aynı oranda düşeceği anlamına gelmez.
• Origin çıkışı da azalabilir; maliyet farkını gerçek byte hit oranı, origin tarifesi, kota ve diğer transferler belirler. Ek dönüşüm veya ağ sınıfı ücretlerini ayrıca hesaplayın.

Bu varsayımsal tasarrufu kendi projenize uyarlarken bölge ve cihaz bazında görsel kaliteyi, yükleme sürelerini ve hata oranlarını önceki durumla karşılaştırın; kalite kaybı olmadan ne kadar tasarruf edilebileceği içerik ve kullanıcı beklentilerine bağlıdır.

DCHost ile Uygulanabilir Bir Yol Haritası

CDN giderlerini izlemek için trafik, uygulama ve altyapı kararlarını ortak ölçümlerle değerlendirin. DCHost planını origin olarak kullanırken de aynı kontrol adımları geçerlidir:

1. Başlangıç ölçümü: CDN ve origin faturalarını ayırın; istek/byte hit oranı, gerçek origin transferi, en büyük URL’ler, bölgeler ve tarifeleri çıkarın.
2. Mimari seçenek: Statik içeriği ayırmanın faydasını depolama, transfer, yedek ve yönetim giderleriyle karşılaştırın; gerekli hizmetlerin sunulduğunu doğrulayın.
3. Güvenli önbellek: Yanıtların gizliliğini, anahtar/varyant davranışını ve sıkıştırma başlıklarını hit/miss durumlarında test edin. Özel yanıtları ortak önbelleğe açmayın.
4. Bölgesel plan: Gerçek fetch ve teslimat yollarını, kaliteyi, faturalandırmayı ve ek origin maliyetlerini birlikte değerlendirin.
5. Sürekli ölçüm: Değişiklikten sonra aynı trafik hacmi ve içerik dağılımına göre giderleri karşılaştırın. Harcama ve hata alarmları kurun; kampanya, dağıtım ve önbelleğin yeniden dolma etkilerini ayrıca izleyin.

DCHost üzerinde VPS veya dedicated sunucu değerlendirirken kaynak, lokasyon, çıkış kotası ve aşım ücretlerini mevcut origin ile karşılaştırın. Plan değişikliği otomatik TCO düşüşü sağlamaz; taşıma, yönetim ve yedek giderlerini de dahil edin. Hosting maliyetlerini düşürme ve VPS boyutlandırma rehberi bu karşılaştırma için ek yöntemler sunar.

Önce hangi ücretin hangi veri akışından doğduğunu belirleyin, sonra küçük bir değişiklik yapıp maliyet, gecikme, güncellik ve kaliteyi yeniden ölçün. DCHost’tan CDN yapılandırması veya mimari destek gerekiyorsa hizmetin varlığını, sorumlulukları ve ücretini önceden teyit edin; bu desteğin standart plana dahil olduğunu varsaymayın.