DDoS Protection Architecture: Anycast Scrubbing, L3/L4 vs L7 Mitigation, Rate Limiting and Origin Shielding

The largest distributed denial-of-service (DDoS) attack Cloudflare has publicly reported peaked at 31.4 terabits per second and lasted 35 seconds. That pairing of size and brevity is the problem a modern ddos protection architecture has to solve. No human can open a ticket, page a network engineer and reroute traffic in 35 seconds. Either the defence is already in the path and acting automatically, or the attack is over before anyone notices which link saturated.

It matters now because the floor has risen, not just the ceiling. Cloudflare’s H1 2026 report counted 935 attacks above 1 Tbps in six months, most of them in Q2. Botnets of hijacked Android TVs and set-top boxes now produce volumes that exceed the total transit capacity of most enterprises and many regional providers.

You will leave with a layered reference architecture, a clear split between what the network edge and the application edge must each absorb, a working view of BGP-based controls such as Flowspec and remote-triggered blackholing, rate-limit design that survives real traffic, origin shielding that actually hides the origin, and a runbook.

What this covers: attack taxonomy with dated figures, anycast scrubbing versus on-demand diversion, L3/L4 versus layer 7 DDoS mitigation, HTTP/2 Rapid Reset, cloud-native tiers from AWS, Azure and Google, rate limiting, origin shielding, the autoscaling cost trap, failure modes and a runbook.

Context and Background

A DDoS attack exhausts a finite resource by sending more work than the target can process. The resource varies by layer. Volumetric attacks fill links measured in bits per second. Packet-rate attacks overwhelm router and NIC forwarding measured in packets per second. Protocol attacks exhaust state tables in firewalls, load balancers and TCP stacks. Application-layer attacks exhaust CPU, threads, database connections or upstream API quota with requests that look individually legitimate.

The numbers have moved fast. Cloudflare’s Q4 2025 threat report, published 5 February 2026, put the record at 31.4 Tbps and attributed the holiday-season campaign to the Aisuru-Kimwolf botnet, estimated at one to four million infected devices, mostly Android TVs. During that campaign it reported peaks of 24 Tbps, 9 billion packets per second and 205 million HTTP requests per second (Cloudflare Q4 2025 DDoS threat report). The same report counted 47.1 million DDoS attacks across 2025, an increase of 121 percent on 2024.

The H1 2026 report, published 11 August 2026, shows the mix shifting. Cloudflare counted 23.2 million network-layer attacks in the half, and DNS floods grew from 25.7 percent of network-layer attacks in Q1 to 40.0 percent in Q2, while CLDAP floods rose 580 percent quarter over quarter (Cloudflare H1 2026 DDoS threat report). It also reported that 90.6 percent of network-layer attacks ended within ten minutes and 96.62 percent stayed below 500 Mbps. Most attacks are small and short; a few are enormous and short.

The incumbent defences fall into three families. Network operators and scrubbing providers absorb volume with large anycast networks or diversion to scrubbing centres. Cloud providers bundle baseline protection into their edge and sell premium tiers with response teams and cost protection. Content delivery networks (CDNs) and web application firewalls (WAFs) defend layer 7. Our CDN architecture guide on edge caching, anycast and origin shield covers the delivery side of that third family.

My thesis is that most DDoS outages in 2026 are not caused by an attack exceeding a provider’s capacity. They are caused by the gaps between layers: an origin reachable around the CDN, a rate limit keyed on the wrong identity, an autoscaler that turns an attack into a bill, or a DNS record nobody moved behind the shield. Capacity is a procurement decision. Architecture closes the gaps.

DDoS Protection Architecture: The Layered Reference Design

Direct answer: A DDoS protection architecture is a layered set of controls that drops attack traffic as early and as cheaply as possible. Anycast edges or scrubbing centres absorb volumetric L3/L4 floods, stateless and stateful filters remove protocol abuse, an L7 tier with WAF, bot management and rate limiting handles request floods, and origin shielding ensures nothing reaches the origin except through those layers.

Figure 1: Layered DDoS protection architecture. Traffic enters an anycast edge, passes stateless L3/L4 filtering and stateful protocol checks, then an L7 proxy tier with WAF, bot scoring and rate limits, before reaching a shielded origin over an authenticated private path.

Read the figure top to bottom as a funnel. Each tier is cheaper per packet than the one below it and sees less traffic. Stateless filters at the edge can drop hundreds of millions of packets per second because they look at headers only. Stateful checks such as SYN cookies cost more per packet, so they run on what survives. The L7 tier terminates TLS and parses HTTP, which is orders of magnitude more expensive, so it must only see traffic that already passed the cheaper filters. The origin, the most expensive resource of all, sees only clean requests that reached it through an authenticated channel.

Anycast turns a global attack into many small local ones

Anycast means announcing the same IP prefix from many locations over the Border Gateway Protocol (BGP). Each client, legitimate or not, is routed to the topologically nearest announcement. A botnet whose devices are spread across hundreds of networks is therefore split across hundreds of points of presence (PoPs). Instead of one 30 Tbps flood against one data centre, each PoP sees its regional share.

A worked example shows why this matters, with illustrative numbers. Suppose a 24 Tbps attack is spread across 300 PoPs. If distribution were uniform, each PoP would see 80 Gbps, comfortably within a site provisioned with multiple 100 Gbps or 400 Gbps ports. Distribution is never uniform, because botnets cluster where vulnerable devices are common. If a quarter of the traffic originates in one country served by ten PoPs, those ten see 600 Gbps each. Anycast does not eliminate hot spots, but it converts a single impossible problem into a set of large but tractable ones.

Anycast also gives the defender a lever. An operator can withdraw a prefix from an overloaded PoP so traffic shifts to neighbours, or announce more specific routes to steer load. Our deep dive on DNS anycast, GeoDNS and global server load balancing covers the routing mechanics, and the BGP guide for cloud engineers explains route selection, which decides where attack traffic actually lands.

The limitation is that anycast distributes load according to routing, not according to attack intent. A single large source, such as one compromised cloud tenant with a fat pipe, lands entirely on one PoP. Anycast also breaks long-lived stateful protocols if routes flap mid-session, which is why anycast edges usually terminate connections and proxy them, rather than forwarding packets statefully to a single origin.

Always-on versus on-demand diversion

There are two ways to get traffic into scrubbing capacity. Always-on means the scrubbing network is permanently in the path: DNS points at the provider, or the provider announces your prefixes all the time. On-demand means traffic flows directly to you normally, and during an attack you or your provider divert it, usually by having the provider announce your prefix (often a more specific /24 for IPv4, the smallest prefix most networks accept) so the internet routes it to scrubbing centres. Clean traffic returns over a Generic Routing Encapsulation (GRE) tunnel or a direct interconnect.

On-demand looks cheaper and adds no latency in peacetime. Its weakness is time. Detection usually depends on flow telemetry such as NetFlow or IPFIX sampled at the edge, which typically needs tens of seconds to establish a baseline deviation. BGP propagation then needs seconds to minutes to converge globally. If an attack is over in 35 seconds, as the Cloudflare record was, on-demand diversion may activate after the damage is done, and repeated short bursts can keep you oscillating between modes.

Always-on adds a few milliseconds where the scrubbing site is not on the natural path and requires you to trust the provider with all your traffic, often including TLS termination for L7 services. For anything customer-facing on HTTP, always-on via a reverse proxy or CDN is the 2026 default. On-demand remains rational for whole-prefix protection of infrastructure that cannot be proxied: VPN concentrators, game servers, VoIP, and enterprise data centres where the provider only needs to see L3/L4 headers.

Drop at the cheapest layer that can still decide

The principle that organises the whole design is simple. Every packet should be dropped by the cheapest component that has enough information to classify it. A UDP packet from source port 389 arriving at a web server cannot be legitimate traffic to that server, so a stateless edge filter should drop it; parsing it later wastes capacity. A TCP SYN from a spoofed address can be neutralised by SYN cookies without holding state. An HTTP request with a valid TLS handshake, plausible headers and an abusive rate needs the L7 tier because no lower layer can see it.

Violating this principle produces the classic failure: the expensive layer becomes the bottleneck. A WAF that inspects traffic a router ACL could have dropped will fall over at a fraction of the edge’s capacity. Conversely, pushing L7 logic down to the network edge (for example, by blocking whole IP ranges because one URL is under attack) causes collateral damage to legitimate users behind carrier-grade NAT, where thousands of mobile users can share a single public IPv4 address.

L3/L4 vs L7 Mitigation: A Walk-Through by Layer

Different layers fail in different ways, so the mitigations differ in mechanism, cost and collateral damage. This section walks the stack from the wire upwards, then looks at the BGP controls operators use when scrubbing alone is not enough, and closes with capacity and cost.

Volumetric and reflection-amplification attacks

Reflection attacks exploit connectionless UDP services. The attacker sends small requests with the victim’s address forged as the source, and open servers send larger responses to the victim. The ratio of response size to request size is the amplification factor. CISA’s long-standing alert on UDP-based amplification (TA14-017A) lists bandwidth amplification factors of roughly 28 to 54 for DNS, about 556.9 for NTP’s monlist command, about 30.8 for SSDP, 46 to 55 for CLDAP, and 10,000 to 51,000 for memcached over UDP. Those factors explain why a modest botnet with spoofing capability can generate terabits.

Reflection traffic has a weakness: it is predictable. It arrives from well-known source ports (53 for DNS, 123 for NTP, 389 for CLDAP, 1900 for SSDP, 11211 for memcached) towards destinations that normally never receive unsolicited UDP from those ports. A web property that does not run a recursive DNS resolver has no reason to accept large UDP packets sourced from port 53. Stateless edge filters, matched on protocol, source port and packet size, drop this class at line rate. This is why Cloudflare’s H1 2026 shift towards DNS and CLDAP amplification does not change the defensive pattern; it changes which filters carry the load.

The strategic fix is upstream. Reflection only works because some networks still allow packets with forged source addresses to leave them. BCP 38 (RFC 2827) describes ingress filtering that drops such packets at the network edge. Every network that deploys it shrinks the attacker pool. As a defender you cannot force other networks to comply, but you can make sure your own cloud egress, data centre and customer edges do so. Your network should never be the reflector or the spoofing source in someone else’s incident.

Direct-path floods from botnets are harder. Aisuru-class botnets do not need reflection, because they control millions of devices with real addresses and real bandwidth. Their UDP floods often target random high ports with random payloads. Edge defences classify these by statistical fingerprints, such as payload entropy, fixed fields in packet generators, TTL distributions and per-source rate anomalies, then compile signatures into eXpress Data Path (XDP) or hardware filters. Our XDP and eBPF layer 4 load balancer deep dive explains why dropping in the NIC driver, before the kernel allocates a socket buffer, is what makes filtering at billions of packets per second economically possible.

Protocol attacks: SYN floods and state exhaustion

A TCP SYN flood sends connection requests and never completes the handshake. A naive server allocates state for each half-open connection and runs out of backlog. The standard mitigation is SYN cookies, described in RFC 4987, “TCP SYN Flooding Attacks and Common Mitigations”. With SYN cookies the server encodes the connection parameters into the initial sequence number of its SYN-ACK and keeps no state. Only when the client’s final ACK returns the cookie does the server allocate a connection.

SYN cookies trade state for computation and lose some TCP options, which matters less now that most stacks encode window scaling and SACK hints in the timestamp field. The real gotcha is that SYN cookies protect the endpoint that generates them. A stateful firewall or load balancer in front of the server can still exhaust its own connection table. In a layered design the anycast edge or the L4 load balancer generates the cookies and only forwards connections that completed the handshake. Variants such as ACK floods, RST floods and SYN-ACK reflection target the same state tables and need connection-tracking-aware filters that can drop packets belonging to no known flow without creating flow state for them.

Protocol attacks also hit stateful middleboxes in less obvious ways. A NAT gateway or cloud firewall with per-flow state has a finite table, and a flood of unique 5-tuples fills it even at modest bandwidth. Teams often discover this limit the first time an attack lands on a path that bypasses the scrubbing tier.

Figure 2: Where each class of attack is decided. Reflection and malformed packets are dropped statelessly, SYN-class floods are absorbed by cookies at the edge, and only completed, decrypted HTTP reaches the layer 7 DDoS controls of WAF rules, bot scoring, challenges and rate limits.

Figure 2 is the decision flow behind the funnel in Figure 1. The important property is that each decision point has a fallback that fails safe for availability: unknown UDP to a web-only prefix is dropped, unknown TCP is cookie-challenged, and unknown HTTP clients are scored and either challenged or rate-limited rather than blocked outright.

BGP tools for operators: RTBH and Flowspec

When an attack exceeds the capacity of your own links, filtering on your side of the link is too late. The link is already full. You need your upstream provider to drop traffic before it reaches you, and BGP offers two standardised ways to ask.

Remote-triggered blackhole (RTBH) routing lets you announce a host route, such as a /32, tagged with a community that tells the upstream to discard all traffic to it. RFC 7999 reserves the well-known BLACKHOLE community, 65535:666, for this purpose, and RFC 5635 describes the destination- and source-based RTBH techniques, the latter combined with unicast reverse path forwarding. RTBH is blunt. It completes the attack on the targeted address, because legitimate traffic is dropped too, but it saves every other customer and service behind the same link. Use it to sacrifice one IP to save the network, not as a mitigation for a service you need to keep online.

BGP Flow Specification, currently RFC 8955 for IPv4 (which obsoleted RFC 5575 and RFC 7674) and RFC 8956 for IPv6, is the precise tool. A Flowspec rule carries match criteria (destination prefix, source prefix, protocol, ports, packet length, TCP flags, fragment bits) and an action such as discard or rate-limit to a byte rate. You can tell an upstream to drop UDP from source port 123 towards one prefix, while leaving TCP 443 alone. Providers that accept customer Flowspec usually validate that the destination falls within your own prefixes and cap the number of rules.

Flowspec has known sharp edges. Rules are installed in router hardware, whose filter capacity is limited and varies by platform. A badly formed rule can drop far more than intended, and there have been real-world outages caused by Flowspec rules propagating where they should not. Treat Flowspec as code: generate rules from a reviewed template, scope every rule to your own prefixes, set expiry, and test on a lab router before production.

For cross-organisation signalling, the IETF DDoS Open Threat Signaling (DOTS) work defines a standard protocol for a customer to request mitigation from a provider: RFC 8811 describes the architecture, RFC 9132 the signal channel (which obsoleted RFC 8782) and RFC 8783 the data channel. Adoption is uneven, so verify that your provider actually supports it before designing around it.

Layer 7 DDoS: when every request looks legitimate

Application-layer attacks send valid HTTP requests over completed TLS sessions. Nothing at L3/L4 distinguishes them from customers. The cost asymmetry is reversed compared with volumetric attacks: a request costs the attacker microseconds but can cost the origin a database query, a template render and a call to a third-party API. A layer 7 DDoS of a few hundred thousand requests per second against an uncached search endpoint can take down an origin that would shrug off a terabit UDP flood at the edge.

HTTP/2 made this worse in a specific way. HTTP/2 Rapid Reset, tracked as CVE-2023-44487 and disclosed on 10 October 2023, abused stream cancellation. A client opens a stream, sends a request, and immediately sends RST_STREAM. The cancelled stream no longer counts against the server’s concurrent-stream limit, so the client can issue requests at a rate bounded only by its bandwidth, while the server still does work for each one. Google reported a peak of 398 million requests per second, Cloudflare about 201 million and AWS about 155 million, in coordinated disclosures that day. Cloudflare noted that its attack came from a botnet of roughly 20,000 machines, which shows how much leverage a protocol flaw provides.

The fix was not a WAF rule. It was a change in HTTP/2 server implementations to track cancelled streams and close connections that reset too often. In August 2025, researchers disclosed MadeYouReset (CVE-2025-8671), a variant in which the attacker tricks the server into resetting streams by sending malformed frames, again bypassing concurrency accounting in vulnerable implementations. The lesson for architecture is that protocol-level L7 DDoS defences live in the proxy software, so patch velocity on your edge proxies is a DDoS control. Our QUIC and HTTP/3 deep dive shows how HTTP/3 moves stream management into QUIC, which has its own stream-limit and amplification-limit rules that deserve the same scrutiny.

Request floods without a protocol flaw are handled by a combination of controls. Caching removes origin cost for anything cacheable. Bot management scores clients on TLS and HTTP fingerprints, header order and behaviour. Challenges, ideally non-interactive proof-of-work or browser-integrity checks rather than CAPTCHAs, raise the cost per client. Rate limits cap what any one identity can do. Our OWASP API Security Top 10 and WAF architecture guide covers the WAF and bot-mitigation side in detail; here the focus is how those pieces sit inside the DDoS funnel.

Rate limiting that survives a real attack

Rate limiting is the last generic control before the origin, and the most commonly misconfigured. Three design choices decide whether it helps.

The first is the algorithm. A fixed-window counter is cheap but allows a burst of twice the limit across a window boundary. A sliding-window log is exact but stores a timestamp per request. Token bucket and its equivalent, the generic cell rate algorithm (GCRA), store one or two numbers per key and allow a controlled burst followed by a sustained rate, which matches how real clients behave. Our distributed rate limiting architecture guide compares these with Redis and Envoy implementations.

The second is the key. Keying on client IP alone fails in both directions. It punishes thousands of legitimate users behind one carrier-grade NAT or corporate proxy, and it barely slows a botnet of a million residential addresses that each send a few requests per minute. A 1 million-device botnet sending one request every 10 seconds per device produces 100,000 requests per second while staying under almost any per-IP limit. Better keys combine identity signals: an API key or session token where one exists, a TLS or HTTP fingerprint, the autonomous system number (ASN), and the target path. Rate limits per path matter because the expensive endpoints, such as search, login, checkout and report generation, need much tighter budgets than static pages.

The third is where the counter lives. A rate limiter enforced per edge server with local counters is fast and resilient but lets a distributed attacker get the limit multiplied by the number of servers. A globally synchronised counter is accurate but adds a network hop and becomes a dependency that can itself fail under load. The practical compromise is local enforcement with periodic aggregation, accepting some overshoot, plus a global circuit breaker on the origin side: an admission controller that sheds load when origin latency or queue depth crosses a threshold, regardless of who is asking.

Origin shielding: closing the bypass

Every layer above is worthless if the attacker can reach the origin directly. Origin shielding has two meanings that are often confused. In CDN terminology, an origin shield is a designated mid-tier cache that collapses cache misses from many edge PoPs into a single request to the origin. In DDoS terms, shielding means cloaking: making the origin unreachable except through the protection layer. A sound design needs both.

Figure 3: Origin shielding in two senses. Edge PoPs funnel misses through a shield tier to collapse load, and the origin accepts connections only from the provider over an authenticated tunnel or mutual TLS, so a leaked IP address leads nowhere.

Cloaking fails through leaks. The origin’s IP appears in historical DNS records, in mail headers when the application server also sends email, in TLS certificate transparency logs if the origin has its own public certificate for the same hostname, in subdomains such as dev or ftp that were never moved behind the proxy, or in server-side request forgery responses. Attackers routinely search these sources. Once they find the origin, they attack it directly and the scrubbing contract never sees a packet.

Hardening follows from the leak list. Rotate origin IPs when moving behind a protection provider, because the old ones are already known. Restrict inbound traffic at the network layer to the provider’s published ranges, but recognise that IP allow-listing alone is weak if another customer of the same provider can send requests through the same edge to your origin. Stronger options are authenticated origin pulls with mutual TLS, a provider-specific header with a secret value checked at the origin, or an outbound-only tunnel from the origin to the provider so the origin needs no inbound public listener at all. In cloud deployments, putting the origin load balancer on private addressing and connecting it through the provider’s private connectivity removes the public target entirely.

Cloud-native protection tiers in 2026

The three hyperscalers bundle baseline L3/L4 protection with their edges and sell premium tiers. The details below are from each provider’s documentation as checked in November 2026; prices change, so confirm them before budgeting.

Provider	Baseline tier	Premium tier	Notable premium features
AWS	Shield Standard, no additional cost for all customers	Shield Advanced, from 3,000 USD per month with a 1-year commitment, plus data transfer out fees	24/7 Shield Response Team access, DDoS cost protection, AWS WAF requests up to 50 billion per month included; requires Business or Enterprise support
Azure	Platform-level infrastructure protection	DDoS IP Protection, priced per protected IP; DDoS Network Protection, priced per 100 protected IPs	Network Protection adds rapid response support, cost protection and a WAF discount; IP Protection does not
Google Cloud	Cloud Armor Standard, pay per policy, rule and request, always-on L3/L4 protection, Adaptive Protection in alerting-only mode	Cloud Armor Enterprise Paygo, 200 USD per project per month; Enterprise Annual, 3,000 USD per month per billing account with a 12-month commitment	Full Adaptive Protection, advanced network DDoS protection for pass-through endpoints; Annual adds DDoS response support and bill protection

Sources: AWS Shield pricing, Microsoft Learn’s Azure DDoS Protection tier comparison, and Google Cloud Armor Enterprise overview.

Two patterns stand out. First, each premium tier sells the same three things beyond technology: a human response team, cost protection against scaling charges caused by an attack, and tighter integration with the provider’s WAF. Second, each tier protects resources inside that provider. A multi-cloud estate needs either a premium tier per cloud or a provider-neutral edge in front of all of them.

Capacity planning and the autoscaling cost attack

Capacity planning for DDoS starts with an uncomfortable fact: you cannot buy enough bandwidth to absorb a 2026-class attack on your own links. The 31.4 Tbps record is tens of thousands of times larger than a typical enterprise 1 Gbps internet link. Owned capacity should be sized to survive the small, frequent attacks that make up most of Cloudflare’s counts, and the edge provider should absorb everything else.

The less obvious threat is economic. In an elastic architecture, an L7 flood that passes the edge does not take the service down. It scales it up. Consider an illustrative case: a service that normally runs on 20 instances and scales on CPU receives a slow-rate flood of uncacheable search requests. The autoscaler adds instances to keep latency within target, reaching a configured maximum of 400. At an assumed 0.20 USD per instance-hour, the extra 380 instances cost 76 USD per hour, or about 1,824 USD per day, before database, egress and logging costs. A week-long low-intensity campaign can cost more than an annual premium DDoS tier, without ever triggering an outage alarm.

This is sometimes called economic denial of sustainability. The defences are architectural: set hard maximums on autoscaling groups and serverless concurrency; alert on cost and request-mix anomalies, not just on errors; put rate limits and caching in front of anything that scales automatically; and understand exactly what your provider’s cost protection covers, because it typically requires a claim, an attack confirmed by the provider and specific protected resources.

A DDoS Mitigation Runbook That Works in 35 Seconds

A DDoS runbook has two clocks. The machine clock runs in seconds: automated detection and mitigation must act before a human has read the alert. The human clock runs in minutes: people confirm impact, tune what the automation missed, communicate and escalate. Designing the runbook means deciding which actions belong on which clock.

Figure 4: DDoS mitigation runbook as a sequence. Automated edge mitigation acts first, the on-call engineer verifies impact and tunes L7 rules, the provider response team is engaged for sustained or novel attacks, and BGP controls are the last resort.

The machine clock covers everything that can be decided from traffic shape alone. Edge signature generation, SYN cookie activation, adaptive L7 rules that the provider proposes and auto-deploys, and origin-side load shedding all belong here. If your design requires a human to approve any of these during an attack, you have accepted an outage of at least your paging latency.

The human clock starts with a single question: are users affected? Many attacks are fully absorbed and need nothing but a log entry. If users are affected, the on-call engineer identifies which layer is hurting, using a short checklist. Is an upstream link saturated? Is the origin’s CPU or database saturated? Are errors coming from the edge (for example 5xx from a proxy that cannot reach the origin) or from the origin itself? Each answer maps to a different action: a link problem points to scrubbing diversion or Flowspec, an origin problem to tighter L7 rules, caching or emergency challenge mode, and an edge problem to the provider.

Escalation paths must be prepared before the incident. That means having provider response-team contacts and the account identifiers they need, pre-authorised Flowspec templates, a known procedure for switching DNS or BGP to on-demand scrubbing, and a pre-written status page message. One mitigation deserves a special warning: switching a whole site into an interactive challenge mode protects the origin but breaks API clients, webhooks and mobile apps that cannot solve challenges. Scope emergency challenges to browser paths, and keep machine-to-machine traffic on authenticated rate limits.

Drills close the loop. Several providers allow authorised DDoS simulation against your own assets under specific rules of engagement, and testing without following those rules can breach terms of service. The goal of a drill is not to see whether the provider can absorb volume. It is to find the bypasses: the forgotten DNS record, the API host not behind the proxy, the rate limit that blocks the payment partner.

Trade-offs, Gotchas, and What Goes Wrong

Collateral damage from coarse controls. Geoblocking, ASN blocking and RTBH all work by sacrificing legitimate traffic. A geoblock during an attack sourced from one country cuts off real customers and travellers there. Blocking a large mobile carrier’s ASN can block a meaningful share of your actual users. Prefer controls that raise cost for suspicious clients, such as challenges and tighter rate limits, over controls that refuse whole populations.

False positives in adaptive mitigation. Machine-learned L7 defences, such as Google’s Adaptive Protection or equivalent features from CDN providers, propose rules from traffic baselines. A legitimate flash crowd from a product launch, a ticket sale or a viral link looks statistically similar to a request flood. Review auto-deployed rules during known events, and give marketing a way to warn the platform team before traffic spikes.

TLS and privacy trade-offs. Layer 7 DDoS mitigation needs to see plaintext HTTP, so the provider terminates TLS. That has compliance implications for regulated data and requires managing certificates or keys at the provider. Keyless or split-key options exist at some providers; evaluate them if key custody matters to you.

Stateful devices in the wrong place. On-premises firewalls, intrusion prevention systems and load balancers with connection tables are frequently the first thing to fall over in a protocol attack, often before the link saturates. Place them behind the scrubbing layer, or ensure the edge drops spoofed and incomplete flows before they create state.

DNS as the forgotten target. Cloudflare’s H1 2026 data shows DNS floods rising sharply as a share of network-layer attacks. If your authoritative DNS is a single provider with no DDoS protection, an attack on DNS takes down every service that depends on name resolution, however well each one is shielded. Use an anycast authoritative DNS provider, consider a secondary provider, and keep TTLs sensible for the records you may need to change during an incident.

On-demand diversion latency and route leaks. On-demand protection depends on BGP behaving. More-specific announcements can be filtered by networks that enforce strict prefix-length or RPKI policies if you have not created matching route origin authorisations for the scrubbing provider’s announcements. Test diversion under calm conditions at least twice a year.

Contract fine print. Cost protection, response-team service-level objectives and the definition of a qualifying attack vary. Read what triggers a credit, how quickly it must be claimed, and whether it covers the scaling resources you actually use.

Practical Recommendations

Start from your traffic types. HTTP and API traffic should sit behind an always-on reverse proxy or CDN with L7 controls. Non-HTTP services that cannot be proxied need either a provider’s L4 proxy (for TCP and UDP) or prefix-level scrubbing with on-demand or always-on BGP diversion. Infrastructure such as DNS should use an anycast provider built for that protocol.

Then close the gaps, which is where most real outages come from. Inventory every public hostname and IP, confirm each one is behind the protection layer, and lock the origin so it accepts only authenticated connections from the provider. Design rate limits per expensive path and per identity, not just per IP. Cap autoscaling. Finally, rehearse the runbook so that the first time someone switches on diversion or deploys a Flowspec rule is not during a real attack.

A short checklist:

Every public DNS record and IP address is inventoried and behind the protection layer, with no exceptions for dev, staging or mail.
The origin accepts traffic only via mutual TLS, a tunnel, or private connectivity from the provider; old origin IPs have been rotated.
Stateless edge filters drop UDP reflection ports that your services do not use.
L7 rate limits exist per expensive endpoint, keyed on session, API key or fingerprint plus IP.
Autoscaling and serverless concurrency have hard maximums and cost-anomaly alerts.
HTTP/2 and HTTP/3 edge proxies are on versions patched for Rapid Reset and MadeYouReset.
Authoritative DNS is anycast and protected; a secondary provider is evaluated.
Provider response contacts, Flowspec templates and diversion steps are documented and drilled.
RPKI route origin authorisations cover any prefixes a scrubbing provider may announce for you.

Frequently Asked Questions

What is the difference between L3/L4 and layer 7 DDoS mitigation?

L3/L4 mitigation works on packet headers: IP addresses, protocols, ports, flags and sizes. It drops volumetric floods, reflection traffic and SYN floods cheaply at the network edge, often in hardware or XDP. Layer 7 DDoS mitigation works on decrypted HTTP requests and must decide whether a valid-looking request is abusive, using WAF rules, bot scoring, challenges and rate limits. L3/L4 controls protect bandwidth and state tables; L7 controls protect application CPU, databases and upstream APIs. A complete architecture needs both.

How does anycast scrubbing stop a DDoS attack?

Anycast scrubbing announces your IP prefixes from many locations, so BGP routes each attacking device to its nearest scrubbing site. A global botnet’s traffic is split across dozens or hundreds of sites, each of which filters its share and forwards only clean traffic to you. Anycast does not filter anything by itself; it distributes load so filters are not overwhelmed. Hot spots still occur where botnet devices cluster, which is why providers also shift load by withdrawing or adjusting announcements.

Is cloud-provider baseline DDoS protection enough?

Baseline tiers such as AWS Shield Standard and Cloud Armor Standard protect against common L3/L4 attacks on the provider’s edge at little or no extra cost, and they are enough for many workloads. They do not include a dedicated response team, cost protection against attack-driven scaling, or the advanced L7 tooling of premium tiers. Whether premium tiers are worthwhile depends on revenue at risk, attack history and how much L7 exposure you have. Check current tier features in each provider’s documentation.

What is origin shielding and why does it matter for DDoS?

Origin shielding has two meanings. In CDNs it is a mid-tier cache that collapses edge cache misses into fewer origin requests, reducing load. In DDoS defence it means cloaking the origin so it is reachable only through the protection provider. The second meaning is critical: if attackers discover the origin IP through old DNS records, mail headers or forgotten subdomains, they bypass the entire protection layer. Lock origins with mutual TLS, tunnels or private connectivity, and rotate exposed IPs.

Should I use RTBH or Flowspec during an attack?

Use Flowspec when you can describe the attack precisely, for example UDP from source port 123 towards one prefix, and your upstream accepts customer rules. It drops attack traffic while keeping legitimate traffic flowing. Use remote-triggered blackholing, signalled with the BLACKHOLE community from RFC 7999, only when one address is under attack and its traffic threatens the rest of your network. RTBH drops all traffic to that address, so it saves neighbours by sacrificing the target.

How do I stop a DDoS attack from inflating my cloud bill?

Treat cost as a failure mode. Set hard maximums on autoscaling groups and serverless concurrency, cache and rate-limit expensive endpoints in front of anything elastic, and alert on cost anomalies and request-mix shifts as well as errors. Premium tiers from AWS, Azure and Google include forms of DDoS cost protection or credits, but each has eligibility conditions, claim processes and covered resources. Read the terms before an incident so you know what will and will not be credited.

DDoS Protection Architecture: Anycast Scrubbing, L3/L4 vs L7 Mitigation, Rate Limiting and Origin Shielding (2026)