Is Google reCAPTCHA a DDoS Defence? The Cost Math Says No

There’s a category of question that gets asked quietly in Slack channels and in private post-incident reviews: “could we just use reCAPTCHA to handle this?” It’s not an unreasonable instinct. Google reCAPTCHA is already deployed on most sites, it can challenge suspicious traffic, and it costs nothing for the first ten thousand requests. As a lightweight speed bump, it has its place.

But “speed bump against DDoS traffic” and “speed bump against spam submissions” are very different things — and running reCAPTCHA into a volumetric attack has a financial profile that most teams haven’t priced out before they need to.

The billing model nobody reads until it matters

Google reCAPTCHA Enterprise pricing is structured like this:

• First 10,000 requests per month: free
• Requests 10,001 – 1,000,000: $8 per 1,000 (effectively $1 per 1,000 additional)
• Beyond 1,000,000: negotiated enterprise pricing

That’s a reasonable cost structure for a contact form or a login page with normal traffic. It becomes something else entirely under attack conditions.

A mid-sized volumetric DDoS at 25,000 requests per second — not unusual, not catastrophic by modern standards — generates 1.5 million requests per minute. At $1 per 1,000 requests once you’ve cleared the free tier, you’re running at approximately:

• $25 per second
• $1,500 per minute
• $90,000 per hour

Four hours of sustained attack: $360,000 in reCAPTCHA billing. Six hours: over half a million dollars. The attack itself may cost the attacker a few hundred dollars on a DDoS-for-hire service.

Why reCAPTCHA isn’t the right tool

The core problem isn’t just cost — it’s that reCAPTCHA is designed for a different threat model. It was built to distinguish human users from automated scripts at application decision points: form submissions, account creation, login attempts. It operates at the application layer, after the request has traversed your infrastructure, been processed by your load balancer, and reached your application.

A volumetric DDoS attack doesn’t care about your application. The goal is to exhaust bandwidth or connection capacity before requests reach the application layer at all. By the time reCAPTCHA could evaluate a request, the infrastructure damage is already done.

reCAPTCHA also assumes legitimate users will complete challenges. Under a real DDoS, a significant portion of attack traffic is generated by botnets running headless browsers or sophisticated automation that can solve v2 challenges and score well on v3’s risk assessment. The friction that stops a casual spammer does not stop a motivated attacker.

What you actually get when you layer reCAPTCHA over a DDoS attack:

• Infrastructure still absorbs the connection load
• Legitimate users get challenged and frustrated
• The attacker’s traffic generates Google billing against your account
• The attack continues until the attacker stops or your bill ceiling triggers a service interruption

Where the cost goes

This isn’t a theoretical concern. Cloud vendors and API providers have billing models that don’t discriminate between legitimate and attack traffic — that’s by design, because the infrastructure cost is real regardless of intent. Google provides no DDoS billing protection for reCAPTCHA Enterprise beyond manual review after the fact.

The asymmetry is stark: the attacker’s cost to generate traffic is low and fixed. Your cost to receive that traffic through a per-request billing API scales linearly with attack volume. Every optimisation the attacker makes to increase request rate directly increases your bill.

What purpose-built DDoS protection actually does

The architectural difference matters. Network-layer DDoS protection — the kind that lives at the edge of a global CDN like Akamai — absorbs and filters attack traffic before it reaches any part of your infrastructure:

Scrubbing at the edge: Traffic is evaluated at the point of ingress, before it traverses your network. Attack packets are dropped at the PoP closest to their origin, not processed through your application stack.

Anycast distribution: The same IP block is announced from hundreds of PoPs simultaneously. A volumetric attack gets distributed across the full capacity of the network rather than concentrated on a single target. Akamai’s edge carries over 340 Tbps of egress capacity — a 1 Tbps attack is a rounding error across that footprint.

Rate limiting and adaptive shaping: Legitimate traffic passes; attack signatures trigger automated mitigation responses that adjust in real time as attack patterns evolve.

Fixed-cost billing: Enterprise DDoS protection is priced as a monthly service, not per request. An attack that generates 10 billion requests doesn’t generate a 10-billion-request bill.

The financial case for doing it properly

The framing of “reCAPTCHA is cheaper” rests on a comparison between normal traffic costs. Under attack conditions, the comparison inverts. A managed DDoS protection service at $5,000–$15,000 per month looks very different against a $360,000 reCAPTCHA bill from a single four-hour incident.

More importantly: the question isn’t whether reCAPTCHA is technically capable of handling some DDoS-like scenarios. It’s whether you’ve actually priced out what happens when it’s tested. Most organisations haven’t — until they receive the invoice.

Security investment decisions should be made against the realistic threat scenario, not the optimistic one. Know what your per-request costs are for every external API in your stack. Understand the billing behaviour under attack conditions. And deploy purpose-built protection for threats that were never in scope for the tools you already have.