Protect them by associating an AWS WAF web ACL with each front door that needs inspection, then applying rules for known bad patterns, rate limiting and request validation. Put the controls at the edge so malicious traffic is filtered before it reaches the application. Make sure logging, rule ordering and exception handling are reviewed regularly.
How AWS WAF fits in front of API Gateway, ALB, and CloudFront
AWS WAF is the inspection layer you attach to each internet-facing entry point, so requests are filtered before they reach the application or origin. For Amazon api gateway, Application Load Balancer, and CloudFront, the practical question is not whether WAF can help, but where each front door terminates traffic and how consistently you apply the same policy across them.
The real value comes from treating WAF as a shared control plane for edge enforcement, not as a one-off rule set. If a service is exposed through more than one front door, the protection model should be mapped to the path the request actually takes, because a policy attached to CloudFront does not automatically protect a direct ALB endpoint, and a policy on ALB does not cover traffic that never reaches it.
That is why the setup is usually built around one web ACL per protected surface, with rules that reflect the traffic pattern of that surface. For example, API endpoints often need schema-aware validation and tighter rate-based controls, while content delivery paths may prioritise blocking obvious abuse, bots, and noisy scanning. A good baseline is to align the inspection logic with the business function that sits behind the front door, then keep the rules as simple as possible while still being effective. For a deeper deployment view, the Web Application Firewall Guide covers tuning, bypass risks, deployment modes and false positives.
CloudFront deserves special attention because it is often the broadest exposure point and can absorb traffic before it reaches any regional origin. API Gateway and ALB are also common choke points, but they are usually part of a more specific application flow. In practice, the more paths you expose, the more important it becomes to avoid policy drift, because a partial rollout can leave one service hardened and another effectively open. The AWS-side baseline should sit alongside your broader account and logging posture, not replace it, which is why teams often pair edge filtering with account-level guardrails described in the AWS Security Guide.
What the web ACL should actually do
The web ACL should express the minimum policy needed to reduce abuse without breaking legitimate clients. In most environments that means a combination of allow or block rules, managed rule groups where appropriate, rate limiting for volumetric abuse, and carefully scoped exceptions for known-good traffic patterns. The control is strongest when it blocks malformed or hostile requests early, before they consume application, origin, or downstream API capacity.
Rule ordering matters because WAF evaluates traffic in the sequence you define, so a narrow exception placed too early can unintentionally bypass broader protections. The same logic applies to custom allowlists, health check paths, partner traffic, and internal automation. Every exception should be explicit, time-bound where possible, and reviewed against the business reason it exists. If the policy is meant to protect APIs, the request discipline should be as tight as the API surface itself, which is why the API Security Guide is a useful companion for schema validation, rate limiting and gateway-centric controls.
Logging is not optional. Without request logs, you cannot tell whether a block rule is stopping real abuse, suppressing valid clients, or masking an upstream misconfiguration. The same is true for exception handling: if you cannot explain why a request was exempted, you cannot safely defend the control during incident review or change review. When you need a broader view of edge hardening, the Edge Device Security Guide is relevant because load balancers and gateways fail in similar ways when management exposure, logging, and configuration drift are neglected.
For CloudFront specifically, the strongest posture is usually to treat the distribution as the public perimeter and reduce direct-origin exposure wherever possible. For ALB and API Gateway, the control is similar in principle, but the operational detail differs because ALB commonly fronts applications and API Gateway fronts programmable interfaces. That distinction matters when you decide which paths should be rate limited, which headers should be trusted, and which requests should be validated more aggressively.
Where protection fails in practice
Protection usually fails because the team assumes the edge is covered when only one entry point is protected, or because a policy is deployed but not maintained. Another common failure mode is over-broad exceptions, which quietly erode the control until the web ACL is present in name only. Attackers do not need to defeat WAF if they can reach an uncovered front door, or if an allowed path exposes a weaker backend route.
A second failure pattern is using WAF as the only compensating control for origin exposure or credential misuse. That is not enough. WAF can stop hostile request patterns, but it does not fix exposed secrets, weak backend authorization, or an origin that is reachable through an alternate path. If your entry points are Amazon API Gateway, Application Load Balancer, and CloudFront, you should assume the attacker will look for the least inspected route and the least constrained request type.
The most useful mental model is that WAF reduces attack surface, but it does not eliminate trust decisions. If a request is accepted by the edge and then reaches an application with weak authorization, the protection has only delayed the problem. That is why edge controls and API controls must be designed together, not as separate projects.
Risk and Threat Considerations
When AWS WAF is inconsistently attached across CloudFront, API Gateway, and ALB, the exposed path becomes the attacker’s preferred path. The main risk is not just request filtering failure, but uneven enforcement that leaves one endpoint harder to abuse than another, which makes the weakest front door the practical target.
Failure mechanism: A distribution, stage, or load balancer is left without the intended web ACL, or an exception and rule-order mistake allows hostile traffic to pass through to the application or origin.
Impact: Attackers can bypass edge controls, increase request volume, probe for application weaknesses, and reach backend services that were assumed to be shielded, raising the chance of abuse, service degradation, and incident response overhead.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | AWS WAF deployment gaps and bad rule ordering create API exposure through misconfiguration. |
| Recommendation — Harden gateway policies and block unsafe traffic paths before requests reach API logic. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | WAF effectiveness depends on logging and review of blocks, allows, and exceptions. |
| Recommendation — Centralize and review WAF logs so exceptions and abuse patterns are visible. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | WAF protection needs request-level events to support review and incident investigation. |
| AC-4 — Information Flow Enforcement | WAF enforces request filtering at the perimeter, shaping which traffic may flow inward. | |
| Recommendation — Log edge security events so blocked, allowed, and exempted requests can be investigated. Enforce traffic filtering at the front door before requests reach protected services. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Web ACLs, exceptions and rule order require controlled configuration across entry points. |
| Recommendation — Control WAF configuration changes and review exception handling as managed changes. | ||
Practitioner Guidance
What to verify: Confirm every public CloudFront distribution, API Gateway stage, and internet-facing ALB that should be inspected is actually associated with the intended web ACL. Then verify that the policy covers the real traffic paths, including alternate hostnames, direct origin access, and any bypass routes created for testing or partner integrations.
Common mistake: Teams often deploy a strong managed rule set and assume the job is done, but the control weakens quickly if exceptions, rule ordering, and logging are not owned as a recurring change process. The practical test is whether you can explain every block, every allowlist entry, and every bypass in a change review.
What good looks like: One consistent inspection standard is applied at the edge, logs are reviewed often enough to spot both abuse and false positives, and rule changes are tied to observed traffic rather than guesswork. Where a path must remain exempt, the exemption should be narrow enough that you can justify it to operations and security without ambiguity.
Practitioner takeaway: Treat AWS WAF as a perimeter control that must be deployed per front door and governed like code, because coverage gaps and unmanaged exceptions are usually more dangerous than the absence of a rule set entirely.
Related resources from NHI Mgmt Group
- What breaks when API visibility is limited to gateway and load balancer integrations?
- How should security teams protect API traffic in AWS without disrupting application availability?
- What happens when a misconfigured API gateway or WAF is placed in front of an AWS workload without proper tuning?
- When should organisations choose an API gateway instead of a load balancer?