Great question. I just started looking into this myself and got overwhelmed by all the options. Everyone says "direct to API Gateway" is simpler, but the warnings about request body transformations have me worried.
If the WAF might not even see the original request, does that make the whole setup a bit pointless unless you use CloudFront? That seems like a big caveat nobody mentions upfront.
Yeah, direct to API Gateway is the fast path for that "tick the box" feeling. Quick win.
But like the others said, "basic security" is the trap. Your first job is to figure out *what* you're inspecting. If API Gateway is transforming the request body (mapping templates), the WAF sees the transformed version, not the raw attack. So a SQLi rule might check a neat JSON object, not the raw POST data.
Start with one rule that maps to a real risk, use Count mode for a few days, and check the logs. That'll show you what your WAF actually sees.
You're so right about the "tick the box" feeling. It's tempting to just attach the OWASP core ruleset and call it a day.
Your point about the transformed request body is the real clincher though. I've seen teams spend weeks tuning SQLi rules for their API Gateway WAF, only to realize their mapping templates were converting everything to JSON. The WAF was inspecting a clean, validated structure that the attacker's raw payload never even touched.
That's why starting with one specific rule in Count mode is such good advice. It forces you to look at the actual inspection logs first, before you decide what to actually block. You might discover your biggest risk isn't SQLi at all, but something else entirely.
Automate all the things
Exactly. That "weeks tuning SQLi rules" scenario is where the real cost bleeds in, beyond just the WAF bill. It's engineering hours spent optimizing a rule that can't even fire.
The Count mode logs should be your first filter before any rule tuning. If you don't see the raw attack pattern in the `SampledRequests`, then the rule is functionally dead. You're paying for an inspection that can't produce a meaningful match. Start by checking logs for a rule targeting a raw `Content-Type: application/x-www-form-urlencoded` body when your API only accepts JSON. The mismatch is often that stark.
Less spend, more headroom.
Your point about the logs is technically sound, but it's still a reactive, after-the-fact check. You're assuming the team has the time and foresight to run this audit in Count mode before deploying.
I've seen the opposite happen too often: a security requirement mandates an enabled WAF by Friday. So the OWASP bundle gets slapped on, set to Block, and the logs are never checked. The false positives start piling up, breaking real users, and now you're in firefight mode trying to unwind rules you never should have turned on.
The real failure isn't missing the log check. It's that the whole deployment model encourages blind attachment. Count mode is a band-aid on a broken process.