Fastly Network Protect Adds Always-On Layer 3 and Layer 4 Filtering
Fastly routes network traffic through its global edge for always-on filtering, using BGP and GRE tunnels without dedicated mitigation appliances.
Fastly Network Protect puts always-on Layer 3 and Layer 4 traffic filtering on the route to a customer’s network. Its main architectural choice is to inspect traffic at Fastly’s points of presence (POPs), rather than send it through a separate, centralized scrubbing facility. That could simplify the path for protected traffic, though the actual latency and operational impact will depend on each customer’s network setup.
The service is aimed at organizations that want protection against network-layer attacks without deploying dedicated mitigation appliances. Fastly says it draws on its global network, which has a stated total capacity of 622 Tbps as of June 30, 2026. The company compares that figure with nearly 20 times the size of the largest recorded DDoS attack. Capacity is a measure of the network as a whole; it doesn’t by itself establish how a particular customer’s traffic will perform during an attack.
Filtering on Fastly’s network
Many conventional mitigation designs send traffic through centralized scrubbing centers for inspection. That adds a routing step, and depending on where the facility sits in relation to users and infrastructure, legitimate traffic may take a longer path. Local mitigation appliances avoid that specific detour but bring hardware to procure, size, maintain and replace.
Network Protect takes a different route: Fastly says the nearest applicable POP processes traffic, applying customer-defined firewall rules at the network edge. Permitted traffic then reaches the customer’s network through a Generic Routing Encapsulation (GRE) tunnel. The service is intended to remain active continuously, so customers don’t need to wait for a separate mitigation process to be switched on when traffic becomes harmful.
That design makes route selection and filtering central to the product. It may reduce dependence on a separate scrubbing-center infrastructure, while the GRE connection provides a path from Fastly’s network to the protected network. Teams evaluating it will still need to understand how the service fits their existing routing, tunnel configuration and traffic-handling practices.
How traffic moves
Fastly describes a three-step onboarding and filtering process. First, it announces the customer’s IP prefixes through Border Gateway Protocol (BGP), drawing traffic destined for those networks into Network Protect. BGP is the routing mechanism that lets networks share reachability information; in this setup, the prefix announcement directs the relevant inbound traffic toward Fastly for inspection.
Fastly announces the customer’s IP prefixes via BGP, routing traffic for those networks through Network Protect.
The service checks traffic against the customer’s firewall rules. Those rules can allow or block traffic based on IP protocol, source or destination port, and source or destination address.
Traffic that passes the rules is sent to the customer’s network over a GRE tunnel.
This is rule-based filtering at launch. The customer’s rules determine what the service permits, which gives teams explicit controls but also puts the quality of those rules and their upkeep into the operational picture. The supplied product description doesn’t detail configuration workflows, reporting, service-level commitments or pricing, so those are practical points for prospective customers to clarify with Fastly.
Less dedicated hardware, with tradeoffs to assess
Software delivery through Fastly’s network could reduce the need for a customer to run a separate fleet of mitigation appliances. That can remove some hardware procurement and maintenance work, as well as the need to plan appliance capacity as traffic patterns change. It doesn’t mean there is no setup: customers still need onboarding, routing changes, suitable firewall rules and a working GRE path to their network.
The practical value will hinge on how well Fastly’s network and the customer’s routing requirements fit together. Organizations should assess the traffic path for their own users and services, confirm how permitted traffic reaches their infrastructure, and understand how rule changes are handled. Fastly’s description presents the architecture and intended benefits, but doesn’t provide customer-specific performance results or independent measurements.
What Fastly says is next
Network Protect launches with filtering based on customer-defined rules. Fastly says it is developing enhancements to its Adaptive Threat Engine for network-layer traffic and telemetry, with the aim of adding more automated mitigation of volumetric attacks. Those capabilities are still in development, so they shouldn’t be treated as part of the service available today.
That planned work points to the next question for the product: how much of the response can move from manually defined rules toward automated decisions, and what controls customers will have over those decisions. For now, the concrete change is a managed, always-on filtering path that uses Fastly’s global network and GRE delivery. Teams weighing it against existing mitigation should focus on routing fit, rule management and measured performance once those details are available.
Fastly says Network Protect is available now. More information is on the Network Protect product page, and customers can contact Fastly about onboarding.
* Fastly’s total global network capacity as of June 30, 2026. The company says this is nearly 20 times the largest network DDoS attack on record as of November 2025.
