ISP DDoS Protection: How Upstream DDoS Mitigation and Scrubbing Work

An enterprise can invest heavily in next-generation firewalls, redundant routers, intrusion prevention, and high-availability network infrastructure and still lose Internet connectivity during a distributed denial-of-service (DDoS) attack.

The reason is straightforward: if malicious traffic overwhelms the bandwidth connecting an organization to the Internet, security equipment inside its network may never have an opportunity to stop the attack. The Internet circuit becomes congested before the firewall can inspect the incoming packets.

The global Internet backbones operated by major carriers play an important role in addressing this problem. The networks profiled in Macronet Services’ guide to the leading global Tier 1 ISPs carry traffic across extensive international infrastructure, making their routing capabilities, interconnection relationships, and network-level security services important considerations for enterprise connectivity. However, a provider’s Tier 1 status does not automatically establish the quality or extent of its DDoS protection.

This is where upstream DDoS mitigation becomes essential. Instead of relying exclusively on a company’s firewall, an Internet service provider or specialized mitigation network can identify and filter malicious traffic before it reaches the organization’s constrained Internet connection.

The threat is not limited to extraordinary attacks measured in terabits per second. According to Cloudflare’s Q3 2026 DDoS Threat Report, 98% of the network-layer attacks mitigated on its network during the quarter were below 1 Gbps, while 96% lasted less than ten minutes. Although those figures reflect Cloudflare’s own telemetry rather than the entire Internet, they demonstrate how frequent, relatively short attacks can create serious operational challenges.

For enterprises dependent on customer-facing applications, cloud infrastructure, public APIs, VPN gateways, and Internet-connected business services, effective protection requires more than sufficient bandwidth or a capable firewall.

It requires understanding where malicious traffic can be intercepted, how legitimate traffic is preserved, and whether the selected provider can maintain service availability during an attack.

This guide explains how ISP DDoS protection works, including upstream filtering, BGP traffic diversion, scrubbing centers, remote-triggered blackholing, and always-on mitigation. It also examines the network design, operational requirements, and commercial considerations that enterprises should evaluate when selecting a protection service.

What Is Upstream DDoS Protection?

Upstream DDoS protection is the detection and mitigation of malicious traffic within an Internet provider’s network or a specialized mitigation network before that traffic overwhelms the customer’s Internet connection or infrastructure.

The term upstream refers to the location of the defensive controls relative to the enterprise. Instead of waiting for traffic to reach a firewall at the customer premises, the provider can identify suspicious activity and apply protective measures earlier in the delivery path.

Depending on the architecture, mitigation may occur at the ISP’s network edge, within its backbone, or at specialized facilities designed to inspect and filter attack traffic.

A provider may discard packets matching an attack signature, rate-limit selected traffic flows, or redirect incoming traffic through a DDoS scrubbing service that attempts to separate legitimate requests from malicious traffic.

The objective is not simply to block an attack. It is to keep the business’s applications and services available to legitimate users.

This distinction is fundamental when comparing protection offerings. An ISP that monitors traffic and provides emergency blackholing delivers a different level of protection from one offering automated traffic analysis, selective scrubbing, and continuous delivery of legitimate traffic.

Both may describe their offerings as DDoS protection, but their effectiveness during an actual attack can differ substantially.

Why Firewalls Alone Cannot Stop Large DDoS Attacks

Enterprise firewalls protect against unauthorized access, malicious connections, and many forms of network abuse. However, the effectiveness of those controls depends partly on where they operate.

Consider a company with a 1 Gbps Dedicated Internet Access (DIA) connection.

Under normal conditions, the connection supports employee Internet access, business applications, VPN traffic, and customer-facing services.

Now imagine attackers directing a sustained 5 Gbps UDP flood toward the company’s public IP addresses.

Even if the firewall can recognize and discard every malicious packet it receives, the incoming Internet circuit cannot carry the full volume of offered traffic.

Congestion develops upstream of the firewall. Legitimate traffic competes with the attack traffic for limited bandwidth, resulting in packet loss, excessive latency, or complete service interruption.

Increasing firewall capacity does not solve a saturated upstream link.

Neither does adding a second firewall behind the same connection.

Other forms of DDoS attack can overwhelm infrastructure without consuming the entire Internet circuit. High packet-per-second rates may stress forwarding hardware, while connection-oriented attacks can exhaust firewall session tables, load balancers, or server resources.

These attacks demonstrate why DDoS protection cannot be evaluated solely in terms of available bandwidth.

Effective protection requires the ability to handle traffic volume, packet-processing demands, protocol behavior, and the capacity limitations of the systems being protected.

This is one reason DDoS mitigation should be evaluated as part of the underlying Internet architecture rather than treated exclusively as a firewall feature. Our IP Transit Guide explains how upstream providers, peering relationships, BGP routing, and network interconnection influence enterprise Internet connectivity.

The central principle is that an attack must be mitigated before it overwhelms the most constrained component in the delivery path.

For volumetric attacks, this generally means moving the defensive controls upstream of the customer’s Internet circuit.

How DDoS Scrubbing Centers Work

A DDoS scrubbing center is network infrastructure designed to receive incoming traffic, identify malicious activity, filter unwanted packets, and forward legitimate traffic toward the protected destination.

Traditionally, scrubbing services relied on specialized mitigation facilities located in strategic network hubs.

Modern providers may distribute similar capabilities across large global networks, using geographically dispersed points of presence and anycast routing to process traffic closer to where it enters the provider’s infrastructure.

The underlying process involves several distinct operations.

Step 1: Detecting the DDoS Attack

The mitigation process begins with network monitoring and traffic analysis.

ISPs and specialized security providers may examine flow telemetry, packet rates, bandwidth utilization, protocol distributions, connection attempts, and historical traffic patterns.

Technologies such as NetFlow, IPFIX, sampled flow monitoring, and packet-level analysis can provide visibility into unusual network behavior.

A sudden increase in traffic may indicate an attack, but volume alone is not sufficient evidence.

A retailer experiencing legitimate demand during a major promotion, for example, may receive traffic levels far above its historical averages.

An effective detection system must distinguish unusual legitimate activity from malicious traffic designed to exhaust network or application resources.

Modern mitigation platforms therefore use combinations of thresholds, behavioral analysis, protocol validation, traffic classification, and attack signatures.

Automation is particularly important because many attacks are brief.

A process that depends on a network administrator noticing an alert, opening a trouble ticket, and waiting for manual intervention can allow an attack to disrupt operations before protective measures are activated.

Step 2: Diverting Traffic to Scrubbing Infrastructure

Once an attack has been identified, the mitigation provider needs to ensure that inbound traffic passes through the appropriate defensive infrastructure.

In an ISP-native architecture, the provider may already have filtering equipment or software-based mitigation capabilities operating within the customer’s normal traffic path.

The ISP can activate additional controls without necessarily changing the customer’s Internet routing arrangements.

In a third-party scrubbing architecture, traffic may need to be redirected from the ordinary delivery path to an independent mitigation network.

This is commonly accomplished using the Border Gateway Protocol (BGP).

BGP allows independently operated networks to advertise which public IP prefixes they can reach. A mitigation provider can use appropriately authorized route announcements to attract inbound traffic for an enterprise’s protected IP addresses.

The traffic enters the mitigation network, where filtering occurs before legitimate packets are forwarded toward the customer.

This is a powerful technique, but it requires careful planning.

The enterprise must ensure that its IP prefixes are eligible for advertisement, that the mitigation provider is authorized to originate or otherwise advertise the necessary routes, and that its existing upstream providers will accept the intended arrangement.

For enterprises unfamiliar with these routing relationships, our guide explaining Autonomous System Numbers and Internet routing provides additional background.

BGP diversion is also not instantaneous or universal. The effectiveness of a routing change depends on provider policies, advertisement acceptance, propagation, and traffic paths across the Internet.

Step 3: Separating Malicious Traffic From Legitimate Traffic

After the traffic reaches the scrubbing infrastructure, the mitigation platform attempts to distinguish harmful packets from legitimate traffic.

The filtering methods depend on the attack.

A UDP flood may be addressed using protocol-aware packet classification and rate controls. A TCP SYN flood may require connection-validation techniques that prevent excessive consumption of connection-state resources.

Malformed packets can be discarded based on protocol validity, while other attacks require more sophisticated behavioral analysis.

The challenge is that legitimate and malicious traffic may share many characteristics.

Attackers frequently use large numbers of distributed systems, compromised devices, and ordinary Internet connections. Some attacks deliberately imitate legitimate application requests.

Simply blocking large groups of source IP addresses can therefore interrupt genuine customers without adequately stopping the malicious activity.

The goal of scrubbing is to remove attack traffic while preserving as much legitimate access as possible.

This is why successful DDoS mitigation should be measured in terms of application availability, false-positive rates, and the ability to sustain legitimate traffic—not merely the volume of packets discarded.

Step 4: Delivering Clean Traffic to the Enterprise

Once malicious traffic has been filtered, the remaining legitimate traffic must reach its intended destination.

In a common routed scrubbing architecture, the mitigation provider delivers clean traffic to the enterprise through Generic Routing Encapsulation (GRE) tunnels, IPsec tunnels, or private network interconnections.

GRE allows packets to be encapsulated and carried across an IP network. However, GRE itself does not encrypt the traffic.

IPsec can provide encryption and authentication when properly configured.

Private interconnections may offer an alternative to carrying the returned traffic across ordinary Internet paths.

The delivery architecture has important performance implications.

Encapsulation introduces overhead that affects packet size and maximum transmission unit (MTU) considerations. Tunnel capacity must be sufficient for legitimate traffic, including periods of unusually high demand.

The enterprise must also account for firewall behavior, load balancing, return-path routing, and redundancy.

Inbound traffic may pass through the scrubbing provider while outbound responses use a different network path. Some architectures support this asymmetry, while others require additional routing or inspection considerations.

For a practical architectural example, Cloudflare Magic Transit documents how BGP-based traffic attraction, network-layer filtering, and clean-traffic delivery work together. Its technical documentation also explains the differences between GRE and IPsec tunnels.

Step 5: Restoring Normal Traffic Flow

In an on-demand mitigation architecture, the provider must eventually determine when the attack has ended and whether traffic should return to its ordinary path.

Restoration may involve withdrawing temporary route advertisements, changing routing preferences, or disabling attack-specific filtering policies.

Returning traffic too early can expose the customer to another attack wave.

Maintaining diversion unnecessarily can introduce additional operational complexity or performance considerations.

A well-designed service should have documented procedures for validating attack completion and safely restoring normal operation.

Always-on architectures generally avoid this particular transition because protected traffic continues through the mitigation infrastructure during both ordinary operation and attack conditions.

ISP-Native DDoS Protection vs. Independent Scrubbing Providers

Enterprises generally encounter two broad approaches to upstream mitigation: protection delivered by the Internet access provider and protection delivered by a specialized mitigation network.

Both can be effective, but they introduce different design and operational considerations.

ISP-Native DDoS Mitigation

Many national and global ISPs offer managed DDoS detection and mitigation alongside DIA and IP transit.

A significant advantage is that the provider already controls the network carrying the customer’s traffic.

The ISP may be able to detect an attack and enforce filtering policies within its backbone or at selected network ingress locations before the malicious traffic reaches the enterprise’s access circuit.

This can simplify the operational model because the organization has one provider responsible for both Internet connectivity and DDoS mitigation.

However, services differ considerably among carriers.

Some offerings emphasize basic detection and emergency containment. Others incorporate automated mitigation, detailed telemetry, dedicated scrubbing infrastructure, and managed security operations.

The enterprise must determine which capabilities are actually included in the proposed service.

An ISP with a large global backbone does not necessarily deliver superior protection for every application. The locations where traffic enters its network, the available mitigation functions, and the quality of operational support all matter.

Independent DDoS Scrubbing Providers

Specialized mitigation providers operate networks designed to protect infrastructure across multiple underlying Internet carriers.

Examples include Akamai Prolexic and Cloudflare Magic Transit.

These services illustrate how an independent protection network can use extensive mitigation infrastructure to filter attack traffic before forwarding legitimate traffic to enterprise or hosting environments.

This model can be attractive for organizations with several ISPs, globally distributed facilities, or infrastructure spanning on-premises data centers and public clouds.

Rather than purchasing separate protection services from each access carrier, an enterprise may establish a coordinated mitigation architecture for its protected IP address space.

However, the independence introduces additional responsibilities.

The enterprise must establish how the protection provider attracts traffic, how existing carriers respond, which public prefixes can be protected, and how clean traffic reaches the origin network.

It must also understand the consequences of a failure within the mitigation provider itself.

Neither approach is universally superior. The most appropriate solution depends on the enterprise’s routing architecture, provider relationships, operational capabilities, and business-continuity requirements.

Always-On vs. On-Demand DDoS Mitigation

One of the most consequential decisions is whether traffic should continuously pass through mitigation infrastructure or be redirected only when an attack occurs.

Evaluation factor	Always-on DDoS protection	On-demand DDoS protection
Normal operation	Protected traffic continuously traverses mitigation infrastructure	Traffic normally follows its standard path
Activation	No attack-time diversion is needed	Mitigation is activated when required
Response considerations	Filtering can begin without waiting for diversion	Detection, activation, and routing changes may introduce delays
Latency	Depends on the continuous protection path	Normal traffic avoids diversion overhead
Operational requirements	Continuous path monitoring and protection management	Reliable activation and restoration procedures
Principal trade-off	Continuous protection versus cost and architecture	Reduced normal-path complexity versus activation exposure

 

Always-On DDoS Protection

Always-on protection is designed to keep protected traffic within the mitigation architecture continuously.

This eliminates the need to redirect traffic into the service after an attack begins.

For applications with extremely low tolerance for interruption, eliminating that activation dependency can be valuable.

Financial platforms, customer transaction systems, healthcare applications, authentication services, and critical APIs may justify this approach.

However, always-on protection should not automatically be assumed to introduce significant latency.

A geographically distributed mitigation network can process traffic close to its normal ingress point, while a centralized design requiring long detours may have greater performance implications.

The enterprise should evaluate the actual architecture and measured application performance.

On-Demand DDoS Protection

On-demand mitigation allows traffic to follow its ordinary route until the protection service is activated.

Activation may be automatic or manual.

This distinction is important. An automated on-demand service that detects an attack and initiates routing changes immediately can provide a different experience from one requiring an administrator to contact a security operations center.

For example, Cloudflare’s on-demand mitigation documentation explains how flow monitoring can trigger automated advertisement of protected prefixes during an attack.

However, even automated activation can involve time for the necessary routing changes to become effective.

The key question for enterprise buyers is not simply whether the provider supports automated mitigation.

It is how long critical business applications may be unavailable between the beginning of an attack and the successful delivery of legitimate traffic.

That interval should be evaluated through realistic testing and clearly defined service commitments.

BGP DDoS Mitigation: Blackholing, FlowSpec, and Traffic Scrubbing

ISPs use several mechanisms to control malicious traffic.

Although these technologies are sometimes discussed interchangeably, they provide different levels of traffic selectivity and service availability.

Remote-Triggered Blackholing (RTBH)

Remote-triggered blackholing allows network operators to discard traffic associated with a specified destination before that traffic reaches the protected network.

In a destination-based implementation, the ISP can install a route or routing policy that causes packets destined for the attacked IP address or prefix to be discarded.

This may be highly effective when the immediate objective is protecting shared network infrastructure from congestion.

However, legitimate traffic to the affected destination is also discarded.

If a company’s public application is blackholed, customers generally cannot reach that application through the affected routes.

Blackholing therefore provides containment, not full application availability.

The Internet Engineering Task Force (IETF) standardized the well-known BGP BLACKHOLE community in RFC 7999, providing a mechanism through which an originating network can request that a neighboring network discard traffic toward an identified destination.

The implementation depends on the participating providers’ policies and authorized routing arrangements.

For some incidents, blackholing is an appropriate emergency measure. It should not be mistaken for selective scrubbing.

BGP Flow Specification (FlowSpec)

BGP FlowSpec provides a mechanism for distributing traffic-matching rules across participating network devices.

Rather than blocking every packet destined for an IP address, a provider can identify more specific traffic characteristics and apply supported filtering or rate-control actions.

For example, a network operator might distribute a rule targeting a particular protocol and destination port associated with an ongoing attack.

When correctly implemented, the resulting controls can be applied across multiple network locations.

FlowSpec can be especially useful when providers need to react quickly to identifiable attack patterns without diverting all traffic through a separate scrubbing facility.

However, overly broad rules can disrupt legitimate traffic, and the ability to enforce rules depends on the provider’s routing platform, policy controls, and forwarding hardware.

The technology is defined in RFC 8955 for IPv4 traffic, with RFC 8956 extending the framework for IPv6.

FlowSpec is a valuable network mitigation tool, but it does not replace sophisticated traffic analysis when malicious and legitimate requests cannot be distinguished using the available traffic-matching characteristics.

Source Address Validation and Anti-Spoofing

Certain reflection and amplification attacks depend on forged source IP addresses.

The attacker sends requests to third-party systems while impersonating the victim’s IP address. Those systems then return traffic toward the victim, potentially amplifying the attack.

Source address validation reduces the ability of networks to originate packets with unauthorized or implausible source addresses.

This is an important preventive measure, particularly when adopted broadly across Internet access and transit networks.

The National Institute of Standards and Technology addresses source address validation, BGP routing security, blackholing, and FlowSpec in NIST SP 800-189: Resilient Interdomain Traffic Exchange.

These mechanisms are complementary rather than interchangeable.

Blackholing deliberately sacrifices reachability to contain the attack. FlowSpec allows more selective network filtering. Anti-spoofing helps prevent certain attacks from being launched or amplified. Scrubbing attempts to distinguish malicious from legitimate traffic while preserving service availability.

An effective provider may use several of these techniques together.

What Types of DDoS Attacks Can an ISP Mitigate?

DDoS attacks can target bandwidth, network equipment, transport protocols, or the applications themselves.

The distinction matters because a service designed to stop large packet floods may not provide the protection required against sophisticated application-layer attacks.

Volumetric DDoS Attacks

Volumetric attacks attempt to overwhelm a network’s available bandwidth.

UDP floods and certain DNS-based reflection attacks are common examples.

These attacks are particularly well suited to upstream mitigation because the provider can attempt to discard malicious traffic before it saturates the customer’s Internet circuit.

Protocol and State-Exhaustion Attacks

Other attacks exploit protocol behavior or consume connection-handling resources.

TCP SYN floods, for example, can exhaust resources in servers, firewalls, and load balancers.

Effective mitigation may require connection validation, state-management protections, and traffic filtering capable of identifying abnormal protocol behavior.

A service’s ability to process packets per second and handle large numbers of connection attempts can be as important as its total bandwidth capacity.

Application-Layer DDoS Attacks

Application-layer attacks target services such as websites, login systems, APIs, and application servers.

An HTTP request flood may generate relatively modest bandwidth while exhausting application resources.

These attacks can be difficult to distinguish from legitimate demand, particularly when the requests originate from distributed sources and resemble normal user behavior.

Mitigation often requires application-aware controls such as web application firewalls, rate limiting, bot management, caching, and request validation.

For businesses hosting applications in public clouds, services such as AWS Shield provide additional capabilities for supported cloud resources.

However, enterprises should not assume that protection for one application, cloud platform, or IP service automatically covers their entire infrastructure.

A company might have strong protection for its public website while leaving its VPN concentrator, DNS infrastructure, or another Internet-facing system exposed.

The protection assessment should identify the actual services being defended, their reachable IP addresses, and the mitigation layers covering each one.

DDoS Protection for Dual-ISP and BGP Multihomed Networks

Multiple Internet connections improve enterprise resilience against several types of infrastructure failure.

They do not automatically provide DDoS protection.

Consider an enterprise with two 1 Gbps Internet circuits from different carriers.

The connections terminate on independent routers, and BGP allows the organization to advertise its public IP prefixes through both upstream providers.

If attackers direct several gigabits per second toward those addresses, traffic can arrive through either ISP.

Both connections may experience congestion.

Changing BGP routing preferences may move some traffic toward another provider, but that does not necessarily remove the attack. The alternate path can become congested as well.

Our BGP Multihoming Guide explains how enterprises establish public IP reachability through multiple providers and why additional coordination is necessary to achieve genuine network resilience.

Coordinating Mitigation Across Multiple Carriers

A multihomed enterprise may purchase protection from each ISP, with clearly defined responsibilities for mitigating attacks on their respective networks.

Alternatively, it may use a specialized scrubbing provider capable of attracting inbound traffic for the protected IP space before that traffic reaches either access carrier.

The independent approach may create a more consistent security model, but its operation depends on correct BGP configuration, address authorization, traffic steering, and clean-traffic delivery.

Public IP ownership is particularly important.

Enterprises using provider-assigned IP addresses may face restrictions on advertising those addresses through another carrier.

Organizations with appropriately allocated portable IP space and their own autonomous system generally have more control over routing, although they also take on additional technical responsibilities.

The Importance of RPKI and Route Authorization

A mitigation provider cannot safely advertise arbitrary customer IP prefixes.

The organization must establish appropriate authorization and ensure that the intended routing design is compatible with provider filtering and Resource Public Key Infrastructure (RPKI) policies.

Route Origin Authorizations (ROAs) identify which autonomous systems are permitted to originate particular IP prefixes.

If a scrubbing provider needs to originate an enterprise prefix during an attack, the routing authorization design must account for that arrangement.

An incorrect configuration can cause legitimate mitigation advertisements to be rejected by networks performing route-origin validation.

Our guide to BGP Security, RPKI, Route Leaks, and BGP Hijacking examines these risks in greater detail.

DDoS mitigation must also be coordinated with physical network resilience.

An enterprise may have two different ISPs but still depend on a shared fiber route, aggregation facility, or building entrance.

As explained in Carrier Diversity vs. Path Diversity, multiple carrier contracts do not necessarily eliminate common points of failure.

For mission-critical environments, DDoS mitigation, routing security, and network redundancy should be designed together rather than purchased as unrelated services.

DDoS Protection for Data Centers, Cloud Infrastructure, and Hybrid Networks

Many enterprises no longer operate their important applications from a single corporate data center.

Customer portals may be hosted in a colocation facility, databases may reside in public clouds, and employees may access services through a combination of VPNs, private cloud connections, and ordinary Internet access.

This creates a more complicated protection problem.

A DDoS service covering the public IP addresses assigned to one data center may not protect Internet-facing workloads hosted elsewhere.

Similarly, a cloud provider’s DDoS controls may protect supported cloud resources without covering an independently operated enterprise Internet edge.

The architecture must reflect the actual application delivery paths.

Colocation and IP Transit

Enterprises operating infrastructure in carrier-neutral data centers often purchase IP transit from multiple upstream providers.

These arrangements may provide substantial bandwidth and routing flexibility, but they require deliberate DDoS protection design.

The enterprise should determine where scrubbing occurs, whether traffic can be redirected to an external mitigation network, and whether the connections carrying clean traffic can support business-critical workloads.

Carrier-neutral facilities may provide access to multiple network providers, but their availability does not automatically establish a coordinated security architecture.

Cloud and Hybrid Applications

For applications spanning cloud and on-premises environments, the protection design may involve several complementary services.

Cloud-native DDoS controls can protect supported cloud endpoints, while upstream ISP mitigation protects independently routed public address space and network infrastructure.

Application delivery networks and web application firewalls may provide further protection for websites and APIs.

These capabilities should be evaluated as a coordinated system.

The objective is to avoid both duplicated expenditure and coverage gaps that leave critical services exposed.

How to Evaluate an ISP DDoS Protection Service

Carrier proposals frequently emphasize large global scrubbing networks, impressive mitigation capacity, and examples of major attacks successfully handled.

Those capabilities can be relevant, but they do not necessarily establish how well the proposed service will protect a particular enterprise.

A sound evaluation should focus on measurable service outcomes.

Scrubbing Capacity and Network Coverage

Providers may advertise mitigation capacity measured in terabits per second.

However, an aggregate global capacity figure does not guarantee that the same capacity is available at every network location.

Attack traffic must reach the mitigation infrastructure before it encounters a bottleneck that can disrupt the protected service.

Geographic placement, peering arrangements, upstream capacity, and traffic distribution therefore matter.

Buyers should understand where traffic enters the protection network, how attack loads are distributed, and whether the architecture is appropriate for the locations and applications being protected.

Detection and Mitigation Response Times

A provider may advertise rapid detection or near-instantaneous mitigation.

The enterprise should establish exactly what those claims measure.

Detection time is the interval before an attack is recognized.

Activation time measures how quickly filtering or diversion is initiated.

Routing convergence describes how the relevant network paths change.

Application recovery measures when legitimate users can successfully access the affected service.

These are related but different outcomes.

A service-level agreement that guarantees rapid rule deployment does not necessarily guarantee that users will experience no interruption.

For critical business applications, recovery should be evaluated from the customer’s perspective.

Legitimate Traffic Preservation

A DDoS service that blocks the attack but also prevents legitimate customers from reaching an application may not meet the business requirement.

The provider’s ability to distinguish harmful traffic from valid activity is therefore essential.

Enterprises should evaluate false-positive handling, policy tuning, visibility into mitigation decisions, and the procedures used to restore legitimate traffic inadvertently blocked during an incident.

Applications with unusual protocol requirements may need dedicated testing and configuration.

Monitoring and Operational Support

The operational response can be as important as the mitigation technology itself.

Enterprises should identify which provider team monitors attacks, who can activate mitigation, who has authority to adjust filtering rules, and how incidents are escalated.

A 24/7 security operations capability may provide more useful support during a major attack than a generic technical support queue.

Customers should also have access to meaningful incident data, including attack duration, traffic volume, packet rates, attack vectors, mitigation actions, and available evidence of service restoration.

The most important reporting question is whether the information helps the organization determine what happened and how effectively the protection service responded.

Testing Before Acceptance

DDoS protection should be validated as a working service, not simply accepted because it has been provisioned.

Testing should establish that protected IP prefixes are configured correctly, traffic can reach the mitigation infrastructure, filtering policies behave as expected, and legitimate applications remain available.

For on-demand services, the activation and routing-diversion process should be included in the testing scope.

For always-on services, tests should examine traffic-path performance and failure handling, including tunnel or mitigation-node failures where applicable.

All testing must be coordinated with the provider and performed under authorized conditions.

A successful technical demonstration is useful, but the most important acceptance criterion is that the complete service behaves as required under the scenarios the enterprise needs to survive.

What Does ISP DDoS Protection Cost?

DDoS protection pricing varies considerably because services differ in scope, architecture, and commercial structure.

Some ISPs include limited mitigation capabilities with their Internet access products.

Others charge separately for managed detection, automated mitigation, advanced scrubbing, protected IP address ranges, or specialized operational support.

Independent mitigation providers may offer different pricing models, particularly for organizations protecting several facilities or large amounts of public IP space.

Commercial terms can depend on protected bandwidth, clean-traffic capacity, the number of protected prefixes, always-on versus on-demand operation, service locations, connectivity requirements, and support commitments.

Some proposals may also involve activation fees, usage-related charges, or other contractual conditions.

For this reason, monthly recurring cost alone is not a sufficient basis for comparison.

A relatively inexpensive service offering attack notification and emergency blackholing should not be considered equivalent to a service engineered to preserve application availability through advanced traffic scrubbing.

Evaluate Total Cost of Ownership

DDoS protection should be evaluated alongside the broader Internet connectivity architecture.

An enterprise with two DIA connections may find that purchasing mitigation independently from each carrier creates a different cost and operational model from using one coordinated third-party protection service.

The correct comparison includes implementation, provider coordination, protected assets, recurring charges, traffic delivery, monitoring, support, and the potential financial consequences of an outage.

Internet connectivity pricing itself can also vary significantly according to access construction, bandwidth commitments, provider infrastructure, and contract structure. Our guide to Tier 1 ISP Pricing and Dedicated Internet Costs explains these considerations in greater detail.

For DDoS protection, the key financial question is whether the protection service provides an appropriate level of resilience for the business exposure it is intended to reduce.

The most expensive architecture is not necessarily the right one, but the least expensive offering may leave unacceptable risk.

Enterprise DDoS Protection: Three Practical Scenarios

The best architecture depends on where business applications reside and what level of interruption the organization can tolerate.

Scenario 1: A Corporate Headquarters With Two Internet Providers

A regional enterprise uses two DIA connections to support cloud applications, employee access, and remote connectivity.

Its public-facing services are limited, and most business applications are hosted by third parties.

The company may be able to satisfy its requirements through ISP-native DDoS protection, provided the services cover the relevant public IP addresses and network functions.

The critical distinction is whether an attack threatens inbound services hosted at the headquarters, outbound Internet availability, or both.

DDoS protection of a public VPN gateway, for example, does not automatically address every possible source of Internet connectivity disruption.

For this environment, a coordinated dual-ISP design with appropriate upstream mitigation may provide the most economical result.

Scenario 2: An Enterprise Hosting Revenue-Generating Applications

A company operates customer-facing applications from a data center with its own public IP addresses and BGP connectivity to two upstream providers.

Its business depends on maintaining service availability during large traffic events.

The company may benefit from always-on mitigation or a coordinated third-party scrubbing architecture that protects its public prefixes across both Internet carriers.

The design should account for BGP authorization, clean-traffic delivery, application-layer defenses, and the behavior of the network if the scrubbing provider becomes unavailable.

The enterprise should also evaluate whether application delivery through a CDN or similar architecture can absorb legitimate demand and reduce direct exposure of its origin infrastructure.

Scenario 3: A Hybrid Enterprise With Cloud and On-Premises Services

A larger organization operates applications across several colocation facilities and public clouds.

Some services are protected by cloud-native security controls, while others use independent Internet transit or dedicated connectivity.

The objective is not necessarily to consolidate every function into one DDoS provider.

Instead, the enterprise needs a coherent inventory of protected services and a clear understanding of which mitigation layer is responsible for each traffic path.

A coordinated design can reduce coverage gaps while preventing unnecessary duplication of services.

These scenarios illustrate why DDoS protection should be selected according to application dependencies and enterprise network architecture rather than a generic product category.

Building an Enterprise DDoS Response Plan

Even a sophisticated upstream mitigation service does not eliminate the need for a response plan.

A DDoS incident can involve network operations, security teams, application owners, customer support, and external service providers simultaneously.

The enterprise should establish which services require protection, who owns the response process, and how availability will be measured.

Network teams need current routing documentation, protected-prefix inventories, tunnel configurations, provider contacts, and emergency procedures.

Security teams need to understand the scope of the upstream service and which attacks require additional application-layer controls.

Application owners should define the checks used to confirm that legitimate customers can complete important business transactions.

This final requirement is particularly important.

A mitigation provider may report that attack traffic has been filtered successfully while customers continue to experience errors, timeouts, authentication problems, or poor application performance.

Network-level attack mitigation and business-service recovery are not necessarily the same event.

After an attack, the enterprise should review the detection timeline, mitigation effectiveness, operational escalation, false positives, application recovery, and any contractual or architectural weaknesses exposed by the incident.

The objective is continuous improvement in enterprise resilience.

The Macronet Services Framework for Evaluating DDoS Protection

Selecting a DDoS protection service requires joining network engineering, security requirements, and carrier procurement.

The evaluation should begin by identifying the applications and services that the business must keep available.

From there, the organization should document how those services connect to the Internet, which IP addresses and routing paths are involved, and where protective controls can operate effectively.

Provider options can then be compared against a common technical and commercial specification.

That specification should define the mitigation architecture, supported attack types, protected IP space, detection and response requirements, traffic-delivery method, operational support, service levels, and total cost.

For multicarrier environments, the evaluation must also address BGP routing, mitigation coordination, physical diversity, and provider responsibilities.

A service that looks impressive in isolation may be poorly suited to the customer’s actual network.

Conversely, a simpler service may be entirely appropriate when it protects the applications and infrastructure that matter most.

A successful procurement process therefore seeks the least complex, commercially efficient architecture that demonstrably meets the organization’s resilience requirements.

Frequently Asked Questions About ISP DDoS Protection

What is ISP DDoS protection?

ISP DDoS protection is a service that detects and mitigates malicious network traffic within an Internet provider’s infrastructure before it overwhelms the customer’s Internet connection. Capabilities may include traffic filtering, rate limiting, blackholing, and advanced scrubbing designed to preserve legitimate application access.

What is a DDoS scrubbing center?

A DDoS scrubbing center is infrastructure that analyzes incoming traffic, identifies malicious packets, applies filtering controls, and forwards legitimate traffic toward the protected destination. Scrubbing may occur in dedicated facilities or across a distributed mitigation network.

How does upstream DDoS mitigation work?

Upstream mitigation detects suspicious traffic and filters or redirects it before it reaches the customer’s vulnerable network connection. Depending on the service, this may involve ISP-based filtering, BGP traffic diversion, scrubbing infrastructure, and delivery of clean traffic through tunnels or private interconnections.

What is the difference between DDoS scrubbing and blackholing?

DDoS scrubbing attempts to filter malicious traffic while preserving legitimate access. Destination-based blackholing discards traffic toward the targeted IP address, including legitimate requests. Blackholing is primarily a containment mechanism, while scrubbing is designed to maintain service availability.

Does having two Internet providers protect against DDoS attacks?

No. Dual-ISP connectivity can improve resilience against certain provider or circuit failures, but attack traffic can still congest either Internet connection. DDoS mitigation must account for all relevant traffic ingress paths.

What is the difference between always-on and on-demand DDoS protection?

Always-on protection continuously processes protected traffic through mitigation infrastructure. On-demand protection activates mitigation when an attack is detected. Always-on designs avoid attack-time diversion, while on-demand designs may introduce activation or routing delays.

Can an ISP stop a DDoS attack before it reaches my firewall?

Yes, if the provider has suitable upstream filtering or scrubbing capabilities and the malicious traffic can be intercepted before reaching the constrained customer connection. The effectiveness depends on the provider’s architecture and the attack’s characteristics.

Does DDoS protection cover websites and APIs?

Not always. Network-layer mitigation primarily protects network and transport infrastructure. Websites and APIs may also require application-layer defenses, including web application firewalls, bot management, caching, and request rate limiting.

Is DDoS protection included with Dedicated Internet Access?

It depends on the provider and service agreement. Some DIA products include limited mitigation capabilities, while advanced scrubbing, automated response, or specialized operational support may require a separate subscription.

How much does enterprise DDoS protection cost?

Pricing varies according to the protection architecture, covered IP space, bandwidth requirements, mitigation model, operational support, and contractual terms. Enterprises should compare complete service capabilities and total cost rather than relying solely on monthly pricing.

What should an enterprise look for in a DDoS mitigation SLA?

The agreement should clearly define protected assets, attack types covered, detection and activation metrics, service availability, reporting, operational responsibilities, exclusions, and contractual remedies. Application recovery requirements should be considered alongside network-level mitigation commitments.

Conclusion: DDoS Protection Is an Enterprise Network Design Decision

DDoS protection is sometimes treated as an optional security feature added after an Internet circuit has been purchased.

For organizations that depend on continuous connectivity, that approach can leave important risks unresolved.

A firewall cannot restore bandwidth consumed before traffic reaches it. A second ISP does not automatically eliminate exposure to an attack. And a mitigation service that merely blackholes the attacked destination may protect the surrounding network without preserving the availability of the affected application.

Upstream DDoS protection addresses these limitations by placing defensive capabilities where attack traffic can be intercepted before it overwhelms the enterprise.

However, successful mitigation depends on more than advertised scrubbing capacity.

Routing design, traffic classification, automation, application-layer protection, provider coordination, and operational support all determine how effectively the service protects legitimate users.

The appropriate solution should therefore be evaluated as part of the organization’s complete Internet architecture.

How Macronet Services Can Help

Macronet Services helps organizations evaluate Internet providers, design resilient connectivity architectures, and source network solutions that align technical requirements with business objectives.

For enterprises considering DDoS protection, this means examining the underlying network design, provider capabilities, carrier dependencies, mitigation requirements, service-level commitments, and total cost of ownership.

Whether the appropriate approach involves ISP-native mitigation, independent traffic scrubbing, or a coordinated multicarrier architecture, the goal is to protect the business without introducing unnecessary complexity or expense.

Macronet Services brings extensive experience in enterprise network design, Internet carrier evaluation, and provider sourcing to help organizations make informed decisions.

Contact Macronet Services to discuss enterprise Internet connectivity, DDoS protection requirements, and provider options.