Attack surface is usually described as the list of public IP addresses and open ports a scanner can find. That is the intrusion view, and for denial of service it is too narrow: a DDoS test starts by mapping a wider version, every place where somebody else's traffic can make your systems spend something. Bandwidth, connection slots, CPU on TLS handshakes, database time behind an uncached search: each is a finite resource, and anything reachable that consumes one belongs on the map.
What belongs on the inventory
The DDoS surface has more layers than a port list.
Addresses and names
Every public address, in both families. A host that is locked down on IPv4 but answers on an IPv6 address nobody added to the firewall is a common gap, because dual-stack was switched on by a cloud default rather than by a decision. Every DNS name as well, especially the ones that resolve to something other than the protective edge; how those leak is covered under origin IP exposure.
Protocols
Not only what listens on TCP. A UDP service counts twice: it can be flooded, and if it answers anyone, it can be used against someone else.
Expensive endpoints
At the application layer the surface is measured in cost, not count. A login handler running a deliberately slow password hash, a search that misses the cache, a report export, a GraphQL endpoint that accepts deeply nested queries. A few hundred requests a second to one of these can do what a gigabit aimed at the home page cannot.
Dependencies you do not run
Your authoritative DNS provider, the identity provider behind sign-in, a payment API, a third-party script loaded on every page. None of them is your address, all of them are on your availability path, and a flood against any one of them is your outage too. Blast radius describes how far damage spreads once a flood lands; the dependency list is where that spread begins.
Why it matters under attack
Attackers do not attack the surface you documented. They attack the surface they found, and the two lists rarely match. An inventory built from a CMDB or a firewall ruleset records what was intended; reconnaissance records what answers. The difference is usually small in count and large in consequence: one staging host behind no protection, one old API version that never moved behind the WAF.
The surface also moves faster than the inventory. Autoscaling hands out new addresses, a new region adds a load balancer, a campaign launches a landing page on a different platform. A map from last quarter is a historical document, which is why mapping is a step at the start of every test rather than a one-off project.
What a DDoS test measures
A test builds the surface from the outside first, the way an attacker would: DNS, certificate transparency logs, both address families, and the cloud provider's own asset listings. It then compares that list with what the team believes is exposed. The difference between the two is the first finding, and often the most useful one.
Next it ranks what it found by how much each target costs the defender per unit of attacker effort, which decides where load is sent. The protected front door is tested to confirm it holds. The unexpected entries are tested to learn whether they need protecting, or simply need to stop answering.
The figure worth carrying away is coverage stated as a fraction: of everything reachable that can be made to spend resources, how much sits behind a control that has been shown to hold under load. What that means for scoping the exercise itself, deciding which targets get load and which stay untouched, is worked through in The DDoS Test Plan.