I'm building a serverless API with Lambda and API Gateway. I need to add a WAF for basic security, but I'm a bit lost on the setup.
Is it better to attach AWS WAF directly to the API Gateway, or should I use CloudFront in front? I'm mostly concerned about common OWASP rules and some IP blocking. Any guidance on the simplest path to get started would be great.
Attach WAF directly to API Gateway. It's the simplest path for your stated needs: OWASP core rules and IP blocking. CloudFront adds complexity (cache behaviors, extra origin config) you don't need unless you're serving static assets or require its geographic restrictions.
Enable the AWS Managed Rules for OWASP Top 10. Start with Count mode for a day to review logs before blocking. For IP blocking, use the IP match condition. Scope it to your API stage.
You can deploy this via the console in under 15 minutes. Terraform or CloudFormation are better for reproducibility.
Show me the query.
Agreed that starting with WAF directly on API Gateway is the simplest operational choice. However, I'd add a caveat regarding pricing that's important for a serverless setup.
Attaching WAF to API Gateway incurs charges per REST API call inspected. For high-volume Lambda APIs, this can become a significant variable cost that isn't present with CloudFront distributions, where WAF charges are per request to CloudFront. If your traffic patterns are unpredictable or scale heavily, the cost model might sway your decision even without needing caching.
The Count mode recommendation is spot-on. I'd also suggest creating a specific Amazon S3 bucket for the WAF logs immediately, as the logging setup is a separate step that's easy to forget. You'll want those logs to analyze the Count mode data and for any future tuning.
Support is a product, not a department.
Solid advice on the direct attachment path. The Count mode step is crucial - I've seen teams jump straight to Block and accidentally lock out their own CI/CD systems making health checks.
For IP blocking, I'd stress scoping the rule to your specific API Gateway stage and HTTP method. A broad IP match rule on the entire API can have unintended side effects if you have multiple environments sharing a WAF. Also, remember that API Gateway stage variables won't work inside WAF rule conditions, which sometimes trips people up.
You're right that Terraform/CloudFormation is better long-term, but for that initial 15-minute console test, also make sure you note the Web ACL ARN somewhere. You'll need it later to attach the same ACL via IaC without causing a resource replacement.
Great point on the CI/CD lockout - happened to my team too! We actually created a separate IP set for our CI systems and attached it as an allow rule before the OWASP block rules. That way health checks pass even if something in the managed rules flags them.
Also good call on noting the Web ACL ARN. I've lost an hour before trying to re-attach via Terraform without it, causing a weird state where the console showed it attached but the API didn't enforce it. The AWS provider docs don't exactly shout about that requirement.
The simplest path is often the one with the most surprising invoice. Attaching WAF directly to API Gateway means you're paying per call to your actual API. If your Lambda scales, your WAF bill scales right along with it. CloudFront's pricing model can be more predictable for high-volume, pure API workloads, even without caching. So the 'simple' operational choice might just be trading setup complexity for financial complexity later.
Show me the data
The direct attach path will work, but skip the console and go straight to CloudFormation. The "15 minute" console setup is a trap - it'll take you longer to untangle it later.
Create a separate IP set for your VPC, CI/CD systems, and office IPs as an explicit allow rule. Place it *before* the managed OWASP rules. Don't rely on Count mode alone to catch self-inflicted blocks. Test the Web ACL by temporarily assigning a rule to block your own IP, then remove it. If you can't break your own API, your WAF isn't on.
-- bb
The direct attachment method works for initial testing, but you need to consider cost scaling. While API Gateway with WAF charges per API call, CloudFront distributions have a per-request WAF cost that is often lower for high-volume APIs. I'd recommend a quick load test estimate before committing to a pattern; the operational simplicity of direct attachment can be overshadowed by a 30% cost increase at 10k RPS.
Start with a CloudFormation template that deploys the Web ACL to API Gateway in Count mode, but include the CloudFront distribution as a commented alternative. This lets you benchmark latency and cost for both architectures in a staging environment before production.
Also, remember that WAF on API Gateway inspects after transformation, while CloudFront inspects the raw request. This can affect rule efficacy for certain OWASP rules if you're using request mapping.
The cost scaling point is real, but the load test estimate advice is misleading. The cost delta isn't a flat 30% at 10k RPS. It depends entirely on your AWS region, and whether your API Gateway is HTTP or REST.
More importantly, > WAF on API Gateway inspects after transformation. This changes everything for certain rules, and not many people actually check. An SQLi payload buried in a mapped request body might slip past CloudFront rules but get caught by API Gateway inspection. So it's not just a cost/ops tradeoff, it's a security coverage one. A cheap WAF that misses half the attacks is just a fancy meter.