A firewall can drop every unwanted packet it receives while the service behind it remains unreachable. If attack traffic has already saturated the internet circuit, legitimate traffic may never reach the firewall. For distributed denial-of-service protection, the location of the mitigation matters as much as what it can detect.
Different attacks exhaust different resources. A flood can fill an upstream link. Traffic that repeatedly initiates connections can consume state on an intermediary. Requests to a costly search or login endpoint can exhaust application capacity while using comparatively little bandwidth. A useful protection plan identifies which resources would fail first and places controls where they can help.
Inventory exposure by service and path
List public websites, APIs, DNS services, VPN gateways, and other internet-reachable endpoints. For each one, record the provider that carries inbound traffic, the enforcement point, and the path to the origin. Check direct IP addresses and alternate hostnames as well as the public domain.
For a proxied website, evaluate what reaches the origin and how the origin restricts direct access. For an exposed network prefix, work with the connectivity or scrubbing provider on how traffic is diverted and how clean traffic returns. For an expensive application endpoint, evaluate what rate limits or request challenges would do to legitimate users and integrations.
Match the protection service to the traffic it can see
Cloudflare provides DDoS mitigation for traffic that reaches its network through supported services. For a website already using its proxy, test the public entry path and the origin access controls. For other protocols or network-level exposure, confirm which Cloudflare service would carry and protect that traffic. Cloudflare DDoS protection documentation
AWS Shield protects eligible AWS resources, with Shield Advanced offering expanded protection for supported resource types. Map each public AWS entry point to its eligibility and enrollment requirements. Include DNS and load balancing in the exercise so the team can see where it has coverage and where it needs a separate control. AWS Shield documentation
Akamai Prolexic uses distributed scrubbing infrastructure and offers routed protection. It is worth evaluating when you need to protect network prefixes. Establish who can initiate diversion, how clean traffic returns, and how your team will verify routing before and after mitigation. Akamai Prolexic routed reporting documentation
Rehearse what the on-call team must decide
Use a tabletop exercise or a provider-approved test. Give responders an alert, degraded user access, and incomplete information. Have them distinguish among link saturation, connection exhaustion, and application overload. Then check whether they can reach the provider, find the relevant dashboards, and carry out an approved mitigation while monitoring legitimate user traffic.
For on-demand routing, include the time needed to authorize and activate diversion. For always-on protection, verify the traffic path and visibility during normal operation. In both cases, measure service recovery from the user’s perspective. A provider can report that attack traffic is being filtered while the application is still recovering from exhausted capacity.