News: AWS released a 'best practices' guide. Anything new in there?

I'm a senior engineer at a mid-sized fintech SaaS, and we've been running AWS Shield Advanced and a fairly complex WAF setup across our production APIs for about three years.

The guide is a great reference, but you're right that the real value is how it prioritizes actions. My main takeaways from a practitioner's perspective are:

1. **Emphasis on Managed Rules Early On:** They explicitly recommend starting with `AWSManagedRulesCommonRuleSet` and `AWSManagedRulesBotControlRuleSet` before custom rules. This is smart, but watch the cost if you're multi-tenant; the Bot Control rule group alone is about $10 per web ACL per month, and costs can scale quickly if you need isolated ACLs per tenant.
2. **Logging Clarity is a Major Win:** The detailed Athena queries for S3 logs are new and directly useful. In my environment, routing WAF logs through Firehose to a real-time monitoring dashboard (about a day of setup) cut our mean time to diagnose a block from 20 minutes to under 5.
3. **Rate-Based Rules Get Specific Numbers:** They finally give concrete starting points. For a public API endpoint, they suggest a rate-based rule at "1,000 requests per 5 minutes per IP" as a baseline, which is far more actionable than the generic advice they had before.
4. **The "Enhanced" Phase is Where Most Teams Should Live:** The guide's middle tier - integrating with Amazon CloudFront, automating deployments via CloudFormation, and setting up centralized logging - is the sweet spot. Getting to this stage took us a focused sprint, but it's stable. The "Advanced" phase (like custom machine learning models) is a massive lift and honestly overkill unless you're at FAANG scale.

My pick is to follow their phased approach starting with the managed rule groups they highlight. If your multi-tenant app has a single public endpoint layer, it's a fit. But if you need per-tenant WAF policies, tell us your tenant count and monthly bill for AWS WAF currently, because the cost trajectory changes completely.

The phased approach is good in theory, but good luck getting budget for the "Enhanced" stage before you're actively on fire. Seen it happen.

Pushing bot control earlier is interesting. That managed rule set is decent, but we had to pair it with some custom rate-based rules because it was missing some obvious, persistent scrapers hitting our APIs. The defaults catch the easy stuff, but you still need to look at your own logs.

> automation in rule deployment

If they're pushing that, they better have updated those CloudFormation snippets. Last time I checked, the properties for some of the newer managed rule groups were still a pain to get right in IaC. Hope they included a proper CDK example.

I hear you on the budget challenge. It's a classic "pay for insurance" argument that's hard to win without past incidents to point to.

On the IaC point, the guide does link to some updated CloudFormation templates, but I didn't see any CDK L2 construct examples. It still feels like you need to translate from the JSON/YAML specs yourself, which is exactly the pain point you're mentioning. The automation push feels a bit theoretical without those ready-to-use code snippets.

Yeah, that missing CDK L2 piece is a real bummer. I've been banging my head against the same wall on a recent project. The CloudFormation templates they linked are fine if you're doing raw YAML, but once you're in CDK you end up having to use L1 constructs (`CfnWebACL`, `CfnRuleGroup`) and then manually wire up the `ruleGroupReferenceStatement` properties. It's doable, but it's clunky and you lose all the nice type safety.

One trick I've used is to define the managed rule group ARNs as constants and then use the escape hatch with `addOverride` to patch in the JSON config. Kind of ugly, but it works. For example:

```
const botControl = new wafv2.CfnWebACL.RuleProperty({
name: 'AWS-AWSManagedRulesBotControlRuleSet',
priority: 1,
statement: {
managedRuleGroupStatement: {
vendorName: 'AWS',
name: 'AWSManagedRulesBotControlRuleSet',
excludedRules: [],
},
},
overrideAction: { none: {} },
visibilityConfig: { ... }
});
```

That's a rough sketch - you still need to manually set the `overrideAction` vs `action` based on the rule group type. The docs aren't great about which one to use.

Have you tried the newer `aws-cdk-lib/aws-wafv2` module? I think it's still L1-only for the rule groups, but I heard they're working on L2 wrappers. Probably another six months out though.

That's a good summary of the consolidation value. I've also been working through this for a single-tenant setup, and the phased approach really does help with internal discussions. Having those stages labeled makes it easier to justify starting with the "Foundational" items to our security team.

You mentioned the *much clearer guidance on logging and monitoring*. I spent a lot of time on that section. While the Athena sample queries are helpful, I found myself wishing they had included more examples of what to actually *do* with that real-time Firehose data. It's one thing to capture it, but turning it into an actionable alert seems like the next logical step they could have covered.

For someone in a multi-tenant situation like yours, does the logging structure they suggest hold up when you have to separate logs and costs per tenant? I'm curious if the guide's approach scales cleanly or if it gets messy in practice.

Exactly. You hit on a key gap in the monitoring section. The guide's Firehose-to-S3 logging is a great data pipe, but turning that into alerts is left as an exercise for the reader. We built a Lambda consumer off the Firehose stream to parse and push counts to CloudWatch, then set alarms on specific rule actions. Without that, you're just archiving logs, not monitoring.

On the multi-tenant logging question: the suggested structure doesn't inherently isolate tenant data. The `terminatingRuleId` and `httpRequest` client IP are in the logs, but if your tenant context is in a JWT or a custom header, you're stuck parsing it yourself. It holds up if your tenant separation is at the ACL level (isolated Web ACL per tenant), but that's cost-prohibitive for many. So it gets messy; you'll need post-processing to tag logs by tenant for cost allocation.

Spot on about the consolidation value. That phased approach is the biggest takeaway for me too. It gives teams a concrete roadmap to follow, which is often missing from AWS docs.

You mentioned the stronger push for automation. While the guide references CloudFormation, I've found the real automation challenge isn't in deploying the ACL, but in managing rule updates and exceptions dynamically. The guide doesn't go deep enough on a process for that. For a multi-tenant app, you need a way to safely roll out rule changes or temporary allow-lists without manual console work, and that's still a custom build.