- Newest
- Most votes
- Most comments
When managing AWS Network Firewall at scale, your current approach with a single standard stateful rule group per account will likely face challenges as your environment grows.
For structuring stateful rule groups at scale, consider these approaches:
-
Functional segmentation: Instead of one rule group per account, organize rule groups by function or traffic type (e.g., web traffic, database traffic, internal communications). This makes management more modular and easier to maintain.
-
Leverage all rule group types: AWS Network Firewall offers three types of stateful rule groups that can be used together:
- Standard stateful rules for basic network connection attributes
- Domain list rules for domain-based filtering
- Suricata compatible rule strings for more advanced inspection
- Rule evaluation order: With strict rule ordering (which you're already using), ensure you carefully plan the sequence of rule evaluation. This becomes increasingly important at scale as rule interactions become more complex.
Regarding Suricata rules versus standard stateful rules at scale:
Yes, Suricata compatible rule strings tend to become the preferred choice in larger environments because:
- They provide more flexibility and power for complex inspection needs
- They support deep packet inspection (DPI) of traffic flows
- They allow for more granular control over traffic inspection
- You can write any stateful rule in Suricata compatible format
Real-world patterns and lessons:
- Use Suricata rules for complex inspection needs while maintaining simpler domain lists or standard rules where appropriate
- Consider implementing a CI/CD pipeline for rule management to ensure consistent deployment across environments
- Implement a testing framework to validate rule changes before deployment to production
- Document rule intent and expected behavior to aid in troubleshooting and knowledge transfer
- Consider breaking down rule groups by function rather than by environment to promote reuse and consistency
Remember that all stateful rule groups in Network Firewall ultimately use the Suricata rules engine for processing, so becoming proficient with Suricata rule syntax will be valuable as your deployment scales.
Sources
Managing your own rule groups in AWS Network Firewall - AWS Network Firewall
Working with stateful rule groups in AWS Network Firewall - AWS Network Firewall
Managing evaluation order for Suricata compatible rules in AWS Network Firewall - AWS Network Firewall
StatefulEngineOptions - AWS Network Firewall
answered 9 months ago
Relevant content
asked 3 years ago
asked 3 years ago
asked 2 years ago
- AWS OFFICIALUpdated 7 months ago

Thanks for the response but I’m looking for a real-world implementation pattern.
In practice, I’m leaning toward standardizing on Suricata-compatible rules, since they can already cover both standard stateful rules and Domain list rules. This would avoid maintaining multiple rule group types and simplify rule lifecycle management.
I already have a conceptual design based on the AWS Network Firewall best-practice guide: https://aws.github.io/aws-security-services-best-practices/guides/network-firewall/
What I’m trying to validate is whether teams running larger or long-lived environments actually follow this model in production, or if they still deliberately split rules across standard stateful, domain list, and Suricata rule groups for operational reasons.
Concrete examples of how rule groups are structured and reused at scale would be much more helpful than high-level guidance.