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

Pick an edge control by asking two questions: at which layer does the attack work, and where can a control be inserted in front of this workload? Network and transport layer floods (SYN floods, UDP reflection) never look like HTTP, so only AWS Shield and the scale of the AWS edge absorb them. Application layer threats arrive as valid-looking HTTP requests, so they need AWS WAF — and WAF can only sit on a supported resource.

When a workload has no WAF insertion point (for example it sits behind a Network Load Balancer or is an API Gateway HTTP API), the usual design move is to put CloudFront in front of it and attach a global web ACL to the distribution — that adds both the L7 inspection point and the DDoS-absorbing edge without changing the workload.

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, including an Amazon CloudFront distribution, an Application Load Balancer, an Amazon API Gateway REST API stage, an AWS AppSync GraphQL API, an Amazon Cognito user pool, an AWS App Runner service, an AWS Verified Access instance, an Amazon Bedrock AgentCore gateway, or an AWS Amplify app. WAF does not associate with EC2 instances, Network Load Balancers, or API Gateway HTTP APIs — those need a supported resource, typically CloudFront, in front of them.

Scope matters and is a recurring trap. A web ACL for CloudFront (and Amplify) must be created with the CloudFront (global) scope in US East (N. Virginia); web ACLs for ALBs, API Gateway, AppSync, Cognito, App Runner and Verified Access are Regional and must live in the same Region as the resource. Scope is fixed by where the protected resource lives, not by where its traffic ends up: a Regional web ACL can never be attached to a distribution, and a global web ACL can never be attached to a Regional resource. So "the WAF rules exist but the resource 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 — another reason to add only the rule groups that match your stack. Rules are evaluated in priority order (lowest number first), and the first terminating action ends evaluation: Allow and Block always terminate, and CAPTCHA/Challenge terminate when the request lacks a valid token. Count is non-terminating: the request is recorded as a match (and labelled), and evaluation continues. A rule's action applies regardless of whether it is custom or managed — a managed rule group does not outrank an earlier custom Allow. That ordering drives both tuning and troubleshooting later in this lesson.

AWS Managed Rules are the fast path to OWASP Top 10 coverage, and they are organised by purpose so you add only what matches your application:

Choose groups from the stack in front of you: the operating system groups follow the servers' OS — Linux servers get the Linux and POSIX groups, other Unix-like servers get POSIX, and Windows servers get the Windows group, since each OS group covers command injection for its own shell family. The application groups follow the language or CMS, and the SQL database group follows the presence of a SQL backend — whatever the server OS. Bot Control, ATP and ACFP are separately priced intelligent threat mitigation groups, not exploit signatures. Managed rule groups are versioned (you can stay on the default version or pin a static one), and you can override the action of individual rules inside a group — typically to Count — without discarding the rest of the group.

Custom rules match on request components: URI path, query string, headers, cookies, body, HTTP method, source IP (via IP sets), country (geo match), ASN, JA3/JA4 fingerprint, labels, and regex pattern sets. String-match rules can apply text 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, only the matching subset of traffic is counted toward the limit — rate-limit only POST /login, 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. A scope-down is evaluated before the group's rules, and requests it excludes skip every rule in the group — so it is not the tool for silencing one noisy rule; a per-rule override is.

Labels connect rules. Many rules — managed and custom — add labels to the requests they match (for example a Bot Control category label or a geolocation label), and a label match statement in a later rule can act on them. Two behaviours matter: a rule overridden to Count still adds its labels, and a label match statement only sees labels added by rules that were evaluated earlier — that is, rules with a lower priority number. The standard way to give a managed rule a custom action is therefore: override it to Count, then add a rule with a higher priority number than the rule group that matches its label and applies your action (Block, CAPTCHA, or a custom response).

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 over an evaluation window you choose (1, 2, 5 or 10 minutes) and applies the rule's action to keys that exceed your threshold, releasing them automatically when their rate falls back below it. A rate-based rule set to Count only records; to stop the abuse its action must be Block (or CAPTCHA/Challenge).

Aggregation keys decide what "one client" means:

• Source IP (the default) — the address of the connection WAF sees. On a web ACL attached to CloudFront, that is already the viewer's address.
• Forwarded IP — an address read from a header such as X-Forwarded-For. Use it only when the web ACL sits behind a trusted proxy — for example a Regional web ACL on an ALB that is itself behind CloudFront, where the ALB's source IPs are CloudFront's. On an internet-facing web ACL a client can write whatever it likes into that header, so keying on it lets an attacker rotate fake values and evade the limit.
• Custom keys — up to five components such as a header, cookie, query argument, URI path, HTTP method, label namespace, ASN, or the JA3 or JA4 fingerprint, alone or combined with IP. A composite key counts each combination separately: JA4 + IP splits a bot that rotates IPs back into many small buckets, while JA4 alone groups every request from the same TLS client stack together.
• Count all — no per-client grouping; one counter for every request that matches the scope-down, useful to cap total traffic to an expensive path.

Scope-down plus a low threshold is the precise tool. A single broad limit has to be set high enough for your busiest legitimate client, so it is blind to abuse spread thinly across many keys. A second rate-based rule with a scope-down statement counts only the requests that share some trait — a sensitive endpoint, a request method, a label from an earlier rule — and can therefore carry a far lower threshold without touching the rest of your traffic. Layering a broad rule with narrow, low-threshold ones is the general pattern.

Client fingerprinting. AWS WAF computes JA3 and JA4 fingerprints from each request's TLS Client Hello — a hash of how the client's TLS stack negotiates, which stays the same when a bot rotates IP addresses. Fingerprints are available for web ACLs on CloudFront and Application Load Balancers (where WAF sees the TLS handshake). You can match a fingerprint exactly in a string match statement, or aggregate a rate-based rule on it. A fingerprint identifies a TLS client stack, not a person: unrelated clients built on the same library or browser share it. Treat it as a strong signal to combine with other evidence (rate, path, labels) rather than as an identity, and prefer actions whose impact scales with behaviour over blanket blocks.

AWS WAF Bot Control is a managed rule group that classifies automated traffic and lets you allow, block, count, or challenge it by category. It has two inspection levels:

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 an AWS WAF token with an immunity period, so verified clients are not repeatedly interrupted. They suit browser-facing endpoints where you want to slow abuse without cutting off real users — login, signup, search.

Tokens and non-browser clients. A native iOS or Android app, or any API client, cannot run the challenge script, so a CAPTCHA, Challenge or Targeted token check breaks it. The fix that keeps the protection on is the AWS WAF mobile SDK, which the app integrates to acquire and send tokens. The web ACL's token domain list only controls which domains accept a token the client already holds (for example across sibling subdomains); it cannot give a token to a client that never acquired one. For the same reason, CAPTCHA and Challenge are never a safe way to evaluate a new rule: they interrupt users and break non-browser traffic, whereas Count observes without touching anyone.

There are two places to enforce country rules at the edge, and they differ in granularity:

They compose: use geo restriction for the distribution-wide allow list, and a WAF rule such as geo match country X AND URI path starts with /regulated → Block for a path-specific restriction. An exception ("block this country except our partner's office") is a WAF rule — geo match AND NOT IP set → Block — because geo restriction has no exceptions. Route 53 geolocation routing chooses which endpoint answers a DNS query; it is routing, not an access control, because a client can still reach any endpoint directly.

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 against real production traffic, watch the sampled requests and per-rule CloudWatch metrics, and flip to Block only after confirming the matches are genuinely malicious. Count is the only rule action that leaves every request's outcome unchanged while still recording and labelling matches, and production traffic is the only place a rule meets the real mix of clients it will judge.

Real triage runs on WAF logs, delivered to Amazon CloudWatch Logs, Amazon S3, or Amazon Data Firehose — they are the only log source that carries rule-level match detail for each request. Each log record includes the request metadata, the action, the terminating rule, any non-terminating (Count) matches, and the labels applied. Read the terminating fields carefully:

• terminatingRuleId names the rule in the web ACL that ended evaluation. If that was a custom rule, it is the rule itself.
• If a rule inside a rule group decided, terminatingRuleId holds the rule group, and the specific rule is in ruleGroupList[].terminatingRule.ruleId.

The false-positive workflow follows from that: filter the logs for the affected requests with action BLOCK, find the deciding rule, and if it lives in a managed group override that one rule to Count — keeping every other rule in the group active on those requests. A higher-priority Allow for the path or a scope-down that excludes it would also stop the false positive, but they exempt those requests from every rule in the group. Note that WAF inspects only a limited portion of the request body and you configure oversize handling for larger payloads — inspection limits are a legitimate reason a payload rule fails to match, and size rules such as the Core rule set's body-size rule are a common source of false positives on uploads.

Two habits keep tuning honest: never assume a rule protects you while it is still in Count, and re-check priorities after every change — an early terminating Allow silently bypasses everything below it.

DDoS defense on AWS starts with architecture. CloudFront, Route 53 and Global Accelerator are massively distributed 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:

Coverage follows the protection list. Protecting a distribution does not protect its ALB origin — cost protection and tuned detection apply only to resources you add as protections, so a distribution and its origin each need one. An NLB is not a protected resource type; you protect its Elastic IPs. Protection groups only aggregate resources that are already protected (so detection and mitigation treat them as one), they do not add protection.

SRT and proactive engagement. With proactive engagement the SRT contacts you when an event it detects is affecting your application; it needs the support plan, proactive engagement contacts, and a Route 53 health check associated with each protection. Proactive engagement is not triggered by events that the AWS WAF Anti-DDoS managed rule group detects.

L7 floods: the Anti-DDoS managed rule group. Since 26 March 2026 the AWS WAF Anti-DDoS managed rule group is AWS's default protection against HTTP request floods, added to a web ACL like any managed group. It supersedes Shield Advanced automatic application layer DDoS mitigation, which is now a legacy feature: existing users can keep it, but new Shield Advanced customers must ask AWS Support for it.

At organization scale, an AWS Firewall Manager Shield Advanced policy applies protections across member accounts, including resources created later. It needs auto remediation turned on to add the protections and associate an empty web ACL with in-scope resources that lack one — with auto remediation off it only reports non-compliant resources. Firewall Manager is the organization-wide mechanism for continuously applying Shield Advanced protections (and WAF rules) to existing and newly created resources in every in-scope account.

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 the legacy origin access identity): CloudFront signs origin requests with SigV4, and the bucket policy allows the cloudfront.amazonaws.com service principal only with an AWS:SourceArn condition naming your distribution. Without that condition, any distribution — including one in another account — could read the bucket. The bucket keeps Block Public Access on; only your distribution can read it. For custom origins such as ALBs, see the origin-locking scenario below.

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; 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.

Private content: signed URLs vs signed cookies. Both grant time-limited access and are verified against public keys in a trusted key group. A signed URL carries the signature in the query string of each URL, so it suits one object or a download link. Signed cookies are sent with every request to the domain without changing any URL, so they suit many objects — a subscriber area, or streaming formats such as HLS and DASH, where a manifest references hundreds of segments by relative path and those segment requests would not carry the manifest's signed query string. Each uses a policy:

OAC and signed URLs/cookies solve different problems and are often used together: OAC keeps the bucket private behind the distribution; signed URLs or cookies decide which viewers the distribution serves. Two further edge features: 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.

CloudFront has four header-related policies and settings, and each acts on a different hop:

Response headers policies are the way to add browser security headers without touching the origin or its objects: the security headers section covers Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, X-XSS-Protection and Referrer-Policy, and AWS publishes a managed SecurityHeadersPolicy. Each header has an origin override setting. When the origin does not send the header, CloudFront adds the policy's value either way. When the origin does send it, override on replaces it with the policy's value, and override off lets the origin's header pass through. A response header set in an origin request policy or origin custom header never reaches the viewer — those act on the request to the origin.

Amazon S3 CORS is a bucket configuration of rules — AllowedOrigins, AllowedMethods, AllowedHeaders, ExposeHeaders, MaxAgeSeconds — that tells browsers which other origins' scripts may read responses (S3 answers with Access-Control-Allow-Origin and related headers, and handles preflight OPTIONS requests). CORS is not access control. It is enforced by the browser on scripts running in a web page; curl, server-side code or any non-browser client ignores it, and S3 still serves every request its bucket policy, ACLs and Block Public Access allow. To stop downloads you restrict access (bucket policy, OAC, signed URLs), not CORS.

CORS through CloudFront. S3 returns CORS headers only when the request carries an Origin header, and the allowed-origin value it returns is specific to that origin. So the Origin header must reach S3 and the cache must vary on it — put Origin in the cache policy (which also forwards it). The managed CORS-S3Origin origin request policy forwards Origin on cache misses but does not add it to the cache key, so the first cached response — with one site's allow-origin header, or none — is served to every site. The alternative is to have CloudFront itself answer with CORS headers through the CORS section of a response headers policy, which moves the allowed-origin list from the bucket to CloudFront.

The requirement reads: "The origin must only accept traffic that has passed through CloudFront and AWS WAF; requests sent directly to the ALB must be rejected." There are two designs: keep the ALB internet-facing and cloak it in two layers, or remove its public endpoint with a VPC origin.

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. 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, a rule forwards to the target group only when that header matches, and the listener's 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.

The alternative: CloudFront VPC origins. Since November 2024, CloudFront can use an internal ALB, an internal NLB, or an EC2 instance in a private subnet as a VPC origin. The origin has no public IP or internet-facing listener at all, so there is no direct path to bypass and no shared secret to rotate; the web ACL on the distribution becomes the only way in. Choose VPC origins for new designs where the origin can be private; use the prefix list plus secret header when the origin must stay internet-facing.

Verification and pitfalls. Request the ALB DNS name directly — expect a rejection; request via the distribution — expect success. If requests appear in the ALB access logs but never in the distribution's WAF logs, the origin is being bypassed: look for a lingering 0.0.0.0/0 rule, or a listener whose default action forwards instead of rejecting. The origin's identity can also leak through DNS history or certificate transparency logs, so treat cloaking as enforcement by the security group and listener, not as secrecy.

API Gateway brings its own edge protections. Throttling applies token-bucket rate and burst limits at three levels: the account limit per Region (shared by every API in the account there), stage defaults, and method-level overrides in the stage settings — so capping one expensive method uses a method-level limit, not the account limit. Usage plans add per-client throttling and quotas (per day, week or month): you create a plan per tier, and associate each customer's API key with the plan for that customer's tier. An API key enforces nothing until it is associated with a usage plan, usage-plan throttles and quotas are applied on a best-effort basis (not a hard billing or security limit), and 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. REST API stages accept a Regional WAF web ACL; HTTP APIs do not.

Mutual TLS makes callers present an X.509 certificate chained to a truststore you upload to Amazon S3. It is configured on a Regional custom domain name using the TLS_1_2 security policy, is not supported for private APIs, and applies only to that domain — so you must disable the default execute-api endpoint, or callers simply bypass it. Do not confuse it with a stage client certificate: that certificate is presented by API Gateway to your backend so the backend can verify that calls come from API Gateway; it does not authenticate callers.

WAF versus Network Firewall is a layering question, not a rivalry. AWS WAF is L7-only, inspecting HTTP(S) at supported edge and Regional resources. AWS Network Firewall (Task 3.3) is a stateful, managed firewall deployed in VPC subnets with Suricata-compatible rules and domain-based egress filtering for all traffic, not just web requests. Use WAF for inbound web exploits and floods; use Network Firewall for VPC ingress/egress inspection and non-HTTP protocols.

The troubleshooting playbook. Legitimate traffic blocked: WAF logs → the terminating rule (and ruleGroupList for a rule inside a group) → override that rule to Count or add a narrowly 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, rate thresholds aren't above the attack's per-key rate (add a scoped-down rule or a better aggregation key), and body inspection limits aren't hiding the payload. Origin directly reachable: look for an open security group rule, a missing prefix-list restriction, a listener default action that forwards, an enabled execute-api endpoint, or a leaked origin address.

AWS IoT Core policies are JSON policies attached to a device's X.509 certificate (or other principal) that authorize MQTT actions. Least privilege depends on using the right resource type for each action:

Subscribing and receiving are authorized separately: a policy that puts iot:Subscribe on a topic/ resource never authorizes any subscription, because subscriptions are evaluated against topicfilter/ resources. In policy resources, * is the policy wildcard, while the MQTT wildcards # and + are treated literally — so topicfilter/cmd/device1/# authorizes exactly the filter cmd/device1/#.

One policy for every device comes from thing policy variables — IoT-specific variables populated from the device's connection, certificate and registry entry. ${iot:Connection.Thing.ThingName} resolves to the name of the registered thing behind the connection (when the client ID equals the thing name, or when the certificate is attached exclusively to one thing), so a single policy can let each device connect only as itself and publish or subscribe only under topics that contain its own name. Wildcard resources such as topicfilter/cmd/* or topic/sensors/*/telemetry break that isolation — every device could read or write every other device's topics.

Third-party (AWS Marketplace) managed rule groups plug into a web ACL exactly like AWS managed groups, after you subscribe in AWS Marketplace. Their rules are hidden — you cannot view or copy their logic — but you can still override individual rule actions (or the whole group) to Count. The seller owns the rules, their versioning and support, so a false positive is handled by overriding the rule to Count and asking the seller (not AWS Support) to tune it. Subscriptions are per account: to deploy one through an AWS Firewall Manager AWS WAF policy, every account in the policy scope must subscribe. Charges continue until the group is removed from every web ACL and Firewall Manager policy and the subscription is cancelled.

OCSF integration. The Open Cybersecurity Schema Framework (OCSF) is an open schema for security events, and Amazon Security Lake is AWS's OCSF data lake (the new AWS Security Hub also represents findings in OCSF, while Security Hub CSPM uses ASFF). Edge data arrives in two ways:

• Native AWS sources — AWS WAFv2 logs are a natively supported Security Lake source, alongside CloudTrail, VPC Flow Logs, Route 53 Resolver query logs, Security Hub CSPM findings and EKS audit logs. Security Lake collects them across the organization and converts them to OCSF in Apache Parquet itself — no transformation code.
• Custom sources — third-party data, such as events from another vendor's CDN or WAF, must arrive already converted to OCSF as Apache Parquet, written under the prefix Security Lake assigns to the source and partitioned by region, accountId and eventDay, with one OCSF event class per custom source. Security Lake does not convert raw vendor JSON; it creates the writer IAM role, the Lake Formation table and a Glue crawler for the source.

Once the data is in Security Lake, subscribers — Athena queries, or third-party SIEM and analytics tools — read edge, network and API activity in one schema.