AWS WAF Recommended Design
For the priority principles that apply to every firewall type, see Policy Priority. The scopes in this table come from the Scope examples.
The following table shows our general recommendation for the AWS WAF NSM policies of any organization, listed in the recommended order, with the business need that each NSM policy meets and the NSM rules that it contains. The order of the NSM traffic inspection rules follows the Recommended WAF Rule Order in the AWS WAF Best Practices guide. NSM policies that contain only NSM firewall configuration rules or NSM policy settings, such as WAF Mandatory things, Shield Advanced, and WAF default things, don't affect WAF rule order. Their priority decides only which NSM policy wins when two NSM policies set the same property.
These priorities are an example, not hard requirements. What matters is the relative order of the NSM policies, not the numbers themselves. The numbers matter only in that they leave adequate spacing to add NSM policies over time, including room for thousands of applications that each have their own exceptions. These placements work for most organizations, so adjust them to fit your organization.
The Importance column uses the following values:
- Recommended – We recommend this NSM policy for every organization.
- Consider – Evaluate this NSM policy and make sure that it's applicable for you.
- Use case – Add this NSM policy when your applications have the use case that it addresses.
- Optional – Not a best practice, but if you choose to use it, this is where it belongs.
* Shield Advanced is a different firewall type than AWS WAF. NSM tracks priority separately for each firewall type, so the Shield Advanced NSM policy can share priority 10 with Anti-DDoS without competing with it.
The following describes what each NSM policy in the table contains, why it's its own NSM policy, and the scope we recommend for it.
- Contains: The Anti-DDoS AMR rule group.
- Why it's its own NSM policy: It must run before every other NSM traffic inspection rule, so that it sees all traffic before any other WAF rule can end evaluation, including the IP allow list. Priorities 1–9 stay free, so that you can still add exceptions before it.
- Scope: All Public Facing Resources.
- Most common owner: Cloud architect or central operator.
- Contains: No NSM rules. Shield Advanced protection is a setting on the NSM policy itself.
- What it provides: Shield Advanced provides enhanced layer 3 and layer 4 DDoS protection, including for non-HTTP and Regional endpoints. It also includes layer 7 protections, such as the Anti-DDoS AMR, under a different cost model, and adds features such as Shield Response Team (SRT) engagement and cost protection.
- Why it's its own NSM policy: It configures Shield Advanced rather than AWS WAF, and you might choose to protect a different set of resources than the WAF baseline. It doesn't affect WAF rule order.
- Scope: All Public Facing Resources.
- Most common owner: Cloud architect or central operator.
- Contains: NSM firewall configuration rules for settings that security mandates on every public-facing web ACL, such as WAF logging to a central bucket. It doesn't contain settings that depend on application context, such as the default action or token domains. Those belong in WAF default things or in application NSM policies.
- Why it's its own NSM policy: These settings rarely need exceptions, and any exception would be a truly unique one-off. Its low priority number means that it wins when another NSM policy sets the same property. It contains only NSM firewall configuration rules, so it doesn't affect WAF rule order.
- Scope: All Public Facing Resources.
- Most common owner: Cloud architect or central operator.
- Contains: An IP allow list NSM rule, with an IP set of trusted addresses and an allow action. Use sparingly or not at all, because allowed requests skip every WAF rule after it.
- Why it's its own NSM policy: It must run after Anti-DDoS and before every blocking NSM policy, and allow lists often differ by application.
- Scope: All Public Facing Resources for organization-wide trusted addresses, or Application for addresses that only one application trusts.
- Most common owner: App team requested.
40 – Threat intelligence/block lists
- Contains: NSM rules that block requests that match threat intelligence, such as an IP block list NSM rule with IPv4 and IPv6 IP sets. Threat intelligence doesn't need to be IP-based. It can include JA3 or JA4 fingerprints, or anything else that a WAF rule can match.
- Why it's its own NSM policy: The threat analysts own and update it on their own schedule, and changes to their threat intelligence reach every in-scope resource without changing anyone else's NSM policies.
- Scope: All Public Facing Resources.
- Most common owner: Threat analysts.
- Contains: The Amazon IP reputation list and anonymous IP list AMR rule groups.
- Why it's its own NSM policy: These WAF rules are inexpensive to evaluate and remove known-bad and anonymized traffic before content inspection, so they run right after threat intelligence, before the geo and rate checks and the baseline AMRs.
- Scope: All Public Facing Resources.
- Most common owner: Cloud architect or central operator.
- Contains: A geo blocking NSM rule that blocks a list of countries, or every country that isn't on an allowed list.
- Why it's its own NSM policy: Allowed and blocked countries often differ by application, so geo blocking often needs a different scope than the central baseline.
- Scope: All Public Facing Resources for countries that the whole organization blocks, or Application for application-specific restrictions.
- Most common owner: Cloud architect or central operator.
- Contains: A blanket rate limit NSM rule with a high-bar rate-based WAF rule, usually by client IP address, across all requests.
- Why it's its own NSM policy: It stops request floods before they reach more expensive WAF rules, and its threshold applies to every public-facing application.
- Scope: All Public Facing Resources.
- Most common owner: Cloud architect or central operator.
- Contains: The baseline AMR rule groups that every public-facing application needs, with every WAF rule in count mode, such as the Core Rule Set and Known Bad Inputs. For every baseline AMR rule group, see Baseline rule groups.
- Why it's its own NSM policy: Count mode labels matching requests without blocking them, so application exception NSM policies can act on those labels before AMR block with exceptions enforces them.
- Scope: All Public Facing Resources.
- Most common owner: Cloud architect or central operator.
101–199 – Use-case AMRs in count
- Contains: One NSM policy for each use-case AMR rule group that your applications need, such as WordPress or SQL database. Each has every WAF rule in count mode. For every use-case AMR rule group, see Use-case specific rule groups.
- Why each is its own NSM policy: Each use-case AMR rule group applies only to applications that use that technology, so each needs its own scope.
- Scope: The Technology apps scope for that technology.
- Most common owner: Cloud architect or central operator.
Exceptions to NSM policies below priority 200
Apart from the AMRs in count, the NSM policies above this point aren't normally in the purview of application teams to request exceptions to. Keep exceptions to these NSM policies to true one-offs. If application teams regularly need exceptions to one of these NSM policies, consider moving that NSM policy closer to or above priority 200, so that you can grant exceptions with the label-based exceptions pattern that follows.
200–9499 – Application exceptions
One NSM policy for each application, owned by that application's team, that grants the application exceptions to the baseline AMRs. The same NSM policy can also contain protections that only that application needs. The range leaves room for thousands of applications.
- AMR exceptions, such as app1.example.com exceptions
- Contains: Application exceptions for App1, such as a WAF rule that adds an exception label to requests for one URI path.
- Why it's its own NSM policy: The App1 team owns it, and it must reach only App1's web ACLs. It runs after the AMRs in count and before the block NSM policies, because a WAF rule can read only the labels that earlier WAF rules added.
- Scope: Application, for App1 only.
- Most common owner: App team requested.
- Application-specific protections
- Contains: Application-specific protections for each application, such as scoped rate limits for a login page or an expensive API.
- Why each is its own NSM policy: Each application team owns its own NSM policy, so protections for one application don't affect any other application.
- Scope: Application, one for each application.
- Most common owner: App team requested.
9500 – AMR block with exceptions
- Contains: AMR block with exceptions NSM rules, one for each unique label that the baseline AMRs add. Each blocks requests that carry its AMR label, unless the request also carries the matching exception label.
- Why it's its own NSM policy: It must run after every exception NSM policy, so that it can read their exception labels.
- Scope: All Public Facing Resources, the same scope as AMRs-in-Count.
- Most common owner: Cloud architect or central operator.
9501–9599 – Use-case AMR blocks with exceptions
- Contains: One NSM policy for each use-case AMR rule group, with AMR block with exceptions NSM rules that block requests that the AMR rule group labeled, unless the request also carries an exception label.
- Why each is its own NSM policy: Each block NSM policy must reach the same resources as the use-case AMR NSM policy that it enforces.
- Scope: The same Technology apps scope as the matching use-case AMR NSM policy.
- Most common owner: Cloud architect or central operator.
- Contains: Partner managed rule groups from AWS Marketplace.
- Why it's its own NSM policy: Partner rule groups have per-request costs, so they run after the free WAF rules, and requests that were already blocked don't add cost.
- Scope: All Public Facing Resources or Application, depending on which applications need the partner protections.
- Most common owner: App team requested.
- Contains: The Bot Control AMR rule group with a scope-down statement.
- Why it's its own NSM policy: Bot Control has per-request charges, so it runs near the end, after every other filter.
- Scope: All Public Facing Resources or Application, depending on which applications need bot management.
- Most common owner: App team requested.
- Contains: The Account Takeover Prevention (ATP) and Account Creation Fraud Prevention (ACFP) AMR rule groups, scoped down to each application's login and sign-up pages.
- Why it's its own NSM policy: Fraud Control has the highest per-request charges, so it runs last, and each application has its own login and sign-up pages.
- Scope: Application.
- Most common owner: App team requested.
- Contains: NSM firewall configuration rules for settings that have application considerations, such as the web ACL default action, token domains, and visibility configuration.
- Why it's its own NSM policy: Its high priority number makes it a fallback that any more specific NSM policy can override. It doesn't affect WAF rule order.
- Scope: All Public Facing Resources.
- Most common owner: Cloud architect or central operator.