DDoS protection architecture: a layered design guide

The hard part isn't picking a vendor; it's deciding where detection ends and absorption begins, and how fast rerouting happens when it matters. This guide breaks down the mitigation lifecycle, reference topologies, and sizing decisions that separate a resilient architecture from a checklist of tools.

What is a DDoS protection architecture?

A multi-tiered mitigation architecture combines defenses against volumetric, protocol, application-layer, and reflection/amplification attacks across network layers, instead of pointing one appliance at everything and hoping it scales. Point solutions fail predictably: a single inline box sized for average traffic saturates the moment a volumetric flood exceeds its packet-per-second ceiling, and by the time someone reroutes traffic manually, the attack has already achieved its goal.

Application-layer defenses matter just as much here, since protecting APIs from evolving threats requires the same layered mindset as network-level mitigation.

Sizing scrubbing capacity is a first-order design decision, not an afterthought: an on-prem appliance sized to average traffic can hit its packet-per-second ceiling within seconds of a volumetric spike, long before a human notices. Netscout's 2024 DDoS Threat Intelligence Report recorded over 7 million attacks globally in the first half of 2024 alone, which is why detection-to-mitigation speed, not just peak capacity, drives architecture choices below.

The four categories of DDoS attacks your architecture must handle

Four attack categories hit different layers of your stack, and each needs a distinct control rather than a bigger version of the same appliance.

According to Netscout's 2025 DDoS Threat Intelligence Report, reflection and amplification techniques remained a dominant volumetric attack vector through 2024, with DNS and NTP amplification factors capable of multiplying a single spoofed packet many times over on the wire.

Azure DDoS Protection applies this same split inside a virtual network: its always-on detection tier absorbs volumetric and protocol floods, while a separate Layer 7 WAF tier handles application-layer abuse that volume-based filtering never sees. A large SYN flood is exactly the scenario that split is built for: the detection tier has to absorb it at the network layer before it ever reaches a compute resource that could otherwise be saturated in seconds.

Rate limiting alone would not touch that kind of flood.

Building a multi-tiered mitigation stack: L3/L4, L7, and DNS

A multi-tiered mitigation stack pairs three independent controls, each sized for a different failure mode: a scrubbing center absorbing volumetric floods, a Layer 7 web application firewall filtering malicious requests that look legitimate at the packet level, and a content delivery network (CDN) that caches and reroutes traffic before it ever reaches origin.

These network-layer controls work best as one piece of a broader application security lifecycle that also addresses code-level vulnerabilities and secure development practices.

The sequencing matters more than the tools you pick.

Detect at the edge, absorb in the CDN's cache layer, filter through the web application firewall, then reroute survivors to a scrubbing center sized for your worst plausible burst, not your average day. Each tier needs its own resources and its own failure budget; when one is enabled, the others should degrade gracefully rather than fail closed.

A common sizing baseline is a scrubbing center provisioned at roughly 3x historical peak ingress, modeled against a reflection/amplification scenario and the CDN's own absorption ceiling. The gap between average and worst-case traffic is where most under-provisioned architectures fail.

Teams rebuilding infrastructure to handle heavier, less predictable traffic should map each tier against real traffic logs, not a vendor's default sizing template, before committing to a topology.

Azure's DDoS Protection Standard reference architecture builds this hierarchy directly into the virtual network layer. Network-layer protection sits in front of application-layer rules, so a volumetric attack never reaches the compute tier that would otherwise need to autoscale. An architecture diagram of this setup typically shows public IPs behind a virtual network with network protection enabled, catching floods before they hit the application gateway.

If you are provisioning this yourself, confirm DDoS protection enabled status at the subscription level, not just the resource group; a single unprotected public IP undermines the whole stack. Azure DDoS Protection documentation walks through the same detect-absorb-filter-reroute sequence for virtual network deployments, with configuration information for each tier.

Hyper-volumetric attacks exceeding 1 Tbps have become a recurring occurrence in the DDoS landscape rather than an anomaly, per Netscout's 2025 DDoS Threat Intelligence Report.

That single data point argues for scrubbing capacity headroom over a purely reactive plan, since manual BGP blackholing decisions cannot execute fast enough against sub-minute floods. Using automated failover between tiers, rather than manual escalation, is what separates architectures that survive from ones that see extended outages.

The mitigation lifecycle: Detect, absorb, filter, reroute

The mitigation lifecycle runs in a fixed order, detect, absorb, filter, reroute, because skipping a stage breaks the one after it. Detect late and absorption starts overloaded. Filter before absorbing and the web application firewall drops legitimate requests along with the flood.

Detect. Anomaly detection against a live traffic baseline, not static thresholds. According to Netscout's 2025 DDoS Threat Intelligence Report, median attack duration fell under 10 minutes in H2 2024, detection has to trigger inside 60-90 seconds or the DDoS attack is over before mitigation starts.

Absorb. A scrubbing center takes the volumetric hit first, and this is why scrubbing-then-forward beats an always-on inline appliance for burst traffic. Inline hardware sized for sustained load either sits idle most of the year or falls over at the peak. Scrubbing capacity scales elastically, then forwards clean traffic toward the origin network.

Filter. With volume under control, the Layer 7 web application firewall inspects what remains, application-layer floods and protocol abuse that look legitimate at the packet level and require deeper request inspection, not more bandwidth. This step depends on knowing your application's underlying architecture, since request inspection is only as effective as the visibility it has into how the app's components and APIs are structured.

Reroute. BGP blackholing is the last resort: an upstream router drops all traffic to a targeted IP, trading availability on that address for network protection of everything else behind it. Setting the blackholing trigger well above the legitimate traffic baseline, rather than at a round number, is what keeps this stage from firing on ordinary spikes.

Of the four stages, absorb is the one that deserves the largest share of the budget: it's the stage that decides whether reroute ever triggers at all.

Azure DDoS Protection documents a comparable tiered response for virtual network deployments behind a hub-and-spoke topology, and it is worth reading the reference architecture on Microsoft Learn before assuming your Azure DDoS setup needs a separate scrubbing contract on top.

Cloud reference architectures: AWS, Azure, and Cloudflare compared

AWS Shield, Azure DDoS Network Protection, and Cloudflare Magic Transit solve the same problem, absorbing volumetric and protocol floods before they reach compute, with three different blast-radius models. The choice changes your mitigation capacity sizing, not just your vendor bill. These volumetric and protocol-layer defenses typically sit alongside layer 7 WAF protection to cover the application-layer attacks that slip past network-level scrubbing.

Azure's hub-and-spoke model trades a few milliseconds of added routing latency versus a flat topology for a real operational win: consolidating detection into one perimeter instead of per-VPC rules cuts incident response time by removing the need to correlate alerts across every workload separately. Ask which model your traffic actually needs before comparing sticker price.

Protecting DNS infrastructure with anycast

Anycast DNS rewrites the blast radius math for reflection and amplification attacks. With unicast, every query for a zone resolves to one physical location, so a 300 Gbps reflection flood lands entirely on that box. Anycast advertises the same IP from dozens of points of presence via BGP, so the same flood splits across every site advertising the route, the attacker's volume gets divided by your PoP count, not multiplied by it.

Migrating authoritative DNS from a two-datacenter unicast setup to an anycast provider is a common response to exactly this failure mode: a single-site outage that takes resolution down entirely during a UDP reflection attack. Post-migration, the same attack class gets absorbed with no measurable resolution latency at any PoP, since the flood is now spread across every site advertising the route instead of landing on one box.

Anycast doesn't replace scrubbing or a web application firewall for application-layer attacks against DNS-over-HTTPS endpoints, it changes where the flood lands, not whether it needs filtering.

Hub-and-spoke topology for centralized DDoS defense

Hub-and-spoke network topology centralizes DDoS protection at one choke point instead of duplicating scrubbing capacity in every application team's virtual network. Spoke virtual networks route north-south traffic through the hub, where a scrubbing service inspects volumetric, protocol, and application-layer traffic before it reaches a workload.

Microsoft's own Azure hub-and-spoke reference architecture, documented on Microsoft Learn, recommends this pattern because one Azure DDoS Protection policy at the hub covers every spoke without redeploying appliances per network.

The tradeoff is latency, not resilience. Every packet takes an extra hop through the hub. Sizing the hub's scrubbing tier against actual attack history, sustained and burst capacity both, is what determines whether that extra hop buys a single auditable enforcement point across every spoke network or just adds latency without a matching security payoff.

For most business applications that trade is worth it. For latency-sensitive real-time systems, ask whether a mesh with local scrubbing beats forcing every packet through a single hub.

DDoS protection for Kubernetes and serverless workloads

Kubernetes ingress and serverless triggers move the attack surface from the network edge to the API gateway, and that breaks the assumption behind appliance-based scrubbing. A10 Thunder TPS and similar inline appliances protect VM-backed network segments; they have no natural insertion point in front of a Lambda function or an EKS ingress controller.

For PaaS and serverless, the fix is routing through cloud-native scrubbing and a Layer 7 web application firewall ahead of the API gateway, then letting a service like Imperva DDoS Protection handle the detect-absorb-filter-reroute cycle at the application layer rather than the network layer. Sizing shifts too: instead of provisioning Gbps scrubbing capacity, size for requests-per-second and concurrent connection limits on the gateway, since Netscout's 2024 threat report found application-layer attacks now account for a growing share of incidents versus pure volumetric floods.

For organizations without in-house expertise to manage this shift, Netguru's cloud security services team can architect and build cloud-native DDoS mitigation tailored to serverless and PaaS environments.

Migrating from an appliance-based setup like EC2-with-A10 to an EKS ingress controller means replacing the appliance with gateway-level rate limiting entirely, since there's no equivalent insertion point for an inline box in front of Kubernetes ingress. The payoff is mitigation that reacts at request-level speed instead of needing a network-layer detection window to trigger first.

Sizing mitigation capacity and measuring DDoS resilience

Size scrubbing capacity against your observed peak legitimate traffic plus the largest attack volume your upstream carriers report seeing on comparable ASNs, not against a round number picked in a planning meeting. IoT-botnet-driven floods have demonstrated peak capacity as high as 30 Tbps (Netscout's 2025 DDoS Threat Intelligence Report), a scale no self-hosted appliance absorbs alone.

Modeling capacity against the client's own legitimate traffic ceiling and regional attack data, then measuring the actual time-to-mitigate from detect to filter during the first live incident, is what turns a sizing decision into a verified one. That measured number, not the vendor's marketing sheet, should become the acceptance criterion.

Measuring DDoS resilience means tracking three figures across the mitigation lifecycle: detection latency, time-to-mitigate, and false-positive rate on legitimate traffic. Akamai Prolexic publishes SLA-backed mitigation times that make a useful benchmark when negotiating your own contract. Azure DDoS Protection on a virtual network gives comparable telemetry natively; ask your Azure quickstart docs which metrics are exposed before you build custom dashboards.

Whichever vendor you pick, resilience is a measured property, not an assumed one.

Best-practices checklist for a DDoS-resilient architecture

A DDoS-resilient architecture checklist works only if every item maps to a layer of the mitigation lifecycle, not a generic security control. Use this as a pre-launch audit, not a wish list.

• CDN in front of every public endpoint. A content delivery network absorbs volumetric and reflection/amplification traffic at the edge, before it reaches origin compute.
• Rate limiting at both the CDN and application tiers. Layer 7 rate limiting stops credential-stuffing and slow-POST attacks that a network-layer scrubber never sees.
• Anycast DNS across at least two providers. Single-provider DNS is a single blast radius.
• BGP blackholing pre-arranged with your upstream carriers, tested annually, not just documented.
• Hub-and-spoke topology reviewed against your latency budget, added resilience costs real milliseconds at the spoke.
• Web application firewall rules versioned in the same repo as application code.
• Runbook aligned to detect-absorb-filter-reroute, referencing Azure DDoS Protection's reference architecture or an equivalent AWS Shield pattern for virtual network-specific controls.

CDN-tier rate limiting alone, without any scrubbing-center intervention, is often enough to cut a meaningful share of origin-facing attack traffic before it ever reaches the network-layer defenses.

FAQ: DDoS protection architecture questions

Get help designing your DDoS protection architecture

A multi-tiered mitigation architecture only works if the tiering decisions match your actual traffic profile, not a vendor's default template. That's the gap most teams hit when they try to bolt Azure DDoS Protection or a scrubbing center onto an existing virtual network without rethinking the hub-and-spoke topology underneath it.

Before you can trust an architecture diagram, you need to see how it behaves under real load, not just on paper.

Our infrastructure engineers work through the same sizing decisions covered here: scrubbing capacity, BGP blackholing thresholds, and Layer 7 web application firewall rules, tuned against your actual traffic profile rather than a vendor's default template.

We typically start by reviewing where DDoS protection is already enabled across your resources, and where gaps exist between subnets that assume network protection enabled elsewhere in the stack. That mapping alone surfaces most of the risk.

If you're weighing managed protection against a self-hosted setup, or want a second look at your current response plan before the next attack tests it, get an estimate for your project. We'll help you ask the right questions using the information you already have, and learn where your architecture's actual blast radius sits.

If deeper, ongoing risk analysis is what you need, our risk management and threat modeling services can help you identify and mitigate vulnerabilities beyond DDoS-specific scenarios.