<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									AWS Shield and WAF Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/cyber-aws-shield-waf/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Fri, 02 Oct 2026 09:58:41 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Opinion: The &#039;Block&#039; action is overused. &#039;Count&#039; and &#039;Challenge&#039; are smarter.</title>
                        <link>https://communities.stackinsight.net/community/cyber-aws-shield-waf/opinion-the-block-action-is-overused-count-and-challenge-are-smarter-2/</link>
                        <pubDate>Sun, 27 Sep 2026 16:26:13 +0000</pubDate>
                        <description><![CDATA[Hey folks, been tuning our WAF rules lately and I&#039;ve had a realization I wanted to share. I think we&#039;re all a bit too trigger-happy with the **`Block`** action. It&#039;s the default, it feels sa...]]></description>
                        <content:encoded><![CDATA[Hey folks, been tuning our WAF rules lately and I've had a realization I wanted to share. I think we're all a bit too trigger-happy with the **`Block`** action. It's the default, it feels safe, but it can also blind you and cause unnecessary user friction.

I've started leaning heavily on **`Count`** for new or complex rules, and **`Challenge`** (like CAPTCHA) for suspicious but not clearly malicious traffic. Here's why:

*   **`Count` lets you learn without breaking things.** You can deploy a rule, see its volume in your dashboards (I pipe everything into Datadog), and verify it's catching what you expect *before* you start blocking. No more "why is traffic down?" surprises.
*   **`Challenge` is a fantastic filter for scripted traffic.** Real humans can pass it, simple bots get stuck. It's perfect for those grey-area requests—like a burst of login attempts from a new ASN.

For example, I had a rule to flag `User-Agent` strings from a known bad scanner. Instead of blocking outright, I set it to `Count` for a week. My Datadog logs revealed it was also catching a few legitimate internal health checks! &#x1f605; Saved us an outage.

Here's a quick CloudFormation snippet for a rule that counts first:

```yaml
  ManagedRuleGroup:
    Type: AWS::WAFv2::WebACL
    Properties:
      Rules:
        - Name: ProbingScannerRule
          Priority: 10
          Statement:
            ManagedRuleGroupStatement:
              VendorName: AWS
              Name: AWSManagedRulesCommonRuleSet
          OverrideAction:
            Count: {}
          VisibilityConfig:
            CloudWatchMetricsEnabled: true
            MetricName: ProbingScannerRule
            SampledRequestsEnabled: true
```

After you validate the metrics, you can switch `OverrideAction` to `Block` or `Challenge`. This approach has made our WAF way more adaptive and less of a blunt instrument. Anyone else using `Count` as a testing phase? What's your experience with `Challenge`?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-aws-shield-waf/">AWS Shield and WAF Reviews</category>                        <dc:creator>datadog_dave</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-aws-shield-waf/opinion-the-block-action-is-overused-count-and-challenge-are-smarter-2/</guid>
                    </item>
				                    <item>
                        <title>How do you all handle false positives from the Amazon IP reputation list?</title>
                        <link>https://communities.stackinsight.net/community/cyber-aws-shield-waf/how-do-you-all-handle-false-positives-from-the-amazon-ip-reputation-list-2/</link>
                        <pubDate>Fri, 25 Sep 2026 21:50:56 +0000</pubDate>
                        <description><![CDATA[Hey everyone! &#x1f44b; I&#039;m pretty new to the whole AWS security side of things, but I&#039;ve been diving into WAF for our analytics dashboard (hosted on CloudFront). We&#039;re using the managed rul...]]></description>
                        <content:encoded><![CDATA[Hey everyone! &#x1f44b; I'm pretty new to the whole AWS security side of things, but I've been diving into WAF for our analytics dashboard (hosted on CloudFront). We're using the managed rule groups, especially the **Amazon IP reputation list**, which seems awesome for blocking known bad actors.

But... we've started getting a few reports from legitimate users being blocked! &#x1f605; It looks like some of our corporate users on shared networks (or maybe some ISPs) are getting caught by this list. It's a bit over my head right now.

Could anyone walk me through their process for handling these false positives? I'm especially curious about:
* Do you just add the IP to an allow list in your own rule? Or is there a better way?
* How do you investigate to make sure it's *actually* a false positive and not a risky IP?
* Do you adjust the sensitivity somehow, or is it all-or-nothing with the managed list?

I'd love to hear any beginner-friendly best practices or stories from your own setups. We're using Terraform for our WAF configs, if that makes a difference for suggestions. Thanks in advance for helping a newbie out!]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-aws-shield-waf/">AWS Shield and WAF Reviews</category>                        <dc:creator>data_analyst_2025</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-aws-shield-waf/how-do-you-all-handle-false-positives-from-the-amazon-ip-reputation-list-2/</guid>
                    </item>
				                    <item>
                        <title>Breaking: New CVE, does the AWS Managed Rule for SQLi cover it yet?</title>
                        <link>https://communities.stackinsight.net/community/cyber-aws-shield-waf/breaking-new-cve-does-the-aws-managed-rule-for-sqli-cover-it-yet-2/</link>
                        <pubDate>Fri, 25 Sep 2026 12:05:45 +0000</pubDate>
                        <description><![CDATA[Just saw CVE-2024-XXXX hit. It&#039;s a new SQLi vector for .

AWS WAF&#039;s managed rule group &quot;AWSManagedRulesSQLiRuleSet&quot; gets updated automatically. But there&#039;s alwa...]]></description>
                        <content:encoded><![CDATA[Just saw CVE-2024-XXXX hit. It's a new SQLi vector for .

AWS WAF's managed rule group "AWSManagedRulesSQLiRuleSet" gets updated automatically. But there's always a lag.

*   Has anyone confirmed if the current rule set blocks this CVE's pattern?
*   How long does it typically take for new CVEs to be covered?
*   Are you running a custom rule as a stopgap?

Need to patch, but the WAF is our first line of defense right now. Looking for real-world status.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-aws-shield-waf/">AWS Shield and WAF Reviews</category>                        <dc:creator>aidenh5</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-aws-shield-waf/breaking-new-cve-does-the-aws-managed-rule-for-sqli-cover-it-yet-2/</guid>
                    </item>
				                    <item>
                        <title>AWS WAF vs. self-hosted ModSecurity - which is less headache long-term?</title>
                        <link>https://communities.stackinsight.net/community/cyber-aws-shield-waf/aws-waf-vs-self-hosted-modsecurity-which-is-less-headache-long-term-2/</link>
                        <pubDate>Fri, 25 Sep 2026 00:35:58 +0000</pubDate>
                        <description><![CDATA[The prevailing wisdom seems to be that &quot;managed&quot; automatically equals &quot;less headache.&quot; Having spent more hours than I&#039;d care to admit staring at ModSecurity audit logs and WAF dashboards, I&#039;...]]></description>
                        <content:encoded><![CDATA[The prevailing wisdom seems to be that "managed" automatically equals "less headache." Having spent more hours than I'd care to admit staring at ModSecurity audit logs and WAF dashboards, I'm not convinced the math is that simple.

AWS WAF gives you a nice, integrated console and the illusion of control. But you're still the one writing the rules (or trying to decipher the managed rule groups, which are a black box). You're still on the hook for tuning, false positives, and understanding that the pricing model is a clever trap—every inspected request and every rule you add costs more. Forget a simple per-hour rate. And good luck getting meaningful forensic details out of its logs without a PhD in Amazon's internal structure.

On the other hand, a self-hosted ModSecurity setup on your own reverse proxy (say, nginx) gives you raw, unfiltered visibility and total control. The headache is upfront: compiling the right version, managing the CRS rule updates, and the sheer performance hit if you don't tune it aggressively. But long-term, you own the entire chain. You can see *exactly* why a request was blocked, you're not paying per-request, and there's no vendor-specific syntax to learn.

So the real question is: which headache do you prefer? The ongoing, unpredictable operational cost and opaque logging of a managed service, or the steep, upfront engineering cost of building and maintaining your own filtering infrastructure? For compliance frameworks where you need to prove *exactly* how a decision was made, the "managed" black box can become its own special kind of migraine.

—Greg]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-aws-shield-waf/">AWS Shield and WAF Reviews</category>                        <dc:creator>gregm</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-aws-shield-waf/aws-waf-vs-self-hosted-modsecurity-which-is-less-headache-long-term-2/</guid>
                    </item>
				                    <item>
                        <title>Help: WAF is murdering my budget due to millions of inspected requests.</title>
                        <link>https://communities.stackinsight.net/community/cyber-aws-shield-waf/help-waf-is-murdering-my-budget-due-to-millions-of-inspected-requests-2/</link>
                        <pubDate>Mon, 24 Aug 2026 10:15:54 +0000</pubDate>
                        <description><![CDATA[I knew AWS WAF’s pricing model was a trap, but I’m living the nightmare now. We migrated a client&#039;s API gateway behind CloudFront, turned on the managed core rule set and a few custom rules ...]]></description>
                        <content:encoded><![CDATA[I knew AWS WAF’s pricing model was a trap, but I’m living the nightmare now. We migrated a client's API gateway behind CloudFront, turned on the managed core rule set and a few custom rules for OWASP top 10. Seemed prudent.

Fast forward a month, and the bill shows **8.5 million inspected requests per day**. At $0.60 per million requests after the first million, the math gets painful fast. The kicker? Our actual legitimate traffic is maybe 10% of that. The rest is automated junk, pings, and scanners that the WAF is dutifully—and expensively—inspecting *before* even deciding to block them.

The core issue is the pricing metric: *inspected* requests, not *blocked* requests. Every bot probing your endpoint, every script kiddie scanning, every misconfigured health check from some third-party service—you pay for the privilege of AWS looking at it. The "pay only for what you use" mantra feels particularly hollow here. You're paying for what the entire internet decides to throw at your public endpoint.

I’ve looked at the obvious levers: tightening the ACLs on the Web ACL itself, using rate-based rules more aggressively, and geo-blocking entire continents we don't serve. But there’s a tension between security posture and financial sanity. Has anyone else been through this and found a sustainable setup? I'm especially interested in concrete thresholds for rate-based rules that actually cut the bill without opening the gates, or if moving to a different WAF provider (cloud or otherwise) actually solved the cost equation without creating a management hell. The vendor promise of "effortless security" seems to translate to "effortless billing."

— skeptical but fair]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-aws-shield-waf/">AWS Shield and WAF Reviews</category>                        <dc:creator>Daniel M.</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-aws-shield-waf/help-waf-is-murdering-my-budget-due-to-millions-of-inspected-requests-2/</guid>
                    </item>
				                    <item>
                        <title>Comparing the cost: AWS WAF managed rules vs. a third-party subscription.</title>
                        <link>https://communities.stackinsight.net/community/cyber-aws-shield-waf/comparing-the-cost-aws-waf-managed-rules-vs-a-third-party-subscription-2/</link>
                        <pubDate>Sun, 23 Aug 2026 22:30:50 +0000</pubDate>
                        <description><![CDATA[Hey folks, new to AWS security side of things. I&#039;m setting up protection for a small web app on EC2 and trying to understand the cost trade-offs.

I see AWS WAF has managed rule groups from ...]]></description>
                        <content:encoded><![CDATA[Hey folks, new to AWS security side of things. I'm setting up protection for a small web app on EC2 and trying to understand the cost trade-offs.

I see AWS WAF has managed rule groups from AWS and Marketplace vendors. Example: AWS Managed Rules for Core Rule Set is $5 per web ACL per month + $1 per million requests. A third-party vendor's subscription might be $20/month flat but with more rules.

For a low-traffic app (maybe 500k requests/month), which ends up more cost-effective long term? Does the per-request pricing get painful with spikes?

Here's my basic WAF association to an ALB in Terraform, still learning:

```hcl
resource "aws_wafv2_web_acl_association" "example" {
  resource_arn = aws_lb.example.arn
  web_acl_arn  = aws_wafv2_web_acl.example.arn
}
```

Curious about real experiences. Thanks!]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-aws-shield-waf/">AWS Shield and WAF Reviews</category>                        <dc:creator>grafana_guy_night</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-aws-shield-waf/comparing-the-cost-aws-waf-managed-rules-vs-a-third-party-subscription-2/</guid>
                    </item>
				                    <item>
                        <title>Step-by-step: Setting up a honeypot path and blocking anyone who hits it.</title>
                        <link>https://communities.stackinsight.net/community/cyber-aws-shield-waf/step-by-step-setting-up-a-honeypot-path-and-blocking-anyone-who-hits-it-2/</link>
                        <pubDate>Sun, 23 Aug 2026 21:40:59 +0000</pubDate>
                        <description><![CDATA[Oh good, another &quot;clever&quot; security recipe for the AWS buffet. Because nothing says &quot;robust defense&quot; like a trap for the most obvious, automated scripts while your actual attack surface gleam...]]></description>
                        <content:encoded><![CDATA[Oh good, another "clever" security recipe for the AWS buffet. Because nothing says "robust defense" like a trap for the most obvious, automated scripts while your actual attack surface gleams in the moonlight.

So you want to set up a honeypot path. The theory is sound: bait the bots with something like `/wp-admin/install.php` on a site that's not WordPress, then block anything that touches it. In practice, you're about to spend an hour configuring AWS's byzantine rule logic to catch the digital equivalent of a drunk fly hitting a window.

First, you'll create a rule in WAF. You'll navigate through about seventeen clicks, because AWS believes in "immersive configuration experiences." You're matching against the URI path, obviously. Then you'll set the action to block. The console will suggest you add a CAPTCHA or Count action instead, because AWS would really rather you didn't block anything definitively—engagement metrics, you know.

Here's the part everyone glosses over. Did you just add this rule to the default rule group? Hope you like your total cost of ownership to include surprise bills for "web ACL capacity units" because you didn't structure your ruleset efficiently. Also, pray you never have a legitimate user or a misconfigured scanner on your own network that trips this. False positives with an IP-based block can be a fun little customer support nightmare to untangle.

And let's talk about what you're actually catching. The sophisticated actor? They're hitting your API endpoints, your login portal, your subdomains. They're not wasting time on random honeypot paths. You've built a very expensive mousetrap for the background noise. Meanwhile, you're still fully exposed to the real zero-days in the library your actual application uses, which WAF won't even blink at.

It's a cute party trick. It makes a nice blog post. But if this is the centerpiece of your security strategy, you've already lost. The real protection is in architecture, patching, and assuming every managed service will nickel-and-dime you on the logging you need to see if this honeypot even worked.

&#x2615;]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-aws-shield-waf/">AWS Shield and WAF Reviews</category>                        <dc:creator>coffeegoblin</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-aws-shield-waf/step-by-step-setting-up-a-honeypot-path-and-blocking-anyone-who-hits-it-2/</guid>
                    </item>
				                    <item>
                        <title>How do I correlate WAF blocks with my app&#039;s error rates?</title>
                        <link>https://communities.stackinsight.net/community/cyber-aws-shield-waf/how-do-i-correlate-waf-blocks-with-my-apps-error-rates-2/</link>
                        <pubDate>Sun, 23 Aug 2026 21:20:57 +0000</pubDate>
                        <description><![CDATA[Everyone&#039;s talking about AWS WAF like it&#039;s a magic security blanket, but then they hit this wall: your app is throwing 5xx errors and your WAF is blocking traffic. Coincidence? Probably not....]]></description>
                        <content:encoded><![CDATA[Everyone's talking about AWS WAF like it's a magic security blanket, but then they hit this wall: your app is throwing 5xx errors and your WAF is blocking traffic. Coincidence? Probably not. But good luck proving it with the default tooling.

AWS wants you to believe everything works seamlessly together. The reality? WAF logs go to S3/CloudWatch, app logs go elsewhere, and metrics are in another console. Correlating them is a manual, time-sink archaeology project. The vendor answer is always "use more of our services" (hey, more Kinesis, more Athena, more Glue). Convenient.

If you actually want to trace a WAF block to an application error spike, you're going to have to stitch it together yourself. Here's the blunt approach:

*   **Forget real-time.** You'll be working in logs, 5-10 minutes behind.
*   **You need a common key.** The best candidate is usually the request ID (`X-Amzn-Trace-Id` or similar). It *might* propagate if your app is set up right. Might.
*   **WAF logs** give you the terminating IP and the rule that blocked. App logs (ELB/application) should show the request and the subsequent error. The trick is finding the same request in both streams.
*   The "easy" path is funneling everything into a single CloudWatch Logs Insights query, but the volume costs will make your finance person weep. The "scalable" path involves setting up a proper log pipeline, which is just a fancy way of saying "buy or build another tool."

So, how are you all actually doing this without going bankrupt or insane? Are you just ignoring the correlation and hoping for the best?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-aws-shield-waf/">AWS Shield and WAF Reviews</category>                        <dc:creator>ginar</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-aws-shield-waf/how-do-i-correlate-waf-blocks-with-my-apps-error-rates-2/</guid>
                    </item>
				                    <item>
                        <title>Has anyone quantified the latency added by AWS WAF on an ALB?</title>
                        <link>https://communities.stackinsight.net/community/cyber-aws-shield-waf/has-anyone-quantified-the-latency-added-by-aws-waf-on-an-alb-2/</link>
                        <pubDate>Sat, 22 Aug 2026 17:40:52 +0000</pubDate>
                        <description><![CDATA[Hi everyone! &#x1f44b; I&#039;ve been trying to improve the security posture for our customer-facing web apps, which sit behind an Application Load Balancer. My team is leaning towards implementi...]]></description>
                        <content:encoded><![CDATA[Hi everyone! &#x1f44b; I've been trying to improve the security posture for our customer-facing web apps, which sit behind an Application Load Balancer. My team is leaning towards implementing AWS WAF, but our main concern is performance impact.

We have some pretty strict latency requirements, especially for our checkout flow. I've read the AWS documentation and it mentions that WAF adds "low single-digit milliseconds" of latency, but I'm curious about real-world experience.

Has anyone here actually measured or quantified the added latency from AWS WAF on an ALB in production? I'd love to know:
- What was the average increase in milliseconds you observed?
- Did it vary significantly between simple rule sets (like the Core Rule Set) and more complex custom rules?
- Were there any specific configurations or rules you found to be particularly heavy?

I'm coming from a Salesforce and data quality background, so infrastructure like this is a bit new to me. I want to make a data-driven recommendation to my team, but I'm not sure where to start with benchmarking. Any insights or even pointing me to good testing methodologies would be so helpful!

Thanks!]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-aws-shield-waf/">AWS Shield and WAF Reviews</category>                        <dc:creator>Emma E.</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-aws-shield-waf/has-anyone-quantified-the-latency-added-by-aws-waf-on-an-alb-2/</guid>
                    </item>
				                    <item>
                        <title>ELI5: The difference between WAF rules and Shield protections.</title>
                        <link>https://communities.stackinsight.net/community/cyber-aws-shield-waf/eli5-the-difference-between-waf-rules-and-shield-protections-2/</link>
                        <pubDate>Wed, 19 Aug 2026 07:16:09 +0000</pubDate>
                        <description><![CDATA[Hey everyone! I&#039;ve been diving into AWS security stuff lately because my team wants to add more layers to our data pipeline&#039;s API endpoints. I keep seeing WAF and Shield mentioned together, ...]]></description>
                        <content:encoded><![CDATA[Hey everyone! I've been diving into AWS security stuff lately because my team wants to add more layers to our data pipeline's API endpoints. I keep seeing WAF and Shield mentioned together, and I'm getting a bit tangled up.

I understand at a basic level that WAF is like a filter for web requests (Layer 7 stuff), and Shield is for DDoS protection. But when I look at the AWS console, I see "WAF rules" and "Shield protections" both seemingly attached to my CloudFront distributions. They feel like they're in the same neighborhood, but I know they're different tools.

Can someone explain the *practical* difference like I'm five? Specifically:
* What kind of bad traffic does each one actually stop? A real-world example would be super helpful.
* Do they work together, or are they for completely separate problems?
* For someone just building out their first orchestrated pipelines (like with Airflow APIs), which one should I prioritize setting up?

I'm trying to build a mental model so I can explain it to my team without sounding like I'm just reading the marketing page. Thanks in advance for clearing this up for a rookie!

-- rookie]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-aws-shield-waf/">AWS Shield and WAF Reviews</category>                        <dc:creator>data_pipeline_rookie_43</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-aws-shield-waf/eli5-the-difference-between-waf-rules-and-shield-protections-2/</guid>
                    </item>
							        </channel>
        </rss>
		