Cloudflare Alternatifi CDN: Ne zaman, neden seçilir?

CDN (Content Delivery Network) bir web sitesinin içerik dağıtımında gecikmeyi düşürür, trafik dalgalarını yönetir ve bazı güvenlik katmanları ekler. Cloudflare Türkiye’de yaygın olsa da her proje aynı gereksinime sahip değildir. Bu rehberde Cloudflare yerine alternatif CDN’e ne zaman geçmeniz gerektiğini; hız, maliyet, kontrol paneli (API/GUI), cache davranışı, WAF/DDoS yaklaşımı, loglama ve uyumluluk başlıklarında net şekilde anlatıyorum. Sonunda da alternatif CDN seçerken uygulayacağınız kontrol planını veriyorum.

Cloudflare alternatifi arama sebepleri: “tek sorun” değil, birkaç teknik ihtiyaç

Cloudflare’i tamamen bırakmak genelde tek bir sebepten değil, birden fazla kriterin üst üste gelmesinden olur. Aşağıdaki maddeler “ne zaman alternatif CDN gerekir?” sorusuna pratik yanıt verir:

• Cache kontrolü ve kuralları: Bazı projelerde URL bazlı, header bazlı ya da belirli MIME türlerine göre cache politikasını çok ince yönetmek istersiniz. Alternatif CDN’ler daha esnek kontrol sunabildiğinde geçiş gündeme gelir.
• Origin (asıl sunucu) davranışı: Origin’e giden istek sayısını azaltma, “cache hit oranı” hedefleme ve varyant (vary) yönetimi (ör. Accept-Encoding, dil/ülke varyantları) performansı doğrudan etkiler.
• Loglama ve gözlemlenebilirlik: Hız optimizasyonunun yanında “neden hata oldu?” sorusu kritiktir. Ayrıntılı erişim logları, gerçek zamanlı olay akışı ve uzun dönem raporlama (retention) fark yaratır.
• Maliyet yapısı: Cloudflare’in bazı özellikleri planlara göre farklılaşır. Trafik seviyeniz ve kullanılan bant genişliği/istek türleri (özellikle dinamik istekler) alternatif CDN ile daha öngörülebilir maliyet çıkarabilir.
• Uyumluluk ve veri konumu: Bazı kurumlar logların saklandığı bölge, şifreleme, erişim kontrolü ve hukuki uyumluluk (compliance) için daha net şartlar ister.
• WAF/DDoS işleyişinin proje ile uyumu: Her CDN/WAF aynı şekilde çalışmaz. İmzalar, bot yönetimi, rate limit yaklaşımı veya challenge davranışı (JS challenge vb.) bazı uygulamalarda beklenmedik sonuç doğurabilir.

Bu listeyi “Cloudflare kötü” gibi okumayın. Tam tersine: Cloudflare çoğu site için güçlüdür. Ancak yukarıdaki ihtiyaçların bir kombinasyonu sizde netleştiğinde alternatif CDN daha mantıklı hale gelir.

Alternatif CDN seçmeden önce teknik hedefleri netleştirin

“Ne zaman geçmeliyim?” sorusu için ilk adım hedefi ölçülebilir hale getirmektir. Aşağıdaki hedefler, geçişin başarılı olup olmadığını 1-2 hafta içinde gösterecek kadar somuttur.

Ölçüm planı (geçiş öncesi ve sonrası)

1. TTFB (Time to First Byte): Siteyi CDN ile ve CDN’siz karşılaştırın. Mobil/masaüstü için ayrı bakın.
2. Cache hit oranı: CDN’den dönen yanıtların ne kadarının cache’den geldiğini inceleyin.
3. Origin istek hacmi: Origin’e giden istek sayısı (özellikle 4xx/5xx ve dinamik endpointler).
4. Gerçek kullanıcı metrikleri: Sayfa yüklenme süreleri, hata oranları ve LCP/CLS trendleri.
5. WAF olayları: Gerçek trafiğinizde hangi saldırı/yanlış pozitifler tetikleniyor?

Hedef değerler (referans çerçevesi)

• Cache hit oranı özellikle statik içerikte yükselmelidir (ör. görseller, CSS/JS, dokümanlar).
• Origin’e giden istekler, aynı trafik altında azalmalıdır.
• WAF kaynaklı yanlış engelleme (false positive) sayısı kabul edilebilir sınırda kalmalıdır.

Not: “X% hit olacak” tek bir evrensel sayı değildir. Dil/ülke varyantı, cookie kullanımı, query string (örn. ?v=...) davranışı hedefi değiştirir. Bu yüzden ölçüm esastır.

Cloudflare yerine alternatif CDN’de nelere bakılır? (kontrol listesi)

Aşağıdaki kriterler, CDN seçimini “fiyat” yerine “proje uyumu” eksenine taşır.

1) Cache anahtarı (cache key) ve varyant stratejisi

Bazı CDN’ler cache key’i URL + bazı header’larla oluşturur. Sizin için kritik olan şunlar: - Query string cache’leniyor mu? utm_* parametreleri cache’i bölüyor mu? - Accept-Encoding (Brotli/Gzip) varyantları doğru yönetiliyor mu? - Dil/ülke varyantları nasıl ayrılıyor? - Cookie varsa cache davranışı bozuluyor mu?

Net test: Aynı sayfada farklı query ve header kombinasyonlarıyla cache hit oranını gözlemleyin. Örneğin 10 farklı utm_campaign değeri cache’yi 10 farklı varyanta bölüyorsa maliyet artar ve performans düşer.

2) Purge (temizleme) ve invalidation hızı

İçerik güncelledikten sonra cache temizliği ne kadar hızlı? - Tek dosya purge mi yapılıyor, yoksa tüm prefix/pattern purge var mı? - Yanlış purge riski var mı? - CDN invalidation gecikmesi (propagation) performansı etkiler.

3) Dinamik içerik ve “edge caching” yaklaşımı

Cloudflare gibi bazı çözümler edge üzerinde daha fazla optimizasyon yapar. Alternatif CDN’de şu soruları netleştirin: - Tam sayfa (HTML) edge’de cache’lenebiliyor mu? - Cookie/oturum bilgisi cache’i nasıl etkiliyor? - POST/PUT gibi metodlarda davranış nasıl?

4) Loglar, API ve günlük yönetimi

Operasyon açısından en kritik fark çoğu zaman log detayıdır. - Erişim logları CSV/JSON olarak indirilebiliyor mu? - API ile olay verisi çekiliyor mu? - Log saklama süresi (retention) ve maliyet ilişkisi nasıl?

5) WAF ve DDoS koruma mimarisi

CDN/WAF kombinasyonunda karar verirken “DDoS var mı?” sorusu yetmez: - Rate limiting hangi katmanda uygulanır? - Challenge (örn. tarayıcı doğrulama) tetiklenince kullanıcı deneyimi bozulur mu? - Bot yönetimi false positive üretiyor mu?

6) Origin Shield, pull/push ve trafik azaltma

Bazı CDN’ler origin’e giden trafiği daha agresif azaltır. - Origin Shield benzeri bir katman var mı? - Peak saatlerde origin’e yığılma olur mu? - Cache yeniden doğrulama (revalidation) davranışı nasıl?

7) TLS/sertifika yönetimi ve HTTP/2/HTTP/3 desteği

• Otomatik sertifika yönetimi (ACME) var mı?
• HTTP/2 ve HTTP/3 etkinleştirme kontrolü nasıl?

8) Yönetim arayüzü ve bakım eforu

• Kurallar (rule) dili okunabilir mi?
• Debug (neden cache olmadı?) için “gösterge” sağlıyor mu?
• Ekibin öğrenme eğrisi kaç gün sürer?

“Ne zaman alternatif CDN daha mantıklı?” senaryoları

Aşağıdaki senaryolar, Cloudflare yerine alternatif CDN’e geçişin teknik olarak daha doğru olacağı durumları özetler.

Senaryo A: Cache stratejiniz çok spesifik (varyant + header temelli)

Örneğin bir uygulama, aynı URL’de dil ve cihaz türüne göre HTML üretir ve header’lar kritik olur. Alternatif CDN, cache key’i daha öngörülebilir şekilde ayarlıyorsa origin maliyeti ve gecikme düşer.

Senaryo B: Dinamik sayfalar çok, “edge cache” davranışı kritik

Dinamik sayfalar çoksa amaç sadece “statik dosyaları hızlandırmak” değil; dinamik uçlarda yanlış cache’lemeyi engelleyip doğru bölümlendirme yapmak olur. Kuralların daha net ve daha az sürprizli olduğu CDN tercih edilir.

Senaryo C: Log ve uyumluluk gereksinimleri sıkı

Kurumsal yapılarda denetim (audit) ve veri saklama şartları önemlidir. Örneğin uzun süreli erişim logları gerekiyorsa ve retention politikası net ise alternatif CDN seçilir.

Senaryo D: WAF tarafında yanlış pozitif maliyeti yüksek

E-ticaret/finans gibi alanlarda challenge tetiklenmesi işlem akışını bozabilir. Alternatif CDN’de WAF tuning ve rule override süreçleri daha uyumlu ise geçiş yapılır.

Senaryo E: Maliyet, istek tipine göre daha iyi yönetiliyor

Bant genişliği kadar “istek sayısı” da maliyeti etkiler. Özellikle küçük dosyaların yüksek frekansla servis edildiği durumlarda, alternatif CDN’in fiyatlandırma modeli daha avantajlı olabilir.

Geçiş yaklaşımı: Risksiz bir deneme ile karar verin

CDN değişimi tek hamlede yapılmamalıdır. Net ve güvenli yaklaşım aşağıdaki adımlardır.

1) A/B testi için trafiği bölün

• Tüm trafiği kesmeyin.
• Belirli yolları (ör. /static/, görsel dizinleri, CSS/JS) önce değiştirin.

2) Cache kurallarını staging ortamında doğrulayın

• “Cache olur mu / olmaz mı?” sonucunu gözleyin.
• Aynı içerik farklı URL query’lerinde çoğalıyor mu kontrol edin.

3) Purge ve invalidation prosedürünü uygulamalı test edin

• İçerik güncelle, purge yap, yeni içerik geldi mi ölç.
• Gecikme (propagation) kaç dakikaya yayılıyor?

4) WAF false positive senaryolarını kontrol edin

• Arama/bakul/checkout gibi hassas endpointlerde rate limit ve rule tetiklerini izleyin.
• Gerçek kullanıcı ajanlarına benzer testlerle doğrulayın.

5) KPI raporu çıkarın (karar verdiren kısım)

Aşağıdaki tablo geçiş kararını netleştirir:

Sonuç: Karar için en doğru aksiyon “ölç, dar alanda dene, kuralı doğrula”

Cloudflare yerine alternatif CDN’e geçmek; çoğu zaman “biri diğerinden üstün” olduğu için değil, cache anahtarı, varyant yönetimi, loglama/uyumluluk ve WAF tuning gibi teknik gereksinimler nedeniyle daha doğru bir uyum arandığında yapılır. Bu nedenle hemen tam geçiş yerine statik içerik ve belirli path’lerde kontrollü deneme yapın, cache hit ve origin yükünü ölçün, purge ve WAF davranışını stresleyin. NetKıyas’ta aynı anda plan maliyeti ve teknik özellikleri karşılaştırarak başlamak, geçiş riskini azaltır; kararınızı da ölçüm sonuçlarına göre verin.