The Economics of DDoS: Understanding Attack Costs and Defense Investment

Back in 2018 I got paged at 2:17 AM because a retail customer’s Black Friday sale had flatlined. It wasn’t a bug or a bad deploy — it was a 60 Gbps UDP flood that cost the attacker maybe $30 to launch, but cost the retailer over $80k in lost sales before we could fully reroute them. That night taught me the core lesson of DDoS economics: the math is brutally asymmetric, and if you don’t understand the pricing on both sides, you can’t make smart decisions about defense investment.

Why Attackers Don't Need a Big Budget to Hurt You

I’ve spent the last decade watching attack costs fall through the floor. Ten years ago, you needed a sizable botnet and some real technical skill to push meaningful traffic. Now? Anyone with a PayPal account can rent a booter/stresser service for an afternoon. For common DDoS Volumetric Attack Patterns: Identifying and Absorbing Bandwidth Floods, pricing is openly advertised on forums and even indexed sites. A 10-20 Gbps attack that would’ve required serious infrastructure in 2014 now runs about $10-$25 per hour. Need something bigger, like 100 Gbps? You’re still only looking at $50-$100 per hour, often with discounts for longer durations.

That low entry cost is driven by two things: amplification and scale. Attackers don’t pay for the bandwidth they send you — they trick someone else’s servers into doing it. A small DNS query can be turned into a 50x larger response aimed at your IP, which is why understanding DDoS DNS Amplification Defense: Stopping Reflected Attacks at CDN Scale is so critical for any operator. The economics for the attacker are simple — they send a few megabits, you get hit with gigabits. Add in massive IoT botnets of compromised cameras and routers that cost pennies to rent by the thousand, and the attacker’s DDoS pricing becomes almost negligible compared to your potential losses.

Where it gets really uneven is with application-layer attacks. I once traced a week-long outage for a SaaS API that wasn’t volumetric at all — it was a low-and-slow HTTP flood peaking at maybe 2,000 requests per second. It never tripped the bandwidth alarms, but it tied up all their origin worker threads. Those attacks, as described in DDoS Application Layer Attack Techniques: Slowloris, RUDY, and HTTP Floods, are even cheaper because they don’t need gigabits of traffic. An attacker can run them from a single VPS for $5 a month. The cost to them is trivial, but the cost to you is downtime, support tickets, and SLA credits.

// Rough estimator we use to model attacker cost vs. defender impact
// Based on observed booter service pricing in 2023-2024
function estimateEconomics(attackGbps, durationHours, targetRevenuePerHour) {
  let pricePerGbpsHour = 2.5; // $2-5 is typical for reflected UDP
  if (attackGbps < 10) pricePerGbpsHour = 4.0; // smaller attacks cost more per Gbps

  const attackerCost = attackGbps * pricePerGbpsHour * durationHours;
  const victimLoss = targetRevenuePerHour * durationHours * 0.85; // assume 85% traffic loss
  const asymmetryRatio = victimLoss / Math.max(attackerCost, 1);

  return {
    attackerCost: `$${attackerCost.toFixed(2)}`,
    victimLoss: `$${victimLoss.toFixed(2)}`,
    ratio: `${asymmetryRatio.toFixed(0)}:1`
  };
}

console.log(estimateEconomics(40, 4, 20000));
// { attackerCost: '$400.00', victimLoss: '$68000.00', ratio: '170:1' }

The False Economy of Bare-Minimum Protection

Early in my CDN career I worked with a gaming studio that didn’t want to pay for always-on mitigation. Their logic was, “We’ll just buy a cheap scrubbing service when we need it, and we’ve got a 10 Gbps link, that should be enough.” It wasn’t. When they got hit with a 25 Gbps burst, their upstream null-routed them in under 90 seconds, and it took 45 minutes to manually swing BGP to their on-demand provider. In that window they lost a tournament final and a bunch of players who never came back. That’s the hidden part of defense investment — it isn’t just the monthly bill, it’s the time to mitigation.

A lot of teams look at defense pricing and think anycast + overprovisioning is expensive. And yes, running globally distributed points of presence with 100+ Tbps of aggregate capacity isn’t cheap for us as a provider. But for you as a customer, the alternative is often more expensive. Buying and maintaining on-premise appliances that can handle today’s average attack size (now well over 50 Gbps according to multiple carrier reports) means big capex, power, and someone who knows how to tune them at 3 AM. I’ve seen companies spend $150k on boxes that were undersized 18 months later, because attack sizes keep climbing about 30-40% year over year.

What actually saves money is automated, always-on absorption. Under the HTTP Working Group Specifications (https://httpwg.org/specs/), modern HTTP/2 and HTTP/3 connections are highly multiplexed, which means a single malicious client can create outsized load without high bandwidth. You can’t filter that effectively with simple port-based rules at your firewall. You need behavior-based filtering close to the edge, before it hits your origin. That’s why we push rate limiting, challenge pages, and connection validation into the CDN edge — it’s far cheaper to drop a bad request in Warsaw or Singapore than to let it travel to your origin in Virginia and consume a worker thread. Articles on web.dev (https://web.dev/articles/) consistently show how origin strain directly degrades Core Web Vitals and conversion rates, even when you aren’t fully down — users just leave.

# Example: Edge rate-limiting that costs almost nothing to run
# but blocks cheap application-layer floods before origin
# This is a simplified Cloudflare / NGINX-style config we recommend

limit_req_zone $http_x_forwarded_for zone=api:10m rate=20r/s;
limit_conn_zone $binary_remote_addr zone=addr:10m;

server {
  location /api/login {
    # Enforce 20 req/s per IP, burst 40 with nodelay
    limit_req zone=api burst=40 nodelay;
    limit_conn addr 10;
    
    # Challenge if we see >100 reqs in 10s - likely abusive
    # Returns JS challenge instead of forwarding to origin
    error_page 503 @challenge;
  }

  location @challenge {
    # Serve lightweight challenge - costs attacker CPU, not your origin
    return 200 "js_challenge_html";
  }
}

How to Compare Defense Options Without Guessing

When I advise customers on defense investment, I tell them to stop asking “How much does DDoS protection cost?” and start asking “How much does an hour of downtime cost us, and how often might it happen?” A small blog with $500/month in ad revenue has a very different risk profile than a fintech API processing $2M in transactions per hour. We usually build a simple expected loss model: (probability of attack per year * average duration * hourly revenue loss) + SLA penalties + support overhead. If that number is $200k annually, spending $30k on robust protection isn’t a cost — it’s a 6x return.

There’s also the operational side you don’t see in a pricing sheet. An on-premise solution might look affordable until you factor in the 24/7 SOC staffing needed to monitor and react. Cloud scrubbing services that require manual BGP diversion add 5-15 minutes of exposure, and attackers know that window is enough to do damage. CDN-integrated, always-on mitigation typically adds 0-5 seconds of detection time because the traffic is already flowing through the mitigation network. That difference in time directly translates to dollars. I’ve yet to meet a team that regretted automating this away.

The trick is matching your defense tier to your real risk, not just buying the biggest number. Don’t pay for 100 Tbps of mitigation if your upstream can only deliver 10 Gbps to you anyway — you’ll be null-routed before mitigation helps. Instead, look at capacity, time to mitigation, and operational burden together. The cheapest option on paper is often the most expensive after one real incident.

From Spreadsheet to Shield: Putting Cost-Aware Defense Into Production

Knowing the economics is one thing — wiring it into your actual infrastructure without blowing your budget is where most teams get stuck. You don't need a seven-figure scrubbing contract on day one, but you do need thresholds that kick in automatically. What we've seen work best is a tiered model: baseline protection baked into your CDN or edge, plus pay-as-you-go scrubbing for the spikes that actually hurt. For a typical SaaS doing $50k-200k MRR, that baseline should handle 20-40 Gbps cleanly for under $300/month included in your CDN bill, with burst mitigation that only charges when you're under attack.

The trick is defining what "under attack" means in dollars, not just packets. We tell customers to set two triggers: a volumetric trigger (say, 3x your 95th percentile bandwidth sustained for 60 seconds) and a business-impact trigger (origin error rate >2% or p95 latency >800ms). If either fires, you fail over to your scrubbing tier automatically. Don't rely on a human watching Grafana at 2 AM — by the time someone pages in, you've already burned $4,000-8,000 in lost transactions and your support queue is on fire. Automate the cutover and you'll cut mean-time-to-mitigation from 12-15 minutes down to 45 seconds.

Here's a simplified version of the logic we deploy at the edge for customers on a cost-sensitive plan. It doesn't try to be perfect — it just makes sure you're not paying for a 500 Gbps defense when a 5 Gbps booter is what actually hits you 90% of the time:

# edge-mitigation.conf - cost-aware auto-mitigation
# Triggers L7 challenge + L3 scrubbing only when economics justify it

map $request_uri $mitigation_tier {
    default 0;
}

# Volumetric + business health checks (from Prometheus/edge metrics)
limit_req_zone $binary_remote_addr zone=origin_protect:10m rate=200r/s;

server {
    location / {
        # 1. Check origin health - if error_rate > 2%, escalate immediately
        auth_request /healthcheck-origin;

        # 2. Volumetric check: if edge_pps > 3 * p95_baseline
        # p95_baseline updated hourly via API (e.g., 35k pps)
        if ($edge_pps > 105000) {
            set $mitigation_tier 2; # Enable JS challenge + rate limit
        }

        # 3. Only divert to scrubbing center if tier 2 holds for 60s
        # This avoids paying scrubbing fees for 10-second spikes
        limit_req zone=origin_protect burst=500 nodelay;
        error_page 503 = @scrubbing;

        proxy_pass http://origin;
    }

    location @scrubbing {
        # Anycast scrubbing with clean pipe - billed per-GB only when active
        # ~$0.04/GB vs. $5k/month always-on. Saves ~$42k/year for mid-market.
        proxy_pass http://scrubbing.anycast.internal;
        proxy_set_header X-Mitigation-Tier $mitigation_tier;
    }
}

Advanced Patterns and Troubleshooting When the Math Gets Weird

That tiered model works beautifully until attackers stop playing volumetric games. The nastiest economic inversion we've seen in the last 18 months is carpet bombing. Instead of hammering one IP with 100 Gbps, they'll spray 500 Mbps across 200 IPs in your /24. Your per-IP graphs look totally normal, your volumetric alarms stay quiet, but your upstream router's control plane is melting. We've seen customers get null-routed by their transit provider for "abuse" when total traffic was only 18 Gbps — because it was spread so thin no single threshold fired. If you're seeing random packet loss across your entire subnet without a clear spike, you're not misconfigured, you're likely being carpet-bombed. You'll want a defense that aggregates across the prefix, not per-IP. We break down the full strategy in our guide to DDoS Carpet Bombing Defense: When Attackers Spread Traffic Across Your Entire Subnet.

Reflection amplification is the other place where cost math breaks. An attacker spending $15 on a booter can generate that $15 into 800 Gbps of junk if you've got open reflectors nearby — or if they can spoof your IP. NTP and memcached are still the worst offenders, even in 2024. NTP's monlist command can give a 556x amplification factor, and a single unpatched memcached instance can hit 51,000x. That's not a typo. One 15-byte request becomes a 750KB response pointed at you. If your defense is still doing simple UDP rate-limiting, you're paying to absorb traffic that shouldn't have left the internet in the first place. We've had to help folks who were blocking at their firewall when they should have been blocking upstream with BCP38 and response validation. Check your exposure to DDoS NTP Reflection Mitigation: Blocking Monlist-Based Amplification Attacks and DDoS Memcached Amplification Defense: Neutralizing 51,000x Amplification Factor before you buy bigger pipes — you might just need tighter egress filtering.

Troubleshooting tip: if your mitigation cost suddenly doubles but your attack volume hasn't, look at your cache hit ratio and origin shielding. We've seen teams pay for 40TB of scrubbed traffic that was 85% cacheable assets — images, JS, video segments. By moving those to edge cache with a 1-hour TTL and enabling origin shield in two regions, they dropped billable scrubbing traffic from 40TB to 6TB per attack, saving about $1,360 per incident at typical $0.04/GB scrubbing rates. Don't scrub what you can serve stale. And if your provider can't show you per-attack cost breakdowns — clean GB vs. mitigated GB vs. cache offload — you're flying blind. Ask for it.

Frequently Asked Questions