Edge Security on AWS: WAF, Shield, and CloudFront as Controls

AWS WAF evaluates HTTP and HTTPS requests before they reach your application. The unit of deployment is the web ACL — an ordered collection of rules with a default action (Allow or Block) that applies when no rule matches. You associate a web ACL with a supported resource: an Amazon CloudFront distribution, an Application Load Balancer, an Amazon API Gateway REST API stage, or an AWS AppSync GraphQL API (Cognito user pools and App Runner services are also supported). WAF does not attach to EC2 instances or Network Load Balancers — if a workload sits behind an NLB, there is no WAF insertion point, which is itself an exam-worthy design constraint.

Scope matters and is a recurring trap. A web ACL for CloudFront must be created with the CloudFront (global) scope in the US East (N. Virginia) Region; web ACLs for ALBs, API Gateway, and AppSync are regional and must live in the same Region as the resource. A regional web ACL can never be attached to a distribution, and vice versa — so "the WAF rules exist but the API is unprotected" often means the web ACL was built in the wrong scope or simply never associated.

Each rule consumes web ACL capacity units (WCUs), a complexity budget: managed rule groups publish their WCU cost, and a web ACL has a capacity ceiling. Rules are evaluated in priority order (lowest number first), and the first terminating action — Allow or Block — ends evaluation. Count is non-terminating: the request is recorded as a match and evaluation continues. That distinction drives both tuning and troubleshooting later in this lesson.

AWS Managed Rules are the fast path to OWASP Top 10 coverage: the Core rule set (common exploits such as cross-site scripting), Known bad inputs (patterns tied to known CVEs, including Log4j-style payloads), SQL database rules for SQL injection, the Amazon IP reputation list, and the Anonymous IP list (VPNs, Tor exit nodes, hosting providers). Managed rule groups are versioned, and you can override the action of individual rules inside a group — typically to Count — without discarding the rest of the group. Third-party managed rule groups from AWS Marketplace vendors plug into the same web ACL model, which is how the exam frames "using third-party WAF rules."

Custom rules match on request components: URI path, query string, headers, body, HTTP method, source IP (via IP sets), country (geo match), and regex pattern sets. String-match rules can apply transformations such as lowercasing and URL decoding before matching, which defeats trivial evasion. Logical statements (AND, OR, NOT) combine conditions into precise rules — for example, block requests to /admin unless they arrive from the corporate IP set.

A scope-down statement narrows what a rule even considers. Inside a rate-based rule, it means only the matching subset of traffic is counted toward the limit — rate-limit only POST /login requests, not the whole site. Inside a managed rule group such as Bot Control, it restricts the (comparatively expensive) inspection to the paths that need it. Scope-down statements are the difference between a blunt control and a targeted one, and the exam rewards knowing they exist precisely for rate-based rules and managed groups.

A rate-based rule counters L7 request floods and brute-force patterns that content-matching rules cannot see, because each individual request looks legitimate. WAF counts requests per aggregation key — by default the source IP — over a trailing evaluation window, and applies the rule's action to keys that exceed your threshold, automatically releasing them once the rate drops back under it. The exam phrase "block clients that send more than X requests in five minutes" maps directly to a rate-based rule with action Block. Behind CloudFront or another proxy, aggregate on the forwarded IP (such as X-Forwarded-For) instead of the connection IP, or every client appears to share the proxy's address — a classic misconfiguration that either rate-limits everyone or no one. Custom aggregation keys (for example, header or query values) handle distributed attacks where no single IP crosses the threshold.

Blocking is not the only action. CAPTCHA presents an interactive puzzle a human can solve; Challenge runs a silent browser interrogation that scripts without a real browser environment fail. Both issue a token with an immunity period, so verified clients are not repeatedly interrupted. They suit endpoints where you want to slow abuse without cutting off real users — login, signup, search.

AWS WAF Bot Control is a managed rule group that classifies automated traffic — verified crawlers such as search engines versus unverified scrapers and HTTP libraries — and lets you allow, block, or challenge by category. Know it as the answer to "identify and manage bot traffic at the edge," typically deployed with a scope-down statement to control cost.

Deploying a strict rule set straight to Block on production traffic is how edge security causes its own incident. The professional pattern is count first: run new rules (or an entire managed rule group, via rule action overrides) in Count mode, watch the sampled requests and CloudWatch metrics that WAF emits per rule, and flip to Block only after confirming the matches are genuinely malicious.

Real triage runs on WAF logs, which you deliver to Amazon CloudWatch Logs, Amazon S3, or Amazon Data Firehose. Each log record includes the full request metadata, the action taken, the terminatingRuleId — the rule that made the final allow-or-block decision — plus any non-terminating (count) matches and the labels rules applied. The false-positive workflow is mechanical, and the exam expects you to know it: a legitimate user reports being blocked; you filter the logs for their request and action BLOCK; the terminatingRuleId names the offending rule; if it is inside a managed group, you override that one rule to Count (or add a targeted exception rule at a higher priority) rather than removing the whole group. Note that WAF inspects only a limited prefix of the request body, and you configure oversize handling for payloads beyond that limit — inspection limits are a legitimate reason a payload-based rule fails to match.

Two habits keep tuning honest: never leave a web ACL's default action as Allow while assuming a rule covers you when it is actually in count mode, and re-check rule priorities after every change — an early terminating Allow silently bypasses everything below it.

DDoS defense on AWS starts with architecture. CloudFront and Route 53 are massively distributed, anycast edge services: volumetric L3/4 attacks are spread across the global edge and absorbed far from your origin, which is why "put CloudFront in front of it" is itself a DDoS answer. On top of that sit two Shield tiers:

Exam triggers: "refund or protection against the bill from an attack" → Shield Advanced cost protection; "expert help during an active DDoS" → SRT access (proactive engagement requires configured health checks); "L7 flood mitigation deployed on your behalf" → Shield Advanced automatic application layer mitigation, which requires a WAF web ACL on the resource. Shield Advanced also feeds organization-wide deployment through AWS Firewall Manager.

CloudFront is not just a cache — it is the layer that lets you hide your origins entirely. For S3 origins, origin access control (OAC) is the current mechanism (successor to origin access identity): CloudFront signs origin requests with SigV4, and the bucket policy allows access only to the CloudFront service principal, conditioned with AWS:SourceArn naming your distribution. The bucket stays private; only your distribution can read it. For custom origins such as ALBs, cloaking is a two-part pattern covered in the next section's scenario: a secret custom header plus a security group restricted to CloudFront's origin-facing IPs.

CloudFront also enforces encryption in transit at both hops. The viewer protocol policy forces HTTPS from clients (redirect or require); the security policy sets the minimum TLS version and ciphers viewers may negotiate (for example, a TLSv1.2 minimum policy); the origin protocol policy should be HTTPS-only so the edge-to-origin hop is encrypted too. Certificate details and ACM live in Domain 5 — here, know which knob enforces which hop.

For private content, signed URLs grant time-limited access to a single object, while signed cookies cover many objects (a subscriber video library) without rewriting every URL; both verify signatures from a trusted key group. Geo restriction allows or blocks whole countries per distribution — for finer logic (country plus URI path), use a WAF geo-match rule instead. Two mention-level features round out the edge: field-level encryption encrypts specific sensitive POST fields at the edge with a public key so only the component holding the private key can decrypt them, and Route 53 DNSSEC signs your DNS zone so resolvers can detect spoofed responses directing users away from your edge.

The requirement reads: "The origin must only accept traffic that has passed through CloudFront and AWS WAF; requests sent directly to the ALB's DNS name must be rejected." Walk it as two layers, because each closes a gap the other leaves open.

Layer 1 — network path. Edit the ALB's security group to allow HTTPS only from the AWS-managed prefix list for CloudFront origin-facing servers (com.amazonaws.global.cloudfront.origin-facing), and remove the 0.0.0.0/0 ingress rule. The prefix list is maintained by AWS, so you never chase changing edge IP ranges. Now random internet clients cannot reach the ALB at all. But this is insufficient alone: those edge IPs serve every CloudFront customer, so an attacker can create their own distribution pointing at your ALB and arrive from an allowed address — bypassing your web ACL entirely.

Layer 2 — origin authentication. Configure your distribution to add a custom origin header — for example X-Origin-Verify with a long random value stored in Secrets Manager. On the ALB listener, the rule that forwards to the target group requires that header to match; the default action returns a fixed 403. Rotate the secret periodically by updating the distribution and listener rule. Now only your distribution's traffic is honored, and since your web ACL is attached to that distribution, nothing reaches the origin unfiltered.

Verification and pitfalls. Curl the ALB DNS name directly — expect a rejection; request via the distribution — expect success. Residual risk: the origin's identity can still leak through DNS history or certificate transparency logs, so treat cloaking as reducing exposure, not as secrecy you can bet on — the security group remains the enforcement layer.

API Gateway brings its own edge protections. Throttling applies token-bucket rate and burst limits at the account, stage, and method level, and usage plans with API keys set per-client quotas — remember that API keys identify and meter clients; they are not authentication. Resource policies restrict who can invoke the API by source IP, VPC or VPC endpoint, or AWS account. Mutual TLS on a custom domain requires clients to present certificates chained to a truststore you supply — and you must disable the default execute-api endpoint, or clients can simply bypass the mTLS domain. REST API stages also accept a regional WAF web ACL.

WAF versus Network Firewall is a layering question, not a rivalry. AWS WAF is L7-only, inspecting HTTP(S) at supported edge services. AWS Network Firewall is a stateful, managed L3–L7 firewall deployed in VPC subnets: Suricata-compatible IPS rules, protocol detection, and domain-based egress filtering for all traffic, not just web requests to your endpoints. Use WAF for inbound web exploits and floods at the edge; use Network Firewall for VPC ingress/egress inspection and non-HTTP protocols; mature perimeters run both.

The troubleshooting playbook. Legitimate traffic blocked: WAF logs → terminatingRuleId → override that rule to count or add a prioritized exception; check priority order for an early terminating rule. Attacks getting through: confirm the web ACL is associated and in the correct scope, the rule isn't still in count mode, rate thresholds aren't set above the attack's per-key rate, and body-size inspection limits aren't hiding the payload. Origin directly reachable: look for a lingering 0.0.0.0/0 security group rule, a missing prefix-list restriction, an absent header check, or a leaked origin IP — then rotate the origin's identity and re-cloak.