{"id":502,"date":"2026-04-14T07:17:43","date_gmt":"2026-04-14T07:17:43","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/azure-firewall-manager-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking\/"},"modified":"2026-04-14T07:17:43","modified_gmt":"2026-04-14T07:17:43","slug":"azure-firewall-manager-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/azure-firewall-manager-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking\/","title":{"rendered":"Azure Firewall Manager Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Networking"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Networking<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>Azure Firewall Manager is Azure\u2019s centralized management layer for deploying, configuring, and governing <strong>Azure Firewall<\/strong> at scale\u2014especially in <strong>hub-and-spoke<\/strong> networks and <strong>Azure Virtual WAN secured hubs<\/strong>. It helps platform and security teams consistently apply firewall policies across many networks, regions, and subscriptions without duplicating rule sets and operational processes.<\/p>\n\n\n\n<p>In simple terms: <strong>Azure Firewall Manager is where you define firewall policy once and apply it consistently to many firewalls and hubs<\/strong>.<\/p>\n\n\n\n<p>Technically, Azure Firewall Manager provides a control-plane experience (primarily in the Azure portal and ARM) for creating and managing <strong>Azure Firewall Policies<\/strong> (including hierarchical policies), associating them to <strong>Azure Firewalls<\/strong> (VNet-based) and <strong>secured virtual hubs<\/strong>, and optionally integrating with supported third-party security providers in Virtual WAN (verify supported partners in official docs). It does <strong>not<\/strong> replace Azure Firewall; it manages and orchestrates it.<\/p>\n\n\n\n<p>The problem it solves is common in enterprise Networking and security operations: as environments grow, teams end up with inconsistent firewall rules, duplicated configuration, brittle change processes, and difficult auditing across subscriptions and regions. Azure Firewall Manager addresses this with centralized governance, policy reuse, and more predictable operations.<\/p>\n\n\n\n<blockquote>\n<p>Service name check: <strong>Azure Firewall Manager<\/strong> is the current, active service name in Azure documentation at the time of writing. If Azure renames portal experiences (for example, consolidating blades), the underlying resource types and concepts remain centered around <strong>Azure Firewall Policy<\/strong> and policy associations. Always verify the latest UX in official docs.<\/p>\n<\/blockquote>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Azure Firewall Manager?<\/h2>\n\n\n\n<p>Azure Firewall Manager is an Azure <strong>Networking<\/strong> security management service designed to centrally deploy and manage firewall security policies for <strong>Azure Firewall<\/strong> and <strong>secured virtual hubs<\/strong> in <strong>Azure Virtual WAN<\/strong>.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Official purpose (what it\u2019s for)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Centralize security policy management for Azure Firewall across multiple environments.<\/li>\n<li>Provide consistent enforcement in hub-and-spoke and Virtual WAN architectures.<\/li>\n<li>Simplify policy rollout, change control, and governance for firewall rules.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities (what it can do)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Create and manage <strong>Azure Firewall Policies<\/strong>.<\/li>\n<li>Use <strong>hierarchical policies<\/strong> (parent\/child) for shared baseline controls plus app\/team-specific overrides.<\/li>\n<li>Associate policies to:<\/li>\n<li><strong>VNet-based Azure Firewall<\/strong> deployments (hub VNets)<\/li>\n<li><strong>Secured virtual hubs<\/strong> (Virtual WAN hubs with managed security)<\/li>\n<li>Support scalable architectures like <strong>hub-and-spoke<\/strong> and <strong>Azure Virtual WAN<\/strong>.<\/li>\n<li>Centralize monitoring and governance patterns (through integration with Azure Monitor\/Log Analytics, Microsoft Sentinel, etc., via Azure Firewall logs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Major components<\/h3>\n\n\n\n<p>Azure Firewall Manager is best understood as a management umbrella around these key components:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Azure Firewall<\/strong>: The stateful network firewall (data plane) that processes traffic.<\/li>\n<li><strong>Azure Firewall Policy<\/strong>: The policy object containing rule collection groups, rules (network, application, NAT), threat intelligence settings, TLS inspection settings (Premium capability), IDPS settings (Premium capability), and more (capabilities depend on Firewall SKU\u2014verify).<\/li>\n<li><strong>Policy association<\/strong>: The binding of a policy to an Azure Firewall instance or secured virtual hub.<\/li>\n<li><strong>(Optional) Virtual WAN secured hub<\/strong>: A Virtual WAN hub with security provider (Azure Firewall or supported partner) enabled.<\/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>Primarily a <strong>management\/control-plane<\/strong> service for Azure Firewall deployments.<\/li>\n<li>It does not process traffic itself; <strong>Azure Firewall<\/strong> (and\/or the Virtual WAN security provider) processes traffic.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scope: regional\/global and Azure resource scope<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Azure Firewall Policy<\/strong> is an Azure resource created in a specific <strong>resource group<\/strong> and <strong>region<\/strong> (location), but can often be used across environments depending on Azure Firewall architecture. The exact constraints can vary by scenario; verify in official docs for your topology.<\/li>\n<li>Azure Firewall Manager provides <strong>centralized management across subscriptions and regions<\/strong> (subject to RBAC permissions and supported capabilities).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How it fits into the Azure ecosystem<\/h3>\n\n\n\n<p>Azure Firewall Manager sits at the intersection of:\n&#8211; <strong>Networking<\/strong>: VNets, peering, route tables (UDR), Virtual WAN, VPN\/ExpressRoute gateways\n&#8211; <strong>Security<\/strong>: centralized policy, enforcement controls, logging and SIEM integration\n&#8211; <strong>Operations<\/strong>: change management, governance, consistent rollout, auditing and troubleshooting<\/p>\n\n\n\n<p>It complements (not replaces) other Azure Networking and security services like:\n&#8211; Network Security Groups (NSGs) for subnet\/NIC-level filtering\n&#8211; Azure Application Gateway \/ WAF for HTTP(S) application layer protection\n&#8211; DDoS Protection for volumetric attack mitigation\n&#8211; Microsoft Defender for Cloud for posture management (recommendations)<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Azure Firewall Manager?<\/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>Consistency and standardization<\/strong>: Apply a baseline firewall posture across business units and environments.<\/li>\n<li><strong>Reduced operational cost<\/strong>: Central policy management reduces duplicated effort and configuration drift.<\/li>\n<li><strong>Faster onboarding<\/strong>: New spokes, subscriptions, or environments can inherit security posture with less manual work.<\/li>\n<li><strong>Audit readiness<\/strong>: Easier to demonstrate standardized controls and rule governance.<\/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>Policy reuse at scale<\/strong>: Use centralized policies rather than recreating rules per firewall.<\/li>\n<li><strong>Hierarchical policies<\/strong>: Separate global baseline rules (parent) from workload rules (child).<\/li>\n<li><strong>Works with hub-and-spoke and Virtual WAN<\/strong>: Two of the most common Azure enterprise network patterns.<\/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 change workflow<\/strong>: Fewer places to edit rules, fewer \u201csnowflake\u201d firewalls.<\/li>\n<li><strong>Separation of duties<\/strong>: Central team owns baseline; app teams can own child policies (with appropriate RBAC).<\/li>\n<li><strong>Repeatable rollout<\/strong>: Standardized association patterns for new hubs and spokes.<\/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>Central governance<\/strong>: Helps enforce consistent outbound filtering and segmentation.<\/li>\n<li><strong>Improved visibility<\/strong>: With Azure Firewall logs routed centrally, security teams can monitor policy outcomes.<\/li>\n<li><strong>Supports regulated environments<\/strong>: Central rule management and auditing are useful for ISO 27001, SOC 2, PCI DSS, HIPAA-aligned programs (compliance depends on your controls\u2014Azure Firewall Manager is an enabler, not a certification).<\/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>Better scalability of operations (people\/process) rather than raw packet throughput.<\/li>\n<li>Azure Firewall scaling\/performance is primarily determined by the Azure Firewall SKU and architecture; Firewall Manager helps you manage it.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose Azure Firewall Manager<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You have <strong>multiple VNets\/subscriptions<\/strong> and want centralized policy management.<\/li>\n<li>You\u2019re implementing <strong>hub-and-spoke<\/strong> or <strong>Virtual WAN<\/strong> and want consistent inspection.<\/li>\n<li>You want <strong>baseline security rules<\/strong> plus <strong>team\/application-specific rules<\/strong> using hierarchical policies.<\/li>\n<li>You need a structured way to apply firewall governance at enterprise scale.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You have a small environment with a single VNet and no need for centralized policy governance (managing Azure Firewall directly may be sufficient).<\/li>\n<li>You only need simple segmentation that NSGs can handle (note: NSGs are not a full firewall replacement; they\u2019re L3\/L4 and don\u2019t provide the same centralized inspection\/logging capabilities).<\/li>\n<li>You require a non-Azure firewall vendor feature set not supported by Azure Firewall (consider partner security providers or third-party appliances; validate support and architecture implications).<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Azure Firewall Manager used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Financial services: centralized egress control, segmentation, auditing<\/li>\n<li>Healthcare: controlled outbound access, monitoring, compliance reporting<\/li>\n<li>Retail\/e-commerce: environment separation (prod vs non-prod), controlled outbound dependencies<\/li>\n<li>Government\/public sector: strict egress control and centralized governance<\/li>\n<li>SaaS and tech: multi-subscription landing zones with standardized controls<\/li>\n<li>Manufacturing\/IoT: hub inspection for hybrid connectivity and device telemetry paths<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform engineering: standardize connectivity and security across landing zones<\/li>\n<li>Networking teams: hub-and-spoke routing, centralized security appliances<\/li>\n<li>Security engineering: egress filtering, threat intelligence controls, SIEM integration<\/li>\n<li>DevOps\/SRE: operational runbooks, change control, incident response workflows<\/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-facing web apps (paired with WAF) needing controlled outbound<\/li>\n<li>Internal APIs and microservices needing segmentation and egress policies<\/li>\n<li>Hybrid workloads with VPN\/ExpressRoute where hub inspection is required<\/li>\n<li>Data platforms (Synapse, Databricks, Kubernetes) where outbound dependencies must be controlled<\/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>Hub-and-spoke VNets with centralized Azure Firewall<\/li>\n<li>Azure Virtual WAN with secured hubs for centralized security<\/li>\n<li>Multi-region networks with consistent policy definitions<\/li>\n<li>Shared services hubs for DNS, identity, monitoring, and security inspection<\/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>Production: strict change control, centralized logging, high availability patterns<\/li>\n<li>Dev\/test: enforce \u201cno-open-egress\u201d policies, reduce risk of accidental exposure, lower operational overhead with reusable policies<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic Azure Networking scenarios where Azure Firewall Manager is a strong fit.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Centralized outbound internet control (egress filtering)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Spoke VNets and workloads can reach any internet destination, increasing exfiltration and compliance risk.<\/li>\n<li><strong>Why Azure Firewall Manager fits<\/strong>: Central policy defines allowed FQDNs\/IPs and is applied to hub firewall(s).<\/li>\n<li><strong>Example<\/strong>: Only allow outbound HTTPS to <code>*.microsoft.com<\/code>, OS update endpoints, and approved SaaS; deny everything else.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Standard baseline policy across many subscriptions (landing zone governance)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Different teams deploy their own firewall rules, leading to drift and audit pain.<\/li>\n<li><strong>Why it fits<\/strong>: Hierarchical policies allow a <strong>parent baseline<\/strong> with mandatory rules, plus <strong>child policies<\/strong> for teams.<\/li>\n<li><strong>Example<\/strong>: Parent policy enforces deny-to-known-malicious + required internal services; child policy adds app-specific allow rules.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Hub-and-spoke segmentation between environments (prod\/non-prod)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: East-west traffic between environments is accidentally permitted via peering and routes.<\/li>\n<li><strong>Why it fits<\/strong>: Central policy defines inter-spoke rules and is enforced at the hub.<\/li>\n<li><strong>Example<\/strong>: Block non-prod from reaching prod databases; allow only specific management ports from jump hosts.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Standardized firewall rollouts in multi-region architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Each region deploys its own firewall rules; rule parity becomes difficult.<\/li>\n<li><strong>Why it fits<\/strong>: Use a consistent policy approach and associate to region-specific Azure Firewalls.<\/li>\n<li><strong>Example<\/strong>: Global policy reused in two regions; only region-specific endpoints differ via child policies.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Controlled access to platform services (PaaS) with central inspection<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Workloads need outbound access to PaaS endpoints; governance wants visibility and restriction.<\/li>\n<li><strong>Why it fits<\/strong>: Central outbound rules and logging provide governance.<\/li>\n<li><strong>Example<\/strong>: Allow outbound to Azure Container Registry, Azure Storage, Key Vault endpoints (as appropriate) while denying unknown destinations.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) M&amp;A \/ multi-tenant consolidation<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Newly acquired business units must be brought under a centralized security posture quickly.<\/li>\n<li><strong>Why it fits<\/strong>: Central policy + association pattern accelerates standardization.<\/li>\n<li><strong>Example<\/strong>: Add new spokes into shared hub, inherit baseline policy, and use a child policy for BU-specific apps.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Virtual WAN secured hub security standardization<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Large global WAN needs consistent security enforcement at hubs.<\/li>\n<li><strong>Why it fits<\/strong>: Firewall Manager is designed to manage security in <strong>secured virtual hubs<\/strong>.<\/li>\n<li><strong>Example<\/strong>: Global Virtual WAN with hubs in key regions; consistent security policy applied per hub.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Central logging and SIEM integration readiness<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Firewall logs are inconsistent, scattered, or not collected.<\/li>\n<li><strong>Why it fits<\/strong>: Central deployments can standardize diagnostics settings patterns (implementation still requires Azure Monitor configuration).<\/li>\n<li><strong>Example<\/strong>: All Azure Firewalls forward logs to central Log Analytics workspace and Microsoft Sentinel.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Shared services hub for outbound dependencies (DNS\/NTP\/updates)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Workloads require a small set of essential outbound dependencies; everything else should be denied.<\/li>\n<li><strong>Why it fits<\/strong>: Central policy codifies essential services and simplifies expansion as needed.<\/li>\n<li><strong>Example<\/strong>: Allow DNS to internal resolvers, allow OS updates and time sync; deny everything else.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Incident response: fast global block rule rollout<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A newly discovered malicious domain\/IP must be blocked everywhere quickly.<\/li>\n<li><strong>Why it fits<\/strong>: Central policy update applies across many firewalls (depending on your association strategy).<\/li>\n<li><strong>Example<\/strong>: Add \u201cdeny known IOC list\u201d rule collection group at high priority in parent policy.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<p>Azure Firewall Manager\u2019s value is mainly in centralized policy and deployment workflows. Key features include:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Centralized Azure Firewall Policy management<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Lets you create and manage Azure Firewall Policies centrally (often via the Firewall Manager portal experience).<\/li>\n<li><strong>Why it matters<\/strong>: Standardizes rules and reduces configuration drift across multiple environments.<\/li>\n<li><strong>Practical benefit<\/strong>: Faster change implementation and consistent enforcement.<\/li>\n<li><strong>Caveats<\/strong>: Policy changes affect associated firewalls; apply change control and testing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Policy association to multiple Azure Firewalls<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Enables associating a single policy to one or more Azure Firewall instances.<\/li>\n<li><strong>Why it matters<\/strong>: Promotes reuse and consistency across regions and hubs.<\/li>\n<li><strong>Practical benefit<\/strong>: One policy update can roll out to many enforcement points.<\/li>\n<li><strong>Caveats<\/strong>: Validate impact\u2014shared policies can create unintended blast radius if not designed properly.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Hierarchical firewall policies (parent\/child)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Supports a base (parent) policy inherited by child policies, allowing overrides\/extension where supported.<\/li>\n<li><strong>Why it matters<\/strong>: Enables enterprise governance patterns: central security baseline + workload flexibility.<\/li>\n<li><strong>Practical benefit<\/strong>: Security team controls non-negotiable rules; app teams add necessary exceptions.<\/li>\n<li><strong>Caveats<\/strong>: Hierarchical behavior has specific rules about evaluation and what can be overridden; verify in official docs and test.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Support for secured virtual hubs (Azure Virtual WAN)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Helps configure security providers (Azure Firewall or supported partners) for Virtual WAN hubs and apply policy.<\/li>\n<li><strong>Why it matters<\/strong>: Virtual WAN is common in global enterprise networking; security must be consistent at hubs.<\/li>\n<li><strong>Practical benefit<\/strong>: Standard hub security posture with centralized management.<\/li>\n<li><strong>Caveats<\/strong>: Virtual WAN and secured hubs add additional cost and have specific constraints; verify topology requirements.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Central governance for hub-and-spoke inspection architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Aligns with hub-and-spoke designs where traffic is routed through a central firewall.<\/li>\n<li><strong>Why it matters<\/strong>: Hub-and-spoke is a foundational Azure Networking model.<\/li>\n<li><strong>Practical benefit<\/strong>: Repeatable designs across subscriptions and business units.<\/li>\n<li><strong>Caveats<\/strong>: Requires correct routing (UDRs), DNS planning, and careful segmentation design.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Integration with Azure role-based access control (RBAC)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Uses Azure RBAC to control who can create policies, modify rules, and associate policies.<\/li>\n<li><strong>Why it matters<\/strong>: Supports separation of duties and least privilege.<\/li>\n<li><strong>Practical benefit<\/strong>: Delegated management\u2014platform team manages infrastructure, security team manages policy.<\/li>\n<li><strong>Caveats<\/strong>: Mis-scoped roles can lead to accidental broad permissions; use resource group scoping and PIM where possible.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Works with Azure Firewall logging and diagnostics<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: While logging is configured on Azure Firewall resources, Firewall Manager architectures typically standardize log pipelines.<\/li>\n<li><strong>Why it matters<\/strong>: Without logs, firewall enforcement becomes hard to audit and troubleshoot.<\/li>\n<li><strong>Practical benefit<\/strong>: Central visibility for allow\/deny, threat intel hits, and operational troubleshooting.<\/li>\n<li><strong>Caveats<\/strong>: Logging costs can be significant (Log Analytics ingestion\/retention).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Supports standardized deployments and lifecycle operations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Helps you deploy new firewalls or secured hubs in a repeatable, centrally managed way (commonly via portal, IaC, or both).<\/li>\n<li><strong>Why it matters<\/strong>: Enterprises need consistency across environments.<\/li>\n<li><strong>Practical benefit<\/strong>: Reduced time-to-deploy and reduced configuration drift.<\/li>\n<li><strong>Caveats<\/strong>: Your IaC approach (Bicep\/Terraform) should codify policies and associations for repeatability; portal-only workflows are harder to audit.<\/li>\n<\/ul>\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 architecture<\/h3>\n\n\n\n<p>Azure Firewall Manager sits in the control plane and manages <strong>Azure Firewall Policies<\/strong> and their association to <strong>Azure Firewall<\/strong> and\/or <strong>Virtual WAN secured hubs<\/strong>. The actual traffic inspection occurs in Azure Firewall data plane.<\/p>\n\n\n\n<p>Key concepts:\n&#8211; <strong>Control plane<\/strong>: Create\/modify policy, associate policy, configure hub security.\n&#8211; <strong>Data plane<\/strong>: Azure Firewall processes traffic, applies policy rules, produces logs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Request\/data flow vs control flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>\n<p><strong>Control flow<\/strong> (administrative):\n  1. Admin defines rules in Azure Firewall Policy (often via Firewall Manager experience).\n  2. Policy is associated to an Azure Firewall or secured virtual hub.\n  3. Azure Firewall enforces rules and emits logs\/metrics.<\/p>\n<\/li>\n<li>\n<p><strong>Data flow<\/strong> (network traffic):\n  1. Workload in a spoke subnet sends traffic.\n  2. Route table (UDR) sends 0.0.0.0\/0 or specific prefixes to Azure Firewall private IP (hub).\n  3. Azure Firewall evaluates rules (network\/application\/NAT).\n  4. Traffic is allowed\/denied; logs written to configured destinations.<\/p>\n<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services<\/h3>\n\n\n\n<p>Common integrations in Azure Networking and security architectures:\n&#8211; <strong>Virtual Network peering<\/strong>: connect spokes to hub VNet.\n&#8211; <strong>Route tables (UDR)<\/strong>: force traffic through Azure Firewall.\n&#8211; <strong>Azure Monitor + Log Analytics<\/strong>: collect firewall logs and metrics.\n&#8211; <strong>Microsoft Sentinel<\/strong>: SIEM\/SOAR on top of Log Analytics.\n&#8211; <strong>Azure Policy<\/strong>: govern resource configurations (for example, enforce diagnostics settings or tagging). Exact built-in policies vary; verify.\n&#8211; <strong>Private DNS \/ DNS Resolver<\/strong>: ensure consistent DNS resolution for FQDN-based rules and private endpoints.\n&#8211; <strong>ExpressRoute\/VPN Gateway<\/strong>: hybrid connectivity; hub inspection patterns often apply.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<p>Azure Firewall Manager deployments typically depend on:\n&#8211; Azure Firewall (Standard or Premium; Basic has different capabilities\u2014verify applicability)\n&#8211; VNets\/subnets (AzureFirewallSubnet required for VNet-based firewall)\n&#8211; Public IP addresses (for outbound SNAT and inbound DNAT scenarios)\n&#8211; Route tables (UDRs) for traffic steering\n&#8211; Log Analytics workspace (if enabling logs)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Uses <strong>Azure RBAC<\/strong> for management actions.<\/li>\n<li>Supports governance via management groups, subscriptions, resource groups.<\/li>\n<li>For policy changes, use <strong>least privilege<\/strong>, <strong>PIM<\/strong>, and change control.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Hub-and-spoke:<\/li>\n<li>Hub VNet contains Azure Firewall and shared services.<\/li>\n<li>Spoke VNets peer to hub.<\/li>\n<li>\n<p>UDRs force spoke subnets through firewall.<\/p>\n<\/li>\n<li>\n<p>Virtual WAN:<\/p>\n<\/li>\n<li>Virtual hubs connect VNets and on-prem via hub.<\/li>\n<li>Secured hub deploys security provider in hub.<\/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 Azure Firewall diagnostic logs:<\/li>\n<li>Application rule logs<\/li>\n<li>Network rule logs<\/li>\n<li>NAT rule logs<\/li>\n<li>Threat intelligence logs (if enabled)<\/li>\n<li>IDPS\/TLS inspection logs for Premium features (verify)<\/li>\n<li>Send logs to:<\/li>\n<li>Log Analytics (common)<\/li>\n<li>Storage account (archival)<\/li>\n<li>Event Hub (streaming to SIEM)<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Simple architecture diagram (Mermaid)<\/h4>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  Admin[Admin \/ SecOps] --&gt;|Define policy| AFM[Azure Firewall Manager]\n  AFM --&gt;|Creates\/updates| AFP[Azure Firewall Policy]\n  AFP --&gt;|Associated to| AF[Azure Firewall in Hub VNet]\n  Spoke[Spoke Workload Subnet] --&gt;|UDR to firewall| AF\n  AF --&gt;|Allow\/Deny| Internet[(Internet)]\n  AF --&gt; Logs[Azure Monitor \/ Log Analytics]\n<\/code><\/pre>\n\n\n\n<h4 class=\"wp-block-heading\">Production-style architecture diagram (Mermaid)<\/h4>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph MG[Management Group \/ Governance]\n    RBAC[Azure RBAC + PIM]\n    AzPolicy[Azure Policy (governance)]\n  end\n\n  subgraph Sec[Security Operations]\n    AFM[Azure Firewall Manager]\n    Parent[Parent Firewall Policy (baseline)]\n    ChildA[Child Policy - App A]\n    ChildB[Child Policy - App B]\n    LA[Log Analytics Workspace]\n    Sentinel[Microsoft Sentinel]\n  end\n\n  subgraph Region1[Region 1]\n    subgraph Hub1[Hub VNet]\n      AF1[Azure Firewall]\n      DNS1[DNS \/ Resolver (optional)]\n    end\n    subgraph Spokes1[Spoke VNets]\n      AppA1[App A Subnet]\n      AppB1[App B Subnet]\n    end\n  end\n\n  subgraph Region2[Region 2]\n    subgraph Hub2[Hub VNet]\n      AF2[Azure Firewall]\n    end\n    subgraph Spokes2[Spoke VNets]\n      AppA2[App A Subnet]\n    end\n  end\n\n  Internet[(Internet)]\n  OnPrem[(On-prem via VPN\/ER)]\n\n  RBAC --&gt; AFM\n  AzPolicy --&gt; AF1\n  AzPolicy --&gt; AF2\n\n  AFM --&gt; Parent\n  Parent --&gt; ChildA\n  Parent --&gt; ChildB\n  ChildA --&gt; AF1\n  ChildB --&gt; AF1\n  Parent --&gt; AF2\n\n  AppA1 --&gt;|UDR| AF1\n  AppB1 --&gt;|UDR| AF1\n  AppA2 --&gt;|UDR| AF2\n\n  AF1 --&gt; Internet\n  AF2 --&gt; Internet\n\n  OnPrem --&gt; AF1\n  OnPrem --&gt; AF2\n\n  AF1 --&gt; LA\n  AF2 --&gt; LA\n  LA --&gt; Sentinel\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<p>Before starting with Azure Firewall Manager in a hands-on lab or production:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Account\/subscription requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>An active <strong>Azure subscription<\/strong> with billing enabled.<\/li>\n<li>Ability to create resource groups, VNets, Azure Firewall, route tables, and VMs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>You need Azure RBAC permissions such as:\n&#8211; For lab simplicity: <strong>Owner<\/strong> or <strong>Contributor<\/strong> on the subscription or target resource group.\n&#8211; For least-privilege setups (recommended in real environments):\n  &#8211; Permissions to manage <strong>Azure Firewall Policy<\/strong>\n  &#8211; Permissions to manage <strong>Azure Firewall<\/strong>\n  &#8211; Permissions to manage <strong>Networking<\/strong> (VNets, subnets, route tables, peering)\n  &#8211; Permissions to configure <strong>diagnostic settings<\/strong> (Microsoft.Insights)<\/p>\n\n\n\n<p>Role names and exact permissions vary; verify in official docs and your organization\u2019s RBAC model.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Azure Firewall is a paid service (hourly + data processing). Logs may add cost.<\/li>\n<li>VM for validation is paid (compute + disk).<\/li>\n<li>Public IP resources incur cost.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Tools (CLI\/SDK\/portal)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Azure portal (recommended for Firewall Manager experience).<\/li>\n<li>Azure CLI (optional but useful): https:\/\/learn.microsoft.com\/cli\/azure\/install-azure-cli<\/li>\n<li>SSH client (if using Linux VM) or RDP client (if using Windows VM).<\/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>Azure Firewall and Azure Firewall Policy availability varies by region.<\/li>\n<li>Firewall Manager experience is generally available where Azure Firewall is available, but always <strong>verify region support<\/strong> in official docs for your target region(s), especially for Virtual WAN secured hubs and partner providers.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<p>Common limits come from Azure Firewall and policy objects, not specifically Firewall Manager:\n&#8211; Rule collection group limits\n&#8211; Number of rules\n&#8211; IP group limits\n&#8211; Public IP limitations\n&#8211; Virtual WAN hub constraints (if using secured hub)\nThese limits evolve; <strong>verify in official docs<\/strong> before large-scale designs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services<\/h3>\n\n\n\n<p>For the lab (VNet-based hub-and-spoke):\n&#8211; Resource group\n&#8211; Hub VNet + AzureFirewallSubnet\n&#8211; Spoke VNet + workload subnet\n&#8211; Azure Firewall (Standard\/Premium; choose based on needs)\n&#8211; Route table (UDR) to force traffic through the firewall\n&#8211; Test VM in the spoke subnet<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<p>Azure Firewall Manager is primarily a management experience; the main costs come from the resources it manages and the telemetry you enable.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (what you pay for)<\/h3>\n\n\n\n<p>You should model costs across these dimensions:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Azure Firewall<\/strong>\n   &#8211; Billed per deployment\/SKU (for example Standard vs Premium) with:<\/p>\n<ul>\n<li><strong>Hourly<\/strong> charge (running instance time)<\/li>\n<li><strong>Data processing<\/strong> charge (GB processed)<\/li>\n<li>Source: Azure Firewall pricing page: https:\/\/azure.microsoft.com\/pricing\/details\/azure-firewall\/<\/li>\n<\/ul>\n<\/li>\n<li>\n<p><strong>Azure Virtual WAN \/ secured virtual hub<\/strong> (only if you use Virtual WAN)\n   &#8211; Virtual WAN and hubs have their own pricing components.\n   &#8211; Source: Virtual WAN pricing: https:\/\/azure.microsoft.com\/pricing\/details\/virtual-wan\/<\/p>\n<\/li>\n<li>\n<p><strong>Public IP addresses<\/strong>\n   &#8211; Standard public IP resources incur charges.\n   &#8211; Pricing varies by SKU and region; verify on Azure pricing.<\/p>\n<\/li>\n<li>\n<p><strong>Logging and monitoring<\/strong>\n   &#8211; Log Analytics ingestion and retention can become a major cost driver.\n   &#8211; Microsoft Sentinel adds additional cost on top of Log Analytics (if used).<\/p>\n<\/li>\n<li>\n<p><strong>Network egress<\/strong>\n   &#8211; Outbound data transfer to the internet is typically chargeable.\n   &#8211; Inter-region traffic may incur costs depending on routing patterns.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Azure Firewall Manager itself is commonly presented as having no separate line-item cost, but this can change. <strong>Verify in official docs\/pricing<\/strong>.<\/li>\n<li>There is no meaningful \u201cfree tier\u201d for Azure Firewall usage; running a firewall incurs cost.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost drivers (what increases your bill)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Firewall SKU<\/strong>: Premium typically costs more than Standard.<\/li>\n<li><strong>Traffic volume<\/strong>: Data processed charges scale with throughput.<\/li>\n<li><strong>Log volume<\/strong>: Deny-heavy rulesets and verbose diagnostics increase log ingestion.<\/li>\n<li><strong>Architecture choices<\/strong>:<\/li>\n<li>Virtual WAN secured hubs add hub-related costs.<\/li>\n<li>Multi-region deployments multiply fixed hourly components.<\/li>\n<li><strong>Always-on resources<\/strong>: Firewalls are typically always-on for production.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden or indirect costs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Log Analytics retention<\/strong>: longer retention increases cost.<\/li>\n<li><strong>Sentinel<\/strong>: additional SIEM cost (if enabled).<\/li>\n<li><strong>Operational overhead<\/strong>: not a cloud bill item, but change management and troubleshooting time is real; centralized management can reduce it.<\/li>\n<li><strong>Data transfer<\/strong>:<\/li>\n<li>Forced tunneling patterns can increase egress and routing complexity.<\/li>\n<li>Inter-region inspection can cause unexpected bandwidth charges and latency (avoid unless required).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost (without weakening security)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Start with <strong>Standard SKU<\/strong> unless you need Premium-only features (TLS inspection\/IDPS, etc.\u2014verify feature requirements).<\/li>\n<li>Keep firewall policies clean:<\/li>\n<li>Avoid overly broad logging in steady state; use targeted diagnostics for investigations.<\/li>\n<li>Use rule ordering to reduce unnecessary rule evaluations and deny noise.<\/li>\n<li>Centralize logging smartly:<\/li>\n<li>Tune Log Analytics retention.<\/li>\n<li>Consider archiving to Storage for long-term retention and using LA for shorter hot retention.<\/li>\n<li>For dev\/test:<\/li>\n<li>Use strict cleanup discipline; firewalls are expensive if left running.<\/li>\n<li>Consider whether NSGs or smaller patterns are sufficient for non-production (risk-based decision).<\/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 minimal lab will typically include:\n&#8211; 1 Azure Firewall (Standard) running for a short time\n&#8211; 1 small Linux VM for testing\n&#8211; 1 public IP for the firewall\n&#8211; Log Analytics workspace (optional)\nYour cost will be dominated by <strong>Azure Firewall hourly + data processing<\/strong>. Run the lab briefly, validate, then <strong>delete resources<\/strong>.<\/p>\n\n\n\n<p>Because prices vary by region and change over time, do not use static numbers here. Use:\n&#8211; Pricing: https:\/\/azure.microsoft.com\/pricing\/details\/azure-firewall\/\n&#8211; Calculator: https:\/\/azure.microsoft.com\/pricing\/calculator\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>In production, consider:\n&#8211; One firewall per region (or per hub) for latency and resiliency.\n&#8211; Log Analytics ingestion at scale (can be significant).\n&#8211; Virtual WAN hub costs if you standardize on secured hubs.\n&#8211; Additional services: DDoS Protection, Sentinel, third-party security providers.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<p>This lab uses <strong>VNet hub-and-spoke<\/strong> with an <strong>Azure Firewall<\/strong> in the hub VNet. You will create and manage the firewall policy via the <strong>Azure Firewall Manager<\/strong> experience, associate it to the firewall, route spoke egress through the hub, and validate that traffic is allowed\/blocked as expected.<\/p>\n\n\n\n<blockquote>\n<p>Cost warning: Azure Firewall is not a low-cost service. Do this lab in a non-production subscription, keep the runtime short, and complete cleanup.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Deploy a hub-and-spoke network.<\/li>\n<li>Deploy Azure Firewall in the hub.<\/li>\n<li>Create an <strong>Azure Firewall Policy<\/strong> using <strong>Azure Firewall Manager<\/strong>.<\/li>\n<li>Associate the policy to the firewall.<\/li>\n<li>Force spoke VM outbound traffic through the firewall using a route table.<\/li>\n<li>Validate an allow rule and a deny rule.<\/li>\n<li>Clean up all resources.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will build:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Hub VNet<\/strong>: <code>10.0.0.0\/16<\/code><\/li>\n<li><code>AzureFirewallSubnet<\/code>: <code>10.0.0.0\/24<\/code> (required name)<\/li>\n<li><code>HubSharedSubnet<\/code> (optional): <code>10.0.1.0\/24<\/code> (not required)<\/li>\n<li><strong>Spoke VNet<\/strong>: <code>10.1.0.0\/16<\/code><\/li>\n<li><code>WorkloadSubnet<\/code>: <code>10.1.1.0\/24<\/code><\/li>\n<li><strong>Azure Firewall<\/strong> in hub with a public IP<\/li>\n<li><strong>Firewall Policy<\/strong> (via Azure Firewall Manager)<\/li>\n<li>Application rule: allow <code>ifconfig.me<\/code> over HTTP\/HTTPS (or another test endpoint)<\/li>\n<li>Network rule: optionally allow DNS to a resolver if needed<\/li>\n<li>Default deny (implicit)<\/li>\n<li><strong>Route table<\/strong> on spoke workload subnet:<\/li>\n<li><code>0.0.0.0\/0<\/code> next hop = Virtual appliance (Azure Firewall private IP)<\/li>\n<li><strong>Linux VM<\/strong> in spoke to test connectivity<\/li>\n<\/ul>\n\n\n\n<blockquote>\n<p>Note on test endpoints: Choose a stable public endpoint you control or a well-known endpoint. Some sites block cloud IPs or change behavior. You can substitute another domain and adjust rules accordingly.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Create the resource group and networks (Azure CLI)<\/h3>\n\n\n\n<p>1) Open Cloud Shell (Bash) in the Azure portal or use local Azure CLI.<\/p>\n\n\n\n<p>2) Set variables (adjust region as needed):<\/p>\n\n\n\n<pre><code class=\"language-bash\">RG=\"rg-afm-lab\"\nLOC=\"eastus\"\n\nHUB_VNET=\"vnet-hub-afm\"\nSPOKE_VNET=\"vnet-spoke-afm\"\n\nHUB_CIDR=\"10.0.0.0\/16\"\nAF_SUBNET_CIDR=\"10.0.0.0\/24\"\nSPOKE_CIDR=\"10.1.0.0\/16\"\nWORKLOAD_SUBNET_CIDR=\"10.1.1.0\/24\"\n\naz group create -n \"$RG\" -l \"$LOC\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: Resource group created.<\/p>\n\n\n\n<p>3) Create hub VNet with AzureFirewallSubnet:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network vnet create \\\n  -g \"$RG\" -n \"$HUB_VNET\" -l \"$LOC\" \\\n  --address-prefixes \"$HUB_CIDR\" \\\n  --subnet-name \"AzureFirewallSubnet\" \\\n  --subnet-prefixes \"$AF_SUBNET_CIDR\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: Hub VNet with <code>AzureFirewallSubnet<\/code> exists.<\/p>\n\n\n\n<p>4) Create spoke VNet:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network vnet create \\\n  -g \"$RG\" -n \"$SPOKE_VNET\" -l \"$LOC\" \\\n  --address-prefixes \"$SPOKE_CIDR\" \\\n  --subnet-name \"WorkloadSubnet\" \\\n  --subnet-prefixes \"$WORKLOAD_SUBNET_CIDR\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: Spoke VNet with <code>WorkloadSubnet<\/code> exists.<\/p>\n\n\n\n<p>5) Peer hub and spoke:<\/p>\n\n\n\n<pre><code class=\"language-bash\">HUB_ID=$(az network vnet show -g \"$RG\" -n \"$HUB_VNET\" --query id -o tsv)\nSPOKE_ID=$(az network vnet show -g \"$RG\" -n \"$SPOKE_VNET\" --query id -o tsv)\n\naz network vnet peering create -g \"$RG\" --vnet-name \"$HUB_VNET\" \\\n  -n \"peer-hub-to-spoke\" --remote-vnet \"$SPOKE_ID\" --allow-vnet-access\n\naz network vnet peering create -g \"$RG\" --vnet-name \"$SPOKE_VNET\" \\\n  -n \"peer-spoke-to-hub\" --remote-vnet \"$HUB_ID\" --allow-vnet-access\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: VNet peering established both ways.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Deploy Azure Firewall in the hub<\/h3>\n\n\n\n<p>1) Create a public IP for the firewall:<\/p>\n\n\n\n<pre><code class=\"language-bash\">PIP_NAME=\"pip-afm-fw\"\n\naz network public-ip create \\\n  -g \"$RG\" -n \"$PIP_NAME\" -l \"$LOC\" \\\n  --sku \"Standard\" \\\n  --allocation-method \"Static\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: Standard static public IP created.<\/p>\n\n\n\n<p>2) Create the Azure Firewall:<\/p>\n\n\n\n<pre><code class=\"language-bash\">FW_NAME=\"afw-hub-afm\"\n\naz network firewall create -g \"$RG\" -n \"$FW_NAME\" -l \"$LOC\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: Azure Firewall resource created (may take a few minutes).<\/p>\n\n\n\n<p>3) Configure the firewall IP configuration:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network firewall ip-config create \\\n  -g \"$RG\" -f \"$FW_NAME\" -n \"fw-ipconfig\" \\\n  --public-ip-address \"$PIP_NAME\" \\\n  --vnet-name \"$HUB_VNET\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: Firewall has a public IP and is attached to the hub VNet.<\/p>\n\n\n\n<p>4) Capture the firewall private IP (you\u2019ll need it for routing):<\/p>\n\n\n\n<pre><code class=\"language-bash\">FW_PRIVATE_IP=$(az network firewall show -g \"$RG\" -n \"$FW_NAME\" \\\n  --query \"ipConfigurations[0].privateIPAddress\" -o tsv)\n\necho \"Firewall private IP: $FW_PRIVATE_IP\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: You have the firewall private IP address.<\/p>\n\n\n\n<blockquote>\n<p>If <code>privateIPAddress<\/code> is empty, wait a few minutes and retry. Provisioning can take time.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create a Firewall Policy using Azure Firewall Manager (Portal)<\/h3>\n\n\n\n<p>Azure Firewall Policy can be created via CLI, Bicep, Terraform, or portal. To explicitly use <strong>Azure Firewall Manager<\/strong>, do it through the portal experience.<\/p>\n\n\n\n<p>1) In the Azure portal, search for <strong>Firewall Manager<\/strong> and open it.<\/p>\n\n\n\n<p>2) Go to:\n&#8211; <strong>Azure Firewall policies<\/strong> \u2192 <strong>Create Azure Firewall policy<\/strong><\/p>\n\n\n\n<p>3) Configure:\n&#8211; Subscription: your lab subscription\n&#8211; Resource group: <code>rg-afm-lab<\/code>\n&#8211; Policy name: <code>afwp-afm-lab<\/code>\n&#8211; Region: same as your firewall (for simplicity)\n&#8211; SKU: match your firewall needs (Standard is enough for this lab; Premium adds features\u2014verify)<\/p>\n\n\n\n<p>Create the policy.<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>: An Azure Firewall Policy resource exists.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Add firewall rules to the policy (allow one site, deny everything else)<\/h3>\n\n\n\n<p>You\u2019ll create an <strong>application rule<\/strong> allowing a specific FQDN, and rely on the default deny behavior for other outbound web requests.<\/p>\n\n\n\n<p>1) In <strong>Firewall Manager<\/strong> \u2192 <strong>Azure Firewall policies<\/strong> \u2192 select <code>afwp-afm-lab<\/code>.<\/p>\n\n\n\n<p>2) Add a <strong>Rule collection group<\/strong> (example):\n&#8211; Name: <code>rcg-lab-egress<\/code>\n&#8211; Priority: <code>100<\/code><\/p>\n\n\n\n<p>3) Inside the rule collection group, add an <strong>Application rule collection<\/strong>:\n&#8211; Name: <code>arc-allow-test<\/code>\n&#8211; Priority: <code>100<\/code>\n&#8211; Action: <code>Allow<\/code><\/p>\n\n\n\n<p>Add an application rule:\n&#8211; Name: <code>allow-ifconfig<\/code>\n&#8211; Source type: IP address\n&#8211; Source: <code>10.1.1.0\/24<\/code> (workload subnet)\n&#8211; Protocols: <code>http:80<\/code>, <code>https:443<\/code>\n&#8211; Target FQDNs: <code>ifconfig.me<\/code> (or your chosen test domain)<\/p>\n\n\n\n<p>4) Save changes.<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>: Policy contains a rule that allows outbound web access only to the chosen domain (plus any other default allowances you add).<\/p>\n\n\n\n<blockquote>\n<p>DNS note: Application rules depend on DNS resolution. If your VM uses Azure-provided DNS, it should work, but in locked-down environments you may need explicit DNS rules and\/or a DNS resolver design. For this lab, keep DNS simple.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Associate the policy to the Azure Firewall (using Firewall Manager)<\/h3>\n\n\n\n<p>1) In <strong>Firewall Manager<\/strong>, find your firewall and associate the policy:\n&#8211; Go to <strong>Azure Firewalls<\/strong> (or equivalent blade that lists managed firewalls; UX can change\u2014verify)\n&#8211; Select <code>afw-hub-afm<\/code>\n&#8211; Set <strong>Firewall policy<\/strong> = <code>afwp-afm-lab<\/code>\n&#8211; Save<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>: The Azure Firewall is now governed by the policy you created.<\/p>\n\n\n\n<blockquote>\n<p>Alternative method: You can set the policy directly on the Azure Firewall resource (outside Firewall Manager). For this tutorial, use Firewall Manager to reinforce the workflow.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Create route table to force spoke egress through the firewall<\/h3>\n\n\n\n<p>1) Create a route table:<\/p>\n\n\n\n<pre><code class=\"language-bash\">RT_NAME=\"rt-spoke-egress\"\n\naz network route-table create -g \"$RG\" -n \"$RT_NAME\" -l \"$LOC\"\n<\/code><\/pre>\n\n\n\n<p>2) Create a default route (0.0.0.0\/0) to the firewall private IP:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network route-table route create \\\n  -g \"$RG\" --route-table-name \"$RT_NAME\" \\\n  -n \"default-to-firewall\" \\\n  --address-prefix \"0.0.0.0\/0\" \\\n  --next-hop-type \"VirtualAppliance\" \\\n  --next-hop-ip-address \"$FW_PRIVATE_IP\"\n<\/code><\/pre>\n\n\n\n<p>3) Associate route table to the spoke workload subnet:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network vnet subnet update \\\n  -g \"$RG\" --vnet-name \"$SPOKE_VNET\" -n \"WorkloadSubnet\" \\\n  --route-table \"$RT_NAME\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: Any outbound traffic from the workload subnet is routed through Azure Firewall.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Create a test VM in the spoke<\/h3>\n\n\n\n<p>Create a small Ubuntu VM (choose a small size to reduce cost). This VM does not need a public IP if you use Azure Bastion, a jumpbox, or Cloud Shell + run-command. For simplicity, this lab uses a public IP with SSH; secure it with a strong SSH key and restrict source IP where possible.<\/p>\n\n\n\n<p>1) Create an NSG rule set (optional but recommended) and VM:<\/p>\n\n\n\n<pre><code class=\"language-bash\">VM_NAME=\"vm-spoke-test\"\nADMIN_USER=\"azureuser\"\n\naz network nsg create -g \"$RG\" -n \"nsg-spoke-vm\" -l \"$LOC\"\n\n# Restrict SSH to your IP if possible (replace YOUR_PUBLIC_IP\/32)\n# If you cannot, you can temporarily open and then tighten.\naz network nsg rule create -g \"$RG\" --nsg-name \"nsg-spoke-vm\" \\\n  -n \"Allow-SSH\" --priority 1000 \\\n  --access Allow --protocol Tcp --direction Inbound \\\n  --source-address-prefixes \"YOUR_PUBLIC_IP\/32\" \\\n  --source-port-ranges \"*\" \\\n  --destination-address-prefixes \"*\" --destination-port-ranges 22\n\naz vm create -g \"$RG\" -n \"$VM_NAME\" -l \"$LOC\" \\\n  --image \"Ubuntu2204\" \\\n  --vnet-name \"$SPOKE_VNET\" --subnet \"WorkloadSubnet\" \\\n  --nsg \"nsg-spoke-vm\" \\\n  --admin-username \"$ADMIN_USER\" \\\n  --generate-ssh-keys\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: A Linux VM is created in the spoke subnet.<\/p>\n\n\n\n<blockquote>\n<p>If you cannot restrict SSH to a fixed IP, use Azure Bastion instead. Bastion adds cost but avoids exposing SSH to the internet.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>You will validate that:\n1) The allowed domain is reachable (HTTP\/HTTPS).\n2) A disallowed domain is blocked.<\/p>\n\n\n\n<p>1) SSH to the VM:<\/p>\n\n\n\n<pre><code class=\"language-bash\">VM_PIP=$(az vm show -g \"$RG\" -n \"$VM_NAME\" -d --query publicIps -o tsv)\nssh \"${ADMIN_USER}@${VM_PIP}\"\n<\/code><\/pre>\n\n\n\n<p>2) From the VM, test the allowed domain:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -I https:\/\/ifconfig.me\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: You should receive an HTTP response (for example <code>200 OK<\/code> or a redirect). If it times out or fails, check troubleshooting.<\/p>\n\n\n\n<p>3) Test a disallowed domain (example):<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -I https:\/\/example.com\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: This should fail (timeout\/connection reset) because the policy only allows <code>ifconfig.me<\/code> for HTTP\/HTTPS.<\/p>\n\n\n\n<p>4) Confirm logs (recommended):\n&#8211; In Azure portal, go to the Azure Firewall resource \u2192 <strong>Logs<\/strong> (or Log Analytics if configured).\n&#8211; If you configured diagnostic settings to Log Analytics, query firewall logs to confirm allow\/deny events.<\/p>\n\n\n\n<blockquote>\n<p>Log query details vary by diagnostic configuration and table names; verify the current Azure Firewall logging schema in official docs.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p>Common issues in Azure Firewall Manager \/ Azure Firewall labs:<\/p>\n\n\n\n<p>1) <strong>Firewall private IP is empty<\/strong>\n&#8211; Cause: Firewall not fully provisioned.\n&#8211; Fix: Wait 5\u201315 minutes and re-run the query.<\/p>\n\n\n\n<p>2) <strong>Traffic bypasses the firewall<\/strong>\n&#8211; Cause: Route table not associated to subnet, wrong next hop IP, or VM in different subnet.\n&#8211; Fix:\n  &#8211; Confirm the route table is attached to <code>WorkloadSubnet<\/code>.\n  &#8211; Confirm <code>0.0.0.0\/0<\/code> route points to firewall private IP.\n  &#8211; Check effective routes on the VM NIC in the portal.<\/p>\n\n\n\n<p>3) <strong>DNS resolution issues break FQDN rules<\/strong>\n&#8211; Cause: Application rules require DNS; if DNS is blocked or misrouted, FQDN-based allow rules won\u2019t match.\n&#8211; Fix:\n  &#8211; Ensure the VM can resolve DNS (try <code>nslookup ifconfig.me<\/code>).\n  &#8211; Verify your DNS architecture (Azure-provided DNS vs custom resolver).\n  &#8211; In more advanced setups, explicitly allow DNS traffic to your resolver and ensure that traffic also routes appropriately.<\/p>\n\n\n\n<p>4) <strong>SSH NSG rule blocks you<\/strong>\n&#8211; Cause: Wrong source IP in NSG rule.\n&#8211; Fix: Update NSG inbound rule to your current public IP, or use Bastion.<\/p>\n\n\n\n<p>5) <strong>Policy association not applied<\/strong>\n&#8211; Cause: Policy not associated, or applied to different firewall, or propagation delay.\n&#8211; Fix:\n  &#8211; Verify Azure Firewall resource shows the policy attached.\n  &#8211; Wait a few minutes for propagation.\n  &#8211; Confirm you edited the correct policy\/rule collection group.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>Delete the resource group to remove everything created:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az group delete -n \"$RG\" --yes --no-wait\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: All lab resources (firewall, policy, VNets, VM, public IPs, route tables) are deleted. Monitor deletion to ensure no billable resources remain.<\/p>\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 hub-and-spoke or Virtual WAN intentionally<\/strong>:<\/li>\n<li>Hub-and-spoke is straightforward and common for many orgs.<\/li>\n<li>Virtual WAN is ideal for large-scale global connectivity and standardized hubs.<\/li>\n<li><strong>Avoid cross-region inspection unless required<\/strong>: It increases latency and may increase bandwidth charges.<\/li>\n<li><strong>Design for blast radius<\/strong>:<\/li>\n<li>Use separate policies or child policies per environment\/team to reduce the risk of one change impacting all.<\/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><strong>Separate duties<\/strong>:<\/li>\n<li>Platform team: networking resources, firewall deployment, routing<\/li>\n<li>Security team: firewall policy rules and change approval<\/li>\n<li><strong>Use least privilege<\/strong>:<\/li>\n<li>Scope RBAC to the resource group containing firewall policies.<\/li>\n<li>Use Azure AD Privileged Identity Management (PIM) for elevated roles.<\/li>\n<li><strong>Tagging and ownership<\/strong>:<\/li>\n<li>Tag policies and firewalls with owner, environment, cost center, and change group.<\/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><strong>Right-size your footprint<\/strong>: Avoid deploying firewalls in regions you don\u2019t need.<\/li>\n<li><strong>Manage logs intentionally<\/strong>:<\/li>\n<li>Send to Log Analytics with tuned retention.<\/li>\n<li>Archive long-term logs to Storage when appropriate.<\/li>\n<li><strong>Dev\/test discipline<\/strong>: Tear down lab\/test firewalls promptly.<\/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><strong>Keep rule sets maintainable<\/strong>:<\/li>\n<li>Use structured rule collection groups and priorities.<\/li>\n<li>Keep high-frequency allow rules early where appropriate (validate behavior with docs).<\/li>\n<li><strong>Minimize overly broad application rules<\/strong>:<\/li>\n<li>Prefer specific FQDNs and destination constraints.<\/li>\n<li><strong>Plan DNS<\/strong>:<\/li>\n<li>FQDN-based rules require reliable DNS resolution; treat DNS as a critical dependency.<\/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><strong>Plan for regional failures<\/strong>:<\/li>\n<li>For mission-critical systems, design multi-region patterns and failover strategies.<\/li>\n<li><strong>Avoid single points of operational failure<\/strong>:<\/li>\n<li>Use IaC to recreate configuration consistently.<\/li>\n<li>Use controlled change rollout (staged environments).<\/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><strong>Centralize monitoring<\/strong>:<\/li>\n<li>Standardize diagnostics settings for all Azure Firewalls.<\/li>\n<li>Use alerts on key signals (threat intel hits, unusual deny spikes, health signals).<\/li>\n<li><strong>Runbooks<\/strong>:<\/li>\n<li>Document how to add rules, validate changes, and roll back.<\/li>\n<li><strong>Change control<\/strong>:<\/li>\n<li>Use pull requests and IaC for policy\/rule changes where possible.<\/li>\n<li>If using portal changes, maintain audit trails and approvals.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Naming examples:<\/li>\n<li>Policies: <code>afwp-{org}-{env}-{region}-{purpose}<\/code><\/li>\n<li>Firewalls: <code>afw-{org}-{env}-{region}-hub<\/code><\/li>\n<li>Route tables: <code>rt-{env}-{spoke}-egress<\/code><\/li>\n<li>Tag baseline:<\/li>\n<li><code>Environment<\/code>, <code>Owner<\/code>, <code>CostCenter<\/code>, <code>DataClassification<\/code>, <code>ChangeGroup<\/code><\/li>\n<\/ul>\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><strong>Azure RBAC<\/strong> controls who can:<\/li>\n<li>Create\/modify firewall policies<\/li>\n<li>Associate policies to firewalls\/hubs<\/li>\n<li>Configure diagnostics and routing<\/li>\n<li>Recommendations:<\/li>\n<li>Use <strong>management groups<\/strong> and consistent RBAC assignments.<\/li>\n<li>Use <strong>PIM<\/strong> for privileged roles.<\/li>\n<li>Use separate resource groups for:<ul>\n<li>Networking infrastructure<\/li>\n<li>Security policies<\/li>\n<li>Workloads (spokes)<\/li>\n<\/ul>\n<\/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>Control plane operations use Azure\u2019s standard secure management plane.<\/li>\n<li>Data plane encryption depends on your workloads (TLS, IPsec, etc.).<\/li>\n<li>If using Azure Firewall Premium TLS inspection, certificate and key handling becomes critical\u2014<strong>verify Premium requirements and harden key management<\/strong>.<\/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>Avoid exposing management endpoints unnecessarily.<\/li>\n<li>Use secure administrative access patterns:<\/li>\n<li>Bastion for VM access<\/li>\n<li>Restrictive NSGs<\/li>\n<li>No public IPs on workloads when not needed<\/li>\n<li>For inbound publishing:<\/li>\n<li>Prefer Application Gateway\/WAF for HTTP(S) front doors.<\/li>\n<li>Use Azure Firewall DNAT where it fits, but ensure strict destination constraints.<\/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>Firewall policies themselves generally do not require secrets.<\/li>\n<li>If TLS inspection is used (Premium), certificate management becomes a secret-handling concern. Use Key Vault and strict access controls where supported; verify current integration guidance.<\/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 diagnostic logs for Azure Firewall and route to central logging.<\/li>\n<li>Integrate with Microsoft Sentinel for detection and response if desired.<\/li>\n<li>Regularly review:<\/li>\n<li>Rule change history (via Azure Activity Log)<\/li>\n<li>Firewall deny spikes (could indicate misconfig or malicious activity)<\/li>\n<li>Threat intelligence events (if enabled)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<p>Azure Firewall Manager supports compliance goals by enabling centralized policy and auditing, but compliance depends on:\n&#8211; Your control implementation (rules, logging, retention, incident response)\n&#8211; Proper identity governance\n&#8211; Network segmentation design<\/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>Overly permissive \u201callow all outbound\u201d rules for convenience.<\/li>\n<li>Not forcing routes through firewall (traffic bypass).<\/li>\n<li>No logging or short retention.<\/li>\n<li>Too broad policy reuse causing large blast radius.<\/li>\n<li>Weak admin access to test VMs (public SSH from anywhere).<\/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 a <strong>deny-by-default<\/strong> egress posture and add explicit allows.<\/li>\n<li>Use <strong>hierarchical policies<\/strong>:<\/li>\n<li>Parent baseline: threat intel, deny lists, core enterprise allow list<\/li>\n<li>Child policies: workload-specific exceptions<\/li>\n<li>Ensure <strong>routing enforcement<\/strong> and validate effective routes.<\/li>\n<li>Centralize logs, and protect the logging pipeline.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<p>Azure Firewall Manager inherits most practical constraints from Azure Firewall, Azure Firewall Policy, and (optionally) Virtual WAN. Common gotchas include:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Firewall Manager is not the firewall<\/strong>: It manages policies and associations; Azure Firewall is the enforcement point.<\/li>\n<li><strong>Routing is required<\/strong>: Without UDRs (or correct Virtual WAN routing), traffic will bypass inspection.<\/li>\n<li><strong>DNS dependency for FQDN rules<\/strong>: Application rules require correct DNS resolution; broken DNS looks like \u201cfirewall issue\u201d but isn\u2019t.<\/li>\n<li><strong>Policy blast radius<\/strong>: Shared policies across many firewalls can cause widespread outage if changed incorrectly.<\/li>\n<li><strong>Propagation delays<\/strong>: Policy updates and associations can take time to apply.<\/li>\n<li><strong>SKU\/feature mismatch<\/strong>: Some policy settings require Azure Firewall Premium (TLS inspection\/IDPS, etc.). Verify capabilities per SKU.<\/li>\n<li><strong>Logging cost surprises<\/strong>: High-volume environments can generate large Log Analytics ingestion charges.<\/li>\n<li><strong>Virtual WAN complexity\/cost<\/strong>: Secured hub architectures are powerful but introduce additional moving parts and cost centers.<\/li>\n<li><strong>Regional availability differences<\/strong>: Not all features (especially partner integrations) are available in all regions; verify.<\/li>\n<li><strong>Third-party security providers<\/strong>: Supported partners and capabilities change; validate current list and constraints in official docs.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Azure Firewall Manager is best compared as a centralized management layer for firewalls and hub security, not as a firewall itself.<\/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>Azure Firewall Manager<\/strong><\/td>\n<td>Central management of Azure Firewall Policies across hubs\/firewalls<\/td>\n<td>Centralized policy, hierarchical policies, scalable governance, Virtual WAN secured hub alignment<\/td>\n<td>Still requires Azure Firewall; routing\/DNS complexity; cost is mainly in underlying firewall\/logging<\/td>\n<td>You need consistent firewall policy management across many VNets\/subscriptions\/regions<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Firewall (directly managed)<\/strong><\/td>\n<td>Single or few firewalls with simple governance<\/td>\n<td>Direct control, fewer layers<\/td>\n<td>Harder to standardize at scale; more manual duplication<\/td>\n<td>Small environments or early-stage deployments<\/td>\n<\/tr>\n<tr>\n<td><strong>Network Security Groups (NSGs)<\/strong><\/td>\n<td>Basic subnet\/NIC L3\/L4 filtering<\/td>\n<td>Low cost, simple, distributed control<\/td>\n<td>Not a centralized stateful firewall; limited L7 features; limited central logging\/inspection<\/td>\n<td>Simple segmentation, micro-segmentation, or complementing firewall (not replacing it)<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Application Gateway WAF<\/strong><\/td>\n<td>HTTP\/HTTPS inbound app protection<\/td>\n<td>Strong L7 WAF features, app routing<\/td>\n<td>Not a general egress firewall; not for non-HTTP protocols<\/td>\n<td>You need inbound web protection (often paired with Azure Firewall)<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Front Door WAF<\/strong><\/td>\n<td>Global edge + web protection<\/td>\n<td>Global routing, edge WAF<\/td>\n<td>Not for internal east-west or general egress control<\/td>\n<td>Global web apps requiring edge routing and WAF<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Network Firewall + Firewall Manager (AWS)<\/strong><\/td>\n<td>Similar concept in AWS<\/td>\n<td>Managed firewall + centralized policies (AWS ecosystem)<\/td>\n<td>Different cloud; migration complexity<\/td>\n<td>AWS-native environments (not Azure)<\/td>\n<\/tr>\n<tr>\n<td><strong>GCP Cloud Firewall Policies \/ Cloud Armor<\/strong><\/td>\n<td>Similar concepts in GCP<\/td>\n<td>GCP-native controls<\/td>\n<td>Different cloud; not Azure Firewall equivalent<\/td>\n<td>GCP-native environments (not Azure)<\/td>\n<\/tr>\n<tr>\n<td><strong>Self-managed firewall appliances (e.g., NVA)<\/strong><\/td>\n<td>Highly customized firewall needs<\/td>\n<td>Full vendor feature set, deep customization<\/td>\n<td>Ops burden, scaling\/HA complexity, patching, licensing<\/td>\n<td>When Azure Firewall features don\u2019t meet requirements and you can operate NVAs reliably<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\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: multi-subscription landing zone with centralized egress control<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A large enterprise has 30+ subscriptions across multiple teams. Each team deploys workloads in spokes. Security needs consistent outbound restrictions, logging, and incident response capability.<\/li>\n<li><strong>Proposed architecture<\/strong>:<\/li>\n<li>Hub-and-spoke per region (or Virtual WAN hubs for global WAN).<\/li>\n<li>Azure Firewall per hub.<\/li>\n<li>Azure Firewall Manager-managed <strong>parent policy<\/strong>:<ul>\n<li>Deny known malicious indicators (threat intel)<\/li>\n<li>Allow required enterprise services (identity endpoints, update services, approved SaaS)<\/li>\n<li>Standard logging and alerting requirements<\/li>\n<\/ul>\n<\/li>\n<li><strong>Child policies<\/strong> per business unit\/application to allow specific external dependencies.<\/li>\n<li>Central Log Analytics + Sentinel for correlation.<\/li>\n<li><strong>Why Azure Firewall Manager was chosen<\/strong>:<\/li>\n<li>Central governance with hierarchical policies.<\/li>\n<li>Reduced duplication and more predictable auditing and change control.<\/li>\n<li><strong>Expected outcomes<\/strong>:<\/li>\n<li>Faster onboarding of new spokes\/subscriptions with inherited baseline.<\/li>\n<li>Reduced policy drift and fewer security exceptions.<\/li>\n<li>Improved visibility for incident response.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: standard hub firewall for a few environments<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A startup runs staging and production in separate VNets and wants to prevent accidental open egress while maintaining a small ops footprint.<\/li>\n<li><strong>Proposed architecture<\/strong>:<\/li>\n<li>Single hub VNet with Azure Firewall.<\/li>\n<li>Two spokes (staging\/prod).<\/li>\n<li>Azure Firewall Manager used to maintain:<ul>\n<li>A baseline policy shared by both environments<\/li>\n<li>Separate child policies per environment (prod tighter, staging slightly more permissive)<\/li>\n<\/ul>\n<\/li>\n<li>Log Analytics workspace with short retention for cost control.<\/li>\n<li><strong>Why Azure Firewall Manager was chosen<\/strong>:<\/li>\n<li>Even with only a few environments, policy reuse and separation reduces mistakes.<\/li>\n<li><strong>Expected outcomes<\/strong>:<\/li>\n<li>Less risk of accidental exposure.<\/li>\n<li>Easier troubleshooting and visibility into outbound dependencies.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is Azure Firewall Manager a firewall?<\/strong><br\/>\nNo. Azure Firewall Manager is primarily a management layer for defining and associating <strong>Azure Firewall Policies<\/strong>. <strong>Azure Firewall<\/strong> is the service that actually inspects and allows\/denies traffic.<\/p>\n\n\n\n<p>2) <strong>Do I need Azure Firewall Manager to use Azure Firewall Policy?<\/strong><br\/>\nNot strictly. You can create and attach firewall policies directly on Azure Firewall resources. Azure Firewall Manager provides a centralized experience and governance model, especially useful at scale.<\/p>\n\n\n\n<p>3) <strong>Can one policy be applied to multiple Azure Firewalls?<\/strong><br\/>\nYes, that\u2019s a common pattern. Design carefully to manage blast radius.<\/p>\n\n\n\n<p>4) <strong>What is a hierarchical firewall policy?<\/strong><br\/>\nA parent\/child policy model where a child policy inherits baseline controls from a parent policy and extends it. Exact inheritance and override behavior should be verified in official docs.<\/p>\n\n\n\n<p>5) <strong>Does Azure Firewall Manager support Azure Virtual WAN?<\/strong><br\/>\nYes, it is commonly used with <strong>secured virtual hubs<\/strong> in Virtual WAN. Verify specific region and feature support.<\/p>\n\n\n\n<p>6) <strong>Does Azure Firewall Manager add extra cost?<\/strong><br\/>\nTypically, the major costs are Azure Firewall, Virtual WAN (if used), logging, and data transfer. Azure Firewall Manager is mainly a management layer. Always verify current pricing guidance in official sources.<\/p>\n\n\n\n<p>7) <strong>How do I force traffic through Azure Firewall?<\/strong><br\/>\nIn hub-and-spoke VNets, you typically use <strong>User Defined Routes (UDRs)<\/strong> on spoke subnets pointing <code>0.0.0.0\/0<\/code> (or specific prefixes) to the firewall private IP.<\/p>\n\n\n\n<p>8) <strong>Why are my FQDN application rules not working?<\/strong><br\/>\nMost commonly due to DNS resolution issues, routing that bypasses the firewall, or rule misconfiguration. Validate DNS and effective routes.<\/p>\n\n\n\n<p>9) <strong>Can Azure Firewall Manager manage third-party firewalls?<\/strong><br\/>\nIn Virtual WAN secured hubs, Azure supports certain third-party security providers. Firewall Manager can help configure hub security providers. Verify current supported partners in official docs.<\/p>\n\n\n\n<p>10) <strong>Should I replace NSGs with Azure Firewall Manager?<\/strong><br\/>\nNo. NSGs and Azure Firewall serve different purposes and often complement each other. NSGs are good for local segmentation; Azure Firewall provides centralized, stateful inspection and L7 controls.<\/p>\n\n\n\n<p>11) <strong>How do I audit who changed firewall rules?<\/strong><br\/>\nUse the <strong>Azure Activity Log<\/strong> for management operations and maintain IaC and pull request workflows when possible.<\/p>\n\n\n\n<p>12) <strong>What\u2019s the best way to roll out policy changes safely?<\/strong><br\/>\nUse staged rollout:\n&#8211; Test in dev\/test\n&#8211; Use child policies for controlled scope\n&#8211; Validate logs and traffic behavior\n&#8211; Apply to production with change windows and rollback plans<\/p>\n\n\n\n<p>13) <strong>Can I use Azure Firewall Manager across multiple subscriptions?<\/strong><br\/>\nYes, as long as RBAC permissions allow it. Centralized governance often uses management groups.<\/p>\n\n\n\n<p>14) <strong>How do I monitor Azure Firewall?<\/strong><br\/>\nEnable diagnostics and metrics to Azure Monitor\/Log Analytics and consider Sentinel for detection. Create alerts for threat intel hits, deny spikes, and health signals.<\/p>\n\n\n\n<p>15) <strong>What\u2019s the most common design mistake?<\/strong><br\/>\nDeploying the firewall but failing to enforce routing through it, resulting in traffic bypass and a false sense of security.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Azure Firewall Manager<\/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>Azure Firewall Manager documentation: https:\/\/learn.microsoft.com\/azure\/firewall-manager\/<\/td>\n<td>Primary reference for concepts, supported scenarios, and configuration workflows<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>Azure Firewall documentation: https:\/\/learn.microsoft.com\/azure\/firewall\/<\/td>\n<td>Required to understand the enforcement plane, SKUs, rules, and deployment patterns<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>Azure Firewall Policy documentation: https:\/\/learn.microsoft.com\/azure\/firewall-manager\/policy-overview (verify exact page paths)<\/td>\n<td>Explains policy structure, rule collection groups, and hierarchy concepts<\/td>\n<\/tr>\n<tr>\n<td>Official pricing page<\/td>\n<td>Azure Firewall pricing: https:\/\/azure.microsoft.com\/pricing\/details\/azure-firewall\/<\/td>\n<td>Authoritative pricing model for firewall runtime and data processing<\/td>\n<\/tr>\n<tr>\n<td>Official pricing page<\/td>\n<td>Azure Virtual WAN pricing: https:\/\/azure.microsoft.com\/pricing\/details\/virtual-wan\/<\/td>\n<td>Needed if you use secured virtual hubs<\/td>\n<\/tr>\n<tr>\n<td>Official pricing tools<\/td>\n<td>Azure Pricing Calculator: https:\/\/azure.microsoft.com\/pricing\/calculator\/<\/td>\n<td>Build region-specific estimates based on your architecture<\/td>\n<\/tr>\n<tr>\n<td>Architecture guidance<\/td>\n<td>Azure Architecture Center: https:\/\/learn.microsoft.com\/azure\/architecture\/<\/td>\n<td>Reference architectures for hub-spoke, Virtual WAN, and network security patterns<\/td>\n<\/tr>\n<tr>\n<td>Monitoring guidance<\/td>\n<td>Azure Monitor documentation: https:\/\/learn.microsoft.com\/azure\/azure-monitor\/<\/td>\n<td>Learn how to route logs\/metrics and build alerts<\/td>\n<\/tr>\n<tr>\n<td>SIEM guidance<\/td>\n<td>Microsoft Sentinel documentation: https:\/\/learn.microsoft.com\/azure\/sentinel\/<\/td>\n<td>If you want SIEM\/SOAR on firewall logs<\/td>\n<\/tr>\n<tr>\n<td>CLI reference<\/td>\n<td>Azure CLI network commands: https:\/\/learn.microsoft.com\/cli\/azure\/network<\/td>\n<td>Practical command reference for VNets, route tables, firewall resources<\/td>\n<\/tr>\n<tr>\n<td>Product updates<\/td>\n<td>Azure updates: https:\/\/azure.microsoft.com\/updates\/<\/td>\n<td>Track changes in Azure Firewall\/Firewall Manager and Networking services<\/td>\n<\/tr>\n<tr>\n<td>Community learning (reputable)<\/td>\n<td>Microsoft Tech Community (Azure Networking): https:\/\/techcommunity.microsoft.com\/category\/azure-networking\/blog\/azurenetworkingblog<\/td>\n<td>Practical posts and announcements from Azure Networking teams (validate against docs)<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\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, SREs, platform teams<\/td>\n<td>Azure fundamentals, cloud operations, DevOps practices (verify course catalog)<\/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 engineers<\/td>\n<td>DevOps\/SCM and cloud-adjacent training (verify specifics)<\/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 ops practitioners<\/td>\n<td>Cloud operations and automation topics (verify specifics)<\/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, operations teams<\/td>\n<td>Reliability engineering practices and operations (verify specifics)<\/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 + monitoring practitioners<\/td>\n<td>AIOps concepts, monitoring\/observability (verify specifics)<\/td>\n<td>check website<\/td>\n<td>https:\/\/www.aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\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>DevOps\/cloud training content (verify focus)<\/td>\n<td>Students, engineers seeking guided learning<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps training and mentoring (verify focus)<\/td>\n<td>Beginners to intermediate DevOps engineers<\/td>\n<td>https:\/\/www.devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>Freelance DevOps guidance\/services (verify specifics)<\/td>\n<td>Teams seeking practical help and learning<\/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 specifics)<\/td>\n<td>Ops\/DevOps teams needing hands-on support<\/td>\n<td>https:\/\/www.devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\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 Name<\/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 offerings)<\/td>\n<td>Architecture, implementation, operationalization<\/td>\n<td>Hub-and-spoke rollout, IaC enablement, monitoring\/logging setup<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps and cloud services (verify exact offerings)<\/td>\n<td>Training + consulting engagements<\/td>\n<td>Azure landing zone practices, CI\/CD integration, ops readiness<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting (verify exact offerings)<\/td>\n<td>Advisory and implementation support<\/td>\n<td>Standardized deployments, automation, operational best practices<\/td>\n<td>https:\/\/www.devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\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 Azure Firewall Manager<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Azure Networking fundamentals:<\/li>\n<li>VNets, subnets, peering<\/li>\n<li>Route tables (UDR), effective routes<\/li>\n<li>DNS basics in Azure (Azure-provided DNS vs custom DNS)<\/li>\n<li>Security fundamentals:<\/li>\n<li>Least privilege and RBAC<\/li>\n<li>Network segmentation patterns<\/li>\n<li>Azure basics:<\/li>\n<li>Resource groups, subscriptions, regions<\/li>\n<li>Azure Monitor and Activity Log<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Azure Firewall Manager<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Advanced Azure Firewall capabilities:<\/li>\n<li>Firewall Premium features (TLS inspection, IDPS) if relevant (verify)<\/li>\n<li>Threat intelligence tuning and incident workflows<\/li>\n<li>Azure Virtual WAN secured hubs (for global WAN architectures)<\/li>\n<li>Microsoft Sentinel:<\/li>\n<li>Detection rules, hunting queries, incident automation<\/li>\n<li>Infrastructure as Code:<\/li>\n<li>Bicep\/ARM or Terraform for repeatable firewall policy deployment<\/li>\n<li>Governance:<\/li>\n<li>Azure Policy initiatives for diagnostics\/tagging compliance<\/li>\n<li>Management group design and centralized RBAC models<\/li>\n<\/ul>\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>Solutions architect (Networking\/security focus)<\/li>\n<li>Platform engineer<\/li>\n<li>SRE\/operations engineer (for monitoring and incident response)<\/li>\n<li>Security operations analyst (consuming firewall logs in SIEM)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (Azure)<\/h3>\n\n\n\n<p>Azure certifications evolve; choose based on role:\n&#8211; Networking-heavy: Azure network-focused exams (verify current exam codes)\n&#8211; Security-heavy: Azure security engineer track\n&#8211; Architecture: Azure solutions architect track<br\/>\nAlways verify the latest certification paths on Microsoft Learn: https:\/\/learn.microsoft.com\/credentials\/<\/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 hub-and-spoke with:<\/li>\n<li>Parent\/child firewall policies<\/li>\n<li>Separate policies for prod vs non-prod<\/li>\n<li>Central logging + alerting for deny spikes<\/li>\n<li>Implement \u201cegress allow list\u201d for a container platform (AKS) and validate required endpoints.<\/li>\n<li>Build an incident response playbook:<\/li>\n<li>Add IOC block rules centrally<\/li>\n<li>Validate propagation<\/li>\n<li>Verify logs and rollback<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Azure Firewall Manager<\/strong>: Central management service\/experience for Azure Firewall Policies and security configurations (especially hubs and Virtual WAN).<\/li>\n<li><strong>Azure Firewall<\/strong>: Managed, stateful network firewall that inspects and controls traffic.<\/li>\n<li><strong>Azure Firewall Policy<\/strong>: Resource that defines firewall rules and settings to be enforced by Azure Firewall.<\/li>\n<li><strong>Hierarchical policy<\/strong>: Parent\/child policy model for baseline + workload-specific rules.<\/li>\n<li><strong>Hub-and-spoke<\/strong>: Network topology where a central hub VNet connects to multiple spoke VNets.<\/li>\n<li><strong>UDR (User Defined Route)<\/strong>: Custom route in an Azure route table used to steer traffic (for example, to a firewall).<\/li>\n<li><strong>NAT (Network Address Translation)<\/strong>: Translating addresses\/ports, commonly used for inbound publishing (DNAT) or outbound SNAT.<\/li>\n<li><strong>Application rule<\/strong>: Layer 7-ish rule based on FQDNs and protocols (HTTP\/HTTPS), enforced by Azure Firewall.<\/li>\n<li><strong>Network rule<\/strong>: Layer 3\/4 rule based on IPs, ports, and protocols.<\/li>\n<li><strong>Secured virtual hub<\/strong>: An Azure Virtual WAN hub with a security provider enabled for traffic inspection.<\/li>\n<li><strong>Log Analytics<\/strong>: Azure service for log ingestion, query (KQL), and retention.<\/li>\n<li><strong>Microsoft Sentinel<\/strong>: Cloud-native SIEM\/SOAR built on Log Analytics.<\/li>\n<li><strong>RBAC<\/strong>: Role-based access control in Azure.<\/li>\n<li><strong>PIM<\/strong>: Privileged Identity Management for just-in-time privileged access.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Azure Firewall Manager (Azure) is a <strong>Networking<\/strong> security management service that centralizes <strong>Azure Firewall Policy<\/strong> creation and policy association across Azure Firewall deployments and (optionally) Virtual WAN secured hubs. It matters because it helps organizations apply consistent firewall rules, reduce configuration drift, and operate at scale with clearer governance and auditing.<\/p>\n\n\n\n<p>Cost-wise, Firewall Manager is mainly a control-plane layer; your bill is driven by <strong>Azure Firewall runtime + data processing<\/strong>, <strong>Virtual WAN<\/strong> (if used), <strong>logging<\/strong>, and <strong>data transfer<\/strong>. Security-wise, treat policy changes as high impact, enforce least privilege with RBAC\/PIM, and design routing and DNS carefully to avoid traffic bypass and rule mismatch.<\/p>\n\n\n\n<p>Use Azure Firewall Manager when you need <strong>centralized, reusable, governable firewall policy<\/strong> across multiple VNets, hubs, subscriptions, or regions. Next, deepen your skills by learning Azure Firewall Policy design, logging with Azure Monitor\/Log Analytics, and\u2014if needed\u2014Virtual WAN secured hub architectures on Microsoft Learn: https:\/\/learn.microsoft.com\/azure\/firewall-manager\/.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Networking<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[40,50,10],"tags":[],"class_list":["post-502","post","type-post","status-publish","format-standard","hentry","category-azure","category-networking","category-security"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/502","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=502"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/502\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=502"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=502"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=502"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}