What's New

AWS Network Firewall now supports container attribute-based rules, allowing security teams to write firewall policies using native Kubernetes and ECS constructs—such as EKS Namespace, Cluster Name, and Labels, or ECS Cluster Name and Container Instance Attributes—instead of brittle IP-based rules. This eliminates the longstanding problem of firewall rules breaking whenever pods scale, restart, or receive new IP addresses. The feature also brings advanced inspection capabilities including TLS decryption, FQDN filtering, URL category filtering, and GeoIP filtering, all of which automatically adapt as container workloads scale dynamically.

How It Works

• Container attribute mapping: AWS Network Firewall integrates natively with the EKS and ECS control planes to resolve container metadata (Namespace, Cluster Name, Labels for EKS; Cluster Name and Container Instance Attributes for ECS) into the corresponding network identities at policy evaluation time.
• Dynamic rule adaptation: As pods scale out, restart, or receive new IP addresses, the firewall automatically tracks the updated mappings without requiring manual rule updates, ensuring continuous policy enforcement.
• TLS decryption and deep packet inspection: Policies can invoke inline TLS inspection to decrypt HTTPS traffic originating from or destined to specific container workloads, enabling full URL-level visibility rather than SNI-only inspection.
• FQDN-based filtering: Rules can restrict specific pods or namespaces to a whitelist of approved fully qualified domain names, preventing unauthorized egress to arbitrary external endpoints.
• URL category and GeoIP filtering: Using Suricata-compatible rule groups with aws_url_category and aws_domain_category keywords, operators can block traffic by content category (e.g., Malicious, Malware, Phishing) or geographic origin/destination, scoped to specific container attributes.
• Centralized multi-cluster policy management: A single AWS Network Firewall policy can enforce consistent rules across multiple EKS clusters and ECS clusters within or across accounts, leveraging AWS Transit Gateway integration for centralized inspection.

Why It's Important

• Eliminates IP churn fragility: In containerized environments, pod IPs are ephemeral; IP-based firewall rules require constant manual updates or automation glue. Attribute-based rules remove this operational burden entirely.
• Accelerates secure GenAI adoption: As organizations deploy generative AI workloads on EKS and ECS, they need fine-grained egress controls (e.g., restricting AI pods to approved model API endpoints). This feature provides that control natively without custom tooling.
• Reduces blast radius of compromised containers: Namespace- or label-scoped rules enforce least-privilege network access at the workload level, limiting lateral movement if a container is compromised.
• Simplifies compliance: Centralized, auditable firewall policies mapped to logical container constructs make it easier to demonstrate network segmentation controls required by frameworks like PCI-DSS, HIPAA, and SOC 2.
• Closes the gap between Kubernetes network policy and perimeter security: Kubernetes NetworkPolicy operates within the cluster; this feature extends enforcement to the VPC perimeter and beyond, providing defense-in-depth.
• No additional cost: The capability is included in existing AWS Network Firewall pricing, lowering the barrier to adoption for teams already using the service.

How It's Different

• vs. Kubernetes NetworkPolicy: Native NetworkPolicy is cluster-internal and cannot enforce rules on traffic leaving the VPC, inspect TLS content, or apply GeoIP/URL category filtering; container attribute-based rules in Network Firewall operate at the VPC edge with full L7 inspection.
• vs. traditional IP-based firewall rules: IP rules require continuous updates as pod IPs change; attribute-based rules are identity-driven and self-maintaining, eliminating operational toil and rule drift.
• vs. service mesh egress controls (e.g., Istio): Service meshes provide mTLS and traffic management within the cluster but typically lack GeoIP filtering, URL category blocking, and centralized multi-account policy management that Network Firewall provides.
• vs. third-party CNI security plugins: These operate at the node level and are cluster-specific; AWS Network Firewall provides a managed, multi-cluster, multi-account control plane with AWS-native threat intelligence integration.
• vs. previous AWS Network Firewall capabilities: Prior to this release, Network Firewall had no awareness of container identity; all rules had to reference IP CIDRs or security groups, requiring external automation to keep rules synchronized with pod scheduling.

When to Prefer It

• Multi-tenant EKS clusters: When multiple teams share a cluster and you need namespace-level network isolation enforced at the VPC perimeter rather than relying solely on in-cluster controls.
• Generative AI workloads with strict egress requirements: When AI inference or training pods must only communicate with approved model endpoints (e.g., Amazon Bedrock, specific SaaS APIs) and you need FQDN or URL category enforcement scoped to those pods.
• Regulated industries: When compliance mandates require documented, auditable network segmentation between workload tiers (e.g., PCI cardholder data environment pods vs. general application pods).
• Large-scale ECS deployments with dynamic task placement: When ECS tasks are scheduled across many container instances and IP-based rules are impractical to maintain due to frequent task restarts and IP reassignment.
• Centralized security operations across multiple clusters: When a platform or security team manages firewall policy for multiple EKS/ECS clusters across accounts and needs a single pane of glass rather than per-cluster tooling.
• Encrypted traffic inspection for container egress: When you need to inspect HTTPS traffic from specific pods (e.g., detecting data exfiltration from a compromised container) and require TLS decryption scoped to container attributes.

Availability

• GA status: Generally available as of June 30, 2026; no preview or beta limitations noted.
• Supported regions: Available in select AWS regions; refer to the AWS Capabilities by Region page for the full and current list of supported regions.
• Pricing: Included at no additional cost as part of existing AWS Network Firewall pricing; standard Network Firewall endpoint and traffic processing charges apply.
• Prerequisites: Requires AWS Network Firewall to be deployed in the VPC(s) hosting EKS or ECS workloads; TLS inspection capabilities require configuration of TLS inspection policies within Network Firewall.
• Supported orchestrators: Amazon EKS (Namespace, Cluster Name, Labels) and Amazon ECS (Cluster Name, Container Instance Attributes); no mention of self-managed Kubernetes or ECS Anywhere support at launch.

Related Resources

• https://builder.aws.com/build/capabilities/explore?f=eJxVirEKg0AQBX9FXq1FWiGFjZAmRVKkcC0uusji4cneqYj477lcEUg3b94c8Gy5C9w_eBA3eZRoCIsv2PhQXAgt8l9TrUaseYuVsMewmvbsT-WY1c2sYa_FBtbYHIRAKJs2J8wRCE4JcQxfG98xSc-6Sse3Pn0uuWviNXH1emZ3DpvTMatFeTPWEs72xPkBR_VAow&tab=service-feature
• https://docs.aws.amazon.com/network-firewall/latest/developerguide/rule-groups-url-filtering.html