Skip to content
AS213382 / PEERYX NETWORKUnder attack?Contact the network team
PEERYXNETWORK
Discuss this architecture

Deployment requirements

DDoS protection for enterprise and SaaS networks

Keeping a public service available requires both a reachable network path and an application that can handle legitimate work. Identify the address and routing you control before choosing how protected traffic reaches the service.

Discuss this architecture Compare deployment options
A development workstation with monitors, a keyboard and a computer.
Illustrative photograph · Anete Lusina / Pexels

Identify which resource is becoming unavailable

Network saturation and expensive requests differ
A flooded link can block access before an application sees traffic. A costly authenticated request can exhaust backend resources without filling that link. The same bandwidth graph does not diagnose both problems.
An origin can sit behind several delivery layers
A CDN, application proxy, firewall and origin server may observe different traffic. Map the public name, exposed addresses and return path, including endpoints outside the main website, before changing protection.
The address may belong to another provider
Hosted or cloud-assigned addresses are not automatically portable through a new BGP service. Review address ownership and the provider’s routing or tunnel constraints; a design must fit what each operator permits.

Keep network protection and application controls complementary

Protected Transit IP or a compatible local filtering deployment can address the network layer. HTTP authorization, request budgets and application-specific controls still belong to an appropriate application or security component; no universal WAF service is implied.

  1. Map the exposed services

    Identify public endpoints, hosting ownership, required protocols and the application action that must remain available.

  2. Qualify the protected network path

    Review delivery options, allowed routing, MTU and the visibility required by the selected filtering mode.

  3. Retain application safeguards

    Keep origin access policy, authentication, request limits and backend monitoring aligned with the application.

Illustrative deployment sequence. The quotation and acceptance record define the delivered service.

Choose the boundary your team can operate

Can you change routing or only the application endpoint?
The answer determines whether network transit, a compatible tunnel arrangement or another delivery layer can be considered. Confirm provider constraints before selecting the architecture.
What does availability mean for this service?
Use a successful business action, not only an open port. Record the expected response, timeout and dependency behavior so that network and application teams can compare the same incident.
Who investigates when the network remains reachable?
Keep application errors, resource use and network counters available over a common interval. A healthy route does not prove that authentication, a database or an external dependency is working.

Validate the complete user action

  • Record ordinary application success and dependency behavior before modifying the delivery path.
  • Verify required protocols, both traffic directions and representative larger exchanges through the proposed network layer.
  • Agree on rollback and incident ownership across hosting, network and application teams; preserve the existing application controls.

Questions for this deployment

Does network DDoS protection replace a WAF or application authorization?

No. Network delivery and supported packet filtering do not replace application-aware access decisions. Review those layers separately for the service you operate.

Must the application move to a new server?

That depends on the compatible delivery path and the current provider’s constraints. Review routing and origin reachability before making a migration commitment.

Technical reference : OWASP: denial-of-service defenses across system layers