CDN + WAF + Rate Limiting: Katmanları sırayla kurun ve maliyeti ölçün

Web sitenizde trafiğin hem hız hem de güvenlik açısından yönetilmesi gerekir. CDN, WAF ve rate limiting (istek oranı kısıtlama) birlikte kurulduğunda aynı anda sayfa yükleme süreleri düşer, kötü niyetli istekler filtrelenir. Bu rehberde katmanları doğru sırayla nasıl kurgulayacağınızı, ölçüm için hangi metrikleri izlemeniz gerektiğini ve maliyeti nasıl hesaplayacağınızı net adımlarla anlatıyorum.

Hedef: CDN/WAF/rate limiting kurulumundan sonra "iyileşti mi"yi sayısal kanıtla görmek ve gereksiz maliyet üretmeden en doğru ayarı bulmak.

1) Katmanlar neden sırayla kurulmalı?

Bu üç katman aynı sorunu farklı seviyelerde çözer:

CDN (Content Delivery Network): Statik ve mümkünse dinamik içeriği en yakın PoP’dan (Point of Presence) dağıtır. TLS/HTTP oturumları, cache hit oranı ve edge işleme hızları öne çıkar.
WAF (Web Application Firewall): Uygulama katmanına gelen istekleri kurallarla değerlendirir. SQL enjeksiyonu, XSS, bot davranışları, anomali desenleri gibi örüntüler engellenir.
Rate limiting: Trafiği bir kaynağa (IP, token, kullanıcı, endpoint) göre sınırlar. Özellikle login, arama, checkout, API gibi hassas uçlarda saldırı maliyetini artırır.

Sıralama için pratik kural şudur:

Önce CDN ile trafiği “yönetilebilir” hale getirin.
Sonra WAF ile istekleri uygulama öncesinde filtreleyin.
En son aşamada rate limiting ile kötüye kullanımı “oran” bazında durdurun.

Bu sıra, WAF’in ve rate limiting’in gereksiz yere çok fazla istek üzerinden çalışmasını azaltır. Örneğin CDN cache’lenen içerik için uygulama tamamen devre dışı kalınca WAF’in değerlendirmesi de azalır (özellikle edge seviyesinde devreye giriyorsa).

Performans beklentisini bir formülle bağlayın

Süre (ms) ve maliyet (€/₺) aynı anda düşünülmeli. Aşağıdaki denklemi hedef olarak kullanın:

Süre azaltma: Cache hit oranı yükseldikçe origin (orijinal sunucu) yanıt süresi ve TTFB düşer.
Maliyet azaltma: WAF ve rate limiting değerlendirmesi azaldıkça lisans/istek maliyetleri (bazı sağlayıcılarda “işlenen istek” bazında) kontrol altında kalır.

2) Ölçüm planı: Kurulumdan önce ve sonra neyi ölçmelisiniz?

Kurulumdan sonra “hissettim iyi oldu” yerine, üç kategoride ölçüm yapın: hız, güvenlik olayı, maliyet.

Hız metrikleri (performans)

En az şu dördünü toplayın:

TTFB / Origin TTFB: İlk byte süresi. CDN sonrası edge TTFB ve origin TTFB ayrımı önemlidir.
Page Load / First Contentful Paint (FCP): Tarayıcı tarafı. RUM (Real User Monitoring) varsa kullanın.
Cache hit rate (cache doluluk oranı): CDN’in ne kadarının origin’e gitmeden döndüğünü gösterir.
5xx oranı ve hata kodları dağılımı: Özellikle 502/503 (origin sorunları) ve 504 (gateway timeout) izlenmeli.

Güvenlik metrikleri (WAF + rate limiting)

Kurulum sonrası şu soruların cevabını ölçün:

Kaç istek WAF tarafından engellendi? (örn. 403 response)
Engelleme dağılımı hangi endpoint’lerde? (örn. /login, /wp-admin, /api/*)
Rate limiting kaç kez tetiklendi? Hangi eşiklerde en çok reject var?

Maliyet metrikleri (finans)

Sağlayıcı fiyat modeline göre değişir; yine de genel çerçeve aynıdır:

CDN veri çıkışı (GB/TB)
WAF işlem/istek (requests) veya koruma lisansı
Rate limiting tetik sayıları (bazı sistemlerde her istek ücretlenir; bazılarında log/analitik ek maliyet olabilir)
Origin kapasite maliyeti: aynı trafikle daha az origin CPU/RAM/DB yükü oluşuyor mu?

Kurulumdan önce baseline alın. En pratik yöntem: 7 gün normal trafik + 1-2 gün özellikle yoğun saat aralığı. Sonra aynı zaman penceresinde karşılaştırma yapın.

3) CDN’i önce kurun: Cache, header ve origin yükünü netleştirin

CDN kurulumunda hedef sadece “açmak” değil; cache davranışını ve origin trafiğini ölçülebilir şekilde kontrol etmektir.

Adım adım CDN yapılandırma checklist’i

DNS yönlendirmesi: Domain’inizi CDN’in verdiği CNAME/ALIAS/NS akışına bağlayın.
TLS kurulumu: Edge üzerinde TLS’i etkinleştirin. Mümkünse end-to-end şifreleme hedefleyin.
Cache policy: Statik dosyalar için uzun TTL, dinamik içerik için kısa TTL veya “revalidate” yaklaşımı kullanın.
Cache anahtarı (cache key): Cookie veya query string cache’i bozuyorsa, gereksiz varyasyonları azaltın.
Header’lar: Origin’e giden gerçek IP için doğru header’ı kullanın (ör. X-Forwarded-For). Aksi halde rate limiting yanlış IP üzerinden çalışır.

Cache başarısını doğrulayın

Aşağıdaki gibi bir karşılaştırma yapın:

Kurulum öncesi: “Origin istekleri = toplam istek”
Kurulum sonrası: “Origin istekleri = toplam istek × (1 - cache hit)”

Cache hit oranını hedeflerken şu mantığı kullanın: - Statik ağırlıklı sitelerde (CSS/JS/img): %70-90 aralığı gerçekçi bir hedef olabilir. - Dinamik ağırlıklı uygulamalarda: hedef daha düşüktür, ama doğru varyasyon azaltımıyla önemli kazanç sağlanır.

Origin loglarıyla doğrulayın

CDN sonrası origin’de şu olaylar görünmelidir: - Cache hit’ten dolayı origin çağrılarında belirgin düşüş - “Gerçek kullanıcı IP’si” için log alanlarınızın doğru dolması - Rate limiting veya WAF için gerekli endpoint metriklerinin tutarlı olması

4) WAF’i takın: Kuralların etkisini endpoint bazında ölçün

WAF’in amacı istekleri “engellemek”ten önce, yanlış pozitifleri minimize ederek doğru saldırı türlerini yakalamaktır.

Uygulama öncesi WAF konumlandırması

WAF’i, mümkünse CDN edge seviyesinde çalıştırın. Bu sayede gereksiz origin yükü oluşmadan filtreleme yapılır.

Kural seti seçimi: Sıralı yaklaşım

Temel bot/OWASP benzeri çekirdek kurallar ile başlayın.
Uygulamanıza özel riskli endpoint’lerde (login, kayıt, arama, API) kademeli olarak sertleşin.
Her kural seti sonrası 24-72 saat izleme yapın.

Yanlış pozitif kontrolü: somut test

WAF 403 üretmeye başladığında önce şunu kontrol edin: Hangi User-Agent / hangi path / hangi parametre engelleniyor?
Uygulamanızın normal davranış akışlarını (login denemesi, form gönderimi, kullanıcı profili güncelleme) bir test listesiyle doğrulayın.
Hız testi: Kural sayısı artınca TTFB artışı oluşabilir. Bunu “WAF etkinleşmeden önce/sonra” karşılaştırın.

5) Rate limiting’i son katman yapın: Eşik seçimi ve maliyet kontrolü

Rate limiting, saldırıyı tamamen durdurmak yerine saldırının maliyetini yükseltir. Doğru eşik seçimi burada kritiktir.

Eşik mantığı: endpoint + kimlik

Genel olarak şu yaklaşımı kullanın:

Login / register: IP bazlı + mümkünse kullanıcı davranışı/oturum bazlı.
API: Token veya API key varsa bu anahtar üzerinden.
Arama: Daha sıkı eşik; aynı query’nin tekrarını kontrol edin.

CDN header ile gerçek IP kullanımı

Rate limiting yanlış IP’ye göre çalışırsa iki problem olur: - Aynı NAT arkasındaki binlerce kullanıcı tek bir IP’de toplanır ve toplu engel oluşur. - Saldırgan gerçek IP yerine CDN IP’si olarak görünür.

Bu yüzden origin değil edge tarafında da doğru IP’nin geldiğini doğrulayın. Uygulamanızda loglayan IP alanının, rate limiting kuralınızla aynı kaynaktan üretildiğinden emin olun.

Ölçüm: Threshold ayarının ekonomik etkisi

Rate limit eşiğini yükseltmek (daha az engel) genelde daha fazla kötü trafiğin origin’e yaklaşmasına yol açar; eşiği düşürmek ise daha çok 429 üretir. Doğru noktayı şu karşılaştırmayla bulun:

“Engellenen istek / toplam istek” oranı
429/403 oranı artarken “iyi trafik” gerçekten etkileniyor mu?
Origin CPU/DB yükü ne kadar düşüyor?

6) Performans ve maliyeti birlikte hesaplamak: pratik senaryo

Aşağıdaki senaryo gerçekçi bir planlama şablonudur. Sayıları örnek aldım; kendi trafik metriklerinize göre değiştirirsiniz.

6.1 Baseline çıkarın (Kurulum öncesi)

Toplam istek: 30 gün ortalama günlük 1.000.000 request
Origin veri transfer: 600 GB/gün
WAF yok / rate limit yok
Ortalama TTFB (origin): 350 ms

6.2 CDN’i koyun

Cache hit oranı: %80
Origin’e giden istek: 200.000 request
Origin veri transfer: 120 GB/gün

Beklenen etki: TTFB düşer (özellikle dynamic olmayan sayfalarda). WAF/rate limiting maliyeti de (edge filtreleme varsa) azalır.

6.3 WAF’i kademeli açın

Kuralların ilk dalgası ile engellenen istek: %1,2
Ortalama edge TTFB değişimi: +10-20 ms (kural karmaşıklığına bağlı)

Bu noktada hedef, kullanıcı etkisi düşükken saldırı etkisini artırmaktır.

6.4 Rate limiting ile kötüye kullanım maliyetini yükseltin

Login endpoint’inde 429 oranı: %0,3
Origin CPU: %25 düşüş

Bu karşılaştırma, maliyetin “sadece filtreleme” değil “origin tasarrufu” tarafından da geldiğini gösterir.

Kontrol listesi: Maliyet artmadan kazanım

Aşağıdaki durumları görünce planı revize edin:

WAF kural sayısı artıyor ama origin yükü düşmüyor: WAF yanlış noktada çalışıyor olabilir veya cache efektif değil olabilir.
Rate limiting çok sık tetikleniyor: IP header yanlış olabilir; eşikler IP yerine token veya session bazına çekilmelidir.
Cache hit düşüyor: Cookie/query varyasyonları cache’i bozuyordur.

7) Uygulama sırası ile en hızlı sonuç veren strateji

Tüm süreçte “hız + güvenlik + maliyet” birlikte optimize edilmelidir.

Önerilen net sıralama:

CDN + doğru DNS + doğru TLS
Cache policy (statik uzun TTL, dinamik planlı TTL)
Edge’de WAF (base kurallardan başlayarak endpoint bazlı sıkılaştır)
Rate limiting (kimliğe göre eşik + doğru gerçek IP)
Her katmanda 24-72 saat izleme ve metrik kıyas

Aşırı maliyet üretmemek için minimum ölçüm seti

Teknik ekip küçükse bile şu üç metrikten vazgeçmeyin:

CDN cache hit oranı
WAF engelleme (403) ve rate limit tetik (429) dağılımı
Origin TTFB + 5xx oranı

Sonuç: Aksiyon planı

Hedefiniz, CDN/WAF/rate limiting’i “tek seferde kurup bırakmak” değil; katmanların birbirini nasıl azalttığını ölçmektir. Bu nedenle önce CDN’in cache davranışını sayısallaştırın, ardından WAF’i endpoint bazında kademeli sertleştirin, en son olarak rate limiting eşiklerini doğru kimlik (IP/header/token) üzerinden ayarlayın. Kurulumdan sonra aynı trafik penceresinde TTFB/cache hit/403-429/origin 5xx değerlerini kıyaslayın; kazanım üretmeyen kural ve eşikleri kaldırarak maliyeti kalıcı biçimde düşürün.