The most effective way to validate DDoS protection is through simulated attacks, and these often are generated from data centres. But real attacks don't come from a single data centre. They come from thousands of compromised devices spread across the world: home routers, IoT gadgets and smartphones on residential and mobile networks. If your test traffic doesn't look like that, your WAF, load balancer or scrubbing service may block it for the wrong reason, and you finish your tests with a false sense of security.
Today, organisations have three main sources of test traffic, each with different trade-offs in realism, effort and evidential value: data-centre-based load generators, servers you run or rent yourself, and distributed real devices such as phones and hardware endpoints.
Key Overview
- DDoS test traffic can come from three main sources: data centres, servers you control, or distributed real devices and phones.
- Data-centre testing delivers volume and convenience, but its IP ranges are easy for WAFs and scrubbing services to recognise and filter.
- Server-based testing gives full control but limited reach, little IP diversity and a high workload for internal teams.
- Real-device testing produces traffic that looks like a real botnet, thus making this test the most realistic one. However, you need a large enough device network to generate meaningful load.
1. Data-centre-based testing
In this model, attack traffic is generated by load generators running in cloud or hosting data centres, often across several regions. It is the most common approach used by traditional DDoS testing vendors, because cloud capacity is easy to spin up, scale and shut down again.
Pros
- Volume: Cloud infrastructure can generate high traffic volumes quickly, which is useful for testing raw bandwidth and capacity limits.
- Multi-region reach: Load generators can be placed in several cloud regions, giving some geographic spread.
- Low setup effort: No hardware is needed on your side, and test environments can be provisioned from standard images.
Cons
- Detectability: Data-centre IP ranges are well known. Many WAFs, bot-management tools and scrubbing services treat them as suspicious by default, so test traffic may be blocked because of where it comes from rather than how it behaves.
- Realism: A real botnet runs on residential and mobile connections. Traffic from a handful of cloud providers doesn't recreate that diversity of networks, devices and behaviour.
- Scheduling: Vendor-run data-centre tests usually need planning time, coordination and a maintenance window, so retesting after a rule change can take days.
2. Server-based testing
Here, internal IT or security teams generate attack traffic from servers they own or rent, using open-source or commercial traffic-generation tools. Ownership of the test stays fully in-house: you decide when, how and against what you test.
Pros
- Control: Tests can be designed and run entirely on your own terms and schedule.
- Cost per test: Once the servers and tooling are in place, each additional test costs relatively little.
Cons
- Limited distribution: A few servers in one or two locations produce traffic from a narrow set of IP addresses. Real attacks come from thousands of sources at once, so rate limits and geo-rules are rarely tested properly.
- Detectability: Like data-centre traffic, server traffic comes from hosting IP ranges that defences can easily recognise.
- Workload and risk: Your team has to install, maintain and operate the tooling, design the attacks and keep them safe. Without deep DDoS expertise, the risk of misconfiguration, unintended disruption and misread results is high.
- Evidence: Self-run tests rarely produce reports that auditors and regulators will accept as independent proof of resilience.
3. Real devices and phones
The third option runs simulations on a distributed network of physical devices, such as smartphones and other hardware, connected through home and mobile networks around the world. No virtual machines or data-centre IP addresses are involved, so the traffic resembles that of a real botnet.
Pros
- Realism: Traffic comes from real devices on real networks, from real locations. Your defences have to judge it by behaviour, exactly as they would in a real attack.
- No origin bias: Because the traffic doesn't come from known hosting ranges, your WAF can't simply recognise the test by its source and pass it with flying colours.
- On-demand testing: Platforms of this kind are often self-service, so teams can run a simulation after a rule change without waiting for a scheduled test window.
- Audit-ready evidence: Some providers produce tamper-proof, verifiable reports intended for regulatory frameworks such as FINMA, DORA and NIS2.
- No installation: The traffic is generated externally, so no sensors or agents are needed in your environment.
Cons
- Peak volume: Traffic from distributed devices is optimised for realism and distribution rather than for maximum raw bandwidth. If your only goal is to find the absolute bandwidth ceiling of a link, a volumetric data-centre test may still have a role.
- Network size: The test is only as strong as the device network behind it. A small or geographically narrow network can't reproduce the scale of a real attack, so ask providers how many devices they use and where those devices are located.
- Preparation: Because the traffic resembles a real attack, tell your ISP or scrubbing provider in advance so the test isn't handled as a live incident.
DDoS testing comparison table
| Data centres | Servers | Real devices & phones | |
|---|---|---|---|
| Test simulation realism | ++ | + | +++ |
| Resembles a real botnet | + | + | +++ |
| Risk of WAF spotting the test by its origin | High | High | Low |
| Geographic distribution | Medium | Low | Depends on provider |
| Audit-ready evidence (FINMA, DORA, NIS2) | + | + | Depends on provider |
| Workload on internal teams | Medium | High | Low |
| Software installation requirements | Medium | High | None |
| Time to re-test after a rule change | Days | Hours | Can be minutes |
What should you choose?
Data-centre testing suits organisations that mainly want to check raw capacity and are comfortable with periodic, vendor-scheduled tests. Server-based testing works if you have strong in-house DDoS expertise, want full control, and don't need independent evidence for auditors.
If you need to know how your defences perform against a realistic, globally distributed attack, and prove it to regulators, real-device testing is the strongest choice. That applies especially to banks and financial institutions under FINMA, DORA or NIS2, and to any team that changes WAF or load-balancer rules often and wants to validate them the same day.
Ready to see how your defences hold up against a real-world DDoS attack? Obsidio, a Swiss DDoS resilience platform, lets you run DDoS simulations on demand from a global network of real smartphones, with audit-ready reports for FINMA, DORA and NIS2. Request an Obsidio demo.