DDoS Protection Network Architecture for Hosting

The uplink is full, firewall CPU is climbing, and the application is still answering slowly. The server itself may look healthy because the failure is happening before requests reach it. Start by separating the event into bandwidth saturation, protocol state exhaustion, or application resource exhaustion, then place mitigation at the component that can absorb that class of traffic.

A practical first response is to capture interface and flow counters, apply a temporary edge ACL for clearly invalid traffic, and contact the upstream mitigation operator before the transit link saturates. A local firewall can protect a host from a small event, but it can't restore service after an attack has already consumed the uplink.

Table of Contents

• What a DDoS Protection Network Actually Has to Stop
• The Three Attack Classes and Their Traffic Signatures
  • Volumetric traffic saturates the path
  • Protocol attacks consume state
  • Application attacks spend the origin's resources
• On-Prem Versus Upstream Mitigation Compared
• How Scrubbing Centers Divert, Clean, and Return Traffic
• Network Architecture Patterns That Actually Hold Up
  • Match each primitive to its failure mode
• The Attack Surface Most Protection Designs Miss
  • Build an endpoint inventory
• Choosing Protection by Business Impact Instead of Tbps
  • Choose against the business failure
• Putting the Architecture Together in a Hosting Environment

What a DDoS Protection Network Actually Has to Stop

A DDoS protection network is an end-to-end architecture, not a single appliance or vendor feature. It has to keep traffic away from origin links, preserve router and firewall state, and stop expensive requests from consuming application workers.

The three useful categories are:

1. Volumetric floods, which exhaust bandwidth with UDP, TCP, or amplification traffic.
2. Protocol attacks, which consume connection tables, CPU, or packet-processing capacity in routers, firewalls, and load balancers.
3. Application resource exhaustion, which sends apparently valid HTTP or API requests until workers, database connections, TLS processing, or queues are depleted.

A server-local firewall only sees traffic that has already crossed the uplink. A scrubbing service can remove large floods, but it may not understand a tenant's login endpoint or API behavior. A CDN can absorb web traffic while leaving SSH, SMTP, DNS, IPv6, or a direct origin address exposed.

Cloudflare's Q1 2025 report illustrates why the architecture must handle both bandwidth and packet rate. It recorded an attack peaking at 6.5 Tbps and another reaching 4.8 billion packets per second in its DDoS threat report. The first stresses links. The second can exhaust packet-processing paths even when a link's average throughput appears manageable.

Practical rule: Put the control where the resource is consumed. Filter bulk traffic upstream, protect state tables at the edge, and rate-limit expensive application actions at Layer 7.

The rest of the design follows that rule. Traffic signatures identify the attack class, routing determines where filtering occurs, and operational testing decides whether the protection works under pressure.

The Three Attack Classes and Their Traffic Signatures

The fastest diagnosis starts with counters rather than packet payloads. Look at bandwidth, packet rate, flow creation, connection concurrency, and request rate together.

Volumetric traffic saturates the path

A UDP amplification event produces large inbound responses from many reflectors, often with little relationship to the volume of legitimate service traffic. DNS query floods can also generate a high packet rate, either against authoritative DNS or a recursive resolver. Watch bits per second, interface utilization, and the ratio of inbound to outbound traffic.

A volumetric event breaks the transit link or upstream router. An edge ACL may reduce unwanted packets after they arrive, but it can't recover capacity already consumed on the circuit.

Protocol attacks consume state

SYN floods create new TCP connection attempts faster than a firewall or load balancer can track them. TCP state exhaustion can leave legitimate clients unable to establish sessions. Watch new flows per second, SYN-to-established ratios, half-open connections, and firewall state-table occupancy.

A representative check on Linux is:

ss -s
nstat -az | egrep 'TcpExtSyncookies|TcpExtListenOverflows|TcpAttemptFails'

HTTP/2 rapid reset attacks abuse stream creation and cancellation, while malformed or unusual packets can force expensive inspection. These events may not produce headline bandwidth, but they can still exhaust middlebox CPU or connection state.

Application attacks spend the origin's resources

Slowloris holds connections open with incomplete requests. TLS handshake exhaustion consumes cryptographic processing. HTTP request floods can repeatedly call a costly search, login, checkout, or API endpoint. Watch concurrent connections, TLS handshakes, requests per second, response latency, worker utilization, and database connection counts.

Cloudflare reported that Q4 2024 attacks were nearly evenly divided between network-layer protocols, at 49%, and HTTP request floods, at 51% in its Q4 DDoS report. More than 420 attacks exceeded both 1 billion packets per second and 1 Tbps during that quarter. In Q2 2025, 94% of Layer 3/4 attacks were below 500 Mbps and approximately 85% were below 50,000 packets per second, while more than 6,500 attacks exceeded 1 Tbps or 1 billion packets per second in Cloudflare's Q2 report.

Use ARPHost's DDoS attack detection guide alongside your own NetFlow and firewall counters. The useful outcome isn't labeling an attack for its own sake. It's identifying the first exhausted resource so the response doesn't target the wrong layer.

On-Prem Versus Upstream Mitigation Compared

On-premises controls include router ACLs, switch filters, nftables, iptables, hardware appliances, and host-level rate limits. They're close to the workload, quick to change, and useful for small events or obviously invalid traffic. They don't help once the attack has consumed the only uplink.

Upstream mitigation moves the decision before the origin path. A scrubbing provider, CDN, or transit operator receives the traffic, filters it at distributed capacity, and returns clean traffic through a tunnel or protected route. BGP-based diversion can handle attacks that would otherwise overwhelm a dedicated firewall or colocation edge.

The practical boundary is simple: anything larger than the uplink must be handled upstream. Protocol-state attacks also belong upstream or at a purpose-built edge, because a server firewall may run out of state before it can enforce a useful rule.

A hybrid design holds up better than either extreme. Keep edge ACLs and host controls for known bad traffic and local containment. Use upstream capacity for floods, state-table pressure, and route preservation. For teams running dedicated infrastructure in Tampa, the important question isn't whether a firewall exists. It's whether the firewall still receives usable traffic after the upstream path has done its job.

How Scrubbing Centers Divert, Clean, and Return Traffic

A scrubbing center works by changing where traffic is delivered during an attack. In an always-on design, an anycast network or reverse proxy receives traffic continuously. In an on-demand design, the protected prefix is announced toward the mitigation network only when detection triggers diversion.

A common BGP workflow uses a more specific route, often a prefix that is accepted across the public Internet, or a route policy that changes path preference. The mitigation network advertises the protected space, receives the attack, removes unwanted packets, and sends clean traffic to the origin through a GRE or MPLS tunnel.

A simplified router policy might look like this on a Junos device:

policy-options {
    prefix-list PROTECTED-PREFIX {
        203.0.113.0/24;
    }
    policy-statement ADVERTISE-PROTECTED {
        term 1 {
            from prefix-list PROTECTED-PREFIX;
            then {
                community add DDOS-SCRUB;
                accept;
            }
        }
    }
}

The address above is documentation space, not a production destination. The operational point is the route policy: the network must know which prefix is eligible for diversion, which community signals mitigation, and how the clean return path avoids re-entering the attack route.

A more specific advertisement can attract traffic, but it also creates responsibility. Test the announcement, withdrawal, tunnel MTU, asymmetric routing behavior, and failure path before an incident. RTBH can protect the rest of a network by discarding traffic to a targeted destination, but it sacrifices availability for that destination. Flowspec can apply more granular filters, but bad rules can block legitimate traffic or create control-plane risk.

Cloudflare reported that its systems mitigated 8.5 million DDoS attacks in the first half of 2024, blocking 10.2 trillion HTTP DDoS requests and 57 petabytes of network-layer attack traffic before it reached customer origins in its H1 2024 report. That scale explains why cloud-based DDoS protection is often placed in front of shared hosting environments.

In a multi-tenant facility, the hard part is granularity. Diverting one customer may require a per-customer route, tunnel, or proxy identity. Some operators therefore protect the shared public edge continuously, then apply tenant-specific policies after traffic has been cleaned.

Network Architecture Patterns That Actually Hold Up

Reliable designs use several controls with deliberately different failure domains. Capacity headroom helps with ordinary bursts, but it doesn't replace diversion. BGP diversity keeps one transit provider from becoming the only path, but it doesn't inspect HTTP. Application rate limits protect expensive endpoints, but they can't stop a saturated circuit.

Match each primitive to its failure mode

A good baseline profile tracks bandwidth, packets per second, new flows, connection states, and HTTP request rates. Detection should trigger when several indicators move together, not when one noisy metric crosses a static threshold. Stateless filtering can remove spoofed or malformed packets quickly, while protocol-aware controls handle UDP and DNS amplification patterns.

The largest observed attacks in the referenced 2025 reporting lasted only about 35 to 45 seconds. That makes automatic detection and pre-authorized mitigation necessary. A runbook that starts with a human paging a network engineer may describe the response, but it isn't the response path.

What fails in production: A protection policy that covers the website but leaves authoritative DNS, mail, Proxmox, IPMI, or SSH on an unprotected public path.

Multi-tenant operations add another constraint. A scrubbing layer protecting one web hostname doesn't automatically protect the DNS service that resolves it, the SMTP service that sends its notifications, or the management interface used to repair it. Draw the architecture per service, not just per network, and document which component owns each decision.

The Attack Surface Most Protection Designs Miss

The headline mitigation number is not a coverage map. The exposed endpoint that causes the outage is often not the public website. It may be an authoritative DNS address, an API origin, SMTP or IMAP, a VPN gateway, a Proxmox web interface, IPMI, cPanel, WHM, SSH, an IPv6 address, or a cloud-to-data-center tunnel.

A 2025 MazeBolt survey estimated that 37% of a typical organization's DDoS attack surface remains vulnerable even when protections are deployed, and that 86% of organizations tested defenses annually or less in its survey report. The practical lesson is uncomfortable: deployment creates an expectation of coverage, while inventory and testing determine whether that expectation is true.

Build an endpoint inventory

Create a row for every public hostname, address family, service, and route. Mark the protected prefix, the origin destination, the owning team, and the emergency action. Include services that engineers tend to omit:

• Authoritative DNS: Confirm the service has resilient upstream handling and isn't tied to one exposed origin.
• Mail services: Check SMTP and IMAP separately from web protection.
• Management planes: Keep IPMI, Proxmox, cPanel, WHM, and SSH off the public application path where possible.
• APIs: Identify separate origins and service-specific rate limits.
• IPv6: Test the IPv6 path independently. A protected IPv4 hostname doesn't prove IPv6 follows the same route.
• Tunnels: Document cloud, VPN, and data-center links that can become alternate paths to the origin.

Verification should come from outside the facility. From an approved residential or other independent network, inspect DNS and HTTP behavior:

dig +short example.com A
dig +short example.com AAAA
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}n' 
nc -vz -w 3 example.com 443

These checks don't constitute a penetration test. They answer narrower operational questions: does the hostname resolve to the intended protected edge, does IPv6 return a different path, and is the expected TCP service reachable? Run them for every documented endpoint, then compare the results with firewall and routing records.

The origin should not be easier to reach than the protected edge.

If curl exposes an origin address through headers, a separate hostname, or an overlooked IPv6 record, fix that path before tuning mitigation thresholds. Protection is only as complete as the least-protected route to the service.

Choosing Protection by Business Impact Instead of Tbps

Peak capacity is an incomplete buying criterion. A large network flood may be harmless to a business with a resilient edge, while a smaller HTTP attack can disable checkout, authentication, or an internal API.

A 2025 Radware and Osterman Research survey estimated average application-DDoS downtime at $6,106 per minute. Its respondents estimated losses below $500 per minute in 20% of cases, while 13.4% estimated at least $20,000 per minute in the survey report. Those ranges point to a better decision process than comparing advertised terabits.

Choose against the business failure

Start with the service's recovery-time objective and revenue exposure. Add customer-support load, contractual penalties, regulatory consequences, and the cost of false positives. Then select the mitigation model that protects the resource that matters.

DNS dependency deserves special attention. Moving a zone or hostname to a mitigation layer can introduce resolver caching behavior and emergency routing complexity. TLS inspection adds certificate management and cryptographic workload. Emergency BGP changes require a tested rollback, not a document that nobody has executed.

Per-customer policy also changes the engineering problem. A few customer-specific rules can be manageable; many rules require automation, isolation, change control, and tenant-visible reporting. ARPHost's DDoS protection solutions are one option for teams that want hosting infrastructure with network protection and operational support rather than assembling every layer alone.

The final selection test is simple: can staff validate the design without causing downtime? The cited MazeBolt survey's 86% annual-or-less testing figure shows why a protection service that cannot be safely exercised becomes a presumed control rather than a demonstrated one.

Putting the Architecture Together in a Hosting Environment

A workable hosting design starts with an always-on protected edge in front of shared infrastructure. Edge ACLs remove spoofed and malformed traffic, firewalls enforce per-tenant thresholds, and application controls protect expensive HTTP paths. BGP-based on-demand scrubbing handles the tail events that would overwhelm the facility's normal transit capacity.

For dedicated hardware in a Tampa facility, the design also has to preserve local operational access. Multiple Tier-1 providers help avoid dependence on one carrier, N+1 power supports the physical platform, and 24/7 monitoring gives the team visibility into interfaces, routes, firewall state, and application symptoms. Those features don't stop an attack by themselves, but they make the response path less fragile.

Colocation customers should examine the ARPHost colocation service when they need facility access and a direct cross-connect to a mitigation provider. Workloads that need dedicated CPU and uplink headroom for local filtering can be evaluated through bare metal infrastructure. Teams that want runbook-driven escalation, patching, and operational ownership can review managed services.

The clean traffic path should be explicit:

Internet clients
      |
Protected edge, anycast or upstream scrubbing
      |
Clean transit, GRE or direct return path
      |
Facility edge ACLs and routers
      |
Tenant firewalls and reverse proxies
      |
VMs, bare metal servers, DNS, mail, and APIs

A production checklist should include:

• Baseline metrics: Record bandwidth, packets per second, new flows, state usage, TLS handshakes, and HTTP request rates.
• Automated detection: Trigger edge mitigation without waiting for manual escalation.
• Endpoint inventory: Include DNS, mail, management, APIs, IPv6, and alternate tunnel paths.
• Tabletop validation: Exercise the routing and rollback procedure on a recurring schedule.
• After-action review: Record detection time, mitigation latency, false positives, affected tenants, and recovery steps.

The architecture works when each layer has a defined owner and a known failure boundary. If a service can't be tested, rolled back, or traced from public edge to origin, its protection is still an assumption.

ARPHost, LLC provides colocation, bare metal, VPS, Proxmox private clouds, secure web hosting, and managed IT with multi-layer DDoS protection, firewalls, and 24/7 monitoring. If you need help mapping public endpoints, upstream scrubbing, edge controls, and response runbooks, visit ARPHost, LLC to discuss the architecture.