Cloudflare yerine CDN: Ne zaman, hangi alternatif?

CDN (Content Delivery Network) katmanı, sitenizin içeriğini ziyaretçiye en yakın sunucudan teslim ederek gecikmeyi düşürür ve ani trafik artışlarını yumuşatır. Cloudflare en bilinen seçenek olsa da her ihtiyaç Cloudflare’in sunduğu modele uymaz: bazı senaryolarda kontrol ihtiyacı, bazı senaryolarda maliyet ve bazı senaryolarda ülke/varlık (asset) bazlı optimizasyonlar belirleyicidir. Bu rehberde Cloudflare yerine alternatif CDN değerlendirirken hangi teknik ve operasyonel soruların kritik olduğunu, ne zaman hangi yaklaşımın mantıklı olduğunu net şekilde öğreneceksiniz.

CDN türleri: Aynı “CDN” değil, farklı teslim modeli

CDN alternatiflerini doğru kıyaslamak için önce CDN’in hangi mantıkla çalıştığını ayırmak gerekir.

1) Proxy/CDN (HTTP isteğini araya alır)

Tarayıcı ile origin (kaynak sunucu) arasındaki HTTP trafiğini CDN yönlendirir.
Cache kontrolü, WAF/akarım (rate limit) gibi güvenlik özellikleri çoğu zaman bu katmanda uygulanır.
Bazı uygulamalarda “gerçek istemci IP’si” ve header davranışı dikkat ister.

2) Reverse proxy + edge cache

Nginx/HAProxy gibi ters proxy mantığına benzeyen, edge noktalarında cache ve bazı dönüşümler yapan kurgu.
Daha “kontrol” isteyen ekipler için ayarlanabilirlik sağlar.

3) Edge cache + object storage (S3 uyumlu)

Dinamik olmayan varlıklar (CSS/JS/görseller) object storage’a taşınır.
CDN, bu “dosyaları” uç noktadan teslim eder; origin sadece üretim işlerine odaklanır.

Pratik ayrım: Eğer asıl sorun “statik içerik hızlı gitmiyor” ise object storage + CDN modeli çoğu zaman en net faydayı verir. Eğer “trafik taşması + güvenlik + kurumsal kontroller” hedefleniyorsa proxy/CDN hattı daha uygun olur.

Cloudflare yerine alternatif CDN ararken 9 net kriter

Alternatif CDN’e geçmek için “tek sebep” aramak yerine aşağıdaki kriterleri puanlayın. Her madde, teknik kararın hangi yönde olacağını belirler.

Cache davranışı (TTL, cache anahtarı, query string etkisi) - Aynı URL farklı query ile çağrıldığında cache bölünüyor mu? - HTML cache mi yapacak yoksa sadece statik varlık mı?
Origin korunumu - Origin’e doğrudan erişimi (direct-to-origin) ne kadar engelleyebiliyor? - Origin IP saklama / sadece CDN’den gelen istekleri kabul etme mümkün mü?
Kayıp/yanlış header yönetimi - X-Forwarded-For, Host, X-Real-IP doğru aktarılıyor mu? - Uygulama logları ve rate limit mekanizmaları etkileniyor mu?
TLS/SSL ve sertifika yönetimi - Edge’de otomatik sertifika var mı? - mTLS (mutual TLS) gibi ileri senaryolar gerekli mi?
Güvenlik katmanı - WAF, bot kontrol, DDoS koruması seviyeleri. - Özellikle abonelik/plan bazında hangi özellikler “paket içinde” var?
Performans göstergeleri - Edge lokasyon yoğunluğu (hedef ülkelerinizde). - Cache hit oranı için raporlama var mı?
Log/analitik - Gerçek zamanlı istek logu export’u (JSON/HTTP API ile) mümkün mü? - SIEM entegrasyonu veya anlık hata analizi ihtiyacınız var mı?
Ölçek ve bant genişliği maliyeti - “Transfer (GB/ay)” tek kalem mi, yoksa istek (requests) başına da ücret var mı? - Eşik aşımı durumunda maliyet büyümesi nasıl oluyor?
Kontrol ve esneklik - Cache bypass, rewrite, header set etme, özel kural yazma (rule engine) yeterli mi? - Değişikliklerin deploy süresi nedir?

Bu 9 kriteri netleştirmeden “Cloudflare yerine şu ürün” diyerek seçim yapmak genellikle maliyet ve operasyon yükünü artırır.

Ne zaman Cloudflare yerine alternatif CDN seçilir?

Aşağıdaki senaryolar, Cloudflare’den farklı bir CDN’e geçmeyi teknik olarak anlamlı kılan durumları gösterir.

Senaryo A: Origin kontrolü ve “daha kapalı mimari” ihtiyacı

Origin sunucunuzu sadece CDN’den gelen trafikle kısıtlamak istiyorsunuz.
Ürün bazlı kural setleri ve header doğrulama ile güvenlik politikasını “daha deterministik” yapmak istiyorsunuz.

Senaryo B: Statik varlıkların taşınmasıyla asıl problemin çözülmesi

Görsel, JS, CSS, font gibi varlıklar cache’lenemediği için sayfa yüklenmiyor.
Çözüm: object storage + CDN (edge cache) modeli.
Bu durumda “WAF paketi” ağır bir maliyet kalemi olabiliyor; sadece teslim altyapısı odaklı bir CDN daha rasyonel olur.

Senaryo C: Belirli ülkelerde daha iyi edge performansı arayışı

Kullanıcılarınız tek ülkede yoğun ise ve farklı bir CDN’in o bölgede daha güçlü edge ağı varsa beklenen TTL ve hit oranı iyileşebilir.
Bu durumda Cloudflare’in genel performansına rağmen alternatif daha iyi sonuç verebilir.

Senaryo D: Maliyet biriminde farklılaşma (requests vs transfer)

Trafiği çok yükselttiğinizde “istek başına” maliyet büyüyebiliyor.
Alternatif CDN’de ücret modeli transfer ağırlıklıysa aynı mimaride daha öngörülebilir bir maliyet çıkabilir.

Senaryo E: Uygulama uyumluluğu ve header etkisi

Bazı uygulamalar X-Forwarded-For veya Host gibi header’lara duyarlıdır.
Alternatif CDN, aynı header davranışını daha iyi sağlıyorsa geçiş mantıklı olabilir.

Alternatif CDN’ler: Hangi durumda hangisi?

Aşağıdaki tablo, alternatif CDN yaklaşımı seçerken işinizi kolaylaştırmak için pratik bir çerçeve sunar. Burada “tek doğru marka” iddiası yok; karar mantığı senaryonuzla eşleşiyor mu sorusu var.

İhtiyaç / Senaryo	Daha uygun yaklaşım	Öne çıkan kriterler	Not
Sadece statik varlık hızlandırma	Object storage (S3 uyumlu) + CDN edge cache	Cache kontrol, varyant yönetimi, gzip/brotli	HTML dinamiğine dokunmadan fayda sağlar
Proxy seviyesinde kontrol + güvenlik	Proxy/CDN + kural motoru	WAF, rate limit, origin shield	Header/uygulama uyumu test gerektirir
Kurumsal loglama ve entegrasyon	CDN ile log export (API/stream)	Log formatı, gecikme süresi, saklama	SIEM/ELK kullanan ekiplerde kritik
Maliyet öngörülebilirliği	Transfer ağırlıklı ücret modeli	GB/ay, aşım (overage) kuralı	İstek (request) yoğun sitelerde dikkat
Bölgesel gecikme optimizasyonu	Hedef bölge güçlü edge	Peering, lokasyon yakınlığı	Performans testi şart

Karar ağacı: 15 dakikada netleştirme

Aşağıdaki kısa kontrol, “alternatif CDN alalım mı, yoksa başka ayar mı yapalım?” sorusunu netleştirir.

1) Sorun statik varlıklarda mı?

Sayfa yüklenme sürelerinin büyük kısmı görsel/JS/CSS ise: statik varlıkları object storage’a taşıyın ve CDN sadece varlıkları teslim etsin.
Eğer dinamik HTML gecikmesi ana sorunsa: CDN’in cache stratejisini ve uygulama tarafındaki kaynak tüketimini birlikte ele alın.

2) Cache hit oranınız kaç?

Hit oranı düşükse alternatif marka değişimi tek başına çözüm değildir.
URL yapısı, cache bypass header’ları, cookie kullanımı ve query string etkisi önceliklidir.

3) Origin’e doğrudan trafik var mı?

Origin loglarınızda farklı ülke/ASNlerden yoğun direkt istek görüyorsanız origin korunumu zayıftır.
Alternatif CDN’de “origin kısıtlama” ve sadece edge’den erişim mekanizması net olmalı.

4) Maliyet hangi kalemde şişiyor?

Fatura “requests” bazlı büyüyorsa proxy/CDN modeli sizin için pahalılaşabilir.
“transfer” bazlıysa statik varlık odaklı bir CDN daha sürdürülebilir olur.

Teknik geçiş planı: CDN değiştirmek için sıfırdan prosedür

CDN değişimi, DNS değişikliğinden ibaret değildir. Uygulama davranışı, cache kuralları ve TLS/sertifika süreçleri etkilenebilir.

Hedef: Aynı ya da daha iyi cache kontrolü

Yeni CDN’de TTL (ör. 1 saat / 24 saat) ve varyant stratejisini belirleyin.
Query string içeren URL’lerde cache anahtarı kurallarını tanımlayın.
Varlıklar için dosya adında sürümleme (ör. app.2026-05-09.js) kullanın; böylece “cache invalidation” ihtiyacı azalır.

Kesinti riskini azaltma

DNS geçişinden önce yeni CDN’de test domain / staging subdomain kullanın.
Origin loglarında yeni CDN IP aralıklarının geldiğini doğrulayın.
TLS/sertifika oturumlarını test edin (hem tam alan adı hem wildcard ihtiyacı).

Doğrulama metrikleri

İlk 24 saatte şu metrikleri karşılaştırın:
Cache hit oranı
Ortalama TTFB (Time To First Byte)
4xx/5xx hata oranı
Uygulama loglarında header uyumu (özellikle gerçek IP)

Sık yapılan hatalar (doğru alternatif seçimini sabote eden)

Sadece marka değiştirmek: Asıl sorun cache anahtarı veya header değilse geçiş boşa gider.
Dinamik içerikte agresif cache: Admin paneli, kişiselleştirilmiş sayfalar veya cookie kullanan sayfalarda hataya ve veri sızıntısına yol açabilir.
Origin’i korumayı ihmal etmek: CDN olsa bile origin açık kalırsa bot trafiği doğrudan origin’e yük bindirebilir.
Ölçmeden karar vermek: Uygulama testleri olmadan “daha hızlı olur” varsayımı hatalıdır.
Maliyet kalemini okumamak: Fatura request/transfer ayrımını netleştirmeden bütçe sürprizi yaşanır.

Sonuç: En iyi CDN, senaryonla eşleşen CDN’dir

Cloudflare yerine alternatif CDN arıyorsanız kararınızı “hangi probleminiz var?” sorusuyla başlatın: statik varlık hızlandırma mı, proxy seviyesinde güvenlik mi, belirli ülkelerde gecikme mi, yoksa maliyet kalemi mi? İlk adım olarak cache hit oranı, TTFB ve fatura kalemlerinizi netleştirip ardından CDN yaklaşımını (object storage + edge cache mi, proxy/CDN mi) seçin. Geçiş yapacaksanız staging subdomain ile doğrulayın; header ve origin korunumu testlerini tamamlamadan DNS cutover yapmayın.

İsterseniz NetKıyas’ta sitenizdeki profil (trafik, içerik türü, hedef ülke, aylık transfer) ile uygun CDN yaklaşımını kıyaslamak için mevcut şartlarınızı paylaşın; hangi kriterlerde seçim yapmanız gerektiğini listeleyelim.