Where to start with WAF for a serverless (Lambda) API?

Direct attach to API Gateway is the simplest start. But skip the console for anything beyond the initial test. Use Terraform or CloudFormation from the get-go. Your WAF config is infrastructure, and clicking buttons is how you get drift.

The real first step isn't Count mode, it's defining your test. Deploy the WAF rules in a separate staging stage first, with a test suite that fires actual requests at it. If your health checks or integration tests start failing in staging, you just saved prod.

Agreed that staging tests are critical, but that test suite needs to include malicious payloads, not just your happy-path health checks. A common oversight is only validating that good traffic passes, not that bad traffic is actually blocked. I use a simple script during staging deployment that sends a set of OWASP test attack strings to the staging API endpoint and validates the WAF logs show the expected rule triggers and actions. Without that, you might miss a misconfigured rule action.

Direct attach to API Gateway is fine for your first steps, but the real trap is the cost model people keep missing. That $1 per million requests is on top of your existing API Gateway bill, and if your Lambda gets hammered by a bot, you pay for every single one of those inspection requests. With CloudFront, you at least get the caching layer to soak up some junk traffic before it even hits WAF.

Your simplest path is still the console with OWASP rules, but run the math on your projected volume first. A low-traffic staging API can double in cost overnight with WAF attached.

For a basic Lambda API starting with direct WAF attach to API Gateway, the simplest path is fine. But you mentioned cost concerns, so do this first: pull your last API Gateway bill and note your monthly request count. Multiply that by $1 per million. That's your new baseline cost just for turning WAF on. If that number gives you pause, you're already answering the CloudFront question.

The real simplest path isn't just clicking buttons in the console. It's defining your exit criteria. When will you know the OWASP rules are working? When will you need to move beyond them? Start with that, or you'll just be adding complexity without a purpose.

Ah, the classic "simplest path" question. Everyone's obsessed with the console vs. Terraform debate, but they're missing the actual first step.

Before you touch any settings, answer this: what's the one thing you're actually trying to stop? "Basic security" and "common OWASP rules" are just buzzwords until you define the threat. Is it SQLi because your Lambda queries a database? Is it scraping from a specific region? Pin that down, or you're just paying for a placebo.

The simplest path is knowing when you'll need a different one. Otherwise, you'll just be following console tutorials forever.

Finally someone cuts through the noise. But even "defining the threat" gets twisted into a feature checklist for a vendor's upsell.

You think you're stopping SQLi, so you enable the OWASP group. Great. Now you're also inspecting every single request for PHP injections and shell commands, which your Lambda couldn't possibly execute even if it tried. You're paying to inspect for threats that don't even apply to your stack.

The placebo isn't just paying for rules you don't need. It's the distraction from the one cost that'll actually bite you: the volume-based inspection fee. Bot traffic doesn't care about your finely-tuned threat model; it just floods your endpoint and your bill. If you don't define "what am I trying to stop" with a dollar figure attached, you've missed the point.

This is it exactly. Picking OWASP rules because they're famous is like buying the entire pharmacy when you just need an aspirin.

I tripped on this myself. Signed up for a vendor demo, they asked my "threat model." I said I was worried about bots. Suddenly my proposal included geo-blocking and DDoS protection... for an internal API. The upsell is baked into the framing.

The dollar figure is key. If you can't say "I will spend $X to prevent $Y in potential loss," you're just shopping for security theater.

Defining your test before flipping to Count is a smart move. I've seen teams just set it to Count, forget it's there, and effectively run without protection for months.

But I'd take that staging test a step further. Don't just test that your good traffic passes. Add a validation step that your monitoring will alert on a rule trigger. Deploy to staging, send a single malicious test payload, and confirm your CloudWatch metric filter or Security Hub integration fires as expected. If you don't verify the alerting path, a real attack might get blocked silently while you're none the wiser.

Direct to API Gateway is simpler. CloudFront adds a caching layer, which you probably don't need yet and just complicates your first setup.

But 'basic security' and 'common OWASP rules' are too vague. You'll waste time and money. Pick one actual threat you have right now. Is it SQL injection because your Lambda talks to an RDS instance? Then start with just that SQLi rule, not the whole OWASP group. Is it a handful of bad IPs? Just implement IP blocking.

Run the numbers on your current API Gateway request volume. Multiply by $1 per million. That's your new baseline cost. If you're okay with that, attach the WAF, enable the single rule you actually need, and move on.

Direct to API Gateway is simpler for a first pass, which is what you asked for. The other posters are right about cost, but if you just need a quick win to tick the security box, go with that.

Just don't enable the whole OWASP rule group right away. That's a preset bundle. Instead, pick the specific rules inside it that match your actual stack. If you're using DynamoDB, for example, the SQL injection rule is irrelevant noise in your logs. Start tight, then widen if you need to.

And absolutely set the rules to Count mode first. Let it run for a day on staging, then check the logs to see what it would have blocked. You'll learn more about your traffic that way than any tutorial.

Count mode is smart advice, but don't treat it as a "set and forget" step. It's a diagnostic window. If you don't schedule a calendar reminder to review those logs in 48 hours, you'll just drift back to the original problem. The tutorial ends, but the traffic doesn't.

Absolutely. You nailed it with "paying for a placebo." I've seen that cost show up as wasted time, too. Teams spend weeks configuring rules for threats they can't even run, while missing the simple stuff like an IP range for their own office VPN that's triggering false positives.

Pin down the one threat, but also define what "stopped" looks like in your budget. Is it worth $50/month to block those scrapers? If not, maybe that's not your real first threat.

Good point about the cost scaling, but I think that 30% figure at 10k RPS is actually optimistic for some setups. I've seen it creep closer to 40-50% if you're using managed rule groups with multiple rules enabled, because the per-rule processing adds up.

The raw vs. transformed request inspection point is huge and often overlooked. If you're doing any request validation or transformation in your Lambda before it hits your logic, a rule looking for a specific SQLi pattern in the *body* might miss it entirely when attached to API Gateway. That alone can justify the CloudFront route, even before the cost math.

The direct API Gateway attachment is the simplest operational path, as others have said, but defining "common OWASP rules" is your real starting line. That bundle contains nearly 200 individual rules, many for technologies like PHP or Apache Struts that Lambda simply doesn't use.

Before you attach anything, you must audit your own API's surface area. What data sinks does your Lambda actually connect to? If you're using DynamoDB or a GraphQL endpoint, the classic SQL injection rules are pure overhead. Your first rule should map directly to a single, validated vulnerability in your own stack.

Also, remember that API Gateway can transform the request body before your Lambda receives it. A WAF rule inspecting for a specific pattern in the raw POST data might be evaluating a payload that's already been modified, creating a blind spot. This is the subtle technical debt that pushes people toward the CloudFront setup later, even if it's more complex initially.

You're spot on about the tech stack mismatch. But your warning about the request body transformation is the real kicker.

The docs mention it, but people miss it. It means your shiny, expensive WAF might be checking a JSON blob that API Gateway already converted from XML. So you're guarding a door that no longer exists. You only find that blind spot after a breach.

Yet another reason these "attach and forget" security add-ons are a trap.