Cloudflare yerine alternatif CDN: Ne zaman, neden, nasıl seçilir?

Cloudflare CDN (Content Delivery Network) birçok senaryoda hızlı sonuç verir; ancak her proje için tek seçenek değildir. Trafiği kontrol etme şekli, veri saklama/egemenlik gereksinimleri, fiyat modeli ve log erişimi gibi başlıklar, alternatif CDN’lere yönelme nedenini netleştirir. Bu rehberde Cloudflare yerine hangi tür CDN’lerin öne çıktığını, hangi durumda “mantıklı değişim” sayılacağını ve seçim yaparken teknik kontrol listesini öğreneceksiniz.

CDN mi, WAF+DDoS paketi mi? Önce ihtiyacı netleştirin

Cloudflare’yi alternatifle kıyaslamak çoğu zaman hatalı bir başlangıçtır; çünkü CDN ile güvenlik servisleri aynı pakette sunulsa bile aynı şey değildir. Aşağıdaki ayrım, “ne zaman alternatif düşünmeliyim?” sorusunu doğrudan cevaplar.

CDN’nin ana işi

• Statik içerik dağıtımı (CSS/JS, görseller, video parçaları)
• Coğrafi yakınlaşma (edge lokasyonları)
• Cache kontrolü (TTL, varyantlar, sıkıştırma)

Güvenlik katmanı (WAF/DDoS) ana işi

• Uygulama katmanı saldırılarını (OWASP benzeri imzalar) engelleme
• DDoS sırasında trafiğin yönlendirilmesi ve filtrelenmesi
• Rate limiting, bot yönetimi

CDN seçiminde 1. hedef: Cache verimi

Alternatif CDN’e geçmeden önce kendi sisteminizde “cache ne kadar çalışıyor?” sorusunu cevaplayın. Çünkü CDN değişimi, cache oranı düşükse performansı beklenen kadar artırmayabilir.

Ölçüm metrikleri: - TTFB (Time to First Byte): Origin sunucunun ilk yanıt süresini etkiler. - Cache Hit Ratio: Edge’in cache’ten servis oranı. - Önbellek kaçmasına neden olan başlıklar: Cache-Control, Vary, Set-Cookie.

Cloudflare’ye alternatif neden istenir? En net 7 senaryo

Aşağıdaki maddeler, “neden Cloudflare yerine alternatif CDN” sorusunun doğrudan teknik gerekçeleridir.

1) Veri egemenliği ve log erişimi - Bazı kurumlar WAF/edge loglarının belirli ülkelerde tutulmasını veya belirli sürelerde erişilebilir olmasını ister. - Log saklama politikası ve raporlama çıktısı kritik olur.

2) Fiyat modeli uyumsuzluğu - Cloudflare’de maliyet; bant genişliği, istek sayısı, güvenlik eklentileri ve destek seviyesiyle şekillenir. - Düşük trafik ama yüksek “gelişmiş WAF/feature” kullanımı bazı paketlerde pahalıya dönüşebilir.

3) Origin’e dönüş mimarisi (pull/push) - Bazı projelerde cache yaşam döngüsü daha kontrollü olmalıdır. - Örneğin sık içerik değişimi + varyant çokluğu (dil, cihaz tipi) varsa cache politikasını uygulama düzeyinde daha net isteyen ekipler alternatif arar.

4) Özel edge özellikleri - Üst seviye: HTTP/3 optimizasyonları, özel kural motoru, neredeyse gerçek zamanlı purge (temizleme).

5) Kurumsal entegrasyon gereksinimleri - SIEM/observability entegrasyonları (log formatları, webhook/stream) - Sertifika yönetimi ve otomasyon (ACME, otomatik TLS)

6) Hedeflenen lokasyon/Anycast kapsamı - Türkiye trafiğinde edge lokasyon yoğunluğu ve DNS/anycast davranışı kritik olabilir. - Türkiye’ye hizmet eden projede “tahmini en yakın node” bazen beklenenden uzak seçilebilir.

7) Mevcut altyapı kilidi - Daha önce VCL/behaviour benzeri bir mimariyle çalışan takımlar, aynı davranışı sunan alternatifleri tercih eder.

Alternatif CDN türleri: Tek tek marka değil, doğru kategori

Cloudflare yerine bakarken markadan önce kategori düşünmek gerekir. Şu sınıflar genellikle ihtiyaçla birebir eşleşir:

1) Anycast DNS + CDN (global ölçek)

• Avantaj: DNS katmanında hız ve tutarlılık
• Ne zaman: Çok lokasyonlu trafiği olan, farklı ISP’lerden gelen kullanıcıların TTFB’ini düşürmek isteyen ekipler

2) Origin-pull / managed cache sağlayan CDN

• Avantaj: Cache politikasını sizin kontrolünüzle yönetme
• Ne zaman: Uygulama tarafında varyant sayısı yüksek (çoklu dil, cihaz, oturum) ve “hızlı ama doğru cache” isteyen projeler

3) WAF odaklı platform + CDN katmanı

• Avantaj: Güvenlik katmanında geniş kural seti
• Ne zaman: Saldırı yüzeyi yüksek (login, API, e-ticaret), bot trafiği belirgin

4) Edge compute (Workers/Functions) içeren CDN

• Avantaj: Basit yönlendirme, header manipülasyonu, image dönüşümleri
• Ne zaman: Uygulama değiştirmeden edge’de davranış üretmek isteyenler

Hangi durumda geçiş “olumlu” olur? Karar matrisi

Aşağıdaki tablo, Cloudflare’den alternatif CDN’e geçişin neden doğru olabileceğini netleştirir.

Seçim kriterleri: CDN’i “performans + kontrol” olarak değerlendirin

Aşağıdaki başlıklar, pratikte geçiş sırasında sorun yaşamamanızı sağlar.

1) Cache kontrolü (TTL, varyant, purge)

Şu soruların yanıtı net olmalı: - Edge’de varsayılan TTL kaç saniye? - Cache-Control: no-cache veya private başlıklarına nasıl davranıyor? - Dil/Varyant için Accept-Language gibi header’lar cache anahtarına giriyor mu? - Purge (temizleme) API’si var mı ve limitleri nedir?

2) Origin davranışı ve “iyi cache” koşulları

Sık hatalar: - Origin’de gereksiz Set-Cookie gönderimi - Dinamik sayfalarda statik kaynakların cache policy’sinin yanlış ayarlanması - Vary başlıklarının kontrolsüz artması

3) TLS ve sertifika otomasyonu

• Otomatik sertifika yenileme var mı?
• Edge ile origin arasında TLS termination nerede yapılıyor?
• mTLS ihtiyacı varsa destek var mı?

4) WAF/DDoS kapsamı ve rate limiting

a) Bot yönetimi nasıl çalışıyor? - Challange/JS taraması gerektiriyor mu?

b) Rate limiting nerede uygulanıyor? - DNS/edge seviyesinde mi, uygulama seviyesinde mi?

c) Log formatları ve dışa aktarma - Gerçek zamanlı mi, gecikmeli mi?

5) Gözlemlenebilirlik (observability)

CDN’in performansını yönetmek için şu veri akışları önemli: - Edge hit/miss dağılımı - Cache bypass sebepleri - Kullanıcı-agent bazlı sapmalar

Karşılaştırma planı: Geçmeden önce 14 günlük test taslağı

Marka ismi yerine test tasarımı yapın. Cloudflare’den alternatif CDN’e geçişte en sık hata, “tam trafik” geçmeden önce ölçüm yapmamaktır.

Test hedefleri (net sayılar)

• TTFB: Türkiye trafiğinde hedef yüzde iyileştirme (ör. %15-30)
• Cache hit: minimum hedef (ör. %50+) — statik içerik için
• Hata oranı: 4xx/5xx hedef aralığı (ör. %0.1-0.5 gibi)

Kurulum adımları (genel iskelet)

1) Ayrı bir alt domain veya test alan adı oluşturun (ör. cdn-test.example.com). 2) DNS’i test için sadece bu alan adında değiştirin. 3) Origin loglarını (Nginx/Apache) karşılaştırmak için iki haftalık veri alın. 4) Edge cache policy’lerini tek tek ayarlayın: TTL, compression, query handling. 5) WAF kurallarını “monitoring” modunda deneyin; blok moduna geçişi kademeli yapın.

Ölçüm araçları

• CDN panelinin cache istatistikleri
• Origin access log (zaman damgası, status code)
• Basit sentetik ölçüm: aynı URL listesiyle 5 dakikada bir istek

Günlük hayatta en sık görülen geçiş hataları

1) Cache anahtarında fazla varyant - Çoklu dil (hreflang) + parametreli URL + cookie kombinasyonu cache hit’i düşürür.

2) Set-Cookie yüzünden cache bypass - Kullanıcı oturumu gerekiyorsa, statik kaynakları ayrı host’a (veya ayrı path’e) taşıyın.

3) Purge planı yok - İçerik değişim sıklığı varsa “purge workflow” tanımlayın (kim, ne zaman, hangi URL).

4) WAF yanlış eşiği - Login ve checkout akışında false positive bloklar yaşanır.

Net öneri: Cloudflare yerine alternatif CDN’e geçiş için kontrol listesi

Aşağıdaki liste, geçiş kararını “his” yerine “kanıt”a bağlar.

Geçişi haklı çıkaran kanıtlar

• Cache hit oranı iyileştirilebilir (ör. origin kaynaklı bypass problemi)
• Türkiye trafiğinde TTFB farkı ölçülebilir (14 günlük test verisi)
• Log/uyumluluk şartları (saklama, erişim) kontratla doğrulanabiliyor
• Fiyat: aynı metriklerle (GB + istek + güvenlik özelliği) alternatif daha uygun

Geçiş yapılacaksa ön koşullar

• Cache policy dokümanı (hangi header, hangi TTL)
• Purge prosedürü (API limitleri dahil)
• WAF/Rate limiting planı (monitor → kademeli blok)
• Gözlemlenebilirlik: cache hit/miss ve origin error rate takipleri

Sonuç: Alternatif CDN seçimini “senaryo” ile yapın, marka ile değil

Cloudflare yerine alternatif CDN, doğru senaryoda ölçülebilir fayda sağlar: daha iyi cache verimi, daha uygun maliyet modeli, net log/uyumluluk koşulları veya Türkiye trafiğinde daha düşük TTFB. Aksiyon olarak önce origin cache bypass nedenlerini temizleyin, ardından 14 günlük kontrollü testle TTFB ve cache hit metriklerini sayısal olarak kıyaslayın. Bu iki adım bittiğinde, seçtiğiniz CDN’e geçiş kararınız net ve yönetilebilir olur.