Always-on mitigation is usually described as DDoS protection with no reaction time. That holds only for the diversion step, and a DDoS test exists to find out how much reaction time is left once diversion is taken out of the picture. In the always-on model all traffic flows through scrubbing continuously, rather than being diverted only after an attack is detected. Because the scrubbing path is always in line, the detect-and-reroute delay that on-demand protection incurs is eliminated. The trade-off is steady-state latency and cost from inspecting clean traffic at all times.
Two ways to be always in the path
There are two common ways to put a scrubbing tier permanently in front of a service, and they cover different things.
The proxy form changes DNS once and leaves it. The hostname resolves to the provider's edge, which terminates the connection and opens its own connection to the origin. It covers the hostnames that were moved, on the ports the proxy speaks, and nothing else: a mail server or game port on the same network is outside it.
The routing form has the provider announce your prefix in BGP permanently and return clean traffic over a tunnel or a direct interconnect. It covers every address in the prefix on every protocol, which is why networks with non-web services use it. It also makes the tunnel's constraints, the ones a mitigation cutover exposes for an hour during an attack, a permanent property of everyday traffic.
A hybrid is common too: an on-premise appliance inline at all times, with cloud scrubbing kept on-demand for floods that exceed the uplink.
What "always on" does not remove
Being in the path is not the same as already filtering the attack. Static rules, such as dropping traffic to ports the service never uses, act on the first packet. Anything adaptive, a signature built from the attack's own packets or a rate threshold learned from traffic, still has to observe the attack before it acts. Always-on removes the routing delay from time to mitigation; the classification delay stays, and on a well-run deployment it becomes the larger share.
Two costs move from occasional to permanent. Every legitimate request now passes the filters every day, so a rule that is a little too strict hurts real users on quiet Tuesdays as well as under attack. And latency depends on how far the nearest scrubbing location sits from both users and origin, which is fine for one region and noticeable for another.
The model's real strength is against attacks built to exploit diversion. A pulse-wave attack that strikes, stops, and strikes again forces an on-demand setup to divert and withdraw repeatedly; against an always-on path there is nothing to toggle.
Its weakness is everything that does not use the path. If the origin's address is known and the origin still accepts connections from anywhere, the attacker goes straight to it, and the scrubbing tier stays healthy and idle. That is origin IP exposure, and always-on does nothing about it on its own.
What a DDoS test measures
A test of an always-on deployment skips the question on-demand tests spend most of their time on, how long the switch takes, and asks four others. How many seconds pass from attack onset to the point where the inline filters drop it, for a static rule and for an adaptive one? Does latency for legitimate traffic rise while the scrubbing tier is under load, compared with the same traffic on a quiet day? What share of a known-good baseline does the filtering block, in steady state and under attack? And does anything reach the origin without passing through the provider at all?
The last answer is often the one that changes a design, because an always-on path is only as strong as the origin's refusal to accept traffic from anywhere else.
What that means for choosing between an inline and an on-demand design is worked through in DDoS protection in the path.