Volumetric Attack Saturates the Link Before Scrubbing
A media company's origin is behind a CDN with DDoS scrubbing. During a major event, a UDP amplification attack peaks at 600 Gbps toward the company's advertised ranges. The scrubbing provider absorbs most of it, but the company's upstream ISP link to a secondary data center saturates, and a regional audience sees timeouts for ~12 minutes. Investigation shows the secondary data center hosts an origin that is not fronted by the CDN - it serves a legacy API directly on a public IP in the same advertised range. The primary origin is fully behind the CDN and was unaffected. The company has 30 days before the next event and wants to guarantee the regional audience is not impacted again, without a full migration of the legacy API.
1. Diagnose why scrubbing did not protect the regional audience and prioritize the fixes.
Read the worked answer
Scrubbing protects traffic that flows through the scrubbing path. The legacy API's public IP was in the same advertised range but was not fronted by the CDN, so attack traffic aimed at that range still consumed the ISP link even though the primary origin was shielded. The saturation was a link-capacity problem caused by an unprotected asset sharing address space with protected ones.
Priorities, highest first:
- Get the legacy API behind the CDN/proxy (or move it to a range that is not advertised alongside protected assets). Until the unprotected IP is out of the blast radius, the link remains a single point of failure. This is the root cause; everything else is mitigation.
- Reduce the attack surface on that IP: restrict it to the ports/protocols the API actually needs, and block the amplification vector (e.g., the UDP service being abused) at the edge or ISP.
- Coordinate with the ISP on upstream filtering for the specific amplification protocol and on capacity/reroute options for the regional path.
- Segment address space so protected and unprotected assets do not share an advertised range that can be saturated together.
A full migration isn't required - fronting the legacy API with the CDN, or isolating its IP, addresses the cause.
2. What would you verify in the 30-day window to confirm the regional audience is actually protected?
Read the worked answer
Verify the path, not just the configuration:
- Confirm the legacy API's public IP is no longer directly reachable from the internet (test from external vantage points); if it must remain reachable, confirm it is no longer in the same advertised range as protected assets.
- Confirm traffic to the legacy API now traverses the CDN/scrubbing path (check CDN logs show the requests).
- Run a controlled, low-volume test toward the previously abused protocol/port and confirm it is filtered upstream or at the edge, and that the regional link does not saturate.
- Establish a baseline for link utilization on the secondary path and define an alert threshold well below saturation.
- Rehearse the response: who calls the ISP, what the reroute/filter playbook is, and the target time to mitigate.
The 12-minute outage was a detection-and-path problem as much as a capacity one, so the verification must include monitoring and a tested runbook, not only a config change.