DDoS Protection Services: What the Quote Must Say Before You Compare Price

Q: What should a DDoS protection service quote include?

Which traffic layers are covered, whether mitigation is always on or switched on after an alert, what the mitigation time promise measures, how capacity and overage are charged, how the origin is kept from being reached directly, who you can reach during an attack, and what you receive afterwards. A quote that lists only a bandwidth figure and a price cannot be compared with another.

Q: Why do DDoS protection quotes look so different for the same site?

Because they cover different things. One may absorb volumetric floods only, another includes application-layer filtering and rule tuning, and a third adds a human team that acts for you. The headline capacity number says little about which of those you are buying.

Q: Is 'unmetered' or 'unlimited' DDoS protection really unlimited?

Read the fair-use and exclusion wording. Unmetered usually means the provider does not bill you for attack traffic, not that every attack type is covered or that service continues regardless of impact on other customers. Ask what happens to your traffic if an attack exceeds what the provider is willing to absorb.

Q: What does time to mitigate actually measure?

It depends on the contract. It can run from the first malicious packet, from a detection alert, or from your support ticket, and it can end at the first rule applied or at traffic returning to normal. Two providers quoting the same number can be measuring different intervals, so ask for the start event and the end event in writing.

Q: Does buying DDoS protection mean I no longer need a stress test?

No. A service is a promise; a test shows what your configuration does under load. An authorized test against your own setup is how you find out whether the origin is reachable, whether rate limits fit your real traffic and whether your team follows the runbook.

The short answer

A DDoS protection quote is comparable only if it states seven things: which traffic layers are covered, whether mitigation is always on or starts after an alert, what start and end events the mitigation time promise measures, how capacity and overage are charged, how the origin is kept from direct attack, who you can reach during an incident, and what you receive afterwards. Providers can quote the same site at very different prices because they are covering different amounts of the problem. Get those seven in writing before you compare price, and treat a quote that gives only a bandwidth figure as an incomplete offer.

Who this is for

This is for the head of infrastructure, CISO or procurement owner at a casino, crypto exchange or fintech who holds two or three DDoS protection proposals that look alike. It is about reading the quote, not about choosing a vendor. For how the three large providers differ in support model, see Cloudflare vs AWS Shield vs Akamai for an online casino; for the architecture a quote should fit into, see how to protect an online casino from DDoS attacks.

The seven lines to look for

Quote line	What to ask	Why it changes the price and the outcome
Layers covered	Network and transport floods only, or application-layer (L7) filtering too?	Application-layer attacks imitate real users and pass volumetric filters untouched.
Always-on or on-demand	Is traffic scrubbed continuously, or routed to mitigation after detection?	On-demand adds a switch-over delay and a person or rule that must trigger it.
Mitigation clock	Which event starts it, which event ends it?	A number with no start and end is not a commitment.
Capacity and overage	Is capacity capped, and who pays when an attack exceeds it?	The cost of the worst day is the cost that matters.
Origin exposure	How is your real server address kept from direct attack?	If attackers can reach the origin, the edge service is bypassed.
Who answers	Who can you reach mid-attack, how, and with what authority to change rules?	Self-serve, ticket-only and staffed response are different services.
Reporting	What do you get after an attack, and is there a review?	Without it the next attack starts from the same configuration.

Line 1: which layers are covered

A quote may say "DDoS protection" and mean absorption of floods at the network edge. Application-layer attacks, such as login floods, cashier-endpoint abuse or scraping of a price or odds feed, look like legitimate requests and need rules fitted to your traffic. Ask whether L7 filtering is included, who writes and maintains the rules, and whether API endpoints are covered or only the website. The default tier of a large provider and a tuned configuration are different products.

Line 2: always-on or on-demand

Always-on means your traffic passes through mitigation at all times. On-demand means it is redirected after an attack is detected, either by an alert or by you. On-demand can be cheaper, and it adds a delay and a dependency on someone making the change. Ask what triggers the switch, who can trigger it, and what your users see while it happens. For a platform where an outage is paid for in lost transactions, the gap between the first request and the first rule matters.

Line 3: what the mitigation clock measures

A time-to-mitigate promise has a start and an end. The start may be the first malicious traffic, a detection alert or your ticket. The end may be the first rule applied, partial relief or full normal service. Ask for both events in writing and ask what remedy applies if the promise is missed. The same discipline applies to security operations contracts; see where the SLA clock starts for a managed SOC.

Line 4: capacity and overage

Providers describe capacity in different ways: a stated ceiling, a network-wide figure, or "unmetered". Read the fair-use and exclusion language. Unmetered often means the provider does not bill you for attack traffic, not that every attack is absorbed under all conditions. Ask whether there is a cap, what happens to your traffic if an attack passes it, and whether any overage or upgrade charge applies. Then ask what the largest attack the provider has mitigated for a customer of your type is, and request documentation rather than a marketing statement.

Line 5: keeping the origin hidden

Edge mitigation protects only the traffic that goes through it. If your origin address is known, or reachable from the internet, an attacker can aim at it directly. The quote or the design should state how the origin accepts traffic only from the provider, how addresses and old DNS records are handled, and who is responsible for checking. This is a design question rather than a product feature, which is why it is easy to leave out of a quote.

Line 6: who answers during an attack

Self-serve means your team changes the rules. Ticket-based means a provider team responds in a queue. Staffed response means named people act on your account. These are different services at different prices, and some require a paid support plan before anyone answers mid-attack. Ask what channel works when the dashboard is slow, who may change your rules without calling you, and who on your side is the contact. A runbook your own team rehearses is part of the answer; a DDoS readiness assessment checks that.

Line 7: reporting and review

After an attack you need to know what hit, what was blocked, what got through and what changed. The quote should say whether you receive a report, how soon, and whether a review with an engineer is included. This is the input to your next configuration change and, for regulated firms, to the evidence file your auditor or regulator may ask for.

Red flags in a quote

Capacity given as a single figure with no layer or attack type attached.
"Unlimited" or "unmetered" with no fair-use wording supplied.
A mitigation time with no start event, end event or remedy.
No mention of application-layer filtering, API endpoints or rule tuning.
No statement of how the origin is protected.
Support described as "24/7" without saying whether that includes action on your account or only a ticket queue.

Limitations

This is a reading guide, not a price list or a recommendation of any provider. It states no market prices, no durations and no AnySec-original figures, and it does not rank vendors. Terms vary by provider, plan and date, so read the current contract and service description for each option you are considering. A contract does not replace testing: whether your configuration holds is shown by an authorized stress test, not by a quote.

What to do next

Put your proposals side by side against the table above and send the gaps back as questions. If you want help turning the answers into an architecture, provider configuration and runbooks, request a fixed quote for DDoS protection and tell us your providers, your critical endpoints and who answers the phone on your side. The DDoS Protection page describes how an engagement runs, and the DDoS Stress Testing page covers validating the result.

Frequently asked questions

What should a DDoS protection service quote include? Layers covered, always-on or on-demand, the mitigation clock, capacity and overage, origin protection, who answers, and reporting.

Why do DDoS protection quotes look so different for the same site? They cover different amounts of the problem. Compare layers, tuning and support, not the capacity headline.

Is "unmetered" or "unlimited" DDoS protection really unlimited? Read the fair-use wording. It usually means attack traffic is not billed, not that every attack is absorbed.

What does time to mitigate actually measure? It depends on the contract. Ask for the start event, the end event and the remedy in writing.

Does buying DDoS protection mean I no longer need a stress test? No. A service is a promise; an authorized test shows what your configuration does under load.

Sources and review

This article describes procurement practice in general terms and cites no statistics, prices or AnySec-original numbers, case results or SLA figures. Provider terms change; check each provider's current documentation. Author: AnySec Engineering. Published 2026-10-13; last reviewed 2026-10-13.