How do you put AWS WAF and AWS Shield in front of an Amazon CloudFront distribution, and what does each of them actually protect you from?

## Attaching WAF to a distribution AWS WAF is scoped. A web ACL created with regional scope can be associated with an Application Load Balancer, an API Gateway stage, an AppSync API or a Cognito user pool in that Region. A web ACL for CloudFront must be created with **CloudFront scope**, which the console labels *Global (CloudFront)* and which is managed through `us-east-1` — the same anchoring that governs CloudFront's viewer certificates. You then reference the web ACL's ARN in the distribution configuration. A common first-day mistake is building the regional web ACL, finding the distribution refuses it, and concluding the feature is broken. ## What WAF actually inspects WAF is an application-layer filter. It sees the request line, headers, query string, cookies and a bounded portion of the body, and evaluates rules in priority order until one produces a terminating action. The building blocks: - **AWS Managed Rules** — curated groups such as `AWSManagedRulesCommonRuleSet` and `AWSManagedRulesAmazonIpReputationList`, maintained by AWS and versioned. They are the fastest way to a reasonable baseline and the fastest way to break a legitimate upload path if you deploy them straight to block. - **Rate-based rules** — count requests from a client IP over a rolling window and act when the count crosses your threshold. This is the practical answer to credential stuffing and scraper floods that are too small to look like a DDoS. - **Geo match, IP sets, regex and size constraints** — the primitives you combine into your own statements, scoped to particular URI paths so a rule protecting `/login` does not affect `/assets`. - **Custom responses** — a blocked request can return a specific status and body rather than a bare 403. Every rule can be set to **Count** rather than Block. The professional rollout is: deploy in count mode, send WAF logs to CloudWatch Logs, S3 or Firehose, look at what *would* have been blocked over a full traffic cycle including batch jobs and mobile clients, then flip rules to block one at a time. ## What Shield covers Shield Standard applies to every AWS customer at no extra charge and needs no configuration. It defends against the common network and transport layer attacks — SYN floods, reflection and amplification — and CloudFront benefits particularly, because the global edge network absorbs and disperses volumetric traffic instead of funnelling it at one Region. Shield Advanced is a paid subscription with an annual commitment. It adds finer detection tuned to your traffic baseline, health-based detection tied to Route 53 health checks, access to the AWS Shield Response Team during an event, proactive engagement, and **DDoS cost protection** — credits for the scaling and data-transfer charges an attack generates, which is often the real financial exposure. It also covers AWS WAF charges on protected resources. Whether it is worth it is a business question about downtime cost and attack likelihood, not a technical one. ## Why the edge is the right place Filtering at CloudFront blocks a bad request at the edge location nearest the attacker, before it consumes a cross-Region path, an origin connection or an application thread. It also scales with the edge network rather than with your origin fleet. The corollary matters just as much: **WAF at CloudFront only sees traffic that arrives through CloudFront.** If your ALB still has a public DNS name and an open security group, an attacker who discovers it bypasses every rule you wrote. Locking the origin down so it accepts only CloudFront traffic is what makes edge filtering meaningful, and a regional web ACL on the ALB is reasonable defence in depth. ## Cost and evaluation discipline WAF bills per web ACL per month, per rule, and per million inspected requests, and some managed groups carry an additional charge. On a high-volume distribution the request dimension dominates, so rules should be scoped to the paths that need them rather than blanket-applied. This is also why a CloudFront Function that rejects obviously malformed requests can be a genuine cost lever alongside WAF, not a replacement for it.