Login
When your DDoS mitigation provider goes down: Why traffic control can’t be outsourced
Since the headline-grabbing outages of 2021, we’ve had recurring conversations with large enterprises asking some version of the same question.
Do we really want our CDN, security, and routing control to live in the same place?
This issue of control has become more urgent after a series of well‑publicized, multi‑hour outages across major cloud‑based DDoS protection and security platforms. These incidents are rare but appear to be increasing in frequency. And when they happen, they expose architectural decisions many organisations haven’t revisited in years. The fact is that architectures assumed providers would never fail. Reality proved them wrong.
The concern isn’t whether cloud DDoS mitigation works. At scale, it does. The issue is control: whether customers retain the ability to reroute traffic independently if the provider itself goes down.
Many DDoS protection services simplify onboarding by originating customer prefixes and returning traffic via static paths. Under normal conditions, this works. During a provider outage, especially one affecting routing or orchestration, customers may lose the ability to reroute traffic
independently. Recovery depends on provider‑side changes at the worst possible moment.
That’s when a DDoS mitigation service can become a single point of failure.
Protection and control are different problems
One thing we consistently hear from network and security teams is that DDoS attack mitigation and traffic control are often treated as the same problem. They aren’t.
Resilient architectures separate them:
| Function | Who Should Control It |
|---|---|
| Attack mitigation | DDoS provider |
| Traffic routing decisions | Customer network |
The Internet already provides a mechanism to enforce this separation: the Border Gateway Protocol (BGP). This is the Internet’s routing protocol; it determines how traffic is directed between the networks.
So, the real question isn’t whether to use cloud‑based DDoS protection. It’s whether that protection operates with your routing policy, or instead of it.
Resilient architectures treat attack mitigation and traffic control as separate concerns. Providers absorb DDoS attacks. Customers retain routing authority using BGP, enabling them to decide how traffic flows during failures.
When customers control BGP, outages take on a different character. They become routing events, not service outages. Traffic can be redirected faster, the blast radius is reduced, and network teams respond using familiar controls instead of escalation paths.
Designing for the inevitable
No provider is immune to failure. CDNs, hyperscalers, and DDoS mitigation services all operate complex, global control planes.
Resilience doesn’t come from assuming outages won’t happen. It comes from designing so that when they do, customers still control the outcome.
That’s why more organizations are adopting architectures where:
- DDoS protection is cloud‑delivered
- Routing authority remains customer‑owned
- BGP is the final decision layer for traffic steering
This approach preserves the benefits of cloud‑scale mitigation while avoiding the creation of new single points of failure.
A practical next step
If you’re rethinking your DDoS architecture, your best starting point isn’t a product demo; it’s an architectural review. Here are some questions to ask yourself:
- Who originates your prefixes today?
- How quickly can you reroute traffic if a provider is unavailable?
- What dependencies exist between mitigation availability and network availability?
Those answers usually reveal more than any outage postmortem.
On the Internet, control of routing is control of availability, and we think that control should always remain in customer’s hands.
Want to discuss what customer‑controlled DDoS protection looks like in practice? Get in touch with Thales to review your architecture.
The post When your DDoS mitigation provider goes down: Why traffic control can’t be outsourced appeared first on Blog.
