Blast radius is usually described as the size of the target: flood one endpoint and that endpoint suffers. That holds only when nothing behind the endpoint is shared, and a DDoS test exists to find out how far the effect really spreads. The blast radius of an attack, or of the test itself, is the set of services, tenants and links that degrade when one thing is flooded.
How the damage travels
Shared dependencies are the route. A flood aimed at a single search endpoint can drain the database connection pool that login and checkout also draw from. Every request, including the ones later rejected, may call the same authentication service. A NAT gateway that all private workloads use to reach the internet has a fixed limit per destination (on AWS, 55,000 simultaneous connections to each unique destination), so a burst of outbound calls from one service starves the others.
Observability is a shared dependency people forget. Every flooded request writes a log line, and when the logging pipeline or its ingestion quota saturates, the services that were not attacked lose their logs too, at the moment the incident team needs them. Account-level API quotas behave the same way: one noisy workload can spend the budget every other workload in the account relies on.
The spread does not stop at your own stack. Shared hosting, a shared IP on a multi-tenant edge, or a shared upstream link puts other customers' traffic in your blast radius and yours in theirs.
Mitigation can widen it too. A provider facing a large flood may null-route the destination address, which drops the attack and every legitimate packet to that address with it. If the address fronts more than one service, the blackhole takes them all down, and the defence finishes what the attack started.
Why it matters under attack
Blast radius decides whether a cheap attack on an unimportant endpoint becomes an expensive outage of an important one. An attacker does not need to find the layer of first failure on the checkout path if a forgotten reporting endpoint shares its database.
The architectural answer is isolation: separate connection pools per route (bulkheads), per-tenant quotas, cell-based deployments where a failing cell stays a failing cell. None of it can be confirmed from an architecture diagram, because shared dependencies hide in configuration, client libraries and defaults nobody changed.
The idea also bounds the test. A controlled exercise has a blast radius of its own, and one that spills into unrelated production systems produces an incident and polluted results at the same time.
Scoping starts with a dependency map for the target: every database, cache, queue, auth service, resolver and egress path it touches, and which other services touch the same ones. Two paths are easy to miss. If services share a DNS resolver, a flood that triggers lookups can slow name resolution for all of them. If every login goes through one identity provider, flooding anything that checks tokens loads it on everyone's behalf, sometimes against a third-party rate limit.
From the map comes a watch list of the shared tiers that were not targeted, each with its own abort threshold, for example "stop if checkout p95 latency doubles" or "stop if the auth service error rate passes 1 percent". The test team watches those numbers, not just the target's, and the agreed threshold, not a judgment call made in the moment, decides when load comes off.
What a DDoS test measures
A test targets one thing and watches everything else. While load is applied to a single endpoint or segment, it records latency, error rate and saturation for the services that were not targeted. The blast radius is the list of those whose numbers moved, with the load step at which each began to degrade.
That list is usually the surprise of the exercise. The same reasoning applies inside a service-to-service call graph, where one slow dependency spreads through retries and shared pools, which DDoS Testing for Microservices works through.