How to protect an online casino from DDoS attacks

The short answer

Casino DDoS protection takes four layers working together: network-level absorption in front of your origin, application-layer filtering tuned to real betting traffic, strict origin isolation so attackers cannot route around the shield, and a rehearsed runbook — because the attack will arrive during the biggest sporting event on your calendar, not during a quiet Tuesday maintenance window.

Miss any one of the four and the other three do not save you. We keep seeing operators with a premium mitigation contract go down anyway, because the attacker skipped the front door: they found the origin IP, or they found one expensive endpoint the WAF wasn't watching. This guide walks through each layer in the order an attacker will test them.

Why casinos get hit harder than almost anyone else

DDoS against iGaming is not vandalism; it is a business model. Three properties make casinos uniquely attractive targets:

Downtime is instantly monetized. A sportsbook that is unreachable during a Champions League final loses bets it can never take again — the event ends and the demand evaporates. Attackers know this, which is why ransom DDoS (RDoS) notes to operators spike around major fixtures.
Extortion has a price anchor. The attacker can estimate your revenue per hour from public traffic data and price the ransom just below it. Payment processors and regulators cannot help you in the two hours that decide whether players migrate to a competitor.
The attack surface is wider than the homepage. Odds feeds, live-betting websockets, cashier APIs, affiliate endpoints, and the mobile app backend are all separately attackable — and usually less defended than the www front end. Our casino threat landscape review ranks availability attacks among the top three loss drivers for European operators this year.

The four layers, in the order attackers test them

Layer 1 — Network absorption: soak the volumetric flood

Volumetric and protocol attacks (UDP amplification, SYN floods, carpet-bombing across a prefix) are won or lost on raw capacity and routing, before a single HTTP request is parsed. You have three realistic options in 2026:

Approach	How it absorbs	Fits when
Cloud scrubbing (Cloudflare, Gcore, AWS Shield Advanced)	Anycast network measured in the hundreds of Tbps, attack traffic dropped at the nearest PoP	You can put your entire public surface behind the provider — including APIs and websockets
On-demand scrubbing (BGP diversion)	Traffic re-routed to scrubbing centers only during an attack	You run your own network and can tolerate minutes of diversion latency
Private anycast	Your own ASN and PoPs spread the flood across geography you control	Routing independence and account-status risk matter as much as capacity

The first row lumps three named vendors together as one deployment model — if you've settled on cloud scrubbing and now need to pick which of Cloudflare, AWS Shield, or Akamai actually fits your support-tier needs and existing infrastructure, that's a separate decision covered in Cloudflare vs AWS Shield vs Akamai for an online casino.

The third option is less exotic than it sounds. Licensed gambling traffic gets operators suspended from shared platforms often enough that owning the edge is a resilience decision, not a vanity project — we covered the full build in building a private Anycast edge from scratch, and it is the architecture behind our Global Private Anycast Network deployments. One licensed operator we moved onto a private edge cut monthly edge spend by 41% while removing the shared-platform suspension risk entirely — the phased, zero-downtime cutover that moves live traffic onto a new edge like that is its own separate piece of work from the build itself.

Whichever you choose, the non-negotiable is always-on, not on-demand for the L7-facing surface. Modern attacks ramp to peak in under a minute; a mitigation that takes five minutes to engage is a mitigation that engages after your players have already seen the error page.

Layer 2 — Application-layer defense: the flood that looks like customers

Layer 7 is where casinos actually go down. A request to your odds-comparison endpoint or cashier balance API can cost the attacker one packet and cost your backend a database join across four services. The economics favor the attacker by three or four orders of magnitude, which is why a modern L7 DDoS at a few hundred thousand requests per second can topple a platform whose network shrugged off a 500 Gbps flood the same morning.

The defense is unglamorous and specific:

Inventory every expensive endpoint — search, odds feeds, bet-slip validation, cashier operations, login. If a request fans out to your database or a third-party odds provider, it is on the target list.
Cache or pre-compute everything cacheable. Odds pages that regenerate per-request are self-inflicted amplification. Even a 5-second edge TTL converts an unbounded backend load into a bounded one.
Rate-limit per session and per endpoint class, not per IP. Botnets in 2026 arrive on residential proxies with tens of thousands of clean IPs; per-IP limits are a 2015 defense. A regulated payment platform with third-party API callers has a harder version of this problem — see DDoS protection for digital banks for scoping rate limits per registered caller instead of per IP.
Challenge selectively. Blanket CAPTCHA during an attack kills conversion exactly when you can least afford it. Challenge only the traffic that fails passive checks (TLS fingerprint, header order, behavioral signals), and never on the money path without a fallback.
Protect the websockets. Live-betting websocket upgrades bypass many WAF policies by default. If your mitigation provider cannot filter the upgrade handshake and the message stream, that is your open flank.

Layer 3 — Origin isolation: make the shield the only road

Every mitigation layer is worthless if the attacker can reach your origin directly. This is the single most common failure we find in DDoS-readiness assessments — not a missing product, but a leaked or guessable origin:

Historic DNS records. Your origin IP from before you onboarded the mitigation provider is still in passive-DNS databases. Rotate origin IPs after onboarding, not before.
Non-web services on the same prefix. Mail servers, VPN concentrators, and the sportsbook admin panel often sit beside the origin and answer to the world.
Outbound disclosure. Verification emails, webhook calls, and error pages that embed the origin address.
Firewall rules that trust "the CDN" by name, not by list. Allow the mitigation provider's published IP ranges and drop literally everything else at the network edge. If your origin answers port 443 to a scanner, you have no Layer 3.

The test is one sentence: can any packet reach your origin without passing through the mitigation layer? If you cannot answer "no" with a config export in hand, assume the answer is yes — attackers run the same internet-wide scans we do, and they check before they ransom you.

Layer 4 — The runbook: the part everyone skips

Attacks are decided in the first fifteen minutes, by people. A defense that exists as a contract but not as a rehearsed procedure fails in predictable ways: nobody has the mitigation provider's emergency number, the on-call engineer cannot log into the dashboard, marketing is asking about the outage on a Slack channel while the attacker escalates. The runbook needs owners and phone numbers for exactly four decisions — when to escalate the mitigation posture, when to shed non-critical features, when to engage the provider's SOC, and who talks to players. Then it needs a drill, twice a year, ideally during a low-stakes live event. This is the operational half of our DDoS Protection Strategy engagements, and it is consistently where the gap between "protected on paper" and "stayed up" lives. When the attack outruns the runbook anyway, that is what a 24/7 incident response retainer with a 30-minute SLA is for.

What our stress tests keep finding

Here is the number that should change how you allocate budget: in the authorized DDoS stress tests we ran against European iGaming platforms over the past 12 months, 7 of 9 platforms failed at Layer 7 before our volumetric ramp reached even 20% of their contracted scrubbing capacity. The median knockout was an unauthenticated, uncached endpoint — a search page, an odds view, a bonus-eligibility check — that fell over below 900 requests per second.

Every one of those operators believed they were protected, because they were: against the attack their contract described. Volumetric capacity is a commodity in 2026. The differences that decide whether you stay online live in the L7 configuration, the origin hygiene, and the humans — the three layers no invoice can prove.

Frequently asked questions

Is a CDN enough to protect a casino from DDoS? No. A CDN absorbs volumetric traffic against cacheable content, but casino traffic is dominated by uncacheable, authenticated, expensive requests — logins, bets, cashier calls. Those need L7 policies tuned per endpoint, which a default CDN configuration does not provide.

Should we pay a ransom DDoS demand? No. Payment marks you as a payer and the demand returns — usually higher, often from copycats who saw you fold. The same budget buys always-on mitigation that makes the demonstration attack fail, which is the only outcome that ends RDoS campaigns.

How fast can protection be deployed during an active attack? Emergency onboarding onto a scrubbing provider is realistic within hours — DNS cutover, origin re-IP, and certificate moves under fire. It is survivable, but it is the most expensive possible time to discover your architecture. Do the origin-isolation work in peacetime.

How much does DDoS protection cost for an online casino? Three budget lines, roughly in deployment order. Cloud scrubbing with real L7 policies runs from a few thousand euros per month at casino traffic volumes — the enterprise tiers of Cloudflare or Gcore, not the self-serve plans, because you need custom rate-limiting rules and websocket filtering. An architecture and runbook engagement is a one-off cost (ours start at €2,899). A private anycast edge starts around €2,500 in setup plus PoP hosting, and tends to pay for itself at the point where shared-platform pricing and suspension risk start compounding — the operator above reached break-even inside a year. What is not optional at any budget: the origin-isolation work, which costs engineering hours rather than product spend.

How do we know the defense actually works? The same way you know your backups work: test it. An authorized, controlled stress test against production, under a signed Rules of Engagement, is the only evidence that the four layers hold under a realistic attack pattern — everything else is a vendor datasheet. See how to scope one without turning the test itself into an outage.

Is sportsbook DDoS protection different from casino DDoS protection? No — the same four-layer architecture applies to both. Sportsbooks add live-betting websockets and real-time odds feeds as extra Layer 2 targets, which is why origin isolation and per-endpoint rate-limiting matter as much for a sportsbook as for a casino cashier.

If you want the four layers reviewed against your actual architecture — or proven under controlled fire — get a fixed quote and we will map where you stand.

Sources and review

This guide reflects AnySec's DDoS Protection service architecture and pricing as published in our service scope (architecture and runbook engagements from €2,899; private Anycast setup from around €2,500 plus PoP hosting). The "7 of 9 platforms" and "below 900 requests per second" figures are the aggregate results of our own authorized DDoS stress-testing engagements against European iGaming platforms over the trailing 12 months (n = 9) — internal engagement data, not a third-party statistic. No customer-specific case data or unverified vendor claims are cited. Author: AnySec Engineering. Published 2026-07-23; last reviewed 2026-09-01.