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

Deployment requirements

DDoS protection for hosting and server providers

One attacked tenant should not turn an entire rack or virtualization cluster into an unexplained outage. Identify which resources are shared, which policy belongs to each customer and where protected traffic enters your platform.

Discuss this architecture Compare deployment options
An aisle between server racks in a data center.
Illustrative photograph · Brett Sayles / Pexels

Start with the hosting boundaries customers cannot see

A shared bottleneck behind isolated guests
VM separation does not create separate uplink, NIC queue or hypervisor capacity. A host may run out of packet-processing resources while its bandwidth graph looks modest. Keep physical interface, host and guest observations distinct.
Different workloads on the same network
A VPN, mail service, game server and public website do not have the same legitimate packet patterns. A blanket rule can move the incident from overload to false positives. Define the affected prefix or service and who can approve changes.
Ownership across the resale chain
The hosting provider, end customer and upstream can each own different parts of addressing, routing and incident response. Agree who validates an announcement, reports a false positive and communicates restoration to the customer.

Choose who operates the filtering layer

A protected network service can be delivered to the hosting edge. Operators with suitable equipment may also evaluate Defense Fabric for local filtering. The software licence, transport and tenant-facing service remain separate responsibilities.

  1. Protect the shared entrance

    Define the prefixes or public endpoints, delivered bandwidth and upstream protection scope.

  2. Apply an owned local policy

    If local filtering is required, qualify server hardware, port layout, traffic distribution and the selected rules.

  3. Validate the tenant experience

    Test real connections from the supported workload mix and retain a route back to the previous policy.

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

Questions that change the design

Do you want managed delivery or control of your own filter servers?
Compare operating scope, not only licence and transit prices. Local filtering needs compatible hardware, maintenance, observation and an agreed response process.
Which traffic may cross several filtering nodes?
Define ingress and return paths, state ownership and failover behavior. Adding nodes or interfaces does not by itself provide usable capacity under a node-loss scenario.
How will customers be distinguished operationally?
Keep a current mapping from authorized prefixes or endpoints to their service owner and policy. Use that record for incident review; do not assume a shared address or broad rule identifies a single customer.

Test a representative mix of hosted services

  • Record successful connections for the actual services you sell, including workloads that share source addresses.
  • Observe host queues, drops, rule counters and application success over the same interval.
  • Exercise an agreed policy rollback and backup path, then confirm that unaffected tenants retain service.

Questions for this deployment

Does a Defense Fabric licence include protected transit and the servers?

No. Compatible hardware, hosting and transport must be budgeted separately. Any optional Peeryx network service appears as its own component.

Does one game profile cover all hosted applications?

No. Use the documented functions for the actual protocol and test legitimate traffic. FiveM and Minecraft Java delivery require their own compatibility review.