{"id":321,"date":"2026-04-13T15:48:11","date_gmt":"2026-04-13T15:48:11","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/aws-network-firewall-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-security-identity-and-compliance\/"},"modified":"2026-04-13T15:48:11","modified_gmt":"2026-04-13T15:48:11","slug":"aws-network-firewall-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-security-identity-and-compliance","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/aws-network-firewall-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-security-identity-and-compliance\/","title":{"rendered":"AWS Network Firewall Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Security, identity, and compliance"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Security, identity, and compliance<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What this service is<\/h3>\n\n\n\n<p>AWS Network Firewall is an AWS-managed network security service that helps you filter and monitor network traffic in your Amazon Virtual Private Cloud (Amazon VPC). It provides centralized, scalable, policy-based inspection for traffic flowing to, from, or within VPCs\u2014without requiring you to deploy and operate your own firewall appliances.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">One-paragraph simple explanation<\/h3>\n\n\n\n<p>If you need \u201ca real firewall\u201d for your VPC\u2014one that can block known bad domains, inspect protocols, enforce allow\/deny lists, and log traffic for investigations\u2014AWS Network Firewall gives you that as a managed service. You define the rules, place the firewall in dedicated subnets, and route traffic through it.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">One-paragraph technical explanation<\/h3>\n\n\n\n<p>Technically, AWS Network Firewall deploys redundant firewall endpoints into subnets you choose (typically one subnet per Availability Zone). You attach firewall policies that contain stateless and stateful rule groups (including Suricata-compatible rules and managed rule groups). Traffic is steered to the firewall using VPC routing (route tables), and the service can emit flow, alert, and TLS logs to destinations such as Amazon CloudWatch Logs, Amazon S3, or Amazon Kinesis Data Firehose for monitoring and forensics.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What problem it solves<\/h3>\n\n\n\n<p>Security groups and network ACLs are foundational, but they are not full-featured firewalls and they don\u2019t provide deep packet inspection (DPI), managed threat signatures, or centralized, rich network security logging. AWS Network Firewall solves the \u201cmanaged inspection layer\u201d problem: consistent network controls, visibility, and compliance evidence across VPC traffic paths\u2014without building and scaling a fleet of firewall EC2 instances.<\/p>\n\n\n\n<blockquote>\n<p>Service status and naming: <strong>AWS Network Firewall<\/strong> is the current, active service name (not renamed or retired as of the latest known documentation). Always verify the newest capabilities and quotas in the official docs because managed security services evolve frequently.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is AWS Network Firewall?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Official purpose<\/h3>\n\n\n\n<p>AWS Network Firewall is designed to help you <strong>protect your VPC networks<\/strong> by filtering traffic based on rules you define and by applying managed threat intelligence and intrusion detection\/prevention style patterns\u2014while providing detailed logs for visibility and compliance.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities (high level)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Stateful traffic inspection<\/strong> (connection-aware filtering)<\/li>\n<li><strong>Stateless packet filtering<\/strong> (fast, first-pass match\/act)<\/li>\n<li><strong>Intrusion detection\/prevention-style rule support<\/strong> (Suricata-compatible)<\/li>\n<li><strong>Domain-based filtering<\/strong> (for example, using HTTP Host headers and TLS SNI where applicable)<\/li>\n<li><strong>Managed rule groups<\/strong> (AWS-managed threat intelligence and protections\u2014availability varies by region)<\/li>\n<li><strong>Centralized logging<\/strong> (flow, alert, and TLS logs)<\/li>\n<li><strong>VPC routing integration<\/strong> (steer traffic via route tables)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Firewall<\/strong>: The actual deployed resource that creates <strong>firewall endpoints<\/strong> in selected subnets (typically one per AZ). You route traffic to these endpoints.<\/li>\n<li><strong>Firewall policy<\/strong>: A policy document that defines how traffic is handled, including which stateless and stateful rule groups apply and what default actions occur.<\/li>\n<li><strong>Rule groups<\/strong>:<\/li>\n<li><strong>Stateless rule groups<\/strong>: Evaluate packets and take immediate actions (pass, drop, forward to stateful).<\/li>\n<li><strong>Stateful rule groups<\/strong>: Track connections and apply deeper inspection; supports multiple rule formats (including Suricata-compatible rules).<\/li>\n<li><strong>Managed rule groups<\/strong>: Curated rules maintained by AWS (and sometimes partner-managed options, depending on region and offering).<\/li>\n<li><strong>Logging configuration<\/strong>: Defines where flow\/alert\/TLS logs are sent (CloudWatch Logs, S3, or Kinesis Data Firehose).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Managed network security service<\/strong> (firewall-as-a-service within a VPC)<\/li>\n<li>Deployed <strong>inside your VPC<\/strong> via <strong>firewall endpoints<\/strong> created in your subnets<\/li>\n<li>Controlled through the AWS Console, AWS CLI, SDKs, and Infrastructure as Code (IaC) tools<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scope: regional\/global\/zonal<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Regional service<\/strong> in the sense that you create resources in a <strong>specific AWS Region<\/strong>.<\/li>\n<li>Firewall endpoints are created in <strong>subnets<\/strong>, which are <strong>Availability Zone\u2013scoped<\/strong> (you typically deploy across multiple AZs for high availability).<\/li>\n<li>Resources are <strong>account-scoped within a Region<\/strong> (you can share and manage at scale using governance tooling such as AWS Organizations and AWS Firewall Manager\u2014verify applicability for your org design).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the AWS ecosystem<\/h3>\n\n\n\n<p>AWS Network Firewall typically sits alongside:\n&#8211; <strong>Amazon VPC<\/strong> (routing, subnets, route tables)\n&#8211; <strong>AWS Transit Gateway<\/strong> (centralized hub-and-spoke inspection patterns)\n&#8211; <strong>NAT Gateway \/ Internet Gateway<\/strong> (egress\/ingress paths)\n&#8211; <strong>VPC endpoints \/ AWS PrivateLink<\/strong> (reduce internet egress; still may want inspection for remaining traffic)\n&#8211; <strong>Amazon CloudWatch \/ S3 \/ Kinesis Data Firehose<\/strong> (logging destinations)\n&#8211; <strong>AWS Firewall Manager<\/strong> (centralized policy management across accounts\u2014verify latest supported policy types)\n&#8211; <strong>AWS WAF<\/strong> (Layer 7 web application protection\u2014complementary, not a replacement)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use AWS Network Firewall?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Reduce operational burden<\/strong>: Avoid deploying, patching, scaling, and maintaining third-party firewall appliances.<\/li>\n<li><strong>Faster security rollouts<\/strong>: Centralize network security policy and reuse rule groups across environments.<\/li>\n<li><strong>Audit readiness<\/strong>: Built-in logging makes it easier to produce evidence for security reviews and compliance audits.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Deeper inspection than SG\/NACL<\/strong>: Security groups and NACLs are important but limited; AWS Network Firewall adds stateful inspection and richer rule logic.<\/li>\n<li><strong>Managed threat protections<\/strong>: Where available, AWS-managed rule groups help you keep up with common threats and indicators.<\/li>\n<li><strong>Consistent enforcement<\/strong>: Route traffic through a dedicated inspection layer instead of relying on ad-hoc instance-based controls.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Central visibility<\/strong>: Flow\/alert\/TLS logs enable troubleshooting, incident response, and security analytics.<\/li>\n<li><strong>Change management<\/strong>: Policies and rule groups can be versioned and updated more predictably than scattered host firewalls.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Segmentation and policy enforcement<\/strong>: Enforce egress restrictions, block known-bad destinations, or constrain east-west flows.<\/li>\n<li><strong>Defense-in-depth<\/strong>: Combine with SG\/NACL, AWS WAF, GuardDuty, IAM controls, and VPC endpoints.<\/li>\n<li><strong>Central log retention<\/strong>: Route firewall logs to security data lakes (S3) and SIEM pipelines (Firehose).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Managed scaling<\/strong>: The service is designed to scale with traffic patterns; you focus on policy and architecture rather than appliance sizing.<\/li>\n<li><strong>Multi-AZ design<\/strong>: Built to run across Availability Zones when you deploy endpoints across AZs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<p>Choose AWS Network Firewall when you need:\n&#8211; Centralized, VPC-native <strong>network firewalling<\/strong>\n&#8211; <strong>Egress control<\/strong> (domain blocking, allow lists, threat intelligence)\n&#8211; <strong>Inspection before internet access<\/strong> for private workloads\n&#8211; <strong>Central inspection for Transit Gateway<\/strong> architectures\n&#8211; <strong>Detailed network security logs<\/strong> for detection and compliance<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<p>It may not be the best fit when:\n&#8211; You only need basic L3\/L4 allow rules (security groups + NACLs might be sufficient).\n&#8211; You only need web application protection for HTTP(S) at the edge (use <strong>AWS WAF<\/strong> + <strong>CloudFront\/ALB<\/strong>).\n&#8211; Your traffic pattern cannot be routed through dedicated subnets\/endpoints (AWS Network Firewall is routing-based; it does not transparently \u201csniff\u201d traffic like a span port).\n&#8211; You require features only present in specific third-party firewalls (e.g., certain advanced proxy capabilities, specialized DLP, niche vendor ecosystems). In those cases, evaluate <strong>AWS Gateway Load Balancer<\/strong> with third-party appliances.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is AWS Network Firewall used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<p>Common in industries with strict security controls and audit requirements:\n&#8211; Financial services and fintech\n&#8211; Healthcare and life sciences\n&#8211; Public sector and education\n&#8211; SaaS providers handling sensitive data\n&#8211; Retail\/e-commerce (especially where PCI and fraud controls drive requirements)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud platform teams building shared VPC patterns<\/li>\n<li>Security engineering and SecOps teams<\/li>\n<li>Network engineering teams modernizing to cloud-native routing<\/li>\n<li>DevOps\/SRE teams operating production VPCs at scale<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Internet-bound microservices and APIs running in private subnets<\/li>\n<li>Data processing and ETL jobs with controlled egress requirements<\/li>\n<li>Shared services VPCs (AD, patching, logging collectors)<\/li>\n<li>Third-party integrations needing strict outbound allow lists<\/li>\n<li>Multi-account landing zones with centralized inspection<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Single VPC with dedicated firewall subnets for egress control<\/li>\n<li>Hub-and-spoke with AWS Transit Gateway and centralized inspection VPC<\/li>\n<li>Multi-AZ production networks requiring resilient inspection paths<\/li>\n<li>Hybrid connectivity where on-prem traffic enters AWS and must be inspected before reaching workloads<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Production<\/strong>: Deployed multi-AZ, with strong logging, change control, and incident runbooks.<\/li>\n<li><strong>Dev\/test<\/strong>: Often deployed single-AZ to reduce cost, with smaller rule sets and relaxed default actions\u2014while still practicing the same routing design.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic scenarios where AWS Network Firewall is commonly used.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Private subnet egress control (internet access with inspection)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Workloads in private subnets need outbound internet access, but security requires inspection and blocking risky destinations.<\/li>\n<li><strong>Why AWS Network Firewall fits<\/strong>: You can route all 0.0.0.0\/0 traffic through firewall endpoints before it reaches a NAT Gateway\/Internet Gateway path.<\/li>\n<li><strong>Example<\/strong>: EKS worker nodes in private subnets must pull container images and call external APIs, but must block known malware domains.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Domain-based blocking for policy enforcement<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Teams must prevent access to certain categories of domains (phishing, crypto mining, risky file-sharing).<\/li>\n<li><strong>Why it fits<\/strong>: Stateful rules and (where supported) domain-based matching can block by domain indicators rather than raw IPs.<\/li>\n<li><strong>Example<\/strong>: Block outbound access to a list of known command-and-control domains while allowing general web access.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Centralized inspection in a Transit Gateway hub<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Many spoke VPCs need consistent network filtering without deploying per-VPC appliances.<\/li>\n<li><strong>Why it fits<\/strong>: A centralized inspection VPC can enforce policies for multiple VPCs when combined with Transit Gateway routing.<\/li>\n<li><strong>Example<\/strong>: A shared \u201cSecurity VPC\u201d inspects inter-VPC traffic and egress from all application accounts.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) East-west segmentation between application tiers<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You need strict controls between subnets (e.g., app tier \u2192 DB tier) beyond basic SG rules, plus visibility.<\/li>\n<li><strong>Why it fits<\/strong>: Traffic routed through the firewall can be inspected and logged, giving both enforcement and audit trails.<\/li>\n<li><strong>Example<\/strong>: Only specific app subnets can reach database subnets on approved ports; all other attempts are logged as alerts.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Intrusion detection\/prevention-style alerting (Suricata rules)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You want alerts when suspicious network patterns occur, not just allow\/deny.<\/li>\n<li><strong>Why it fits<\/strong>: AWS Network Firewall supports stateful inspection with Suricata-compatible rules (verify current supported keyword sets in docs).<\/li>\n<li><strong>Example<\/strong>: Alert when outbound traffic matches known exploit patterns or suspicious user agents.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Mandatory logging for compliance and investigations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Auditors require network traffic logs retained for a defined period and searchable for investigations.<\/li>\n<li><strong>Why it fits<\/strong>: It can emit structured logs to CloudWatch Logs\/S3\/Firehose, enabling retention and analysis.<\/li>\n<li><strong>Example<\/strong>: Route logs to S3 with lifecycle policies and query them using Athena (Athena setup is separate).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Controlled outbound access to third-party SaaS endpoints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Only specific outbound destinations are allowed (vendor APIs, payment gateways).<\/li>\n<li><strong>Why it fits<\/strong>: Create allow lists and default-deny policies for egress traffic.<\/li>\n<li><strong>Example<\/strong>: A PCI workload can only reach approved payment processor endpoints; everything else is blocked and logged.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Protecting workloads exposed via inbound paths (inspection before public subnets)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You want to inspect inbound traffic before it reaches internet-facing resources.<\/li>\n<li><strong>Why it fits<\/strong>: With careful routing patterns, you can steer inbound paths through firewall endpoints (design varies; verify recommended architectures for your use case).<\/li>\n<li><strong>Example<\/strong>: Ingress from a centralized ingress VPC is inspected before reaching a shared services VPC.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Multi-account governance with centralized policy patterns<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Different teams create VPCs; you need consistent network security baselines.<\/li>\n<li><strong>Why it fits<\/strong>: Policies and rule groups can be standardized; with organizational tooling you can scale enforcement (verify AWS Firewall Manager support for your needs).<\/li>\n<li><strong>Example<\/strong>: All production accounts must enforce a baseline egress deny list and log all denied flows.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Blocking risky protocols or ports organization-wide<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Security wants to block outbound SMTP or unknown high-risk ports from application VPCs.<\/li>\n<li><strong>Why it fits<\/strong>: Stateless\/stateful rules can enforce port\/protocol restrictions consistently.<\/li>\n<li><strong>Example<\/strong>: Prevent data exfiltration by blocking outbound SMTP (25) and direct database ports to the internet.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Controlled access for build systems and CI\/CD runners<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Build runners need outbound access, but only to approved artifact repositories and update endpoints.<\/li>\n<li><strong>Why it fits<\/strong>: Firewall policies can enforce egress allow lists and reduce supply-chain risk.<\/li>\n<li><strong>Example<\/strong>: A private build subnet can only reach Git provider domains and OS update mirrors.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Investigating suspicious activity with correlated logs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You suspect a compromised instance; you need evidence of unusual outbound connections.<\/li>\n<li><strong>Why it fits<\/strong>: Flow and alert logs provide a high-signal view of what was attempted and what was blocked.<\/li>\n<li><strong>Example<\/strong>: Alerts show repeated denied attempts to known malicious domains from a specific private IP.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<blockquote>\n<p>Note: Feature availability can vary by Region and over time. Always confirm in the official documentation before implementing a compliance-critical design.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">1) Stateful firewall rules (connection-aware inspection)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Evaluates traffic with awareness of sessions\/flows, enabling rules based on connection state and more advanced matching.<\/li>\n<li><strong>Why it matters<\/strong>: Prevents simplistic evasion and supports more nuanced policy than pure packet filtering.<\/li>\n<li><strong>Practical benefit<\/strong>: Better control over egress\/ingress patterns and more meaningful alerting.<\/li>\n<li><strong>Caveats<\/strong>: Stateful inspection can be more complex to design and test; rule ordering and default actions matter.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Stateless firewall rules (packet filtering)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Applies fast match\/action logic at the packet level, commonly used to drop obviously unwanted traffic or forward selected traffic to the stateful engine.<\/li>\n<li><strong>Why it matters<\/strong>: Efficient first-line control and a place to enforce simple L3\/L4 rules.<\/li>\n<li><strong>Practical benefit<\/strong>: Lower operational complexity for basic allow\/deny patterns.<\/li>\n<li><strong>Caveats<\/strong>: Stateless rules alone may not provide the depth needed for threat detection.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Rule groups and firewall policies (reusable building blocks)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Rule groups encapsulate sets of rules; policies attach multiple rule groups and define default behavior.<\/li>\n<li><strong>Why it matters<\/strong>: Encourages modularity, reuse, and safer change management.<\/li>\n<li><strong>Practical benefit<\/strong>: You can maintain common baseline rule groups and apply them across multiple firewalls\/VPCs.<\/li>\n<li><strong>Caveats<\/strong>: Poor modularization can lead to policy sprawl; standardize naming and ownership.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Suricata-compatible rule support (stateful)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Supports Suricata-style rules for deeper inspection patterns (keywords and supported features are documented by AWS).<\/li>\n<li><strong>Why it matters<\/strong>: Leverages established IDS\/IPS rule patterns and enables sophisticated detections.<\/li>\n<li><strong>Practical benefit<\/strong>: Alert on known exploit attempts or suspicious protocols.<\/li>\n<li><strong>Caveats<\/strong>: Suricata rule authoring requires expertise; test carefully to avoid false positives.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Managed rule groups (AWS-managed protections)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Provides curated, AWS-maintained rule groups (often focused on threat intelligence and commonly exploited patterns).<\/li>\n<li><strong>Why it matters<\/strong>: Reduces time to get baseline protections and improves hygiene.<\/li>\n<li><strong>Practical benefit<\/strong>: Faster deployment of known-bad indicators with reduced maintenance burden.<\/li>\n<li><strong>Caveats<\/strong>: Managed group availability and scope vary; confirm coverage and update behavior in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Domain list \/ domain-based filtering (where supported)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Helps allow\/deny traffic based on domain names observed in certain protocols (commonly HTTP Host and TLS SNI).<\/li>\n<li><strong>Why it matters<\/strong>: Many modern services use dynamic IPs; domain-based control can be more stable than IP allow lists.<\/li>\n<li><strong>Practical benefit<\/strong>: Block specific risky domains even when their IPs change.<\/li>\n<li><strong>Caveats<\/strong>: Not all traffic exposes a domain; encrypted traffic may hide details beyond SNI; QUIC\/HTTP3 can complicate visibility. Verify current capabilities.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Logging: flow logs, alert logs, TLS logs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>:<\/li>\n<li><strong>Flow logs<\/strong>: metadata about connections\/flows<\/li>\n<li><strong>Alert logs<\/strong>: triggered rule matches\/alerts<\/li>\n<li><strong>TLS logs<\/strong>: metadata about TLS sessions (where supported and enabled)<\/li>\n<li><strong>Why it matters<\/strong>: Visibility is essential for detection, troubleshooting, and audits.<\/li>\n<li><strong>Practical benefit<\/strong>: You can trace blocked connections to source subnets\/instances and refine policy.<\/li>\n<li><strong>Caveats<\/strong>: Logging can generate significant volume and cost (CloudWatch ingestion, S3 storage, Firehose). Plan retention.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) VPC routing integration (traffic steering)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Uses route tables to direct traffic to firewall endpoints.<\/li>\n<li><strong>Why it matters<\/strong>: Clean integration with VPC networking; no need for inline appliance load balancers for basic patterns.<\/li>\n<li><strong>Practical benefit<\/strong>: Deterministic traffic paths; easy to reason about with routing diagrams.<\/li>\n<li><strong>Caveats<\/strong>: Requires careful route table design to avoid asymmetric routing or blackholes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Multi-AZ endpoints for resilience<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: When you associate multiple subnets across AZs, AWS Network Firewall creates endpoints in each.<\/li>\n<li><strong>Why it matters<\/strong>: Avoids single-AZ failure domains for inspection.<\/li>\n<li><strong>Practical benefit<\/strong>: Production-grade availability.<\/li>\n<li><strong>Caveats<\/strong>: Multi-AZ increases cost (endpoints per AZ) and requires consistent subnet\/route setup per AZ.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Automation support (API\/CLI\/IaC)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Supports programmatic management for repeatable deployment.<\/li>\n<li><strong>Why it matters<\/strong>: Infrastructure as Code reduces configuration drift and improves reviewability.<\/li>\n<li><strong>Practical benefit<\/strong>: Integrate with CI\/CD pipelines, change approvals, and environment promotion.<\/li>\n<li><strong>Caveats<\/strong>: Ensure IAM boundaries and change controls\u2014firewall changes are security-sensitive.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level service architecture<\/h3>\n\n\n\n<p>At a high level:\n1. You deploy an <strong>AWS Network Firewall<\/strong> into your VPC.\n2. The firewall creates <strong>endpoints<\/strong> in the subnets you associate (commonly called <em>firewall subnets<\/em>).\n3. You configure <strong>route tables<\/strong> so that desired traffic (for example, private subnet internet-bound traffic) routes to those firewall endpoints.\n4. The firewall applies <strong>stateless rules<\/strong>, then (optionally) passes traffic to the <strong>stateful engine<\/strong>.\n5. Allowed traffic continues to its destination (for example, NAT Gateway \u2192 Internet).\n6. Logs are emitted to your chosen destination.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/data\/control flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control plane<\/strong>:<\/li>\n<li>You create\/update firewall policies and rule groups via Console\/CLI\/API.<\/li>\n<li>IAM authorizes management actions.<\/li>\n<li><strong>Data plane<\/strong>:<\/li>\n<li>Packets flow from source subnet \u2192 route table \u2192 <strong>firewall endpoint<\/strong> \u2192 next hop (NAT\/IGW\/TGW\/etc.)<\/li>\n<li>The firewall inspects traffic and allows\/drops\/alerts.<\/li>\n<li>Logs are streamed asynchronously to CloudWatch\/S3\/Firehose.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services<\/h3>\n\n\n\n<p>Common integrations include:\n&#8211; <strong>Amazon VPC route tables<\/strong>: Primary traffic steering mechanism.\n&#8211; <strong>NAT Gateway<\/strong>: Often used for outbound internet access from private subnets after inspection.\n&#8211; <strong>Internet Gateway<\/strong>: For internet connectivity.\n&#8211; <strong>AWS Transit Gateway<\/strong>: Centralized connectivity and inspection patterns.\n&#8211; <strong>CloudWatch Logs \/ S3 \/ Firehose<\/strong>: Log destinations for monitoring and SIEM pipelines.\n&#8211; <strong>AWS Firewall Manager<\/strong>: Central management across accounts (verify current support for AWS Network Firewall policies and your org structure).\n&#8211; <strong>AWS Organizations<\/strong>: Governance and multi-account patterns.\n&#8211; <strong>Amazon EC2 \/ EKS \/ ECS<\/strong>: Workloads whose traffic you\u2019re inspecting.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You must have an <strong>Amazon VPC<\/strong> with appropriate subnets and routing.<\/li>\n<li>For common outbound patterns, you often need <strong>NAT Gateway<\/strong> and an <strong>Internet Gateway<\/strong>.<\/li>\n<li>For private management access without bastions, <strong>AWS Systems Manager (SSM)<\/strong> is commonly used.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>IAM<\/strong> controls who can create, modify, and delete firewall resources and who can read logs.<\/li>\n<li>Use <strong>least privilege<\/strong> and consider separating:<\/li>\n<li>Network platform administrators (routing\/VPC)<\/li>\n<li>Security policy owners (rule groups\/policies)<\/li>\n<li>Observability\/SOC (log read access)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model (what it can and cannot inspect)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS Network Firewall inspects traffic <strong>that you route through it<\/strong>.<\/li>\n<li>It does not automatically inspect all traffic in the VPC; steering is explicit via route tables (or via centralized patterns using Transit Gateway).<\/li>\n<li>It is commonly placed at:<\/li>\n<li>VPC <strong>egress<\/strong><\/li>\n<li><strong>Ingress<\/strong> paths (architecture-dependent)<\/li>\n<li><strong>Inter-VPC<\/strong> or <strong>east-west<\/strong> inspection points (when routing makes it feasible)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable <strong>alert logs<\/strong> early; they help validate rule matches.<\/li>\n<li>Send <strong>flow logs<\/strong> where you need broad visibility (but control cost).<\/li>\n<li>Consider shipping logs to <strong>S3<\/strong> for long-term retention and to <strong>CloudWatch Logs<\/strong> for near-real-time troubleshooting.<\/li>\n<li>Use tagging standards: environment, owner, cost center, policy version.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (single-VPC egress inspection)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  subgraph VPC[\"Amazon VPC\"]\n    subgraph Private[\"Private Subnet\"]\n      EC2[\"EC2 Instance (no public IP)\"]\n    end\n\n    subgraph FWSub[\"Firewall Subnet\"]\n      NFWEP[\"AWS Network Firewall Endpoint\"]\n    end\n\n    subgraph Public[\"Public Subnet\"]\n      NAT[\"NAT Gateway\"]\n      IGW[\"Internet Gateway\"]\n    end\n  end\n\n  EC2 --&gt;|\"0.0.0.0\/0 route\"| NFWEP\n  NFWEP --&gt;|\"allow\"| NAT\n  NAT --&gt; IGW\n  IGW --&gt; Internet[\"Internet\"]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (multi-account + centralized inspection)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Org[\"AWS Organizations (multi-account)\"]\n    subgraph SecAcct[\"Security Account\"]\n      SIEM[\"Log\/SIEM Pipeline\\n(S3 + Firehose\/Analytics)\"]\n    end\n\n    subgraph NetAcct[\"Network\/Shared Services Account\"]\n      TGW[\"AWS Transit Gateway\"]\n      subgraph InspectVPC[\"Inspection VPC\"]\n        NFW[\"AWS Network Firewall\\n(Multi-AZ Endpoints)\"]\n        NFWLogs[\"Flow\/Alert\/TLS Logs\"]\n      end\n    end\n\n    subgraph AppAcctA[\"App Account A\"]\n      VPC_A[\"Spoke VPC A\"]\n      WorkA[\"Workloads A\"]\n    end\n\n    subgraph AppAcctB[\"App Account B\"]\n      VPC_B[\"Spoke VPC B\"]\n      WorkB[\"Workloads B\"]\n    end\n  end\n\n  WorkA --&gt; VPC_A --&gt; TGW\n  WorkB --&gt; VPC_B --&gt; TGW\n  TGW --&gt; InspectVPC --&gt; NFW --&gt; Egress[\"NAT\/IGW or On-Prem\"]\n  NFW --&gt; NFWLogs --&gt; SIEM\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Account requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>An <strong>AWS account<\/strong> with billing enabled.<\/li>\n<li>(Recommended) A dedicated sandbox or lab account to avoid impacting production routing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>You need permissions to:\n&#8211; Create and manage VPC resources: VPC, subnets, route tables, Internet Gateway, NAT Gateway, security groups, EC2.\n&#8211; Create and manage AWS Network Firewall resources:\n  &#8211; <code>network-firewall:CreateFirewall<\/code>\n  &#8211; <code>network-firewall:CreateFirewallPolicy<\/code>\n  &#8211; <code>network-firewall:CreateRuleGroup<\/code>\n  &#8211; <code>network-firewall:AssociateFirewallPolicy<\/code>\n  &#8211; <code>network-firewall:Update*<\/code>, <code>network-firewall:Delete*<\/code>, etc.\n&#8211; Create log destinations (if used): CloudWatch Logs groups\/streams, S3 buckets, Firehose delivery streams.\n&#8211; Use SSM (optional but recommended): <code>ssm:StartSession<\/code>, <code>ssm:SendCommand<\/code>, plus instance profile permissions such as <code>AmazonSSMManagedInstanceCore<\/code>.<\/p>\n\n\n\n<p>If you don\u2019t have admin access, ask for a scoped role or temporary elevated access for this lab.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS Network Firewall is a paid service.<\/li>\n<li>NAT Gateway and CloudWatch Logs also incur costs.<\/li>\n<li>Plan to <strong>clean up<\/strong> after the lab.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Tools needed<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS Management Console (sufficient for this lab)<\/li>\n<li>AWS CLI v2 (optional, for verification and scripting)<\/li>\n<li>Install: https:\/\/docs.aws.amazon.com\/cli\/latest\/userguide\/getting-started-install.html<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS Network Firewall is <strong>not available in every AWS Region<\/strong>. Verify Region availability in:<\/li>\n<li>Official docs: https:\/\/docs.aws.amazon.com\/network-firewall\/latest\/developerguide\/what-is-aws-network-firewall.html  <\/li>\n<li>Or the AWS Regional Services List (official)<\/li>\n<li>Choose a Region where AWS Network Firewall and NAT Gateway are available.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<p>AWS Network Firewall has quotas such as:\n&#8211; Number of firewalls\n&#8211; Rule group capacity (capacity units)\n&#8211; Rate limits on API operations\n&#8211; Logging throughput considerations<\/p>\n\n\n\n<p>Always confirm current quotas in the Service Quotas console and official docs:\n&#8211; Service Quotas: https:\/\/console.aws.amazon.com\/servicequotas\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Amazon VPC<\/li>\n<li>Amazon EC2 (for generating test traffic)<\/li>\n<li>(Recommended) AWS Systems Manager for instance access<\/li>\n<li>CloudWatch Logs (optional but recommended for observing alerts\/flows)<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<blockquote>\n<p>Pricing changes and is Region-dependent. Do not rely on static blog numbers\u2014use official sources.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Current pricing model (dimensions)<\/h3>\n\n\n\n<p>AWS Network Firewall pricing is commonly based on:\n1. <strong>Firewall endpoint-hours<\/strong><br\/>\n   &#8211; You pay per hour for each firewall endpoint deployed (endpoints are created per associated subnet\/AZ).\n2. <strong>Data processed (GB)<\/strong><br\/>\n   &#8211; You pay per GB of traffic processed by the firewall.<\/p>\n\n\n\n<p>Verify the exact dimensions, units, and Region-specific rates on the official pricing page:\n&#8211; Official pricing: https:\/\/aws.amazon.com\/network-firewall\/pricing\/\n&#8211; AWS Pricing Calculator: https:\/\/calculator.aws\/#\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS Network Firewall <strong>does not typically have a perpetual free tier<\/strong> like some AWS services.<\/li>\n<li>Occasionally AWS may offer trials\/credits in certain programs; verify current offers on the pricing page.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Primary cost drivers<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Number of AZs \/ endpoints<\/strong>: Multi-AZ means multiple endpoints billed hourly.<\/li>\n<li><strong>Traffic volume through the firewall<\/strong>: GB processed can dominate cost in high-throughput environments.<\/li>\n<li><strong>Logging volume<\/strong>:<\/li>\n<li>CloudWatch Logs ingestion and retention<\/li>\n<li>Kinesis Data Firehose delivery and transformation (if used)<\/li>\n<li>S3 storage and requests<\/li>\n<li><strong>NAT Gateway<\/strong> (if used for egress):<\/li>\n<li>NAT Gateway hourly charges<\/li>\n<li>NAT data processing charges<\/li>\n<li><strong>Data transfer<\/strong>:<\/li>\n<li>Inter-AZ data transfer may apply depending on your routing design.<\/li>\n<li>Internet egress charges apply after NAT\/IGW (standard AWS data transfer pricing).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden or indirect costs to plan for<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>NAT Gateway costs<\/strong> (often surprisingly high in long-running labs).<\/li>\n<li><strong>CloudWatch Logs retention<\/strong> (default never-expire can accumulate).<\/li>\n<li><strong>Cross-AZ routing<\/strong>: If private subnet routes to a firewall endpoint in a different AZ, you may incur cross-AZ data charges and create failure modes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost optimization tips<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>single-AZ<\/strong> for non-production labs (and delete promptly).<\/li>\n<li>Keep rule sets minimal in dev\/test (but realistic enough to validate behavior).<\/li>\n<li>Log selectively:<\/li>\n<li>Enable alert logs for security validation<\/li>\n<li>Enable flow logs only where required and set retention<\/li>\n<li>Prefer <strong>VPC endpoints<\/strong> for AWS service access to reduce internet\/NAT traffic (architecture-dependent).<\/li>\n<li>Avoid unnecessary traffic through the firewall (route only what must be inspected).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (conceptual)<\/h3>\n\n\n\n<p>A low-cost lab typically includes:\n&#8211; 1 AZ firewall endpoint running for a short duration\n&#8211; Low traffic volume (few MB\/GB)\n&#8211; Minimal CloudWatch logging\n&#8211; NAT Gateway for a short time<\/p>\n\n\n\n<p>Because exact rates vary by Region, estimate using the AWS Pricing Calculator with:\n&#8211; 1 endpoint-hour for each hour the lab runs\n&#8211; A small number of GB processed\n&#8211; NAT Gateway hours + NAT data processed\n&#8211; CloudWatch Logs ingestion (small)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>For production:\n&#8211; Multi-AZ endpoints (2\u20133 AZs) running 24\/7\n&#8211; Sustained high-throughput traffic (GB processed costs)\n&#8211; Centralized log pipelines (Firehose\/S3\/SIEM)\n&#8211; Potential duplicate processing if traffic passes through multiple inspection layers<\/p>\n\n\n\n<p>Production cost control usually requires:\n&#8211; Careful routing design (avoid hairpinning)\n&#8211; Traffic segmentation (inspect only what needs it)\n&#8211; Log lifecycle management\n&#8211; Regular review of rule group efficacy vs. noise<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Deploy <strong>AWS Network Firewall<\/strong> in a <strong>single-AZ<\/strong> lab VPC to inspect <strong>outbound internet traffic<\/strong> from a private EC2 instance, <strong>block a specific domain<\/strong>, and <strong>verify<\/strong> the behavior using logs and curl tests.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will build this path:<\/p>\n\n\n\n<p>Private EC2 (no public IP) \u2192 Route table \u2192 <strong>AWS Network Firewall endpoint<\/strong> \u2192 Route table \u2192 <strong>NAT Gateway<\/strong> \u2192 Internet Gateway \u2192 Internet<\/p>\n\n\n\n<p>You will also enable <strong>alert logging<\/strong> to CloudWatch Logs so you can see rule matches.<\/p>\n\n\n\n<p><strong>What you\u2019ll implement<\/strong>\n&#8211; A new VPC with:\n  &#8211; 1 public subnet (for NAT Gateway)\n  &#8211; 1 firewall subnet (for AWS Network Firewall endpoint)\n  &#8211; 1 private subnet (for EC2)\n&#8211; An EC2 instance in the private subnet (accessed via SSM Session Manager)\n&#8211; AWS Network Firewall with:\n  &#8211; Firewall policy\n  &#8211; Stateful rule group that <strong>denies<\/strong> a domain (example: <code>example.com<\/code>)\n  &#8211; Logging to CloudWatch Logs<\/p>\n\n\n\n<p><strong>Expected results<\/strong>\n&#8211; <code>curl https:\/\/example.com<\/code> fails (blocked)\n&#8211; <code>curl https:\/\/aws.amazon.com<\/code> succeeds (allowed)\n&#8211; CloudWatch Logs show alerts for blocked traffic<\/p>\n\n\n\n<blockquote>\n<p>Note: Domain-based blocking depends on protocol visibility (HTTP Host \/ TLS SNI). If your test client or protocol does not expose the domain in a way the rule can match, results can differ. If domain blocking does not work as expected, switch validation to an IP\/port-based rule for the lab, or verify domain list rule group support in your Region.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Choose a Region and set up basic variables (optional CLI)<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Pick an AWS Region that supports AWS Network Firewall (verify in official docs).<\/li>\n<li>(Optional) Configure AWS CLI:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">aws configure\naws sts get-caller-identity\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; You can access the AWS Console and\/or the CLI returns your account identity.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create a lab VPC and subnets<\/h3>\n\n\n\n<p>Use the AWS Console for clarity.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Go to <strong>VPC Console<\/strong> \u2192 <strong>Your VPCs<\/strong> \u2192 <strong>Create VPC<\/strong>.<\/li>\n<li>Create a VPC with:\n   &#8211; IPv4 CIDR: <code>10.0.0.0\/16<\/code>\n   &#8211; (IPv6 optional; keep off for this lab unless you need it)<\/li>\n<li>Create subnets (single AZ to reduce cost). Example:\n   &#8211; <strong>Public subnet<\/strong>: <code>10.0.0.0\/24<\/code>\n   &#8211; <strong>Firewall subnet<\/strong>: <code>10.0.1.0\/24<\/code>\n   &#8211; <strong>Private subnet<\/strong>: <code>10.0.2.0\/24<\/code><\/li>\n<li>Create and attach an <strong>Internet Gateway<\/strong> to the VPC.<\/li>\n<li>Create route tables:\n   &#8211; <code>rt-public<\/code>\n   &#8211; <code>rt-firewall<\/code>\n   &#8211; <code>rt-private<\/code><\/li>\n<li>Associate subnets:\n   &#8211; Public subnet \u2192 <code>rt-public<\/code>\n   &#8211; Firewall subnet \u2192 <code>rt-firewall<\/code>\n   &#8211; Private subnet \u2192 <code>rt-private<\/code><\/li>\n<\/ol>\n\n\n\n<p>Now set up <strong>public routing<\/strong>:\n&#8211; In <code>rt-public<\/code>, add route:\n  &#8211; Destination: <code>0.0.0.0\/0<\/code>\n  &#8211; Target: Internet Gateway<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; VPC exists with three subnets and correct route table associations.\n&#8211; Public subnet has internet route via IGW.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create a NAT Gateway (public subnet)<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Go to <strong>VPC Console<\/strong> \u2192 <strong>NAT Gateways<\/strong> \u2192 <strong>Create NAT gateway<\/strong>.<\/li>\n<li>Choose:\n   &#8211; Subnet: your <strong>public subnet<\/strong>\n   &#8211; Connectivity type: Public\n   &#8211; Allocate a new <strong>Elastic IP<\/strong><\/li>\n<li>Create it and wait until status is <strong>Available<\/strong>.<\/li>\n<\/ol>\n\n\n\n<p>Update <code>rt-firewall<\/code> so the firewall subnet can reach the internet through NAT:\n&#8211; In <code>rt-firewall<\/code>, add route:\n  &#8211; Destination: <code>0.0.0.0\/0<\/code>\n  &#8211; Target: NAT Gateway<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; NAT Gateway is available.\n&#8211; Firewall subnet has a default route to NAT Gateway.<\/p>\n\n\n\n<blockquote>\n<p>Why route from firewall subnet to NAT? Because the firewall endpoint sits in the firewall subnet; after inspection, internet-bound traffic must reach NAT to get out to the Internet Gateway (for private source addresses).<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Create IAM role and EC2 instance profile for SSM (recommended)<\/h3>\n\n\n\n<p>To avoid opening SSH, use Session Manager.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Go to <strong>IAM<\/strong> \u2192 <strong>Roles<\/strong> \u2192 <strong>Create role<\/strong>.<\/li>\n<li>Trusted entity: <strong>AWS service<\/strong> \u2192 <strong>EC2<\/strong>.<\/li>\n<li>Attach policy: <strong>AmazonSSMManagedInstanceCore<\/strong> (AWS managed policy).<\/li>\n<li>Name: <code>EC2SSMRole-NFWLab<\/code><\/li>\n<li>Create role.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; You have an instance role allowing the EC2 instance to register with Systems Manager.<\/p>\n\n\n\n<blockquote>\n<p>If your organization restricts managed policies, ask for an equivalent least-privilege SSM role.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Launch a private EC2 instance (no public IP)<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Go to <strong>EC2 Console<\/strong> \u2192 <strong>Instances<\/strong> \u2192 <strong>Launch instances<\/strong>.<\/li>\n<li>Choose:\n   &#8211; AMI: Amazon Linux 2023 or Amazon Linux 2 (either is fine for curl tests)\n   &#8211; Instance type: <code>t3.micro<\/code> (or similar)<\/li>\n<li>Network settings:\n   &#8211; VPC: your lab VPC\n   &#8211; Subnet: <strong>private subnet<\/strong>\n   &#8211; Auto-assign public IP: <strong>Disable<\/strong><\/li>\n<li>Security group:\n   &#8211; Allow <strong>no inbound<\/strong> (SSM does not require inbound rules).\n   &#8211; Allow all outbound (default) for the test; the firewall will enforce policy.<\/li>\n<li>IAM instance profile:\n   &#8211; Attach <code>EC2SSMRole-NFWLab<\/code><\/li>\n<li>Launch.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; EC2 instance is running in a private subnet without a public IP.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Create CloudWatch Log Group(s) for firewall logs<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Go to <strong>CloudWatch<\/strong> \u2192 <strong>Logs<\/strong> \u2192 <strong>Log groups<\/strong> \u2192 <strong>Create log group<\/strong>.<\/li>\n<li>Create a log group, for example:\n   &#8211; <code>\/aws\/network-firewall\/nfw-lab-alerts<\/code><\/li>\n<li>(Recommended) Set retention to a short period (e.g., 1\u20137 days) for a lab.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; Log group exists and you control retention to avoid ongoing cost.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Create a stateful rule group to block a domain (or a fallback rule)<\/h3>\n\n\n\n<p>You have two practical options for a lab:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Option A (preferred)<\/strong>: Domain-based deny list (blocks <code>example.com<\/code>)<\/li>\n<li><strong>Option B (fallback)<\/strong>: Simple stateful rule to block TCP 443 to a specific IP (less realistic, but reliable)<\/li>\n<\/ul>\n\n\n\n<p>Because domain-based behavior can vary by protocol visibility, implement Option A first and keep Option B in mind.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Option A: Domain-based deny list (stateful)<\/h4>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Go to <strong>VPC Console<\/strong> \u2192 <strong>Network Firewall<\/strong> \u2192 <strong>Rule groups<\/strong> \u2192 <strong>Create rule group<\/strong>.<\/li>\n<li>Choose:\n   &#8211; Type: <strong>Stateful<\/strong><\/li>\n<li>Choose a rule group format that supports <strong>domain list<\/strong> (exact UI wording can vary by time\/Region; verify in the console).<\/li>\n<li>Set:\n   &#8211; Action: <strong>Denylist<\/strong> (block)\n   &#8211; Domains: <code>example.com<\/code><\/li>\n<li>Name: <code>rg-deny-example-domain<\/code><\/li>\n<li>Create.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; A stateful rule group exists that should block traffic to <code>example.com<\/code> if the domain is observable (HTTP Host\/TLS SNI).<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Option B (fallback): Stateful Suricata rule (IP\/port block)<\/h4>\n\n\n\n<p>If Option A is not available in your Region\/UI, create a Suricata-compatible rule group that drops traffic matching specific patterns.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Create a <strong>Stateful<\/strong> rule group with <strong>Suricata compatible rules<\/strong>.<\/li>\n<li>Example rule (blocks HTTPS to a known IP\u2014replace with a stable test IP you control\/verify):<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-text\">drop tcp any any -&gt; 93.184.216.34 443 (msg:\"Block example.com IP over 443\"; sid:1000001; rev:1;)\n<\/code><\/pre>\n\n\n\n<p><strong>Important caveats<\/strong>\n&#8211; IPs for domains can change, and CDNs make this unreliable.\n&#8211; Use this only as a lab fallback to prove routing + enforcement.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 8: Create a firewall policy<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Go to <strong>Network Firewall<\/strong> \u2192 <strong>Firewall policies<\/strong> \u2192 <strong>Create firewall policy<\/strong>.<\/li>\n<li>Add your stateful rule group (<code>rg-deny-example-domain<\/code> or your fallback).<\/li>\n<li>Configure <strong>stateless default actions<\/strong>:\n   &#8211; Common pattern: forward traffic to stateful engine for inspection.\n   &#8211; In many deployments, you configure stateless rules to forward and let stateful rules decide.\n   &#8211; Use the console defaults if unsure, but <strong>verify<\/strong> the resulting policy behavior before production.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; A firewall policy exists and references your rule group(s).<\/p>\n\n\n\n<blockquote>\n<p>Tip: Keep the lab policy simple: one deny rule and an \u201callow\/forward rest\u201d behavior so you can easily validate.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 9: Create the AWS Network Firewall and associate subnets<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Go to <strong>Network Firewall<\/strong> \u2192 <strong>Firewalls<\/strong> \u2192 <strong>Create firewall<\/strong>.<\/li>\n<li>Configure:\n   &#8211; Name: <code>nfw-lab<\/code>\n   &#8211; VPC: your lab VPC\n   &#8211; Firewall policy: the policy created in Step 8<\/li>\n<li>Subnet mappings:\n   &#8211; Select the <strong>firewall subnet<\/strong> (single AZ for lab)<\/li>\n<li>Create firewall and wait for it to become <strong>Ready<\/strong>.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; Firewall exists and has created a <strong>firewall endpoint<\/strong> in the firewall subnet.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 10: Configure logging for the firewall<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Open <code>nfw-lab<\/code> firewall details.<\/li>\n<li>Find <strong>Logging configuration<\/strong> \u2192 <strong>Edit<\/strong>.<\/li>\n<li>Enable <strong>Alert logs<\/strong> to CloudWatch Logs:\n   &#8211; Destination type: CloudWatch Logs\n   &#8211; Log group: <code>\/aws\/network-firewall\/nfw-lab-alerts<\/code><\/li>\n<li>(Optional) Enable flow logs as well, but note it increases volume.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; Firewall will deliver alert logs to CloudWatch Logs when rules match.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 11: Update route tables to steer private subnet traffic through the firewall endpoint<\/h3>\n\n\n\n<p>This is the most important step.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p>Find the firewall endpoint ID:\n   &#8211; In the firewall details, look for <strong>Endpoints<\/strong> (an endpoint per subnet mapping\/AZ).\n   &#8211; Note the endpoint ID, typically formatted like a VPC endpoint (AWS-managed).<\/p>\n<\/li>\n<li>\n<p>Update the <strong>private subnet<\/strong> route table (<code>rt-private<\/code>):\n   &#8211; Add route:<\/p>\n<ul>\n<li>Destination: <code>0.0.0.0\/0<\/code><\/li>\n<li>Target: <strong>Network Firewall endpoint<\/strong> (select the endpoint for your AZ)<\/li>\n<\/ul>\n<\/li>\n<li>\n<p>Confirm <strong>firewall subnet<\/strong> routing (<code>rt-firewall<\/code>) still has:\n   &#8211; <code>0.0.0.0\/0<\/code> \u2192 NAT Gateway<\/p>\n<\/li>\n<li>\n<p>Confirm <strong>public subnet<\/strong> routing (<code>rt-public<\/code>) has:\n   &#8211; <code>0.0.0.0\/0<\/code> \u2192 Internet Gateway<\/p>\n<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; The private instance\u2019s internet-bound traffic is routed through AWS Network Firewall.<\/p>\n\n\n\n<p><strong>Common routing mistake to avoid<\/strong>\n&#8211; Routing private subnet directly to NAT Gateway bypasses the firewall.\n&#8211; Routing firewall subnet back to the firewall endpoint creates loops.\n&#8211; Mixing AZs (private in AZ-a, firewall endpoint in AZ-b) can create cross-AZ costs and failure modes\u2014keep all lab subnets in one AZ.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 12: Validate from the private instance (SSM Session Manager)<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Go to <strong>Systems Manager<\/strong> \u2192 <strong>Session Manager<\/strong> \u2192 <strong>Start session<\/strong>.<\/li>\n<li>Select your private EC2 instance and start a shell session.<\/li>\n<li>Run:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">curl -I https:\/\/aws.amazon.com\ncurl -I https:\/\/example.com\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; <code>https:\/\/aws.amazon.com<\/code> returns HTTP headers (e.g., <code>HTTP\/2 200<\/code> or <code>HTTP\/1.1 301<\/code>).\n&#8211; <code>https:\/\/example.com<\/code> should fail or time out if blocked by your rule.<\/p>\n\n\n\n<p>If <code>example.com<\/code> is not blocked:\n&#8211; Your domain-based rule may not be matching due to protocol specifics.\n&#8211; Enable flow logs and confirm traffic is traversing the firewall.\n&#8211; Consider switching to the fallback IP\/port rule (Option B) for deterministic blocking.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Use at least two validation methods:<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">A) Routing validation (does traffic traverse the firewall?)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Temporarily set the firewall policy to <strong>drop<\/strong> all (or add a very broad deny rule) and confirm all internet access from the private instance breaks.<\/li>\n<li>Then revert to your intended policy.<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">B) Log validation (did rules match?)<\/h4>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Go to <strong>CloudWatch Logs<\/strong> \u2192 log group <code>\/aws\/network-firewall\/nfw-lab-alerts<\/code>.<\/li>\n<li>Open the latest log stream and look for entries that indicate:\n   &#8211; The rule group and rule that matched\n   &#8211; Source\/destination metadata\n   &#8211; Action taken (drop\/alert)<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; You see alert records corresponding to blocked attempts.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\">Issue 1: \u201cNo internet\u201d from the private instance even for allowed sites<\/h4>\n\n\n\n<p>Likely causes:\n&#8211; Missing route in <code>rt-private<\/code> to the firewall endpoint\n&#8211; Missing route in <code>rt-firewall<\/code> to NAT Gateway\n&#8211; NAT Gateway not in a public subnet with route to IGW\n&#8211; Network ACL blocks ephemeral ports (if customized)\n&#8211; Security group egress rules too restrictive\n&#8211; Instance has no DNS resolution (check DHCP options \/ Route 53 Resolver settings)<\/p>\n\n\n\n<p>Quick checks (from the instance):<\/p>\n\n\n\n<pre><code class=\"language-bash\">dig aws.amazon.com +short || nslookup aws.amazon.com\ncurl -I https:\/\/1.1.1.1\n<\/code><\/pre>\n\n\n\n<h4 class=\"wp-block-heading\">Issue 2: Firewall logs show nothing<\/h4>\n\n\n\n<p>Likely causes:\n&#8211; Logging not enabled, or wrong log group\/permissions\n&#8211; You\u2019re sending logs to a destination you didn\u2019t configure (S3\/Firehose)\n&#8211; Traffic is bypassing the firewall (routes not updated)<\/p>\n\n\n\n<p>Confirm route tables and that the private route points to the firewall endpoint.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Issue 3: Domain block doesn\u2019t work<\/h4>\n\n\n\n<p>Likely causes:\n&#8211; Domain list rule group type not configured correctly\n&#8211; Traffic uses a protocol where domain is not visible\/matchable\n&#8211; DNS over HTTPS \/ encrypted DNS patterns can hide domain signals\n&#8211; HTTP\/3 (QUIC) can change visibility assumptions<\/p>\n\n\n\n<p>Workarounds:\n&#8211; Validate with an IP\/port deny rule (fallback)\n&#8211; Use managed threat intel rule groups (if available) to see alerts\n&#8211; Verify domain-based features in the official docs for your Region<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Issue 4: Can\u2019t start SSM session<\/h4>\n\n\n\n<p>Likely causes:\n&#8211; Instance role missing <code>AmazonSSMManagedInstanceCore<\/code>\n&#8211; SSM agent not installed\/running (most Amazon Linux AMIs include it)\n&#8211; No network path from instance to SSM endpoints (needs internet via NAT or VPC endpoints for SSM)\n&#8211; Instance not showing as \u201cmanaged instance\u201d in Systems Manager<\/p>\n\n\n\n<p>Fix:\n&#8211; Ensure NAT path works (after firewall routing is correct)\n&#8211; Or create VPC endpoints for SSM (more advanced; optional)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid ongoing charges, delete resources in the right order:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Terminate EC2 instance<\/strong><\/li>\n<li><strong>Delete AWS Network Firewall<\/strong>:\n   &#8211; Delete firewall\n   &#8211; Delete firewall policy (if not used elsewhere)\n   &#8211; Delete rule groups<\/li>\n<li><strong>Delete NAT Gateway<\/strong> (wait for deletion)<\/li>\n<li><strong>Release Elastic IP<\/strong> used by NAT Gateway<\/li>\n<li>Delete CloudWatch log group (optional)<\/li>\n<li>Delete route tables (if created separately and not main)<\/li>\n<li>Detach and delete Internet Gateway<\/li>\n<li>Delete subnets<\/li>\n<li>Delete VPC<\/li>\n<li>Delete IAM role (optional)<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>\n&#8211; No hourly resources remain (firewall endpoints, NAT Gateway, EC2).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Use multi-AZ<\/strong> for production: map firewall subnets in at least two AZs.<\/li>\n<li><strong>Keep routing symmetric and AZ-aligned<\/strong>:<\/li>\n<li>Private subnet in AZ-a should route to the firewall endpoint in AZ-a whenever possible.<\/li>\n<li>Avoid cross-AZ \u201cinspection hairpins\u201d that increase cost and complexity.<\/li>\n<li><strong>Separate firewall subnets<\/strong>:<\/li>\n<li>Use dedicated subnets for firewall endpoints to keep routing clear and prevent accidental route conflicts.<\/li>\n<li><strong>Centralize inspection with Transit Gateway<\/strong> for multi-VPC environments where it makes sense.<\/li>\n<li><strong>Segment traffic<\/strong>:<\/li>\n<li>Don\u2019t automatically send every workload flow through the firewall if not required; route only the paths that need inspection.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enforce <strong>least privilege<\/strong> for firewall management:<\/li>\n<li>Separate roles for rule authors vs. network route administrators.<\/li>\n<li>Use <strong>change control<\/strong>:<\/li>\n<li>Require reviews\/approvals for firewall policy changes (especially default actions).<\/li>\n<li>Use <strong>resource-level permissions<\/strong> where applicable (verify IAM condition key support in docs).<\/li>\n<li>Enable <strong>CloudTrail<\/strong> for auditing API changes to firewall configurations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Minimize unnecessary <strong>endpoint-hours<\/strong>:<\/li>\n<li>Don\u2019t leave lab firewalls running.<\/li>\n<li>Minimize <strong>GB processed<\/strong>:<\/li>\n<li>Avoid routing high-volume internal traffic through inspection unless required.<\/li>\n<li>Control logging costs:<\/li>\n<li>Set CloudWatch retention.<\/li>\n<li>Send long-term logs to S3 with lifecycle policies.<\/li>\n<li>Watch NAT Gateway costs:<\/li>\n<li>Consider VPC endpoints to reduce NAT traffic for AWS service access.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Keep rule groups <strong>manageable<\/strong> and avoid overly complex patterns that create operational risk.<\/li>\n<li>Use stateless rules for quick drops when appropriate, and forward needed flows to stateful inspection.<\/li>\n<li>Monitor throughput and latency expectations using logs and application performance metrics.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Deploy across multiple AZs for production.<\/li>\n<li>Ensure each AZ has:<\/li>\n<li>A firewall subnet + endpoint<\/li>\n<li>Correct route tables<\/li>\n<li>NAT\/egress design consistent with your availability requirements (multi-AZ NAT can be used; verify recommended patterns)<\/li>\n<li>Document failure modes: endpoint\/AZ failure, route misconfigurations, log delivery delays.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Standardize:<\/li>\n<li>Naming: <code>env-region-app-nfw<\/code><\/li>\n<li>Tags: <code>Owner<\/code>, <code>Env<\/code>, <code>CostCenter<\/code>, <code>DataClassification<\/code><\/li>\n<li>Build runbooks:<\/li>\n<li>\u201cHow to unblock a domain\u201d<\/li>\n<li>\u201cHow to confirm inspection path\u201d<\/li>\n<li>\u201cHow to interpret alert log fields\u201d<\/li>\n<li>Validate policies in dev\/test using scripted curl tests before production rollout.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use AWS Organizations patterns and (where appropriate) <strong>AWS Firewall Manager<\/strong> for centralized control (verify current support and fit).<\/li>\n<li>Maintain a rule lifecycle:<\/li>\n<li>Propose \u2192 test \u2192 approve \u2192 deploy \u2192 monitor \u2192 retire<\/li>\n<li>Track rule justification and ticket references in documentation and tags.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS Network Firewall is managed via <strong>IAM-authenticated<\/strong> API calls.<\/li>\n<li>Separate duties:<\/li>\n<li>Network team: VPC and route tables<\/li>\n<li>Security team: firewall policies and rule groups<\/li>\n<li>SOC: log read-only + alerting pipelines<\/li>\n<li>Use SCPs (Service Control Policies) in AWS Organizations to prevent unauthorized deletion in sensitive accounts (design carefully to avoid lockouts).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Logs sent to CloudWatch Logs and S3 can be encrypted with AWS-managed keys by default.<\/li>\n<li>For stricter requirements, use <strong>customer managed KMS keys<\/strong> where supported by the logging destination (verify per destination\/service).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>AWS Network Firewall is not a public endpoint; it\u2019s an internal VPC data-plane service.<\/li>\n<li>Your main exposure risk is <strong>misrouting<\/strong>:<\/li>\n<li>Bypassing the firewall unintentionally<\/li>\n<li>Routing loops<\/li>\n<li>Cross-AZ misalignment<\/li>\n<li>Use route table reviews and automated checks to ensure \u201cmust-inspect\u201d routes always point to firewall endpoints.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Avoid embedding secrets in rule descriptions or tags.<\/li>\n<li>If integrating with automation, store credentials in IAM roles (temporary credentials), not static keys.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable:<\/li>\n<li>CloudTrail for configuration changes<\/li>\n<li>Network Firewall alert logs for detection<\/li>\n<li>Flow logs where required for investigations<\/li>\n<li>Ensure log retention meets compliance requirements.<\/li>\n<li>Ensure access to logs is restricted (SOC-only or need-to-know).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<p>AWS Network Firewall can support compliance goals by:\n&#8211; Enforcing egress policies\n&#8211; Generating network security logs\n&#8211; Supporting centralized control patterns<\/p>\n\n\n\n<p>But compliance is architecture + process:\n&#8211; Document policy intent, rule ownership, and change approvals.\n&#8211; Validate that the firewall controls the required traffic paths (audit evidence often requires demonstrating routing enforcement).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Assuming<\/strong> the firewall inspects traffic automatically (it only inspects what is routed through it).<\/li>\n<li>Leaving default actions too permissive without monitoring.<\/li>\n<li>Logging everything forever in CloudWatch (cost and data governance risk).<\/li>\n<li>Allowing too many administrators to change firewall policies directly in production.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Start with <strong>alert-only<\/strong> or limited blocking in a monitored rollout, then tighten policies.<\/li>\n<li>Use staging environments to test rule changes with representative traffic.<\/li>\n<li>Implement automated checks for route table drift.<\/li>\n<li>For critical environments, design for multi-AZ and document failover behavior.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<blockquote>\n<p>Confirm current limitations in the official documentation before finalizing a production design.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Known limitations \/ practical constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Routing-based inspection<\/strong>: Only traffic routed through endpoints is inspected.<\/li>\n<li><strong>Architecture complexity<\/strong>: Route table design is easy to get wrong; requires careful planning.<\/li>\n<li><strong>Domain visibility constraints<\/strong>: Domain-based filtering depends on visibility (HTTP Host \/ TLS SNI). Encrypted protocols and QUIC can reduce effectiveness.<\/li>\n<li><strong>Logging volume<\/strong>: High throughput + detailed logs can generate large volumes and cost.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Limits on number of firewalls, policies, rule groups, and rule group capacity units.<\/li>\n<li>API throttling limits.<\/li>\n<\/ul>\n\n\n\n<p>Check:\n&#8211; Service Quotas console and AWS Network Firewall quotas documentation.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Regional constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Not available in all Regions.<\/li>\n<li>Managed rule groups availability can vary by Region.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing surprises<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Hourly endpoint charges multiply by AZ count.<\/li>\n<li>GB processed charges can grow quickly in high-throughput environments.<\/li>\n<li>NAT Gateway and data processing costs often rival firewall costs for egress-heavy workloads.<\/li>\n<li>CloudWatch log ingestion costs can be significant if you enable verbose logging at scale.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compatibility issues<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Some traffic types may not be easily matchable with desired rule formats.<\/li>\n<li>Interactions with asymmetric routing (especially in complex TGW designs) can lead to unexpected drops.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational gotchas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Changing firewall policy defaults can cause widespread outages if not tested.<\/li>\n<li>Route propagation changes (TGW) can alter traffic paths unintentionally.<\/li>\n<li>\u201cIt worked in dev\u201d issues due to different AZ layouts, NAT designs, or DNS behaviors.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Migration challenges<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Replacing appliance firewalls requires translating policies into rule groups, understanding differences, and validating equivalence.<\/li>\n<li>Expect iterative tuning for false positives\/negatives if using IDS-style rules.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Vendor-specific nuances<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Suricata rule compatibility is not necessarily 100% identical to self-managed Suricata deployments\u2014verify supported keywords and behaviors in AWS docs.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>AWS Network Firewall is one option in a broader \u201cSecurity, identity, and compliance\u201d toolkit. The right choice depends on your traffic type, inspection needs, and operational model.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Comparison table<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>AWS Network Firewall<\/strong><\/td>\n<td>VPC-level stateful\/stateless inspection and logging<\/td>\n<td>Managed endpoints, deep inspection options, centralized policies, rich logs<\/td>\n<td>Requires routing design; can add cost\/complexity<\/td>\n<td>You need managed network firewalling for VPC traffic paths<\/td>\n<\/tr>\n<tr>\n<td><strong>Security Groups<\/strong><\/td>\n<td>Instance\/ENI-level L3\/L4 access control<\/td>\n<td>Simple, stateful, ubiquitous, low overhead<\/td>\n<td>Not DPI; limited centralized inspection visibility<\/td>\n<td>You need baseline access control at the workload level<\/td>\n<\/tr>\n<tr>\n<td><strong>Network ACLs (NACLs)<\/strong><\/td>\n<td>Subnet-level stateless allow\/deny<\/td>\n<td>Simple subnet boundary control<\/td>\n<td>Stateless complexity; limited logging\/visibility<\/td>\n<td>You need coarse subnet boundary restrictions<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS WAF<\/strong><\/td>\n<td>HTTP(S) application protection<\/td>\n<td>L7 rules, bots\/SQLi\/XSS controls, integrates with CloudFront\/ALB\/API Gateway<\/td>\n<td>Not for non-HTTP traffic; not a VPC network firewall<\/td>\n<td>You need web app protection, not general network inspection<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Firewall Manager<\/strong><\/td>\n<td>Multi-account policy governance<\/td>\n<td>Centralizes policy deployment across org (where supported)<\/td>\n<td>Not a firewall itself<\/td>\n<td>You need governance\/automation across accounts (often used with Network Firewall\/WAF)<\/td>\n<\/tr>\n<tr>\n<td><strong>Route 53 Resolver DNS Firewall<\/strong><\/td>\n<td>DNS-layer domain blocking<\/td>\n<td>Strong DNS control plane; effective for DNS-based enforcement<\/td>\n<td>Only DNS-level; doesn\u2019t inspect non-DNS direct IP access<\/td>\n<td>You need DNS policy enforcement; complement Network Firewall<\/td>\n<\/tr>\n<tr>\n<td><strong>Gateway Load Balancer + 3rd-party firewalls<\/strong><\/td>\n<td>Advanced vendor-specific firewalling<\/td>\n<td>Vendor feature depth; migration from existing appliances<\/td>\n<td>More operations, licensing, scaling complexity<\/td>\n<td>You need specific vendor features not covered by Network Firewall<\/td>\n<\/tr>\n<tr>\n<td><strong>Self-managed Suricata\/pfSense on EC2<\/strong><\/td>\n<td>Custom lab\/low-level control<\/td>\n<td>Full control, flexible<\/td>\n<td>High ops burden; scaling\/HA complexity<\/td>\n<td>You\u2019re prototyping or need full self-managed control (rare for production)<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Firewall \/ GCP Cloud Firewall equivalents<\/strong><\/td>\n<td>Other clouds<\/td>\n<td>Native integration in their ecosystems<\/td>\n<td>Different models; not applicable inside AWS<\/td>\n<td>Choose only when operating in those clouds<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: Centralized inspection for a multi-account landing zone<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong><\/li>\n<li>A regulated enterprise runs dozens of application accounts. Auditors require consistent egress restrictions, threat intel protections, and centralized network logging.<\/li>\n<li>\n<p>Historically, each team implemented ad-hoc security group rules and local NAT gateways with inconsistent logging.<\/p>\n<\/li>\n<li>\n<p><strong>Proposed architecture<\/strong><\/p>\n<\/li>\n<li>A dedicated <strong>Network account<\/strong> hosts:<ul>\n<li>AWS Transit Gateway<\/li>\n<li>An <strong>Inspection VPC<\/strong> with multi-AZ AWS Network Firewall endpoints<\/li>\n<li>Central egress (NAT\/IGW) and\/or controlled on-prem egress<\/li>\n<\/ul>\n<\/li>\n<li>Spoke VPCs attach to Transit Gateway and route internet-bound traffic to the inspection VPC.<\/li>\n<li>\n<p>Firewall logs are delivered to a <strong>Security account<\/strong> S3 bucket (long-term) and optionally to near-real-time analytics.<\/p>\n<\/li>\n<li>\n<p><strong>Why AWS Network Firewall was chosen<\/strong><\/p>\n<\/li>\n<li>Managed service reduces operational risk vs. maintaining appliance fleets.<\/li>\n<li>Central rule groups support consistent enforcement and easier audits.<\/li>\n<li>\n<p>Cloud-native logging integrates cleanly with existing SOC tooling.<\/p>\n<\/li>\n<li>\n<p><strong>Expected outcomes<\/strong><\/p>\n<\/li>\n<li>Standardized egress policy across accounts<\/li>\n<li>Improved incident response with centralized, queryable logs<\/li>\n<li>Faster onboarding of new application accounts with known-good routing templates<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: Safe outbound access for private workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong><\/li>\n<li>A startup runs workloads in private subnets for security and wants controlled outbound access to only a few third-party APIs.<\/li>\n<li>\n<p>They want visibility into unexpected egress without building a firewall appliance stack.<\/p>\n<\/li>\n<li>\n<p><strong>Proposed architecture<\/strong><\/p>\n<\/li>\n<li>Single VPC, two AZs (production) or one AZ (early stage), with:<ul>\n<li>Private subnets for compute<\/li>\n<li>Dedicated firewall subnets with AWS Network Firewall endpoints<\/li>\n<li>NAT gateways for outbound internet access<\/li>\n<\/ul>\n<\/li>\n<li>Stateful rules implement allow lists for required vendor endpoints and deny all else.<\/li>\n<li>\n<p>Alert logs go to CloudWatch Logs with short retention; S3 for long-term only if needed.<\/p>\n<\/li>\n<li>\n<p><strong>Why AWS Network Firewall was chosen<\/strong><\/p>\n<\/li>\n<li>Minimal operational overhead<\/li>\n<li>Clear separation of duties and easy policy iteration<\/li>\n<li>\n<p>Quick path to \u201cgood enough\u201d compliance posture<\/p>\n<\/li>\n<li>\n<p><strong>Expected outcomes<\/strong><\/p>\n<\/li>\n<li>Reduced risk of data exfiltration<\/li>\n<li>Faster debugging of vendor integration issues using firewall logs<\/li>\n<li>A scalable foundation for multi-account governance later<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">1) Is AWS Network Firewall a replacement for security groups?<\/h3>\n\n\n\n<p>No. Security groups are still essential for workload-level access control. AWS Network Firewall adds centralized inspection and logging for routed traffic paths.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">2) Does AWS Network Firewall inspect all traffic in my VPC automatically?<\/h3>\n\n\n\n<p>No. It inspects <strong>only traffic that you route through its endpoints<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">3) Is AWS Network Firewall regional or global?<\/h3>\n\n\n\n<p>You create and operate it <strong>within a Region<\/strong>, and you deploy endpoints in specific subnets (AZ-scoped) in that Region.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">4) Can I use AWS Network Firewall for inbound internet traffic protection?<\/h3>\n\n\n\n<p>Yes, but the design is architecture-dependent and routing must ensure inbound flows traverse firewall endpoints. Many inbound web use cases are better served by AWS WAF at Layer 7.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">5) What\u2019s the difference between AWS Network Firewall and AWS WAF?<\/h3>\n\n\n\n<p>AWS Network Firewall is for VPC network traffic inspection (L3\/L4 and stateful L7-aware patterns depending on rules). AWS WAF is specifically for HTTP(S) web request filtering at Layer 7 on CloudFront\/ALB\/API Gateway.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">6) Can AWS Network Firewall block domains?<\/h3>\n\n\n\n<p>It can support domain-based controls in certain rule formats and protocols (commonly HTTP Host and TLS SNI). Effectiveness depends on traffic visibility. Verify current domain-list capabilities in official docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">7) Does it decrypt TLS traffic?<\/h3>\n\n\n\n<p>Generally, AWS Network Firewall focuses on inspection without terminating and decrypting TLS like a proxy might. TLS logs and SNI-based matching can be used, but full decryption is a different design pattern. Verify current capabilities in official docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">8) What logs can I enable?<\/h3>\n\n\n\n<p>Commonly: <strong>flow logs<\/strong>, <strong>alert logs<\/strong>, and <strong>TLS logs<\/strong> (availability\/config options depend on Region and features). Logs can be sent to CloudWatch Logs, S3, or Firehose.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">9) How do I prove traffic is going through the firewall?<\/h3>\n\n\n\n<p>Validate route tables and use a controlled deny rule to confirm traffic drops when expected. Also confirm logs show flows\/alerts for the relevant sources.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">10) Do I need a NAT Gateway with AWS Network Firewall?<\/h3>\n\n\n\n<p>Not always. NAT is common for private subnet internet access. If your traffic is to on-prem over VPN\/Direct Connect or to AWS services via VPC endpoints, NAT may not be needed.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">11) Can I centralize AWS Network Firewall across multiple VPCs?<\/h3>\n\n\n\n<p>Yes, commonly using <strong>AWS Transit Gateway<\/strong> and an inspection VPC pattern.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">12) Is AWS Network Firewall highly available?<\/h3>\n\n\n\n<p>It supports multi-AZ designs when you deploy endpoint subnets in multiple AZs and align routing accordingly.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">13) What are the biggest causes of outages with AWS Network Firewall?<\/h3>\n\n\n\n<p>Misconfigured route tables, asymmetric routing in complex topologies, and overly broad deny rules or incorrect default actions.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">14) How do I manage policies across many accounts?<\/h3>\n\n\n\n<p>Consider AWS Organizations + AWS Firewall Manager (verify current support and limitations). Also use IaC and CI\/CD with strong approvals.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">15) Should I enable flow logs everywhere?<\/h3>\n\n\n\n<p>Not necessarily. Flow logs can be high volume. Start with alert logs for security signal, then selectively enable flow logs where you need baseline visibility.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">16) Can AWS Network Firewall replace third-party NGFW appliances?<\/h3>\n\n\n\n<p>Sometimes. If you need advanced vendor-specific features (certain proxy functions, niche threat modules, etc.), evaluate Gateway Load Balancer with partner appliances. For many VPC inspection needs, AWS Network Firewall is sufficient and simpler.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">17) How do I test rule changes safely?<\/h3>\n\n\n\n<p>Deploy in dev\/stage first, use synthetic traffic tests (curl, integration tests), monitor alert logs, and roll out gradually with change control.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn AWS Network Firewall<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official Documentation<\/td>\n<td>AWS Network Firewall Developer Guide: https:\/\/docs.aws.amazon.com\/network-firewall\/latest\/developerguide\/what-is-aws-network-firewall.html<\/td>\n<td>Canonical reference for concepts, rule groups, policies, logging, and architecture patterns<\/td>\n<\/tr>\n<tr>\n<td>Official Pricing<\/td>\n<td>AWS Network Firewall Pricing: https:\/\/aws.amazon.com\/network-firewall\/pricing\/<\/td>\n<td>Region-specific pricing dimensions and rates<\/td>\n<\/tr>\n<tr>\n<td>Pricing Tool<\/td>\n<td>AWS Pricing Calculator: https:\/\/calculator.aws\/#\/<\/td>\n<td>Build realistic estimates including endpoints, GB processed, NAT, and logging<\/td>\n<\/tr>\n<tr>\n<td>Official Architecture<\/td>\n<td>AWS Architecture Center: https:\/\/aws.amazon.com\/architecture\/<\/td>\n<td>Reference architectures and best practices (search within for Network Firewall\/TGW inspection patterns)<\/td>\n<\/tr>\n<tr>\n<td>Official VPC Guidance<\/td>\n<td>Amazon VPC documentation: https:\/\/docs.aws.amazon.com\/vpc\/<\/td>\n<td>Essential for routing, subnets, NAT, and IGW designs that make Network Firewall work<\/td>\n<\/tr>\n<tr>\n<td>Official Logging<\/td>\n<td>CloudWatch Logs documentation: https:\/\/docs.aws.amazon.com\/AmazonCloudWatch\/latest\/logs\/<\/td>\n<td>Log groups, retention, IAM, and troubleshooting delivery<\/td>\n<\/tr>\n<tr>\n<td>Official Governance<\/td>\n<td>AWS Firewall Manager documentation: https:\/\/docs.aws.amazon.com\/waf\/latest\/developerguide\/fms-chapter.html<\/td>\n<td>Centralized governance patterns (verify current Network Firewall policy support)<\/td>\n<\/tr>\n<tr>\n<td>Official CLI Reference<\/td>\n<td>AWS CLI Network Firewall commands: https:\/\/docs.aws.amazon.com\/cli\/latest\/reference\/network-firewall\/<\/td>\n<td>Scripting and automation reference<\/td>\n<\/tr>\n<tr>\n<td>Official Service Updates<\/td>\n<td>AWS What\u2019s New: https:\/\/aws.amazon.com\/new\/<\/td>\n<td>Track new features and region expansions<\/td>\n<\/tr>\n<tr>\n<td>Video (Official)<\/td>\n<td>AWS YouTube channel: https:\/\/www.youtube.com\/@AmazonWebServices<\/td>\n<td>Search for \u201cAWS Network Firewall\u201d sessions, re:Invent talks, and workshops<\/td>\n<\/tr>\n<tr>\n<td>Hands-on Workshops<\/td>\n<td>AWS Workshops portal: https:\/\/workshops.aws\/<\/td>\n<td>Some workshops include network security patterns; verify current labs for Network Firewall<\/td>\n<\/tr>\n<tr>\n<td>Community (Reputable)<\/td>\n<td>AWS Security Blog: https:\/\/aws.amazon.com\/blogs\/security\/<\/td>\n<td>Practical security architectures and operational guidance; validate against docs<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps engineers, cloud engineers, SREs, platform teams<\/td>\n<td>AWS foundations, DevOps practices, cloud operations; verify specific AWS Network Firewall coverage<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Beginners to intermediate IT and DevOps learners<\/td>\n<td>DevOps, SCM, cloud basics; verify specific firewall\/network security modules<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud operations teams, SRE\/ops-focused learners<\/td>\n<td>Cloud ops, monitoring, reliability, runbooks; verify AWS security\/networking tracks<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs, platform teams, reliability engineers<\/td>\n<td>Reliability engineering, observability, incident response; applicable to operating AWS Network Firewall<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops and SRE teams exploring AIOps<\/td>\n<td>Automation, AIOps concepts, event correlation; verify AWS-focused curricula<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>Cloud\/DevOps training and guidance (verify offerings)<\/td>\n<td>Learners seeking practical cloud\/DevOps coaching<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps training (verify AWS\/network security coverage)<\/td>\n<td>Beginners to intermediate DevOps learners<\/td>\n<td>https:\/\/www.devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps help\/training (verify scope)<\/td>\n<td>Teams needing targeted project help and mentoring<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support and training resources (verify services)<\/td>\n<td>Ops teams needing hands-on support and troubleshooting help<\/td>\n<td>https:\/\/www.devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps consulting (verify exact portfolio)<\/td>\n<td>Architecture reviews, platform engineering, deployment automation<\/td>\n<td>Centralized inspection VPC design; routing and logging rollout; IaC for Network Firewall<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps and cloud consulting\/training (verify scope)<\/td>\n<td>Implementation support, workshops, operational readiness<\/td>\n<td>Build a landing zone with inspection patterns; create runbooks; cost optimization review<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting (verify offerings)<\/td>\n<td>DevOps pipelines, cloud operations, reliability<\/td>\n<td>Automate firewall policy deployments; integrate logs with monitoring\/SIEM; environment standardization<\/td>\n<td>https:\/\/devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before AWS Network Firewall<\/h3>\n\n\n\n<p>To use AWS Network Firewall confidently, build fundamentals in:\n&#8211; <strong>Networking basics<\/strong>: CIDR, subnets, routing, NAT, stateful vs stateless filtering\n&#8211; <strong>AWS VPC<\/strong>: route tables, IGW, NAT Gateway, security groups, NACLs\n&#8211; <strong>IAM<\/strong>: roles, policies, least privilege, CloudTrail auditing\n&#8211; <strong>Observability<\/strong>: CloudWatch Logs, metrics basics, retention and cost control<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after AWS Network Firewall<\/h3>\n\n\n\n<p>To expand into production-grade network security:\n&#8211; <strong>AWS Transit Gateway<\/strong> inspection patterns (hub-and-spoke)\n&#8211; <strong>AWS Firewall Manager<\/strong> for org-wide governance (verify supported policy types)\n&#8211; <strong>AWS WAF<\/strong> for L7 application security\n&#8211; <strong>Route 53 Resolver DNS Firewall<\/strong> for DNS-based controls\n&#8211; <strong>Security analytics<\/strong>:\n  &#8211; S3 log lakes + Athena queries\n  &#8211; Firehose pipelines to SIEM tools\n&#8211; <strong>Incident response<\/strong> on AWS:\n  &#8211; GuardDuty, Security Hub, Detective (as applicable)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Network Engineer<\/li>\n<li>Cloud Security Engineer<\/li>\n<li>DevOps Engineer \/ Platform Engineer<\/li>\n<li>SRE (operational ownership, reliability, incident response)<\/li>\n<li>Security Operations (SOC) Analyst (log interpretation and detections)<\/li>\n<li>Solutions Architect (designing inspection and governance patterns)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (AWS)<\/h3>\n\n\n\n<p>AWS certifications don\u2019t certify AWS Network Firewall specifically, but it fits naturally into:\n&#8211; <strong>AWS Certified Solutions Architect \u2013 Associate\/Professional<\/strong>\n&#8211; <strong>AWS Certified Security \u2013 Specialty<\/strong>\n&#8211; <strong>AWS Certified Advanced Networking \u2013 Specialty<\/strong><\/p>\n\n\n\n<p>Use the official AWS certification site for current exam guides:\n&#8211; https:\/\/aws.amazon.com\/certification\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build a multi-AZ egress inspection VPC and measure cost\/latency tradeoffs.<\/li>\n<li>Create a \u201cstaging then production\u201d pipeline for firewall policies using IaC and approvals.<\/li>\n<li>Implement centralized logging to S3 and query blocked domains with Athena.<\/li>\n<li>Design a Transit Gateway inspection architecture connecting two spoke VPCs and enforce east-west restrictions.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Amazon VPC<\/strong>: A logically isolated virtual network in AWS where you run resources.<\/li>\n<li><strong>Subnet<\/strong>: A range of IP addresses in a VPC, scoped to one Availability Zone.<\/li>\n<li><strong>Route table<\/strong>: Defines where network traffic is directed (next hop) based on destination CIDR.<\/li>\n<li><strong>Internet Gateway (IGW)<\/strong>: Enables internet connectivity for resources with public IPs or via NAT.<\/li>\n<li><strong>NAT Gateway<\/strong>: Provides outbound internet access for private subnets by translating source IPs.<\/li>\n<li><strong>Firewall endpoint<\/strong>: The data-plane endpoint created by AWS Network Firewall in your subnet; route tables can target it.<\/li>\n<li><strong>Firewall policy<\/strong>: A configuration that defines stateless\/stateful rule groups and default actions.<\/li>\n<li><strong>Rule group<\/strong>: A reusable collection of stateless or stateful rules applied by a firewall policy.<\/li>\n<li><strong>Stateful inspection<\/strong>: Tracks connection state and can apply more context-aware rules.<\/li>\n<li><strong>Stateless inspection<\/strong>: Evaluates packets individually without connection tracking.<\/li>\n<li><strong>Suricata rules<\/strong>: An IDS\/IPS rule language used widely in network security tooling; AWS Network Firewall supports a compatible subset for stateful rules (verify supported features).<\/li>\n<li><strong>Alert log<\/strong>: Logs generated when a rule match triggers an alert\/action.<\/li>\n<li><strong>Flow log (Network Firewall)<\/strong>: Metadata logs describing flows processed by the firewall (not the same as VPC Flow Logs, though conceptually similar).<\/li>\n<li><strong>AWS Systems Manager Session Manager<\/strong>: Lets you access instances without inbound SSH\/RDP by using the SSM agent and IAM.<\/li>\n<li><strong>AWS Transit Gateway (TGW)<\/strong>: A hub for connecting VPCs and on-prem networks; often used for centralized inspection patterns.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>AWS Network Firewall is AWS\u2019s managed, VPC-native firewall service in the <strong>Security, identity, and compliance<\/strong> category. It helps you enforce consistent network security policies\u2014stateless filtering, stateful inspection, domain-based controls (where supported), managed rule groups, and centralized logging\u2014by steering traffic through firewall endpoints using VPC routing.<\/p>\n\n\n\n<p>It matters because it fills the gap between basic security groups\/NACLs and fully self-managed firewall appliances, giving you enforceable inspection and audit-friendly logs without operating your own fleet. Cost is driven primarily by <strong>endpoint-hours<\/strong> and <strong>GB processed<\/strong>, plus indirect costs like <strong>NAT Gateway<\/strong>, <strong>logging<\/strong>, and <strong>data transfer<\/strong>\u2014so design routing carefully and manage log retention.<\/p>\n\n\n\n<p>Use AWS Network Firewall when you need centralized VPC traffic inspection (egress, ingress paths you can route, or TGW-based centralized inspection). Start with a small, testable policy, validate routing and logs, and scale to multi-AZ and multi-account governance as your environment matures.<\/p>\n\n\n\n<p>Next step: build a production-style design using <strong>multi-AZ endpoints<\/strong>, integrate logs into an S3-based security lake, and learn Transit Gateway inspection patterns for multi-VPC environments.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Security, identity, and compliance<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20,39],"tags":[],"class_list":["post-321","post","type-post","status-publish","format-standard","hentry","category-aws","category-security-identity-and-compliance"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/321","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=321"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/321\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=321"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=321"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=321"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}