DDoS protection and a web application firewall (WAF) are often sold together and switched on from the same console, yet they defend different layers, so teams that assume one covers the other find out during an attack. Network DDoS protection absorbs and filters floods at layers 3 and 4 before they reach your infrastructure; a WAF inspects individual HTTP requests at layer 7 and decides whether each one is allowed. Application-layer floods sit in the gap between them and are where most real failures happen. This guide compares the two on layers covered, capacity, rate limiting, bot overlap and failure modes under layer 7 floods, then gives decision guidance, worked scenarios and a rollout order. It is written for network, platform and application security teams and for buyers weighing cloud bundles. It does not re-explain DDoS attack types: see the DDoS Protection Guide for that background.
Key takeaways
- Short answer: you need both if you publish web applications. DDoS protection keeps the pipe and the edge alive under volumetric and protocol floods; the WAF keeps the application alive under malicious or excessive HTTP requests. Neither does the other's job well.
- A WAF is not a capacity product. A WAF can only inspect traffic that reaches it. If it runs on your own appliance or in a single region, a volumetric flood saturates the link in front of it and its rules never get a chance to act.
- Network DDoS services do not read HTTP. Microsoft states that Azure DDoS Protection covers layers 3 and 4 and recommends adding a WAF for layer 7. Plan for that split whichever provider you use.
- Layer 7 floods are the shared weak point. Floods of valid-looking requests from many addresses defeat per-IP rate limits and signature rules. Defence needs edge rate limiting with tuned keys, challenge actions, caching and application-side limits together.
- Bundles simplify buying, not ownership. Cloud WAF plus DDoS packages put both layers at one edge, which is the right architecture for most, but someone still has to own thresholds, rule tuning and the response runbook.
The short answer
The joint CISA, FBI and MS-ISAC guide to DDoS groups attacks into three categories: volume-based floods that saturate bandwidth, protocol-based attacks against layer 3 and 4 weaknesses, and application-layer attacks against layer 7 services, and notes that the categories are not mutually exclusive. DDoS protection services are built for the first two. A WAF is built for request-level inspection, which is the only place layer 7 abuse can be recognised. ATT&CK models the split the same way: T1498 Network Denial of Service (with T1498.001 Direct Network Flood and T1498.002 Reflection Amplification) against the network, and T1499 Endpoint Denial of Service (including T1499.002 Service Exhaustion Flood and T1499.003 Application Exhaustion Flood) against services and applications.
The practical answer is placement rather than choice: put both at a globally distributed edge that has the capacity to absorb a flood, with the WAF evaluating requests only after network-layer scrubbing has removed packet floods.
Side-by-side comparison
| Dimension | DDoS protection | Web application firewall |
|---|---|---|
| Layers | L3 and L4 (volumetric and protocol floods); some services add L7 mitigation through an integrated WAF | L7 (HTTP and HTTPS requests after TLS termination) |
| Unit of decision | Packets, flows and traffic profiles per protected IP | Individual requests, matched against rules and rate counters |
| Capacity model | Provider network and scrubbing capacity, anycast, upstream filtering | Throughput of the WAF deployment; cloud edge WAFs inherit edge scale |
| Typical threats | UDP and reflection floods, SYN floods, protocol abuse | Injection, exploitation of known vulnerabilities, abusive request rates, some automated attacks |
| Rate limiting | Thresholds on packet and connection rates, often tuned automatically | Request rate rules keyed on IP, header, path, ASN, TLS fingerprint and similar |
| Detection | Deviation from learned traffic baselines | Signatures, managed rules, custom rules, request counts |
| False positive impact | Rare in normal operation; collateral blocking during mitigation | Common during tuning; blocks real users on a bad rule |
| Who owns it | Network or platform team, with the ISP or provider | Application security, with developers |
| Fails when | Attack is valid HTTP that looks like users | Traffic never reaches it, or volume exceeds its capacity |
DDoS protection in depth
Threat model
The attacker wants to exhaust a finite resource: link bandwidth, router or firewall state tables, or load balancer connections. Traffic often comes from botnets or from reflection off legitimate public servers, which the CISA guide notes makes source blocking unreliable. The target is availability, not data.
Architecture in words
Traffic for protected addresses is announced from many points of presence or diverted to scrubbing centres; malformed and flood traffic is dropped; clean traffic is forwarded. Cloud providers apply this automatically at their edge (platforms listed alphabetically):
- AWS Shield: Shield Standard is automatic and at no additional charge, defending against common network and transport layer attacks, with fuller coverage for Route 53 hosted zones, CloudFront distributions and Global Accelerator. Shield Advanced is a subscription that adds automatic application layer DDoS mitigation by inserting a rule group into the AWS WAF web ACL, and includes the Layer 7 Anti-DDoS managed rule group. See the AWS WAF and Shield Guide.
- Google Cloud Armor: always-on, inline protection against volumetric and protocol attacks for supported load balancers, dropping malformed traffic at Google's edge; the Enterprise tier adds layer 7 DDoS protection, Adaptive Protection that alerts on suspected layer 7 attacks and can suggest or apply rules, and network DDoS protection for network load balancers and VMs with public IPs. See the Google Cloud Armor guide.
- Microsoft Azure DDoS Protection: enabled on virtual networks (Network Protection) or per public IP (IP Protection), with machine-learned thresholds for TCP SYN, TCP and UDP policies on each protected IP and Azure Monitor alerts on attack start and stop; layer 7 is handed to a WAF. See the Azure Front Door and Application Gateway WAF Security Guide.
For on-premises and hybrid estates the equivalent is an ISP or specialist scrubbing service plus network techniques such as remote triggered black hole and BGP Flowspec: see the RTBH and BGP Flowspec DDoS Mitigation Guide.
Availability: each provider documents tier limits. AWS Shield Advanced, the Google Cloud Armor Enterprise tier and Azure DDoS Network Protection are paid; Azure's documentation states that rapid response support and cost protection come with Network Protection rather than IP Protection. Check the current tier pages before relying on any feature.
Failure modes
- Unprotected origin: the origin's real address is discoverable, so attackers bypass the protected edge and hit it directly.
- Partial coverage: protection enabled on the web front end but not on DNS, VPN gateways or APIs on separate addresses.
- Valid HTTP floods: traffic that completes TCP and TLS handshakes and sends well-formed requests passes network-layer filtering by design.
- Untested escalation: nobody knows how to engage the provider's response team or the ISP during an attack.
WAF in depth
Threat model
The attacker sends HTTP requests that exploit the application or exhaust it. That includes injection and known vulnerability exploitation (the WAF's original purpose), and request floods against expensive endpoints such as search, login, checkout or report generation, where a few thousand requests per second can exhaust backends that would shrug off far larger packet floods. The Denial of Service at Application Layer Guide covers how to bound that work inside the application.
Architecture in words
The WAF terminates TLS (or receives decrypted traffic), parses each request and evaluates an ordered rule set: managed signatures, custom match rules and rate rules. Google Cloud Armor's preconfigured WAF rules are based on the OWASP ModSecurity Core Rule Set, and the open source CRS underpins many other products. Deployment options are cloud edge (inherits provider scale), regional cloud load balancer, or self-managed appliance or module in front of the origin. Only the first has the capacity to sit in the path of a large flood.
Failure modes
- Saturated before inspection: a self-managed WAF behind a 10 Gbps link is irrelevant once the link is full.
- Rule set mismatch: signatures stop injection, not a flood of clean GET requests.
- Per-IP limits against distributed floods: thousands of sources each sending under the threshold pass every per-IP rule.
- Detection mode forever: rules left in count or log mode after tuning, so nothing is blocked during an attack.
- Origin bypass: as with DDoS protection, a reachable origin makes the WAF optional for the attacker.
Rate limiting: where the two meet
Rate limiting is the main WAF control against layer 7 floods, and its behaviour is documented in detail by each provider (listed alphabetically):
| Platform | Rate rule behaviour from the vendor documentation |
|---|---|
| AWS WAF rate-based rules | Evaluation windows of 60, 120, 300 (default) or 600 seconds; minimum limit of 10 requests; aggregation by IP, forwarded IP, a constant key or custom keys; optional scope-down statement; AWS notes the limit is applied near, not exactly at, the configured value. |
| Google Cloud Armor rate limiting | Throttle (deny excess for the interval) or rate-based ban (block the client for an extra ban period); intervals from 10 to 3,600 seconds; keys include IP, XFF_IP, header, cookie, path, region, ASN and JA3 or JA4 TLS fingerprints, up to three combined; 429 is the recommended deny status; thresholds are per region and approximate. |
| Microsoft Azure Front Door WAF rate limiting | Fixed windows of 1 or 5 minutes; per socket IP by default, with grouping by country or region, ASN, JA4 fingerprint or none in preview on Premium; Microsoft notes some requests above low thresholds (roughly under 200 per minute) can pass, and recommends sizing from at least a week of traffic and deploying in Log mode first. |
Three lessons hold across platforms. First, longer windows with the smallest acceptable threshold keep an attacker blocked longer once caught, a point Microsoft illustrates directly. Second, counting is approximate across edge servers, so rate rules are a flood control, not a precise quota. Third, keying only on IP fails against distributed floods: add rules keyed on path (for expensive endpoints), ASN (hosting networks your users do not use) or TLS fingerprint, and keep a per-IP rule alongside, because fingerprints change more easily than addresses. Application-side limits are still needed; see the Rate Limiting and API Abuse Guide.
Bot overlap
Most layer 7 floods are bot traffic, which is why WAF, DDoS and bot management products increasingly overlap. Challenge actions (JavaScript challenge, CAPTCHA) appear in all three cloud WAFs as alternatives to blocking. The CISA guide itself recommends CAPTCHA to distinguish humans from bots. Challenges filter unsophisticated flood tools cheaply but add friction and fail against automation that runs a real browser. Where the problem is sustained abuse of business logic rather than a flood, a dedicated bot management layer is the right tool: see Bot Management vs WAF.
Failure modes under layer 7 floods
| Flood pattern | Why DDoS protection misses it | Why a WAF may miss it | What works |
|---|---|---|---|
| Distributed GET flood on a cached page | Valid HTTP, normal packet profile | Each source under per-IP threshold | Serve from cache; edge absorbs it |
| Flood on an uncacheable expensive endpoint | Valid HTTP | Per-IP limits too loose for that path | Path-scoped rate rule with low threshold; challenge; application work limits |
| Login or search flood from residential proxies | Valid HTTP from many consumer addresses | IP and ASN keys look like real users | Fingerprint keys, challenges, bot management, application throttles per account |
| Protocol abuse such as HTTP/2 Rapid Reset (CVE-2023-44487) | Connections look legitimate at L4 | Abuse happens below request evaluation | Patch the HTTP/2 implementation; use edge services that mitigated it; CISA listed it as exploited in the wild |
| Slow request attacks holding connections | Low volume | Requests never complete for rule evaluation | Connection and header timeouts at the edge and origin |
When to choose which, and the bundle question
- Edge WAF with integrated DDoS (bundle): the default for internet-facing web applications and APIs. One edge absorbs the flood and inspects the requests. Confirm the origin accepts traffic only from the edge.
- Network DDoS service alone: fits non-HTTP services such as DNS, gaming, VPN and VoIP, where there is no layer 7 to inspect, and for protecting whole address ranges.
- WAF alone: acceptable only where the hosting platform already provides automatic network-layer protection and the WAF runs at that platform's edge. A self-hosted WAF with no upstream protection is an application control, not a DDoS defence.
- Separate specialist providers: large organisations with on-premises data centres often keep an ISP or scrubbing provider for the network layer and a cloud edge for web traffic. Map which addresses each covers.
- Small organisations: use the hosting or cloud provider's included network protection, put applications behind its edge WAF with managed rules and a default rate rule, and document the provider's escalation path.
- Large organisations: paid tiers with response team access, cost protection where offered, tuned rate rules per critical path, and quarterly testing.
Worked scenarios
Scenario 1, retailer during a sale. A retailer's site sits behind a cloud edge with network protection and a WAF in detection mode. A distributed flood targets the search endpoint at a rate each address keeps under 100 requests per five minutes. Network protection sees nothing abnormal; the WAF's only rate rule is per IP at 2,000. Search backends fail. The fix: a path-scoped rule for search with a low threshold and a challenge action, an ASN rule for hosting networks, caching of popular queries, and moving tuned rules into blocking mode before trading peaks.
Scenario 2, regional council with on-premises services. A council hosts its portal on premises behind a self-managed WAF. A reflection flood fills the 1 Gbps link and the WAF never sees a request. The fix is upstream: an ISP scrubbing service or moving the portal behind a cloud edge, with the WAF retained for application rules. The DDoS Response Playbook covers the escalation steps.
Where identity fits
Rate rules and DDoS settings are changed through provider APIs and consoles, often by automation using API tokens. A compromised token can switch rules to count mode or disable protection immediately before an attack. Scope those credentials narrowly, require approval for changes to protection policies, and alert on them. See Securing the WAF.
Rollout approach
- Inventory: list every internet-facing address and hostname, including DNS, APIs and VPN, and record which layer of protection covers each.
- Close origin bypass: restrict origins to edge provider address ranges or authenticated connections.
- Enable network protection: confirm automatic protection or subscribe to the paid tier for critical addresses; configure attack alerts.
- Deploy the WAF in log or count mode: managed rules plus a broad per-IP rate rule sized from at least a week of traffic.
- Add path and key specific rate rules: for login, search, checkout and API endpoints; test with challenge actions before blocking.
- Move to blocking: after false positives are resolved; keep a documented switch back to log mode per rule as the rollback.
- Test: run an authorised load test with the provider's agreement and rehearse escalation using the DDoS Readiness Checklist.
Detection and measurement
- Coverage: percentage of internet-facing addresses with network DDoS protection and of web hostnames behind an edge WAF.
- Origin exposure: count of origins reachable directly from the internet (target zero).
- Blocking mode ratio: share of WAF rules in blocking rather than count mode for critical applications.
- Time to mitigate: minutes from attack start alert to stable service in tests and real events.
- False positive rate: legitimate requests blocked or challenged per million, by rule.
- Cache offload: share of requests served from edge cache, which sets how much flood the origin never sees.
Common failure patterns
- Buying the WAF and calling it DDoS protection: a self-hosted WAF behind a finite link.
- Relying on free network protection for layer 7: base tiers protect the network edge, not expensive application paths.
- One global per-IP rate rule: too loose for login and search, too tight for shared NAT addresses.
- Origin left open: a leaked origin address voids every edge control.
- Thresholds never revisited: traffic growth makes old limits block peaks or miss floods.
- No rehearsal: nobody can find the provider escalation contact during the attack.
Framework mapping
| Framework | DDoS protection | WAF |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-5 Denial-of-service Protection | SC-7 Boundary Protection, SI-4 System Monitoring |
| NIST CSF 2.0 | PR.IR-04 adequate resource capacity | DE.CM-09 monitoring of runtime environments |
| CIS Controls v8.1 | Control 13 Network Monitoring and Defense | 13.10 Perform Application Layer Filtering |
| ISO/IEC 27001:2022 Annex A | A.8.6 Capacity management, A.8.20 Networks security | A.8.20 Networks security, A.8.16 Monitoring activities |
| MITRE ATT&CK | T1498, T1498.001, T1498.002 | T1499.002, T1499.003, T1499.004 |
Practitioner checklist
- Map every public address and hostname to its network and application layer protection.
- Make origins reachable only through the protected edge.
- Run the WAF at an edge with flood capacity, not only on premises.
- Size rate rules from at least a week of traffic and scope low thresholds to expensive paths.
- Combine IP keys with path, ASN or TLS fingerprint keys and use challenges before blocks.
- Patch HTTP/2 and other protocol stacks promptly and set connection timeouts.
- Restrict and alert on changes to protection policies and the tokens that make them.
- Know and rehearse the provider and ISP escalation path.
Standards and references
- CISA, FBI and MS-ISAC: Understanding and Responding to DDoS Attacks
- CISA: HTTP/2 Rapid Reset Vulnerability, CVE-2023-44487
- AWS: AWS Shield Advanced overview
- AWS: Rate-based rule high-level settings
- Google Cloud: Cloud Armor overview
- Google Cloud: Cloud Armor rate limiting overview
- Microsoft: Azure DDoS Protection overview
- Microsoft: Rate limiting for Azure Front Door WAF
Related NHI Mgmt Group resources: DDoS Protection Guide · WAF and WAAP Buyer's Guide · Denial of Service at Application Layer Guide · Bot Management vs WAF · DDoS Response Playbook