The DDoS protection you already have, and the layer it cannot see

Why — The Problem This Solves

An internet-facing endpoint receives traffic nobody wrote code for. Path scanners looking for /wp-admin and .env. Log4Shell probes in headers. A single IP sending thousands of requests a minute at an endpoint sized for dozens.

The application usually does not break. It degrades, it bills, and it logs nothing useful about who did it. The team finds out from a latency graph, not from a security signal.

The specific gap: there is no layer between the internet and the application that can say "no" before the request costs you compute. Every request that reaches Lambda is a request you pay for, and a request that gets to touch your code.

Why teams do not already have this

• Managed rules cause false positives. Turn AWS's Core rule set on in Block mode and it will reject a legitimate file upload on day one. Teams enable it, get paged, and switch WAF off permanently.
• The pricing is misread. The "$1 per rule" charge is per rule group, not per rule inside it, which cuts both ways when estimating.
• Shield confusion. Teams believe DDoS protection means AWS Shield Advanced at $3,000/month, conclude it is out of budget, and do nothing at all.

That last one is the misconception this week exists to correct.

What You Need to Know — Skills & Tools

WAF looks simple from the console and has four concepts that decide whether a deployment works or quietly does nothing.

Tools used: Terraform via HCP Terraform (VCS-driven), Python on Lambda, and curl plus CloudWatch metrics for the attack simulation.

Shield Standard is not something you deploy

There is no Terraform resource for AWS Shield Standard. There is no console toggle. It is already active on every AWS account at no charge.

It protects CloudFront, Route 53, Global Accelerator and Elastic Load Balancing against layer 3 and 4 volumetric attacks — SYN floods, UDP reflection. AWS reports mitigating over 99% of infrastructure-layer attacks in under one second.

What Shield Standard does not do is inspect HTTP. An attacker sending well-formed requests at 10,000 per minute, or a single request carrying an SQL injection payload, is invisible to it. That is layer 7, and layer 7 is AWS WAF's job.

The screenshot below is this account's Shield console. Note "Status: Incomplete" against every Shield Advanced setup step — this account runs Standard only, which is the entire point. AWS's own banner at the top states the migration dates.

Architecture — How It Fits Together

Two web ACLs, one at the edge and one at the origin, protecting a deliberately trivial application.

Why two web ACLs and not one

An edge-only WAF protects only the requests that actually travel through CloudFront. The API Gateway invoke URL stays publicly reachable — CloudFront does not hide it. Anyone who discovers that URL walks straight past an edge-only firewall.

The regional web ACL is what makes that bypass pointless. The attack simulation later in this post tests both paths for exactly this reason.

Why Lambda for the origin

The origin is an echo function whose only job is to answer "did this request get through?". It runs only when tested, holds no state, and has effectively zero concurrency. A container or an EC2 instance would bill 24/7 to serve a few minutes of use per month. The choice follows the workload's shape, not habit.

The five rules

AWS WAF evaluates rules in ascending priority order and stops at the first terminating action, so the cheapest and most definitive checks run first.

953 of the 1,500 WCUs included in the base price. This matters: exceed 1,500 and you pay $0.20 per million requests for every additional 500 WCUs. Stacking Core rule set with Bot Control would blow that budget immediately. The console reports the exact figure, and it matched the estimate.

Two choices worth explaining

evaluation_window_sec = 60, not the 300 default

AWS WAF re-checks the request rate roughly every 10 seconds regardless of this setting — the window controls how far back it looks each time. A five-minute lookback averages an attacker's burst across five minutes before it crosses the threshold. A 60-second window treats a burst as a burst.

aggregate_key_type = "IP" is right here and wrong for many real applications

Users behind a shared corporate NAT all present a single source IP, so IP aggregation throttles the entire office together. The fix is CUSTOM_KEYS over a session identifier. The current Terraform provider also supports ASN and JA3/JA4 TLS fingerprints as aggregation keys — both newer than most tutorials will tell you.

rule {
  name     = "rate-limit-per-ip"
  priority = 20

  action { block {} }   # or count {} during the observation phase

  statement {
    rate_based_statement {
      limit                 = 100
      aggregate_key_type    = "IP"
      evaluation_window_sec = 60   # 60 | 120 | 300 (default) | 600
    }
  }

  visibility_config {
    cloudwatch_metrics_enabled = true
    metric_name                = "week13-waf-regional-rate-limit"
    sampled_requests_enabled   = true
  }
}

How We Built It — Step by Step

Count mode first — the discipline that makes WAF stick

Every rule was deployed with its action set to Count. In Count mode WAF inspects the request, records that it would have blocked it, and lets it through anyway.

This is not caution for its own sake. The Core rule set blocks request bodies over 8 KB and query strings over 2,048 bytes. On a real application, a file upload or a long rich-text field trips that immediately. Count mode is how you find that out before it rejects a paying customer.

The four rule actions

Deploying

State lives in HCP Terraform (workspace week-13-dev, VCS-driven). The first apply failed, and it is worth showing rather than hiding.

The fix is to supply at least one exemption pattern, and to guard it with a variable validation so the next person fails at plan time with an explanation instead of part-way through an apply:

variable "anti_ddos_challenge_exempt_uri_regexes" {
  type    = list(string)
  default = ["^/health$"]

  validation {
    condition     = length(var.anti_ddos_challenge_exempt_uri_regexes) > 0
    error_message = "At least one exempt URI regex is required: AWS rejects the web ACL if the Anti-DDoS challenge action is ENABLED with an empty exemption list."
  }
}

Why the exemption exists at all is worth understanding: the Anti-DDoS challenge is a silent browser challenge. A real browser solves it transparently, but a machine-to-machine caller cannot execute JavaScript. Without an exemption list, a DDoS event would fail those legitimate callers outright.

With that fixed, the apply completed and the console reported exactly the predicted capacity:

The regional web ACL must be attached to the API Gateway stage via a separate association resource. CloudFront is the exception: it takes its web ACL as an attribute on the distribution itself.

Testing it: the attack simulation

A shell script sends benign-but-rule-matching requests to my own endpoints. Nothing in it is an exploit — the payloads are the well-known signature strings the managed rule groups look for, sent to a Lambda that echoes its input and does nothing else.

One consequence of that discovery changed a test: a path-traversal sequence in the URI path is rejected by API Gateway with a 400 before WAF is ever consulted. To actually exercise the rule, the payload has to go in a query argument.

In Count mode, the origin web ACL recorded 13 matches and the edge 7 — every one an attack payload, and the benign baseline untouched. Zero false positives is the number that decides whether it is safe to enforce.

Flipping to Block

With clean evidence, the rules were switched to enforcing. The repository default stays count_mode = true deliberately, so anyone reusing the module gets Count-first as the safe default; the flip was made as an HCP workspace variable, which is an operational decision rather than a code change.

Then the identical simulation ran again. Same requests, same endpoints, one variable changed:

Logging, and proving the redaction works

A WAF log records the request it inspected — which means it records credentials unless you tell it not to. Without redaction, the security control becomes the disclosure vector.

resource "aws_wafv2_web_acl_logging_configuration" "this" {
  resource_arn            = aws_wafv2_web_acl.this.arn
  log_destination_configs = [aws_cloudwatch_log_group.waf.arn]

  redacted_fields { single_header { name = "authorization" } }
  redacted_fields { single_header { name = "cookie" } }
  redacted_fields { single_header { name = "x-api-key" } }
}

Configuring redaction and verifying it are different things. I sent a request carrying three fake credentials and then read the logged record back:

Alarms: making a block something a human hears about

A web ACL with no alarm is a control you have to remember to go and look at. Two alarms per web ACL — BlockedRequests for enforcement and CountedRequests for the observation phase — both publishing to SNS.

To prove the notification path end to end rather than assume it, I drove the alarm deliberately — 80 blocked requests to cross the threshold of 50:

The recovery email is the half people forget to configure. An operator who receives an alert and never learns the attack stopped has to go and check manually every time.

Verifying it actually works

The first version of the simulation script reported the benign baseline as "blocked as expected", and it was wrong in a way worth naming: an HTTP status is not a WAF verdict.

API Gateway returns 400 for a malformed URI path and 405 for an unsupported method. CloudFront returns 403 for a method outside allowed_methods. None of those involve WAF at all. And in Count mode everything returns 200 by design, so status codes cannot distinguish a match from a miss.

The only real evidence is CountedRequests and BlockedRequests in CloudWatch, or the WAF logs themselves. A related trap: the Rule metric dimension uses the rule's visibility_config.metric_name, not its name, so querying by rule name silently returns nothing.

Two things were therefore proven by reading data rather than responses — the count-versus-block comparison above, and the redaction check, which confirms a request carrying three fake credentials came back REDACTED in all three headers rather than merely showing the configuration was present.

Challenges — What Actually Went Wrong

Security — Controls at Every Layer

The interesting security property of this build is that the firewall itself is the control. What follows is what protects the rest of it.

• Defence at both scopes. The edge ACL protects CloudFront; the regional ACL protects the API Gateway stage. That pairing exists specifically because an origin URL that stays publicly reachable makes an edge-only firewall decorative.
• A break-glass IP set evaluated before the managed rule groups, so a legitimate client caught by a false positive can be let through without disabling a rule for everyone.
• Logs are redacted at source. authorization, cookie and x-api-key are declared as redacted fields, so credentials never reach the log group rather than being scrubbed afterwards.
• A per-web-ACL log resource policy instead of contributing to the shared account-wide AWSWAF-LOGS policy, which has a maximum size that silently breaks logging configuration once enough web ACLs share it.
• Count mode as a safety control, not just a testing convenience. Shipping managed rules straight to Block is what causes the outage that gets WAF switched off permanently.
• No static credentials anywhere. Deployment uses HCP Terraform's OIDC dynamic credentials against an AWS role.

Cost

Cleanup

The workspace is VCS-connected, which blocks terraform destroy from a CLI checkout but not a destroy queued through HCP — either from the UI (Workspace → Settings → Destruction and Deletion → Queue destroy plan) or the API with is-destroy: true.

./scripts/cleanup.sh

This build was destroyed via an API destroy run: 33 resources destroyed, 0 added or changed, and every post-teardown check passed. Total cost for the week came to about $1.40.

The script verifies rather than destroys, and distinguishes three outcomes rather than two — gone, still present, and could not verify — because an expired session returning an empty result otherwise reads as a clean teardown while having checked nothing at all.

Two things linger for opposite reasons, and both are worth checking by hand:

• A web ACL cannot be deleted while still associated with a resource, so an association left behind blocks the delete.
• A CloudFront distribution must be disabled and fully propagated before it can be removed, which takes roughly fifteen minutes and looks like a hang if you are not expecting it.

Left running, this build has a real floor of about $20/month — unlike most weeks in this series, two web ACLs bill whether or not a single request ever arrives.

References

• Week 13 source on GitHub — Terraform modules, Lambda, attack simulation script
• AWS WAF Developer Guide
• Shield Advanced and the Anti-DDoS managed rule group migration
• AWS WAF pricing · AWS Shield pricing

Key Takeaways

• Shield Standard is already protecting you and there is nothing to deploy. The gap it leaves is layer 7, and that is WAF's job.
• Deploy managed rules in Count mode first. Going straight to Block is what produces the day-one outage that gets WAF disabled permanently.
• Protect the origin as well as the edge. An invoke URL that stays publicly reachable makes an edge-only web ACL trivial to bypass.
• Check the WCU sum before adding a managed group. 1,500 are included; CommonRuleSet alone is 700.
• An HTTP status is not a WAF verdict. Only CloudWatch metrics or the WAF logs tell you what the firewall actually did.
• WAF pricing is prorated hourly, so a build-test-destroy day costs under a dollar. Do not let a monthly figure narrow the design.

What I'd do differently in production

• Stay in Count mode far longer. Fourteen matches from a synthetic script is a thin sample. Real production traffic over several days is what actually surfaces false positives.
• Use rule_action_override rather than dropping a rule group. When Core rule set rejects a legitimate upload, override that single rule to Count — do not disable 700 rules to fix one.
• Reconsider the rate aggregation key. IP aggregation punishes shared-NAT users collectively.
• Add a logging filter. WAF logs one record per inspected request; at real traffic volumes the ingestion cost becomes the dominant line item, not the web ACL.