Cloud / AWS WAF & Shield Interview questions

AWS WAF is a managed web application firewall that filters HTTP and HTTPS requests at Layer 7 before they reach your application. You write rules that look at the IP address, headers, URI, query string, cookies or body, and each rule decides whether to allow, block, count or challenge the request.

It sits in front of CloudFront, Application Load Balancer, API Gateway (REST), AppSync, Cognito user pools, App Runner and Verified Access. Typical uses are blocking SQL injection and cross-site scripting, rate limiting abusive clients, filtering by country and keeping bad bots away.

Pricing is pay-as-you-go: you pay per web ACL, per rule and per million requests inspected. There is no hardware or software to manage.

AWS Shield is AWS's managed DDoS (Distributed Denial of Service) protection service. It detects and absorbs floods of malicious traffic aimed at your applications so legitimate users keep getting through.

It comes in two tiers. Shield Standard is on by default for every AWS customer at no extra charge and covers common network and transport layer (L3/L4) attacks. Shield Advanced is a paid subscription that adds L7 protection, attack visibility, 24/7 access to the Shield Response Team and DDoS cost protection.

Shield does not inspect request content the way a firewall does. It focuses on volume and protocol abuse, and it is usually paired with AWS WAF for application-layer rules.

AWS Shield has Shield Standard and Shield Advanced.

Advanced covers CloudFront, Route 53 hosted zones, Global Accelerator, Elastic Load Balancing and Elastic IPs.

A web ACL (web access control list) is the container that holds your AWS WAF rules and rule groups, plus a default action (Allow or Block) for requests that match nothing. You associate it with one or more protected resources, and every request to those resources is evaluated against it.

A resource can have only one web ACL at a time, but one web ACL can protect many resources. A web ACL also has a scope: CLOUDFRONT (global, created in us-east-1) or REGIONAL (tied to a Region). Rules inside it run in priority order, lowest number first.

Newer console screens may label it a protection pack, but the API and most documentation still say web ACL.

AWS WAF attaches to a specific set of front-door services rather than to arbitrary compute:

• Amazon CloudFront distributions
• Application Load Balancers
• Amazon API Gateway REST APIs (at the stage level)
• AWS AppSync GraphQL APIs
• Amazon Cognito user pools
• AWS App Runner services
• AWS Verified Access instances
• Amazon Bedrock AgentCore Gateway

Network Load Balancers, EC2 instances and API Gateway HTTP APIs cannot take a web ACL directly. The usual workaround is putting CloudFront or an ALB in front of them.

A rule tells AWS WAF what to look for and what to do when it finds it. It has a name, a priority, a statement (the match logic), an action and a visibility configuration for CloudWatch metrics and sampled requests.

Statements can be simple, like an IP set match, or nested with AND, OR and NOT to build conditions such as 'URI starts with /admin AND country is not US'. Rules you reuse can be grouped into a rule group, and AWS or Marketplace sellers publish managed rule groups you can drop in.

{
  "Name": "BlockAdminFromOutside",
  "Priority": 10,
  "Statement": { "ByteMatchStatement": { "SearchString": "/admin", "FieldToMatch": { "UriPath": {} },
    "TextTransformations": [{ "Priority": 0, "Type": "NONE" }], "PositionalConstraint": "STARTS_WITH" } },
  "Action": { "Block": {} },
  "VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true, "MetricName": "BlockAdmin" }
}

A rule can take one of five actions:

Allow and Block are terminating. Count is non-terminating, which is why it is the safe way to test a new rule before enforcing it.

AWS Managed Rules are rule groups written and updated by AWS security teams, so you get tested protections without authoring regexes yourself. You add a rule group to your web ACL as one reference and AWS maintains the rules behind it.

The baseline groups include the Core rule set (OWASP-style protections), Admin protection and Known bad inputs. Use-case groups cover SQL database, Linux, POSIX, PHP and Windows exploits. IP reputation groups cover Amazon IP reputation and Anonymous IP lists.

Intelligent threat groups, such as Bot Control, Account Takeover Prevention, Account Creation Fraud Prevention and Anti-DDoS, are paid add-ons with extra fees. Third-party sellers also offer managed groups on AWS Marketplace.

A rate-based rule counts requests from each client over a time window and takes action once a client crosses your limit. It is the standard answer to HTTP floods, brute-force logins and scrapers.

By default it groups requests by source IP. You set a limit (minimum 10) and the window, then choose Block, Count, CAPTCHA or Challenge. When the client's rate drops back under the limit, the action stops being applied automatically.

A single rate-based rule can track up to 10,000 distinct IPs being rate limited at once, and a web ACL can hold up to 10 of them.

An IP set is a reusable list of IPv4 or IPv6 addresses in CIDR notation that rules can reference. Instead of writing hundreds of addresses into a rule, you keep them in the set and point a rule at it with an IP set reference statement.

Each set holds up to 10,000 addresses, and you can update it without touching the rule. That makes it a good fit for office allow lists, partner ranges and block lists fed by a threat feed.

An IP set match is also one of the cheapest conditions in WCU terms, so it is worth using before heavier regex rules.

The default action is what the web ACL does with a request that matches no rule with a terminating action. You must pick either Allow or Block when you create the web ACL.

Most public websites use Allow as the default and add Block rules for known bad traffic. Internal or partner-only APIs often flip it: default Block, plus explicit Allow rules for approved IP ranges or headers.

Like rule actions, the default action can carry custom response codes and headers, so a blocked client can get a friendly 403 page instead of the stock message.

WCUs are a measure of how much processing power your rules need. Each rule costs a number of units based on its complexity: an IP set match costs 1, while a regex pattern set match costs 25.

A rule group's capacity is fixed when you create it and cannot be changed later, so you have to size it up front. A rule group can use up to 5,000 WCUs, and so can a web ACL.

The base web ACL price includes 1,500 WCUs. Going past that adds a per-request fee in tiers, so WCUs affect both design limits and your bill. They do not change how deeply AWS WAF inspects traffic.

AWS WAF works on web traffic, so it targets application-layer threats:

• Injection attacks - SQL injection and command injection patterns in query strings, headers or bodies
• Cross-site scripting (XSS) - script payloads in request fields
• Known exploit patterns - for example Log4j-style payloads and path traversal
• HTTP floods - via rate-based rules and the Anti-DDoS rule group
• Bots and scrapers - through Bot Control and CAPTCHA or Challenge
• Credential abuse - stuffing and fake sign-ups via ATP and ACFP
• Unwanted sources - by country, ASN, or IP reputation

It does not stop volumetric network floods such as SYN or UDP floods. That is Shield's job.

Shield Standard defends against the most common infrastructure-layer (L3 and L4) DDoS attacks, using always-on detection and inline mitigation in the AWS network.

• SYN and ACK floods that exhaust connection tables
• UDP floods
• Reflection and amplification attacks such as DNS or NTP reflection

It needs no configuration and costs nothing. It gives the strongest protection when your app is behind CloudFront and Route 53, because attack traffic is absorbed at the edge. It does not cover Layer 7 floods, which need WAF rules or Shield Advanced.

The Shield Response Team (SRT) is a group of AWS DDoS specialists you can call on during an attack if you subscribe to Shield Advanced and have a Business or Enterprise Support plan. You open a case and they help triage, analyze traffic and suggest mitigations.

If you grant them access, the SRT can write or adjust AWS WAF rules in your account on your behalf during an event. You give that permission through a dedicated IAM role, and optionally let them read your WAF logs in S3.

The team used to be called the DDoS Response Team (DRT), and you may still see that name in older docs and API calls.

DDoS cost protection is a Shield Advanced benefit that lets you request AWS service credits for usage spikes caused by a DDoS attack. If your protected resources scale out under attack, you are not stuck paying for that surge.

It covers scaling charges on protected Amazon EC2, Elastic Load Balancing, CloudFront, Global Accelerator and Route 53 resources. You file the request through the normal AWS Support channel after the event.

It is a credit for scaling cost, not a refund of the Shield subscription itself.

AWS Firewall Manager lets a central security team define firewall policies once and enforce them across every account in an AWS Organization. Instead of configuring AWS WAF in 40 accounts by hand, you create one policy and Firewall Manager applies it.

It manages AWS WAF, Shield Advanced, VPC security groups, Network Firewall, Route 53 Resolver DNS Firewall and more. Policies are scoped by account, organizational unit, resource type or tag, and new resources that match the scope are covered automatically.

It requires AWS Organizations, a designated Firewall Manager administrator account, and AWS Config enabled in the member accounts.

Labels are tags that a rule attaches to a request while it is being evaluated. A later rule in the same web ACL can match on that label, which lets you split detection from decision.

Managed rule groups use labels heavily. For example, Bot Control labels a request as a verified bot or a scraper, and you can write your own rule that allows one label and rate limits another instead of accepting the group's built-in action.

Labels exist only for that request inside that web ACL. They are not sent to your origin, but they do show up in WAF logs and CloudWatch metrics. A rule can only read labels added by rules with a lower priority number, because those run first.

Logging is enabled per web ACL, not account-wide. You pick one destination and AWS WAF writes a JSON record for each inspected request.

The destination name must start with aws-waf-logs-. In the console, open the web ACL, go to Logging and metrics, enable logging and choose the destination. Each record includes the action, the terminating rule, matched labels and full request details such as headers and URI.

AWS WAF statements can match on many parts of a request:

• IP address - single IP, CIDR range or IP set
• Geo match - by country, plus ASN match for network owner
• String match - contains, starts with, ends with, exactly, or regex
• SQLi and XSS match - built-in detection on a chosen field
• Size constraint - length of body, header, query string or URI
• Label match - react to labels set by earlier rules
• Rate-based - count requests per key over a window
• Rule group reference - your own or managed rule groups

The part of the request to inspect (URI path, query string, a named header, cookies, JSON body, method) is chosen with a 'field to match', and text transformations such as URL decoding can be applied first. Any of these can be combined with AND, OR and NOT.

Bot Control (AWSManagedRulesBotControlRuleSet) is a paid managed rule group that detects and manages automated traffic. It comes in two inspection levels.

• Common - identifies self-declared bots by user agent and verifies well-known ones, such as search engines, through reverse DNS
• Targeted - goes after evasive bots using browser interrogation, fingerprinting and behavior analysis, and relies on CAPTCHA or Challenge tokens

Instead of blocking everything, it mostly labels traffic by category (verified bot, scraper, HTTP library and so on). You then decide per label: allow search engines, count monitoring tools, block scrapers. Because it adds per-request fees, scope it down to the paths that matter.

They solve different problems and are meant to be used together. WAF looks at what a request says; Shield looks at how much traffic is arriving and whether it abuses the network protocol.

A SQL injection attempt is a WAF problem. A 500 Gbps UDP flood is a Shield problem. An HTTP flood is where the two overlap, and Shield Advanced uses WAF rules to mitigate it.

Stay on Standard if an outage from a DDoS would be annoying but not costly. Move to Advanced when downtime or surprise bills would hurt. Typical triggers:

• Revenue-critical sites such as e-commerce, gaming, fintech or media streaming
• You have been targeted before, or expect extortion-style (ransom DDoS) attempts
• You need L7 DDoS detection and mitigation without building it all yourself
• You want the Shield Response Team on call and proactive engagement
• Your workload autoscales heavily and a flood could generate a large bill
• Compliance or customers expect documented DDoS protections

The $3,000 monthly fee covers the whole organization, so it is easier to justify when many accounts share it. Remember that SRT access also requires a Business or Enterprise Support plan, which is an extra cost to plan for.

AWS WAF checks rules in ascending priority order: the lowest number runs first. As soon as a rule with a terminating action (Allow or Block) matches, evaluation stops and that action is applied.

Non-terminating actions such as Count do not stop the flow. The request moves on to the next rule, and any labels or counts are recorded along the way. If it passes every rule without a terminating match, the web ACL default action decides its fate.

flowchart TD
  A["Request arrives"] --> B{Next rule by priority}
  B -->|Match + Allow or Block| C["Apply action and stop"]
  B -->|Match + Count| D["Count and label"]
  D --> B
  B -->|No match| B
  B -->|No rules left| E["Apply default action"]

This is why order matters. Put a cheap Allow for trusted IPs near the top and block rules before expensive inspection.

Count mode lets a rule match and be logged without affecting the request, so you can see what it would have blocked before it blocks anything real. New rules, especially regex and managed groups, can catch legitimate traffic you did not think of.

1. Add the rule with the action set to Count (or override a managed rule's action to Count)
2. Watch CloudWatch metrics, sampled requests and WAF logs for a few days across peak traffic
3. Check whether matches are real attacks or valid users, such as large form posts or API clients
4. Tune or scope the rule, then switch to Block

Count also still adds labels, so you can build label-based logic while the rule is in observation. Skipping this step is a common reason a new rule causes an outage on release day.

A web ACL has one of two scopes, chosen at creation, and it cannot be changed afterwards.

Rule groups, IP sets and regex sets also have a scope and cannot be shared across scopes. To cover both a CloudFront distribution and an ALB, you need two web ACLs, and Firewall Manager can keep them in sync.

AWS WAF only inspects the first part of a body. For ALB and AppSync that limit is a fixed 8 KB. For CloudFront, API Gateway, Cognito, App Runner and Verified Access it is 16 KB by default and can be raised up to 64 KB (extra fee per additional 16 KB).

What WAF does next is set per rule through oversize handling:

• CONTINUE - inspect the portion available and judge on that
• MATCH - treat the oversized request as a match
• NO_MATCH - treat it as not matching

This is a real bypass route. An attacker can pad a payload with junk so the malicious part sits beyond the limit. The fix is a size constraint rule that blocks bodies over the limit on endpoints that never need big payloads, and a separate allowance for upload paths. Headers and cookies have similar limits (first 8 KB or 200 items).

A rate-based rule keeps a running count per aggregation key over a sliding time window and acts once that count passes your limit.

• Window - 1, 2, 5 or 10 minutes (5 is the default)
• Limit - the request threshold per key, minimum 10
• Key - source IP by default, or forwarded IP, header, cookie, query argument, URI path, HTTP method, label namespace, JA3 or JA4 fingerprint, and combinations of these
• Scope-down - an optional statement to count only a subset, such as POST /login

Custom keys are what make it useful beyond plain IP limits. For example, you can cap each API key or each session cookie separately, so a shared corporate NAT address does not lock out a whole office. Enforcement is not instant; expect a short delay between crossing the threshold and the action starting.

A scope-down statement narrows which requests a rule or managed rule group looks at. You use it when only part of your traffic needs the check, which makes rules both more accurate and cheaper.

• Rate limit only /login or /api/search instead of the whole site
• Run Bot Control, ATP or ACFP only on sensitive paths, since they charge per inspected request
• Skip inspection for a known-safe path that keeps triggering a managed rule
• Apply a rule only to a specific host header in a shared web ACL

"ScopeDownStatement": {
  "ByteMatchStatement": {
    "SearchString": "/login",
    "FieldToMatch": { "UriPath": {} },
    "TextTransformations": [{ "Priority": 0, "Type": "NONE" }],
    "PositionalConstraint": "STARTS_WITH"
  }
}

One exception: AWS recommends against scope-down on the Anti-DDoS rule group, since it needs to see all traffic.

AWS WAF has built-in SQLi and XSS match statements. You pick which part of the request to inspect (query string, body, a header, cookies) and the engine looks for attack syntax rather than a fixed string.

Text transformations make the check harder to evade. URL decoding, HTML entity decoding and lowercase conversion run first, so an encoded payload like %27%20OR%201%3D1 is normalized before matching. The SQLi statement also has a sensitivity level, LOW or HIGH; HIGH catches more but can raise false positives.

You can skip writing these yourself by using the AWS Managed Rules SQL database group and the Core rule set. Remember that WAF is a safety net. The real fix is parameterized queries and output encoding in the application.

If CloudFront or another proxy sits in front of your ALB, the ALB-level web ACL sees the proxy's address as the source. IP rules, geo match and rate limits would then hit the wrong address.

The fix is the forwarded IP configuration. You tell the rule to read the client address from a header, usually X-Forwarded-For, and choose which entry to use (first, last or any). You also set a fallback behavior, MATCH or NO_MATCH, for requests where the header is missing or malformed.

This works for IP set match, geo match and rate-based rules. Keep in mind that clients can forge X-Forwarded-For, so trust it only when a proxy you control sets it. Attaching the web ACL at CloudFront, the true edge, avoids the problem.

Nothing breaks. A web ACL can use up to 5,000 WCUs, and the 1,500 mark is simply where the base price stops. Beyond it, AWS WAF adds a request charge in tiers, currently $0.20 per million requests for each additional 500 WCUs used.

The hard limit is 5,000. Past that, you cannot add rules, and a rule group's own capacity cannot exceed 5,000 either. Since rule group capacity is permanent, you have to rebuild the group to change it.

Ways to stay under the line: replace many IP rules with one IP set, avoid regex pattern sets (25 WCUs each), drop duplicate or overlapping rules, and check the capacity of each managed group before adding it.

Both actions check whether the client holds a valid AWS WAF token. If it does, the request passes. If not, WAF blocks the request and sends a check instead.

Once the client solves the check, it gets a token stored as a cookie, and the immunity time (default 300 seconds) decides how long the token is trusted before another check. These actions work for normal browser page loads. For fetch or XHR calls, mobile apps or single-page apps, you integrate the AWS WAF JavaScript or mobile SDK so the client can fetch and attach tokens itself.

Raw WAF logs can hold tokens, passwords in query strings or cookies you would rather not store. Two logging settings handle that:

• Redacted fields - choose request parts to mask in the logs: URI path, query string, a named header, the HTTP method, or the body (JSON body fields). The value is replaced, but the rest of the record stays intact.
• Logging filter - keep or drop records by condition, for example keep only Block and Count, or only requests carrying a specific label.

Filtering matters for cost. Logging every allowed request on a busy site can dwarf your WAF bill in S3 or CloudWatch Logs ingestion. A common pattern is to log blocked and counted requests plus a labeled sample of allowed ones, then use Athena over S3 for investigations.

The Anti-DDoS managed rule group (AWSManagedRulesAntiDDoSRuleSet) watches traffic to the web ACL, learns what normal looks like, and detects HTTP request floods. It labels requests, marks the likely attackers by suspicion level and then challenges or blocks them.

• Every inspected request gets labels such as event-detected and low, medium or high suspicion
• Challenge can run silently in the browser, and you can exempt non-HTML paths such as APIs
• Sensitivity (Low, Medium, High) is set separately for Block and Challenge
• It needs 50 WCUs and no Route 53 health checks

Place it at the highest priority, or right under custom Allow rules, so it sees as much traffic as possible. Any customer can use it for an added fee, and Shield Advanced subscribers get it included. During active mitigation, blocked attack requests are excluded from request charges.

Start with evidence from the logs, not guesses. Each blocked record names the rule that stopped the request.

1. Ask for the time, URL and client IP, or a request ID from the 403 page
2. Find the entry in WAF logs or sampled requests and read terminatingRuleId and ruleGroupList to see which rule fired
3. If it came from a managed group, note the exact sub-rule, for example a body size or XSS rule
4. Switch only that sub-rule to Count with a rule action override
5. Add a narrow exception: a scope-down or a label-based Allow for that path, not a blanket Allow
6. Re-test and monitor the Count metrics before turning it back to Block

fields @timestamp, httpRequest.clientIp, httpRequest.uri, terminatingRuleId, action
| filter action = 'BLOCK' and httpRequest.uri like /checkout/
| sort @timestamp desc
| limit 50

Avoid disabling the whole rule group. That removes protection for every other path.

Create a regional web ACL in the same Region as the API, then associate it with the API's stage. WAF runs before the request reaches your integration, so blocked calls never invoke a Lambda or backend.

aws wafv2 associate-web-acl \
  --web-acl-arn arn:aws:wafv2:us-east-1:111122223333:regional/webacl/api-acl/abcd1234 \
  --resource-arn arn:aws:apigateway:us-east-1::/restapis/a1b2c3/stages/prod

Association is per stage, so dev and prod can have different web ACLs. Only REST APIs are supported. HTTP APIs and WebSocket APIs cannot take a web ACL directly, so place CloudFront in front of them.

Useful rules for APIs: a rate-based rule keyed on the API key or Authorization header, the Core rule set and Known bad inputs groups, and an IP allow list for partner-only endpoints. WAF complements API Gateway throttling and usage plans, it does not replace them.

A Block action can return your own status code, headers and body instead of the default 403. This is handy for a branded error page, a 429 on rate limiting, or a JSON error for API clients.

1. Define a custom response body at the web ACL level with a key, content type (text, JSON or HTML) and content
2. In the rule's Block action, enable custom response and set the status code and any headers
3. Reference the body by its key

The combined size of all custom response bodies in a web ACL or rule group is capped at 50 KB.

Other actions can add things too. Allow, Count, CAPTCHA and Challenge can insert custom request headers. WAF prefixes them with x-amzn-waf-, so your origin can see a tag such as which rule matched and handle that traffic differently.

Account Takeover Prevention (ATP) is a managed rule group (AWSManagedRulesATPRuleSet) that protects login endpoints from stolen credential use, credential stuffing and brute force.

You tell it your login path and how credentials are sent (field names for username and password, JSON or form encoded). ATP then does three things:

• Checks submitted credentials against a database of known-compromised credentials
• Tracks volumetric behavior per IP, session and username
• Optionally inspects your login responses to count failed versus successful logins

Response inspection works only for CloudFront distributions. ATP works best with the AWS WAF client SDK on the login page, because tokens let it tie attempts to a browser session. It adds labels and per-request fees, so keep it scoped to the login path.

Account Creation Fraud Prevention (ACFP) (AWSManagedRulesACFPRuleSet) guards sign-up flows against fake account creation, such as bots farming promo credits.

Configuration is similar to ATP but for registration: you give it the registration page path, the account creation endpoint, and where to find fields like username, password, email, phone number and address.

• Flags sign-ups using stolen credentials
• Detects bulk creation from one IP, session or device
• Evaluates email domains and phone numbers for signs of abuse
• Uses AWS WAF tokens, so the SDK or Challenge on the registration page is strongly recommended

Like ATP, response inspection to see whether account creation succeeded is available only on CloudFront.

Automatic mitigation lets Shield Advanced respond to HTTP floods without a human writing rules. For a protected resource with a web ACL, Shield learns its normal traffic baseline, and when it spots an attack signature it creates WAF rules in a Shield-managed rule group and applies them in Count or Block mode.

It relies on Route 53 health checks for health-based detection and uses 150 WCUs of the web ACL.

flowchart LR
  A["Baseline learned"] --> B["Attack detected"]
  B --> C["Shield creates WAF rules"]
  C --> D{Mode}
  D -->|Count| E["Observe only"]
  D -->|Block| F["Drop attack traffic"]

Update: AWS is replacing this feature with the WAF Anti-DDoS managed rule group. Per the AWS Security Blog, auto-upgrade of eligible web ACLs begins October 25, 2026 and automatic mitigation is scheduled to retire January 29, 2027. Verify the current timeline before relying on either.

With proactive engagement, the Shield Response Team contacts you first when an attack seems to be hurting your application, instead of waiting for you to notice and open a case.

1. Associate a Route 53 health check with the protected resource, one that reflects real application health
2. Register your emergency contacts: email, phone number and notes for the on-call person
3. Enable proactive engagement in Shield Advanced
4. When Shield detects an event and the health check turns unhealthy, the SRT reaches out using those contacts

The health check is the trigger. A check that is too shallow, such as a ping on an unused port, will not fail when the app is really struggling, and the engagement never fires. Keep contacts current, since outdated numbers defeat the point.

Credits are not automatic. You can ask for them after a DDoS event raised your usage, provided you meet the conditions:

• The resource was protected by Shield Advanced before the attack (a short lead time is required)
• For CloudFront and ALB, a web ACL with a rate-based rule was associated
• The spike in charges came from scaling on a covered service such as EC2, ELB, CloudFront, Global Accelerator or Route 53
• The event is confirmed as a DDoS attack

You file the claim through AWS Support with the affected resources and time window. The credit covers the extra scaling charges only; the Shield subscription fee and data transfer fees under Shield Advanced still apply. Check the current terms for exact eligibility windows.

Shield Advanced is a subscription first, then per-resource protections.

1. Subscribe (one-year commitment). In an AWS Organization the fee is $3,000/month for the whole organization.
2. Add protection for each resource: CloudFront distribution, Route 53 hosted zone, Global Accelerator, ALB or Classic Load Balancer, or Elastic IP
3. Associate a web ACL for L7 coverage, and a Route 53 health check for health-based detection
4. Turn on proactive engagement and add emergency contacts
5. Optionally grant the SRT access with an IAM role
6. Create CloudWatch alarms on the DDoSDetected metric

aws shield create-subscription
aws shield create-protection \
  --name prod-alb \
  --resource-arn arn:aws:elasticloadbalancing:us-east-1:111122223333:loadbalancer/app/prod/abc123

Firewall Manager can apply protections across accounts automatically.

A Firewall Manager administrator account creates an AWS WAF policy that contains the rule groups to enforce, plus a scope: which accounts or OUs, which resource types, and optionally which tags. Firewall Manager then creates or updates a web ACL in each in-scope account.

flowchart TD
  A["FM admin account: policy"] --> B["Member account 1"]
  A --> C["Member account 2"]
  A --> D["New account joins OU"]
  B --> E["Web ACL with FM rule groups"]
  C --> F["Web ACL with FM rule groups"]
  D --> G["Policy applied automatically"]

Firewall Manager owns a first and last set of rule groups in each web ACL. Account owners can add their own rules in the middle. With auto-remediation on, existing resources without protection get the web ACL, and drift is corrected. AWS Config must be enabled in the accounts for Firewall Manager to track resources.

The idea is to absorb attacks at the edge, shrink what is exposed, and scale what remains.

flowchart LR
  U[Users] --> R53["Route 53"]
  R53 --> CF["CloudFront + WAF + Shield"]
  CF --> ALB["ALB in public subnet"]
  ALB --> ASG["Auto Scaling app tier"]
  ASG --> DB[(Private database)]

The weakest link is often an origin reachable directly by IP. If attackers can bypass CloudFront, the edge protection is wasted.

In a typical protected setup, traffic passes several checkpoints before your application sees it.

sequenceDiagram
  participant C as Client
  participant D as Route 53
  participant E as CloudFront edge (Shield)
  participant W as AWS WAF web ACL
  participant O as Origin ALB
  C->>D: Resolve domain
  D-->>C: Edge IP
  C->>E: HTTPS request
  E->>E: Shield filters L3/L4 floods
  E->>W: Evaluate rules by priority
  alt Block
    W-->>C: 403 or custom response
  else Allow
    W->>O: Forward request
    O-->>C: Response via CloudFront
  end

1. DNS resolves to the nearest CloudFront edge, and Route 53 itself is protected by Shield
2. Shield filters volumetric and protocol attacks before the request is processed
3. The WAF web ACL evaluates rules in priority order and either blocks or lets the request through
4. Allowed requests go to the origin, which can run its own regional web ACL
5. Logs and metrics are produced for each decision

Many AWS Managed Rules groups are versioned. By default, your web ACL uses the default version, which AWS updates over time as it adds or tunes rules. That keeps you current, but a rule change can occasionally affect traffic that used to pass.

You can instead pin a static version. The behavior stays frozen until you move it yourself, which gives you a controlled upgrade path.

1. Subscribe to the managed rule group's SNS notifications, so you hear about new versions and updates
2. Create a test web ACL (or a duplicate rule) pointing at the new version, with actions overridden to Count
3. Compare matches to the current version using logs
4. Switch production to the new version when it looks safe

Static versions do not last forever. AWS eventually retires old ones, so pinning is a delay tactic, not a permanent setting.

WAF cost is mostly requests, rules and extras. Know the pricing parts first: a monthly fee per web ACL ($5), a monthly fee per rule or rule group ($1 each), a per-million-request charge, and add-ons for WCUs beyond 1,500, larger body inspection and the intelligent threat groups.

• Share one web ACL across many resources where the rules fit; the web ACL fee is per ACL
• Scope down Bot Control, ATP, ACFP and Anti-DDoS to the paths that need them
• Order rules so cheap Allow and Block rules (IP sets, geo) run before expensive inspection
• Replace many IP rules with a single IP set and avoid regex pattern sets (25 WCUs)
• Keep body inspection at the default unless you truly need more
• Use logging filters to avoid storing every allowed request
• If you run Shield Advanced, use the WAF fee waiver on protected resources

Always check the current price list. Rates change by Region and feature.

Treat the web ACL like application code: define it in CloudFormation, Terraform or CDK, review it in pull requests and deploy it through a pipeline.

Resources:
  AppWebAcl:
    Type: AWS::WAFv2::WebACL
    Properties:
      Scope: REGIONAL
      DefaultAction: { Allow: {} }
      VisibilityConfig:
        SampledRequestsEnabled: true
        CloudWatchMetricsEnabled: true
        MetricName: AppWebAcl
      Rules:
        - Name: CommonRules
          Priority: 10
          OverrideAction: { None: {} }
          Statement:
            ManagedRuleGroupStatement: { VendorName: AWS, Name: AWSManagedRulesCommonRuleSet }
          VisibilityConfig:
            SampledRequestsEnabled: true
            CloudWatchMetricsEnabled: true
            MetricName: CommonRules

• Keep IP sets and custom rule groups as separate resources so they can be updated alone
• Size rule group capacity carefully, since changing it forces a replacement
• Ship new rules in Count first, then promote to Block in a later commit
• Use drift detection, and remember Firewall Manager or Shield changes can alter a web ACL outside your template