Choosing DDoS-protected hosting requires more than finding a large mitigation number on a plan page. This guide shows how to compare detection, traffic diversion, network and application-layer coverage, response commitments, logging, exclusions, and SLA remedies before signing a contract, then gives you a practical checklist and tabletop test for validating the provider’s claims.
Overview
DDoS protection hosting is a service arrangement, not a single feature. A provider may protect a dedicated server, VPS, or hosted application by detecting abnormal traffic, diverting it to a scrubbing service, filtering unwanted packets, and forwarding legitimate traffic to your infrastructure. The effectiveness of that arrangement depends on how each stage works and what the contract actually promises.
Start by defining what you need to protect. A public website, API, mail service, DNS endpoint, game server, and business application can have different traffic patterns and different tolerance for interruption. Protection for network and transport protocols may not address an HTTP flood that resembles normal browser activity. Conversely, an application-layer service may not protect every exposed IP address or non-web protocol.
Do not treat a provider’s “maximum mitigation capacity” as a guarantee that your service will remain available during every attack. Ask how capacity is shared, where filtering takes place, what traffic threshold triggers action, and whether the stated capacity applies to your selected plan, region, and service type. A useful comparison records measurable commitments separately from marketing descriptions.
What to track
Use the following comparison table for each candidate provider. Ask for written answers and identify whether each item is included in the contract, an acceptable-use policy, a support procedure, or only a sales explanation.
| Area | Questions to ask | Evidence to request |
|---|---|---|
| Detection | How is an attack identified? Are thresholds fixed, adaptive, or customer-specific? How are false positives handled? | Detection criteria, alert examples, and escalation procedure |
| Mitigation capacity | What capacity applies to this plan and location? Is it a committed limit or an indicative maximum? | Plan-specific specification and any fair-use language |
| Diversion | Is protection always on, or does traffic move to a scrubbing service only after an attack is detected? Is routing automatic? | Traffic-flow diagram and activation procedure |
| Protocol coverage | Are Layer 3 and Layer 4 attacks covered? Which protocols, ports, and IP ranges are excluded? | Technical coverage matrix and exclusions |
| Application coverage | Is Layer 7 protection included for HTTP and HTTPS? Can rules distinguish abusive requests from legitimate spikes? | Application protection scope and configuration examples |
| Scrubbing locations | Where are filtering facilities located, and how does location affect routing, latency, and data residency? | Available regions and routing explanation |
| Response | Who is notified, through which channel, and within what target time? Is an engineer available outside business hours? | Incident-response targets and escalation contacts |
| Communication | Will the provider share attack status, affected services, mitigation actions, and recovery updates? | Sample incident timeline or communication policy |
| Logging | What traffic, attack, and mitigation records are retained? Can customers export them? | Log fields, retention period, access method, and fees |
| SLA remedies | What happens if the protection or availability commitment is missed? Are credits the only remedy? | Complete SLA, exclusions, claim process, and deadlines |
Provider verification checklist
- Confirm the protected IP addresses, hostnames, ports, protocols, and services in scope.
- Separate always-on filtering from on-demand or manually activated mitigation.
- Ask whether DNS, routing, origin concealment, and direct-origin access require separate configuration.
- Check whether application-layer controls require your own rules, a managed service, or an additional product.
- Request the attack notification format, escalation path, and named responsibility for incident coordination.
- Review exclusions for oversized attacks, encrypted traffic, high request rates, prohibited content, and traffic to unprotected endpoints.
- Confirm whether mitigation logs include timestamps, source and destination details, attack classification, action taken, and cleared time.
- Read the acceptable-use policy for clauses that permit suspension, filtering, or additional charges during an incident.
- Check whether SLA credits cover mitigation performance, service availability, support response, or only selected components.
Capacity is only one part of the decision. A smaller deployment with clearly defined coverage, rapid communication, and suitable application controls may be a better operational fit than a larger advertised network with vague exclusions. Consider the hosting architecture as a whole, including origin servers, load balancers, DNS, remote administration, backups, and any cloud or colocation connection. For broader infrastructure trade-offs, see the comparison of colocation, dedicated servers, and cloud hosting.
Cadence and checkpoints
Evaluate DDoS protection at three points: before purchase, during normal operations, and after an incident or material change.
Before signing
Build a short written requirements sheet. Include normal and peak traffic, exposed services, acceptable downtime, administrative contacts, geographic constraints, compliance needs, and the application’s most important user journeys. Ask each provider to respond to the same questions. Store the answers with the proposed order form and SLA rather than relying on an informal sales call.
During normal operations
Review protection status monthly or quarterly, depending on the service’s risk and change rate. Confirm that protected addresses and ports still match the production inventory. Check that alert contacts work, logs are accessible, rules have not drifted, and origin endpoints are not accidentally exposed. Record baseline traffic and legitimate seasonal peaks so that a future event can be assessed against normal behaviour.
After an incident or provider change
Review the service after every significant attack, routing change, plan change, hosting migration, new public endpoint, or application redesign. Refresh the mitigation specification, response commitments, traffic thresholds, abuse policy, and SLA language at least every six months. If the provider changes its product or moves filtering locations, repeat the comparison rather than assuming the old assessment still applies.
Tabletop test workflow
- Define the scenario. Choose a realistic event, such as a volumetric attack against a public IP or an HTTP request flood against a login endpoint. Do not generate attack traffic unless the provider has explicitly approved a safe test.
- Assign roles. Name the technical lead, business owner, provider contact, communications owner, and person responsible for evidence collection.
- Walk through detection. Identify the expected alert, dashboard signal, ticket, or phone call. Record who receives it and the target response time.
- Walk through diversion. Document whether mitigation is automatic, manually activated, or dependent on a routing or DNS change. Note the expected service impact.
- Test decisions. Agree who may change rules, rate-limit traffic, block a region, disable a feature, or fail over to another environment.
- Check communication. Use a fictional timeline to practise updates to internal teams, customers, and relevant third parties without disclosing sensitive attack details.
- Close the exercise. Capture missing contacts, unclear thresholds, inaccessible logs, contract gaps, and actions with named owners and due dates.
How to interpret changes
A change in traffic does not automatically indicate an attack. Product launches, crawlers, promotions, software updates, and regional events can create legitimate bursts. Compare the event with application metrics, request paths, authentication outcomes, source distribution, protocol mix, and error rates. The provider’s classification should be treated as an input to investigation, not a substitute for your own monitoring.
Pay particular attention to changes that reduce certainty. “Up to” capacity without a plan-specific commitment, response times described as goals rather than obligations, or protection limited to selected protocols may be acceptable if the risk is understood and additional controls exist. They should not be recorded as guaranteed protection in an internal risk register.
Review SLA language separately from technical capability. Availability definitions may exclude planned work, customer configuration, upstream connectivity, or events outside the provider’s control. A service credit may compensate for a missed commitment without covering lost revenue, recovery work, or reputational impact. Read the claim window and evidence requirements before an incident occurs. For related guidance, see how to read a hosting uptime SLA.
Finally, check whether the mitigation design creates a new dependency. A central scrubbing location, provider-managed DNS, or single support channel can simplify operations while also becoming a concentration risk. Record the fallback plan, including how you would move services, preserve logs, and communicate if the protection provider itself were unavailable. The hosting portability checklist can help structure that review.
When to revisit
Revisit your DDoS-protected hosting assessment on a monthly or quarterly operational cadence and perform a fuller contract review every six months. Bring the review forward when you add an exposed service, change data centre or server location, move between VPS and dedicated server hosting, adopt hybrid cloud hosting, experience an attack, alter DNS or routing, or see a sustained change in traffic volume or user geography.
End each review with a simple decision: retain, amend, test, or replace. Retain the provider when coverage and response still match the risk. Amend the configuration or contract when a gap is known and fixable. Test when assumptions have not been exercised. Replace only after documenting the operational, compliance, migration, and downtime consequences.
Keep the latest comparison table, signed SLA, escalation contacts, incident records, and tabletop actions together. That evidence makes renewal discussions more precise and gives the next responder a usable starting point when an attack occurs.
