DDoS Readiness for 2026: Designing for Hyper-Volumetric Reality on a Budget

The 2026 Threat Landscape: Hyper-Volumetric Is Normal

Cloudflare's DDoS Threat Reports from 2024 and 2025 document a clear trajectory: attacks exceeding 1 Tbps are no longer exceptional. The largest recorded attacks have surpassed 5 Tbps. More critically, the frequency of hyper-volumetric attacks (defined as exceeding 1 Tbps or 1 billion packets per second) has increased substantially each quarter.

The drivers are straightforward. Botnets composed of compromised IoT devices, virtual private servers rented with stolen credentials, and amplification vectors that refuse to die (DNS, NTP, CLDAP, memcached) combine to produce attack volumes that would have been state-level capabilities a decade ago. Today, they are available as DDoS-for-hire services for modest sums.

For small and mid-sized operators — the team running a handful of sites on a limited budget — this is the reality to design for. You will not outspend the attack. You need architecture that absorbs it.

Principles Before Tools

Before selecting products or configuring services, establish the design principles that guide your DDoS resilience:

1. The edge absorbs; the origin survives. Your origin server should never directly face attack traffic. Every request reaches the origin only after passing through a filtering and absorption layer.

2. Static content is your best defence. A fully static site served from CDN cache is inherently resilient to most application-layer DDoS attacks. There is no database to exhaust, no session state to overwhelm, no dynamic computation to abuse.

3. Defence must be automatic. If your mitigation requires a human to notice the attack and press a button, you will lose minutes or hours of availability. Automatic detection and mitigation is non-negotiable.

4. Budget constraints are real. Not every operator can afford enterprise DDoS protection. The architecture below prioritises free and low-cost options that provide genuine protection.

CDN-Based Absorption: Your Primary Layer

Why CDN-First Works

Content delivery networks operate hundreds or thousands of points of presence (PoPs) worldwide. When attack traffic hits a CDN, it distributes across this global network rather than concentrating on your single origin. The CDN's aggregate capacity — measured in hundreds of terabits per second — dwarfs any individual attack.

For static sites, the CDN can serve the entire site from cache without ever contacting your origin during an attack. This is not a theoretical benefit; it is the primary mechanism that keeps small sites alive during large attacks.

Cloudflare Free Tier: What You Actually Get

Cloudflare's free tier includes unmetered DDoS mitigation. This is not a marketing footnote — it is a genuine, substantial benefit:

• Layer 3/4 volumetric mitigation with no bandwidth cap
• Layer 7 (HTTP) DDoS mitigation using automated detection
• Always-on — no need to manually activate during an attack
• No surge billing — you are not charged for attack traffic

The free tier does have limitations:

• No custom WAF rules (only managed rulesets)
• Limited rate-limiting configuration
• No priority support during incidents
• Five page rules maximum
• No Cloudflare Spectrum (TCP/UDP proxy for non-HTTP)

For a static site, these limitations rarely matter. The HTTP DDoS protection covers the primary attack surface.

Configuration Checklist for CDN-Based Protection

• [ ] Proxy all DNS records — every A/AAAA/CNAME record that serves web traffic must be proxied (orange cloud in Cloudflare). Unproxied records expose your origin IP.
• [ ] Set cache-everything rules for static content. Ensure HTML pages are cached, not just assets. For static sites, there is no reason for cache misses on normal content.
• [ ] Enable "Under Attack" mode as automatic — Cloudflare's Security Level can be set to escalate automatically. On the free tier, you can manually enable "I'm Under Attack" mode, which adds a JavaScript challenge to all requests.
• [ ] Configure browser integrity check — rejects requests with suspicious HTTP headers commonly used by bots.
• [ ] Set minimum TLS version to 1.2 — blocks ancient clients that are overwhelmingly bots.
• [ ] Enable bot fight mode — available on free tier, challenges requests identified as automated.

Origin Hardening: Your Secondary Layer

CDN absorption handles volumetric attacks. Origin hardening handles everything else — attacks that bypass the CDN, application-layer attacks that generate cache misses, and situations where the attacker discovers your origin IP.

Hide Your Origin IP

This is the single most important origin-hardening step. If the attacker knows your origin IP, they can bypass the CDN entirely and attack the origin directly.

• [ ] Never expose origin IP in DNS history. If your origin IP was ever in a public DNS record before you added CDN protection, assume it is known. Change it.
• [ ] Check certificate transparency logs. If you requested a certificate for your domain that includes the origin IP (via SAN or by issuing from the origin), it may be discoverable.
• [ ] Audit outbound connections. Emails sent from the origin server often reveal the origin IP in headers. Use a separate mail relay.
• [ ] Remove server-identifying headers. Strip Server:, X-Powered-By:, and any custom headers that reveal infrastructure details.

Firewall the Origin

Configure the origin server's firewall to accept HTTP/HTTPS traffic only from your CDN's IP ranges:

# Example: iptables rules allowing only Cloudflare IPs
# Cloudflare publishes their IP ranges at https://www.cloudflare.com/ips/

# Allow Cloudflare IPv4 ranges
for ip in $(curl -s https://www.cloudflare.com/ips-v4); do
    iptables -A INPUT -p tcp --dport 443 -s "$ip" -j ACCEPT
done

# Allow Cloudflare IPv6 ranges
for ip in $(curl -s https://www.cloudflare.com/ips-v6); do
    ip6tables -A INPUT -p tcp --dport 443 -s "$ip" -j ACCEPT
done

# Drop all other HTTPS traffic to origin
iptables -A INPUT -p tcp --dport 443 -j DROP

• [ ] Restrict SSH access to known management IPs or a VPN
• [ ] Disable all unnecessary listening services
• [ ] If using a cloud provider, use their security groups or firewall rules — they filter before traffic reaches your instance

Rate Limiting at the Origin

Even with CDN protection, implement rate limiting at the origin as defence in depth:

# Nginx rate limiting
limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=api:10m rate=2r/s;

server {
    location / {
        limit_req zone=general burst=20 nodelay;
    }

    location /api/ {
        limit_req zone=api burst=5 nodelay;
    }
}

For static sites, rate limiting at the origin is primarily relevant for any dynamic endpoints (search, contact forms, APIs) that cannot be fully cached.

Anycast: Why It Matters

Anycast routing advertises the same IP address from multiple locations worldwide. When an attack targets an anycast IP, the traffic is automatically distributed across all locations advertising that address. No single location receives the full attack volume.

CDN providers use anycast by default — this is fundamental to how they distribute traffic. If you are behind Cloudflare, AWS CloudFront, or similar services, you benefit from anycast without additional configuration.

If you operate your own edge infrastructure (unlikely at small scale, but worth noting), anycast requires BGP peering from multiple locations. This is generally only practical if you are already operating in multiple data centres.

Response Runbook

When an attack occurs, you need a documented plan — not a panicked improvisation. Create a runbook and keep it accessible (not only on the infrastructure being attacked).

Detection

How will you know an attack is happening?

• [ ] CDN dashboard alerts — configure alerts for traffic spikes, elevated error rates, and increased challenge solve rates
• [ ] Origin monitoring — uptime checks from external services (UptimeRobot, Pingdom, or similar). If the CDN is absorbing the attack, the origin should remain healthy. If origin monitoring shows degradation, the attack may be bypassing the CDN.
• [ ] Bandwidth alerts from your hosting provider
• [ ] Log analysis — sudden changes in request patterns, geographic distribution, user-agent strings

Escalation Tiers

Tier 1: Automatic mitigation is handling it.

The CDN absorbs the attack. Your site remains available. Origin metrics are normal.

Action: Monitor. No intervention needed. Document the attack characteristics for post-incident review.

Tier 2: Partial degradation despite CDN mitigation.

The CDN is absorbing most traffic, but some attack traffic reaches the origin. Origin CPU or bandwidth is elevated. Some users experience slow responses.

Action:

1. Enable "I'm Under Attack" mode if not already active
2. Tighten rate limits at the origin
3. Block attacking IP ranges at the firewall if identifiable
4. Consider temporarily enabling a stricter security level in the CDN

Tier 3: Origin overwhelmed or CDN bypass.

The attacker has found the origin IP or is generating traffic that causes cache misses.

Action:

1. Change the origin IP address
2. Ensure the new IP is firewalled to CDN-only access
3. Purge DNS caches of the old IP
4. If on a cloud provider, scale up the instance temporarily
5. Contact CDN support if on a paid tier

Post-Incident

• [ ] Document attack timeline, peak volume, duration, and vector
• [ ] Verify that no origin IP exposure occurred
• [ ] Review logs for any successful bypasses
• [ ] Update firewall rules if new attack patterns were identified
• [ ] Update this runbook with lessons learned

Always-On vs. On-Demand Protection

Always-on mitigation routes all traffic through the DDoS protection layer at all times. There is no activation delay when an attack starts.

On-demand mitigation routes traffic through the protection layer only when an attack is detected. This typically involves a DNS change or BGP route announcement, introducing minutes of delay.

For web traffic behind a CDN, you already have always-on protection — the CDN is always in the traffic path. The distinction matters more for non-HTTP services (game servers, VoIP, custom protocols) where you might consider standalone DDoS protection services.

For budget-conscious operators: always-on CDN-based protection (Cloudflare free tier) costs nothing. On-demand standalone DDoS protection services typically start at hundreds of dollars per month. Unless you have non-HTTP services to protect, always-on CDN protection is the clear choice.

Budget-Friendly Architecture Summary

Total ongoing cost for meaningful DDoS resilience: zero, assuming your hosting costs remain the same.

Gotchas

Cloudflare's free-tier DDoS protection is real, but support is not. During a sophisticated attack that requires manual intervention by Cloudflare's team, free-tier customers do not get priority. For most volumetric attacks, the automatic mitigation handles everything. For targeted, adaptive attacks, you may want a paid plan for support access.

Cache bypass attacks are the sophisticated threat. An attacker who understands your site's structure can craft requests that always miss the cache — unique query strings, POST requests, requests for uncacheable URLs. For static sites, ensure your cache rules are comprehensive. Every URL that returns static content should be cacheable.

Your origin IP is probably already known. Historical DNS records, certificate transparency logs, Shodan scans, and outbound email headers may have exposed it. Assume it is known and firewall accordingly.

Geographic blocking is a blunt instrument. Blocking entire countries may stop some attack traffic but also blocks legitimate users. Use it only as a temporary measure during active attacks, and only if you can confirm the attack traffic is geographically concentrated.

SSL/TLS handshake floods consume more origin resources than simple HTTP floods because the cryptographic operations are CPU-intensive. If your origin terminates TLS directly (rather than the CDN handling it), this is a significant vulnerability. Let the CDN terminate TLS; connect to the origin over a private channel or CDN-to-origin TLS.

Verification Steps

After implementing this architecture, verify each layer:

• [ ] Confirm all DNS records serving web traffic are proxied through the CDN
• [ ] Verify origin IP is not discoverable via DNS history tools (SecurityTrails, DNSdumpster)
• [ ] Test that direct connections to the origin IP on ports 80/443 are refused
• [ ] Confirm CDN cache hit ratio exceeds 90% for static content
• [ ] Test rate limiting by sending rapid requests from a test IP
• [ ] Trigger "Under Attack" mode and verify the JavaScript challenge appears
• [ ] Confirm monitoring alerts fire when origin response time exceeds thresholds
• [ ] Walk through the response runbook as a tabletop exercise with your team

Further Reading

• Cloudflare DDoS Threat Reports — quarterly threat intelligence
• Cloudflare IP Ranges — for origin firewall configuration
• AI & Bot Traffic Hardening for 2026 — related traffic management
• Security hub — all security articles
• Operations hub — monitoring and response resources