Keep Local Traffic Local: A Smarter Hybrid Model for DDoS Protection

Donny Chong
Nexusguard
-
7 mins read
Share to:

The Reality of Protecting Smaller Networks

Earlier this year, a regional ISP we will refer to as ISP-A experienced a large distributed denial-of-service attack that peaked at approximately 1.3 Tbps. For a network of its size, the attack volume alone would normally be enough to overwhelm upstream connectivity and disrupt services.

Figure 1. High volume and persistent DDoS attacks overturns typical DDoS mitigation playbooks

For many network operators, the concept of DDoS protection appears deceptively simple. When an attack becomes too large to handle locally, the instinctive solution is to route traffic through a cloud-based mitigation provider. The provider absorbs the attack, scrubs the malicious packets, and returns clean traffic back to the network. On paper, this model is straightforward and effective. However, it quietly assumes something that not every service provider possesses in abundance: large amounts of global transit capacity.

This assumption becomes particularly problematic for smaller and regional communications service providers. Unlike global carriers with multi-terabit backbones and vast upstream connectivity, Tier-3 ISPs often operate highly optimized regional networks. Their traffic flows are built around local Internet Exchanges, domestic peering relationships, and regional connectivity that keeps traffic close to its source. These networks may not control large blocks of address space or operate global infrastructure, but they frequently carry significant volumes of legitimate traffic every day. When these networks face DDoS attacks, the challenge is not simply about absorbing malicious packets. The real difficulty lies in protecting the network without disrupting the economic and architectural balance that allows it to operate efficiently.

When Protection Disrupts the Network’s Economics

To understand the issue more clearly, consider the same ISP-A. From a routing perspective, typical regional ISPs may be relatively small, announcing only a few /24 prefixes to the Internet. Yet within its regional ecosystem, the network could carry close to 20 Gbps of legitimate traffic, the majority of which is exchanged through local Internet Exchanges and regional peering arrangements.

This architecture delivers two key benefits. First, it maintains low latency for users by ensuring that local traffic remains within local routing paths. Second, it keeps bandwidth costs under control by minimizing reliance on expensive international transit. For many regional networks, this balance between performance and cost is precisely what allows them to compete effectively.

When the 1.3 Tbps attack against ISP-A began, however, this same architecture created a dilemma. The attack volume clearly required global mitigation capacity, yet diverting traffic entirely into a traditional cloud scrubbing service would mean forcing the network’s entire legitimate traffic footprint through global transit paths as well.

Figure 2. Attacks are coming from all over the world but not locally.

Most global mitigation services operate on a diversion model in which the ISP announces its prefixes to the protection provider. The provider’s global scrubbing infrastructure then attracts traffic from around the world, analyzes it, filters malicious packets, and forwards the remaining traffic back to the ISP.

A diagram of a cloud scrubbing centerAI-generated content may be incorrect.
Figure 3. In a typical cloud/hybrid setup, all traffic are routed to the global cloud upon activation.

From a purely security-focused perspective, the model works well. The difficulty arises when we examine what happens to legitimate traffic during this process.

The Hidden Cost of Clean Traffic

Once traffic diversion begins, every packet destined for the protected network must first pass through the mitigation provider’s infrastructure. This includes both malicious traffic and legitimate user traffic. In ISP-A’s case, the full 20 Gbps of daily clean traffic would need to traverse upstream transit networks to reach the cloud mitigation provider before being delivered back to the ISP.

Traffic that previously flowed locally through IXs and domestic peering links is suddenly redirected across international transit paths. The additional distance increases latency, but more importantly, it introduces a new cost structure. Transporting that volume of traffic through upstream transit networks can be extremely costly, and someone ultimately bears the cost of carrying it.

For smaller providers, this reality creates an uncomfortable paradox. The attack traffic they want to mitigate may be sporadic and unpredictable, but the cost of diverting their clean traffic is constant. Instead of paying primarily for protection during attack events, they effectively pay global transit rates for traffic that would normally remain within their local network environment.

In many cases, the economics of this model become difficult to justify. The protection solution begins to undermine the efficiency that regional networks are designed to achieve.

Figure 4. Traffic distribution between Traditional Cloud vs Hybrid Approaches

Why Local Traffic Should Remain Local

Regional networks thrive because of locality. Domestic peering, IX connectivity, and carefully engineered routing policies exist to ensure that traffic travels the shortest and most efficient path possible. When that traffic is unnecessarily pushed through distant mitigation infrastructure, the network loses many of the advantages it was designed to provide.

This is why many operators eventually reach the same conclusion: the architecture of DDoS protection must respect the architecture of the network itself. A model that forces all traffic through global infrastructure may work for hyperscale networks, but it does not necessarily translate well to regional operators.

A more sensible principle emerges from this realization. Local traffic should remain local whenever possible, while global attack traffic should be intercepted and mitigated as close to its source as possible.

This is precisely the problem hybrid protection architectures are designed to address.

A Hybrid Model Built for Regional Providers

Nexusguard’s True Hybrid architecture approaches DDoS protection differently by combining locally deployed Bastions infrastructure with Nexusguard’s globally distributed mitigation platform. Instead of forcing all traffic through a centralized cloud scrubbing network, the system allows traffic to follow the most efficient path based on its origin and routing topology.

In a deployment like ISP-A’s, a regional Bastions partner operates Bastions infrastructure within the local network ecosystem. ISP-A subscribes to Origin Protection delivered through this Bastions platform, ensuring that the majority of its traffic continues to flow through local routing paths, domestic peering environments, and regional exchanges.

At the same time, ISP-A enables the True Hybrid capability, which allows Nexusguard’s global mitigation network to participate during large-scale attacks originating from outside the region. Both the Bastions partner network and Nexusguard’s global infrastructure originate ISP-A’s prefixes, allowing routing decisions to naturally follow the most efficient path.

Under normal operating conditions, traffic gravitates toward the Bastions partner network because it is topologically closer. Local user traffic therefore remains within the regional ecosystem, preserving both performance and cost efficiency. When attack traffic originates from outside the region, Nexusguard’s globally distributed mitigation platform intercepts and absorbs those attack streams closer to their source before they reach the regional network.

Figure 5. Nexusguard True Hybrid achieves balance of Mitigation efficacy, performance and cost 

Protection Without Breaking the Network

For operators like ISP-A, the benefits of this approach are immediately apparent. During the 1.3 Tbps attack incident, Nexusguard’s global mitigation infrastructure absorbed the large-scale attack traffic while the Bastions-based local protection continued to serve legitimate regional users without disruption.

The network did not need to divert its entire 20 Gbps traffic footprint through a distant scrubbing infrastructure. Instead, the majority of clean traffic continued to flow through local connectivity provided by the Bastions partner network, utilizing domestic bandwidth and IX peering.

Only the portion of traffic associated with globally distributed attack sources was handled by Nexusguard’s global mitigation network. This allowed ISP-A to withstand a terabit-scale attack without sacrificing the performance and cost efficiency of its local network architecture.

Users continued to reach services through familiar regional routing paths, while the large attack streams were absorbed by Nexusguard’s globally distributed mitigation platform before they could reach the ISP’s infrastructure.

Rethinking DDoS Protection for the Real Internet

The modern Internet is often discussed through the lens of hyperscale infrastructure, but much of its connectivity is still operated by regional providers, national carriers, and specialized communications service providers. These networks form the connective tissue of the Internet, and their operational realities are very different from those of global cloud platforms.

For these operators, DDoS protection cannot be evaluated solely on the size of the attacks it can absorb. It must also align with the network’s routing architecture, performance expectations, and economic constraints. A protection model that ignores these factors may solve one problem while creating several new ones.

Hybrid architectures acknowledge this reality. By combining Nexusguard’s Bastions-based local protection with Nexusguard’s global mitigation infrastructure, operators gain the flexibility to defend against attacks of any size without sacrificing the efficiency of their networks.

In many cases, the smartest way to protect a regional network is not to send everything into the cloud. It is to allow local traffic to remain local, while ensuring that global attacks are stopped long before they reach the network.

Protect Your Infrastructure Today

Explore Nexusguard Edge Protection Solutions Today