{"id":492,"date":"2026-04-14T06:08:13","date_gmt":"2026-04-14T06:08:13","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/azure-firewall-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking\/"},"modified":"2026-04-14T06:08:13","modified_gmt":"2026-04-14T06:08:13","slug":"azure-firewall-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/azure-firewall-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking\/","title":{"rendered":"Azure Firewall 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 is Microsoft Azure\u2019s managed, cloud-native, stateful network firewall service used to control and inspect traffic flowing between your Azure virtual networks (VNets), the internet, on-premises networks, and other Azure services. It provides centralized traffic filtering, logging, and policy management without requiring you to deploy and maintain your own firewall virtual machines.<\/p>\n\n\n\n<p>In simple terms: <strong>Azure Firewall sits in the middle of your network paths and enforces \u201callow\/deny\u201d rules<\/strong> (plus advanced inspection features in higher tiers) so workloads can only talk to what they\u2019re supposed to talk to. It is commonly used for <strong>egress control<\/strong> (restricting outbound internet access), <strong>ingress publishing<\/strong> (DNAT), and <strong>east\u2013west inspection<\/strong> (traffic between subnets\/VNets).<\/p>\n\n\n\n<p>Technically, Azure Firewall is a <strong>managed stateful firewall-as-a-service<\/strong> that you deploy into a dedicated subnet (for VNet deployments) or into an Azure Virtual WAN Secure Hub (for hub-based deployments). Traffic is routed to the firewall using <strong>User Defined Routes (UDRs)<\/strong> or Virtual WAN routing so the firewall can apply <strong>network rules<\/strong>, <strong>application (FQDN) rules<\/strong>, and <strong>NAT rules<\/strong>, and emit detailed logs to Azure Monitor \/ Log Analytics \/ Microsoft Sentinel.<\/p>\n\n\n\n<p>Azure Firewall solves the problem of <strong>consistent, auditable, scalable network security enforcement<\/strong> across Azure environments\u2014especially when many applications, teams, and networks share the same platform and you need centralized control, visibility, and change governance.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Azure Firewall?<\/h2>\n\n\n\n<p><strong>Official purpose (what it\u2019s for)<\/strong><br\/>\nAzure Firewall is a managed network security service that provides <strong>stateful traffic filtering<\/strong> and <strong>threat protection<\/strong> for Azure VNets and hybrid connectivity. It is designed to enforce centralized network and application connectivity policies and provide visibility through logging and metrics.<\/p>\n\n\n\n<p><strong>Core capabilities (what it can do)<\/strong><br\/>\nAt a high level, Azure Firewall provides:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Stateful L3\u2013L4 filtering<\/strong> (IP addresses, ports, protocols) via <em>Network rules<\/em><\/li>\n<li><strong>Stateful L7 filtering for HTTP\/S<\/strong> and some application scenarios via <em>Application rules<\/em> (FQDN-based)<\/li>\n<li><strong>Inbound and outbound NAT<\/strong> (commonly DNAT publishing) via <em>NAT rules<\/em><\/li>\n<li><strong>Threat intelligence-based filtering<\/strong> (known malicious IPs\/domains, depending on configuration)<\/li>\n<li><strong>Centralized logging and metrics<\/strong> through Azure Monitor diagnostic logs<\/li>\n<li><strong>Policy-based management<\/strong> with Azure Firewall Policy and Azure Firewall Manager<\/li>\n<li><strong>Premium tier capabilities<\/strong> such as TLS inspection and IDPS (verify exact feature availability by tier in official docs)<\/li>\n<\/ul>\n\n\n\n<p><strong>Major components (how it\u2019s packaged and managed)<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Azure Firewall resource<\/strong>: The firewall instance deployed into a VNet (or into a Secure Hub in Virtual WAN).<\/li>\n<li><strong>Azure Firewall Policy<\/strong>: The recommended, modern configuration model that stores rules and settings separately from the firewall instance. Policies can be reused across multiple firewalls.<\/li>\n<li><strong>Rule Collection Groups<\/strong> within a policy: Logical containers for rule collections (Application \/ Network \/ NAT) with priorities.<\/li>\n<li><strong>Firewall Subnet<\/strong>: A dedicated subnet named <strong><code>AzureFirewallSubnet<\/code><\/strong> required for VNet deployments.<\/li>\n<li><strong>Public IP address(es)<\/strong>: Used for inbound publishing and\/or outbound SNAT (depending on design).<\/li>\n<li><strong>Routing<\/strong>: UDRs (route tables) or Virtual WAN routing that forces traffic through the firewall.<\/li>\n<li><strong>Logging destinations<\/strong>: Log Analytics workspace, Event Hubs, or Storage (via diagnostic settings).<\/li>\n<\/ul>\n\n\n\n<p><strong>Service type<\/strong><br\/>\nManaged <strong>PaaS<\/strong> firewall service (not a VM you manage). Microsoft operates the underlying compute, scaling, and availability.<\/p>\n\n\n\n<p><strong>Regional \/ global \/ scope<\/strong><br\/>\nAzure Firewall is primarily a <strong>regional<\/strong> resource. You deploy it into a specific Azure region (and optionally across <strong>Availability Zones<\/strong> where supported). It is created inside a subscription\/resource group and attached to a VNet (VNet deployment) or Secure Hub (Virtual WAN deployment). Policies can be centrally managed and associated across multiple instances.<\/p>\n\n\n\n<p><strong>How it fits into the Azure ecosystem<\/strong><br\/>\nAzure Firewall is part of Azure\u2019s Networking and Security toolchain and commonly integrates with:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>VNets, subnets, peering<\/strong><\/li>\n<li><strong>Azure Virtual WAN<\/strong> (Secure Hub)<\/li>\n<li><strong>Azure Firewall Manager<\/strong> (central management and secured virtual hubs)<\/li>\n<li><strong>Azure Monitor + Log Analytics<\/strong>, <strong>Microsoft Sentinel<\/strong><\/li>\n<li><strong>Azure Bastion<\/strong>, <strong>VPN Gateway<\/strong>, <strong>ExpressRoute<\/strong><\/li>\n<li><strong>Azure Policy<\/strong> (governance), <strong>RBAC<\/strong> (access control)<\/li>\n<li><strong>Application Gateway \/ Front Door<\/strong> (for L7 inbound publishing patterns\u2014these are complementary, not replacements)<\/li>\n<\/ul>\n\n\n\n<blockquote>\n<p>Service naming status: <strong>\u201cAzure Firewall\u201d is the current, active product name<\/strong>. It includes multiple tiers (commonly referred to as Basic\/Standard\/Premium). Always verify current tier names and capabilities in official documentation because feature matrices evolve.<\/p>\n<\/blockquote>\n\n\n\n<p>Official docs landing page: https:\/\/learn.microsoft.com\/azure\/firewall\/<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Azure 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>Centralized control<\/strong>: One set of policies can govern many applications and subnets, reducing inconsistent ad-hoc rules.<\/li>\n<li><strong>Faster security approvals<\/strong>: Standardized policy objects and logging help satisfy audit and compliance needs.<\/li>\n<li><strong>Reduced operational overhead<\/strong>: You avoid patching and maintaining firewall VM appliances.<\/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>Stateful inspection<\/strong>: Return traffic is automatically allowed for permitted flows.<\/li>\n<li><strong>Network + application filtering<\/strong>: Combine IP\/port rules with FQDN-based rules for outbound HTTP\/S.<\/li>\n<li><strong>Hybrid-ready<\/strong>: Works in hub-and-spoke and hybrid designs with VPN\/ExpressRoute.<\/li>\n<li><strong>Integration-friendly<\/strong>: Built for Azure routing, monitoring, and policy-based management.<\/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>Built-in high availability<\/strong>: No manual clustering for typical deployments.<\/li>\n<li><strong>Auto scaling<\/strong>: Designed to scale with traffic patterns (architecture-dependent; verify throughput guidance in official docs).<\/li>\n<li><strong>Central logging<\/strong>: Diagnostic logs integrate directly with Azure Monitor tooling.<\/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>Consistent enforcement point<\/strong>: Helps implement network segmentation, egress control, and controlled inbound publishing.<\/li>\n<li><strong>Threat intelligence<\/strong>: Can alert\/deny traffic to\/from known malicious endpoints (depending on configuration).<\/li>\n<li><strong>Auditability<\/strong>: Structured logs can support investigations and compliance reporting.<\/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 model<\/strong>: Better fit than self-managed NVAs when teams don\u2019t want to size\/scale VMs.<\/li>\n<li><strong>Zonal deployment options<\/strong>: Where supported, can improve resiliency with zone redundancy.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose Azure Firewall<\/h3>\n\n\n\n<p>Choose Azure Firewall when you need:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Centralized <strong>egress filtering<\/strong> from multiple subnets\/VNets<\/li>\n<li>A consistent, managed firewall control plane with <strong>logging<\/strong><\/li>\n<li>A hub-and-spoke security boundary in Azure<\/li>\n<li>A straightforward way to publish inbound services via DNAT (when appropriate)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose Azure Firewall<\/h3>\n\n\n\n<p>Avoid or reconsider Azure Firewall if:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You only need <strong>basic subnet-level filtering<\/strong>: Network Security Groups (NSGs) may be enough.<\/li>\n<li>You need a dedicated <strong>web application firewall (WAF)<\/strong> for HTTP inbound protection: Use Application Gateway WAF or Azure Front Door WAF.<\/li>\n<li>You need <strong>very vendor-specific NGFW features<\/strong> not available in Azure Firewall tiers: consider third-party NVAs (Palo Alto, Fortinet, Check Point) in Azure Marketplace.<\/li>\n<li>You cannot route traffic through a centralized point due to latency, asymmetric routing, or application constraints (you may need distributed controls plus NSGs).<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Azure Firewall used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Finance and insurance (regulated environments, strong egress control)<\/li>\n<li>Healthcare (auditability and controlled outbound access)<\/li>\n<li>Retail and e-commerce (segmentation between tiers and partner systems)<\/li>\n<li>Manufacturing\/IoT (hybrid connectivity, controlled internet access)<\/li>\n<li>Government (policy enforcement and monitoring)<\/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 \/ cloud center of excellence (CCoE)<\/li>\n<li>Network engineering teams migrating hub-and-spoke to Azure<\/li>\n<li>Security engineering teams implementing central egress controls<\/li>\n<li>SRE\/operations teams needing consistent logging and incident response<\/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>VM-based enterprise applications (Windows\/Linux)<\/li>\n<li>AKS clusters (commonly for egress control; design carefully)<\/li>\n<li>PaaS workloads accessed privately (via private endpoints and routing patterns)<\/li>\n<li>Shared services (jump boxes, patch servers, update repositories)<\/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 firewall in the hub<\/li>\n<li>Virtual WAN Secure Hub with centrally managed security<\/li>\n<li>Multi-subscription landing zones with shared policy<\/li>\n<li>Hybrid networks with on-premises + Azure interconnect<\/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>: Most common\u2014central egress\/ingress control, auditing, and standardized governance.<\/li>\n<li><strong>Dev\/test<\/strong>: Often used to mirror production security boundaries or to avoid developers having unrestricted internet egress.<\/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, commonly implemented Azure Firewall scenarios.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Centralized outbound internet access control (egress filtering)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Workloads in multiple subnets have unrestricted internet access.<\/li>\n<li><strong>Why Azure Firewall fits<\/strong>: Application and network rules can restrict outbound destinations; logs provide visibility.<\/li>\n<li><strong>Example<\/strong>: Allow only Microsoft update endpoints and a few SaaS domains; block everything else.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Hub-and-spoke shared firewall for multiple VNets<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Teams run apps in different spokes and need consistent security.<\/li>\n<li><strong>Why it fits<\/strong>: A hub firewall plus UDRs\/peering provides a common inspection point.<\/li>\n<li><strong>Example<\/strong>: Finance, HR, and Engineering VNets route outbound via the hub firewall; each team gets its own policy\/rule group.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Publish an internal service to the internet using DNAT<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You need inbound access to a VM-based app, but want centralized control and logging.<\/li>\n<li><strong>Why it fits<\/strong>: NAT rules can map a firewall public IP\/port to a private IP\/port.<\/li>\n<li><strong>Example<\/strong>: DNAT TCP\/443 from firewall public IP to an internal reverse proxy VM.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Control traffic to partner networks via VPN\/ExpressRoute<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You connect to partner networks and must restrict which subnets can communicate.<\/li>\n<li><strong>Why it fits<\/strong>: Network rules and forced routing can enforce segmentation.<\/li>\n<li><strong>Example<\/strong>: Only the integration subnet can reach partner CIDRs over the VPN.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Segmentation between application tiers (east\u2013west inspection)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You need consistent controls between tiers\/subnets beyond NSGs.<\/li>\n<li><strong>Why it fits<\/strong>: A centralized firewall can enforce \u201conly app tier talks to DB tier on port X\u201d across VNets\/subnets.<\/li>\n<li><strong>Example<\/strong>: Web subnet can reach app subnet on 8443; app subnet can reach DB subnet on 1433.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Threat intelligence-based blocking<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You want a managed way to reduce exposure to known malicious endpoints.<\/li>\n<li><strong>Why it fits<\/strong>: Threat intelligence mode can alert\/deny.<\/li>\n<li><strong>Example<\/strong>: Deny traffic to known botnet destinations while logging events to Sentinel.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Central DNS proxy pattern for controlled name resolution (design-dependent)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You want consistent DNS behavior and improved filtering alignment for FQDN-based controls.<\/li>\n<li><strong>Why it fits<\/strong>: Azure Firewall offers DNS proxy capabilities (verify configuration guidance in official docs).<\/li>\n<li><strong>Example<\/strong>: Spokes use the firewall as DNS proxy, with forwarding to an internal resolver.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Policy standardization across environments (dev\/test\/prod)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Security rules drift between environments.<\/li>\n<li><strong>Why it fits<\/strong>: Azure Firewall Policy can be reused; changes can be managed via IaC and CI\/CD.<\/li>\n<li><strong>Example<\/strong>: A baseline policy is shared across dev\/prod with environment-specific rule collection groups.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Secure Azure Virtual WAN hub for distributed branches<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Many branches connect through Virtual WAN and need central security inspection.<\/li>\n<li><strong>Why it fits<\/strong>: Azure Firewall can be deployed in Secure Hub and managed centrally.<\/li>\n<li><strong>Example<\/strong>: Branch-to-Azure traffic is inspected; specific SaaS endpoints are allowed.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Logging and incident response for network flows<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You need to answer \u201cwho talked to what\u201d during an incident.<\/li>\n<li><strong>Why it fits<\/strong>: Firewall logs (application\/network\/NAT\/threat intel) provide a central data source.<\/li>\n<li><strong>Example<\/strong>: Sentinel alerts on unusual outbound destinations, analysts pivot via firewall logs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Restrict admin access paths (jump-host alternatives)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Admins need access to servers, but inbound rules are messy and risky.<\/li>\n<li><strong>Why it fits<\/strong>: Combine firewall DNAT (or private access paths) with logging and strict rules; often used with Bastion\/VPN.<\/li>\n<li><strong>Example<\/strong>: Only a management subnet can reach RDP\/SSH targets; all access is logged.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Controlled outbound for build agents and CI\/CD runners<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Build agents can exfiltrate data or pull from untrusted sources.<\/li>\n<li><strong>Why it fits<\/strong>: Restrict outbound to approved artifact repos and package registries.<\/li>\n<li><strong>Example<\/strong>: Allow access only to Azure DevOps, GitHub Enterprise, and approved package mirrors.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<p>Feature availability can depend on SKU\/tier (Basic\/Standard\/Premium) and deployment model (VNet vs Virtual WAN). Always verify the current feature matrix in official docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">6.1 Stateful firewalling (L3\/L4)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Filters traffic by source\/destination IP, port, and protocol; tracks connection state.<\/li>\n<li><strong>Why it matters<\/strong>: Simplifies rules (return traffic allowed automatically) and reduces misconfiguration risk.<\/li>\n<li><strong>Practical benefit<\/strong>: Replace many distributed \u201callow return\u201d rules in NSGs with centralized stateful inspection.<\/li>\n<li><strong>Caveats<\/strong>: Requires correct routing so traffic actually passes through the firewall.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.2 Application rules (L7 \/ FQDN filtering for HTTP\/S)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Allows\/denies outbound access based on FQDN for HTTP and HTTPS (and some additional protocol handling depending on tier\/features).<\/li>\n<li><strong>Why it matters<\/strong>: IP-based allowlists for SaaS are brittle; FQDN rules are more maintainable.<\/li>\n<li><strong>Practical benefit<\/strong>: Allow <code>*.microsoft.com<\/code> (example) while blocking the rest of the internet.<\/li>\n<li><strong>Caveats<\/strong>: Enforcing FQDN rules depends on protocol behavior (HTTP Host header \/ TLS SNI). Non-HTTP\/S scenarios may require different approaches.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.3 NAT rules (DNAT\/SNAT behavior)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Publishes internal services via DNAT and provides outbound SNAT using firewall public IP(s).<\/li>\n<li><strong>Why it matters<\/strong>: Enables controlled inbound publishing and consistent outbound public IP identity.<\/li>\n<li><strong>Practical benefit<\/strong>: A partner allowlists your outbound IPs; you provide firewall public IPs.<\/li>\n<li><strong>Caveats<\/strong>: Inbound publishing for web apps often fits better with Application Gateway or Front Door plus WAF; use DNAT thoughtfully.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.4 Threat intelligence-based filtering<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Uses Microsoft threat intelligence to alert and\/or deny traffic involving known malicious IPs\/domains (based on mode).<\/li>\n<li><strong>Why it matters<\/strong>: Adds a managed security layer without maintaining your own blocklists.<\/li>\n<li><strong>Practical benefit<\/strong>: Reduce exposure to common malicious destinations.<\/li>\n<li><strong>Caveats<\/strong>: Not a replacement for endpoint protection, EDR, or comprehensive threat hunting.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.5 Azure Firewall Policy (recommended management model)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Separates rules\/configuration from the firewall instance; supports reuse and central governance.<\/li>\n<li><strong>Why it matters<\/strong>: Improves change control, consistency, and multi-firewall management.<\/li>\n<li><strong>Practical benefit<\/strong>: Apply one baseline policy to multiple firewalls across subscriptions (with the right RBAC).<\/li>\n<li><strong>Caveats<\/strong>: Ensure you understand rule priorities and policy inheritance (if using parent\/child policies\u2014verify in docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.6 Azure Firewall Manager (centralized management at scale)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Provides centralized management for Azure Firewall instances and secured virtual hubs.<\/li>\n<li><strong>Why it matters<\/strong>: Needed for larger estates using hub-and-spoke and Virtual WAN patterns.<\/li>\n<li><strong>Practical benefit<\/strong>: Central deployment, routing intent (Virtual WAN), and policy association.<\/li>\n<li><strong>Caveats<\/strong>: Introduces additional design choices; confirm requirements for Virtual WAN secured hubs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.7 Diagnostics: logs and metrics (Azure Monitor)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Emits structured logs for application\/network\/NAT\/threat intel events and exposes metrics.<\/li>\n<li><strong>Why it matters<\/strong>: Operational visibility, auditing, troubleshooting, and incident response.<\/li>\n<li><strong>Practical benefit<\/strong>: Query \u201cwhat was blocked and why\u201d in Log Analytics; alert on patterns.<\/li>\n<li><strong>Caveats<\/strong>: Logs cost money (Log Analytics ingestion\/retention). Plan retention and sampling.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.8 Availability and resiliency options<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Provides a managed HA service; can be deployed with zone redundancy in supported regions.<\/li>\n<li><strong>Why it matters<\/strong>: Firewalls are critical path; downtime affects many workloads.<\/li>\n<li><strong>Practical benefit<\/strong>: Avoid building your own active\/active cluster with NVAs.<\/li>\n<li><strong>Caveats<\/strong>: Zone support varies by region\/SKU\u2014verify in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.9 DNS proxy capability (scenario-dependent)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Allows clients to use the firewall as a DNS proxy (forwarding queries onward).<\/li>\n<li><strong>Why it matters<\/strong>: Can simplify DNS pathing for some inspection and resolution designs.<\/li>\n<li><strong>Practical benefit<\/strong>: Centralize DNS forwarding behavior in certain hub designs.<\/li>\n<li><strong>Caveats<\/strong>: DNS design is easy to break; validate resolution paths, conditional forwarders, and private DNS requirements.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.10 Premium features (examples: TLS inspection, IDPS)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Premium tier adds deeper inspection such as TLS inspection and intrusion detection and prevention (feature set evolves).<\/li>\n<li><strong>Why it matters<\/strong>: Supports stricter security requirements where L7 visibility and signatures are required.<\/li>\n<li><strong>Practical benefit<\/strong>: Detect\/stop known exploit patterns, inspect encrypted outbound traffic (where lawful\/appropriate).<\/li>\n<li><strong>Caveats<\/strong>: TLS inspection requires certificate\/key management and has privacy\/compliance implications. Performance and troubleshooting complexity increase.<\/li>\n<\/ul>\n\n\n\n<p>Official overview and features: https:\/\/learn.microsoft.com\/azure\/firewall\/overview<\/p>\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\">7.1 High-level architecture<\/h3>\n\n\n\n<p>Azure Firewall is typically deployed in one of two ways:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>VNet deployment (hub firewall)<\/strong><br\/>\n   &#8211; Azure Firewall lives in a hub VNet in a dedicated subnet (<code>AzureFirewallSubnet<\/code>).\n   &#8211; Spoke VNets peer to the hub.\n   &#8211; Spoke subnets use UDRs to force traffic (0.0.0.0\/0, RFC1918, or specific prefixes) to the firewall private IP.<\/p>\n<\/li>\n<li>\n<p><strong>Virtual WAN Secure Hub deployment<\/strong><br\/>\n   &#8211; Azure Firewall is deployed into a Virtual WAN hub as a secured hub.\n   &#8211; Routing and security policy are managed through Azure Firewall Manager and Virtual WAN constructs.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<p>This tutorial focuses on the <strong>VNet deployment<\/strong> because it\u2019s easiest to learn and validate in a small lab.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">7.2 Data flow (request path)<\/h3>\n\n\n\n<p>A typical egress flow looks like:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>A workload (VM\/AKS node\/app) sends traffic to an internet destination.<\/li>\n<li>A <strong>UDR<\/strong> on the workload subnet sends 0.0.0.0\/0 to <strong>Next hop: Virtual appliance<\/strong> = Azure Firewall private IP.<\/li>\n<li>Azure Firewall evaluates rules:\n   &#8211; Application rules for HTTP\/S by FQDN\n   &#8211; Network rules for IP\/port\/protocol\n   &#8211; Threat intelligence filtering (if enabled)<\/li>\n<li>If allowed, Azure Firewall performs SNAT (as needed) using its public IP and forwards traffic to the destination.<\/li>\n<li>Logs are written to Azure Monitor via diagnostic settings.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">7.3 Control plane vs data plane<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control plane<\/strong>: Azure Resource Manager (ARM), Firewall Policy, RBAC, Firewall Manager. This is how you configure the firewall.<\/li>\n<li><strong>Data plane<\/strong>: The actual packet\/flow processing, NAT, inspection, and logging.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7.4 Integrations and dependencies<\/h3>\n\n\n\n<p>Common dependencies and integrations:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Route tables (UDRs)<\/strong>: Required to steer traffic.<\/li>\n<li><strong>Public IP<\/strong>: Required for outbound SNAT and inbound DNAT patterns.<\/li>\n<li><strong>Log Analytics \/ Azure Monitor<\/strong>: For logs, metrics, alerts.<\/li>\n<li><strong>Microsoft Sentinel<\/strong>: For SIEM\/SOAR and detection rules.<\/li>\n<li><strong>Key Vault<\/strong> (often used in Premium TLS inspection scenarios): For certificate lifecycle (verify recommended patterns in docs).<\/li>\n<li><strong>Virtual WAN<\/strong>: Alternative deployment model.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7.5 Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Access to configure Azure Firewall is controlled by <strong>Azure RBAC<\/strong> at subscription\/resource group\/resource scope.<\/li>\n<li>Policy management can be delegated (for example, security team owns policies; platform team owns firewall instances).<\/li>\n<li>Logs and workspaces also have RBAC and may be subject to data access governance.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7.6 Networking model considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Azure Firewall is placed in a dedicated subnet with strict naming requirements (<code>AzureFirewallSubnet<\/code>).<\/li>\n<li>Correct routing is essential:<\/li>\n<li>If traffic is not routed through the firewall, rules do nothing.<\/li>\n<li>Avoid asymmetric routing (return path must also traverse expected route).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7.7 Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable <strong>Diagnostic settings<\/strong> on Azure Firewall to send logs to Log Analytics.<\/li>\n<li>Decide retention based on compliance and cost.<\/li>\n<li>Use Azure Policy to enforce diagnostics and tagging.<\/li>\n<li>Build alert rules around:<\/li>\n<li>Denied traffic spikes<\/li>\n<li>Threat intel hits<\/li>\n<li>Unexpected outbound destinations<\/li>\n<li>DNAT attempts from unknown source IPs<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7.8 Architecture diagrams<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\">Simple learning architecture (single VNet)<\/h4>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  VM[Workload VM\\n(WorkloadSubnet)] --&gt;|UDR 0.0.0.0\/0| AFW[Azure Firewall\\n(AzureFirewallSubnet)]\n  AFW --&gt;|SNAT via Public IP| Internet[(Internet)]\n  AFW --&gt; Logs[Azure Monitor Logs\\n(Log Analytics)]\n<\/code><\/pre>\n\n\n\n<h4 class=\"wp-block-heading\">Production-style hub-and-spoke architecture<\/h4>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  subgraph Spokes[Spoke VNets]\n    S1[Spoke VNet A\\nApp Subnets]\n    S2[Spoke VNet B\\nData Subnets]\n    S3[Spoke VNet C\\nShared Services]\n  end\n\n  subgraph Hub[Hub VNet]\n    AFW2[Azure Firewall\\nAzureFirewallSubnet]\n    MGMT[Management Subnet\\n(Bastion\/Jump\/Tools)]\n    GW[VPN\/ExpressRoute Gateway]\n  end\n\n  OnPrem[(On-Prem Network)]\n  Internet2[(Internet)]\n  Monitor[Azure Monitor \/ Log Analytics]\n  Sentinel[Microsoft Sentinel]\n\n  S1 --&gt;|UDR to Firewall| AFW2\n  S2 --&gt;|UDR to Firewall| AFW2\n  S3 --&gt;|UDR to Firewall| AFW2\n\n  AFW2 --&gt;|Egress SNAT| Internet2\n  AFW2 --&gt;|Hybrid routes| GW --&gt; OnPrem\n\n  AFW2 --&gt; Monitor --&gt; Sentinel\n\n  S1 -.VNet Peering.- Hub\n  S2 -.VNet Peering.- Hub\n  S3 -.VNet Peering.- Hub\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Azure account and subscription<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>An active <strong>Azure subscription<\/strong> with permission to create:<\/li>\n<li>Resource groups<\/li>\n<li>VNets\/subnets, route tables, public IPs<\/li>\n<li>Azure Firewall and Firewall Policy<\/li>\n<li>Virtual machines (for validation)<\/li>\n<li>Log Analytics workspace (optional but recommended)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM roles<\/h3>\n\n\n\n<p>At minimum (depending on how your org scopes roles), you typically need:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Contributor<\/strong> on the resource group (or higher) to deploy resources<\/li>\n<li><strong>Network Contributor<\/strong> for networking resources<\/li>\n<li><strong>Log Analytics Contributor<\/strong> (or appropriate workspace permissions) if enabling diagnostics to Log Analytics<\/li>\n<\/ul>\n\n\n\n<p>In regulated environments, security teams may own firewall policies; coordinate RBAC accordingly.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<p>Azure Firewall is a paid service. Ensure:\n&#8211; Your subscription has billing enabled.\n&#8211; You understand that Azure Firewall costs accrue while it exists, plus data processing and logging charges.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Tools<\/h3>\n\n\n\n<p>Choose one:\n&#8211; Azure Portal (browser)\n&#8211; Azure CLI (optional but useful): https:\/\/learn.microsoft.com\/cli\/azure\/install-azure-cli\n&#8211; Azure Cloud Shell (no install): https:\/\/learn.microsoft.com\/azure\/cloud-shell\/overview<\/p>\n\n\n\n<p>This tutorial uses <strong>Azure Cloud Shell + Azure Portal<\/strong> for clarity and reliability.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<p>Azure Firewall is available in many Azure regions, but <strong>features and zone support vary<\/strong>. Verify:\n&#8211; Azure Firewall availability: https:\/\/azure.microsoft.com\/products\/azure-firewall\/ (then cross-check docs)\n&#8211; Zone support and SKU availability: verify in official docs for your chosen region.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<p>Azure Firewall has documented limits (rules, IP configurations, etc.). Before production design, review:\n&#8211; Azure Firewall limits: https:\/\/learn.microsoft.com\/azure\/firewall\/firewall-limits<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services (for this lab)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Virtual Network with:<\/li>\n<li><code>AzureFirewallSubnet<\/code><\/li>\n<li>A workload subnet<\/li>\n<li>Public IP (for the firewall)<\/li>\n<li>A VM for traffic generation\/validation (Ubuntu)<\/li>\n<li>Route table (UDR)<\/li>\n<li>(Recommended) Log Analytics workspace for diagnostics<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<p>Azure Firewall pricing is <strong>usage-based<\/strong> and varies by:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>SKU\/tier<\/strong> (commonly Basic\/Standard\/Premium)<\/li>\n<li><strong>Region<\/strong><\/li>\n<li><strong>Deployment model<\/strong> (VNet vs Virtual WAN)<\/li>\n<li><strong>Data processed<\/strong> volume<\/li>\n<\/ul>\n\n\n\n<p>You should always confirm current pricing on the official pricing page and calculator:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Official pricing page: https:\/\/azure.microsoft.com\/pricing\/details\/azure-firewall\/<\/li>\n<li>Azure Pricing Calculator: https:\/\/azure.microsoft.com\/pricing\/calculator\/<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9.1 Pricing dimensions (how you\u2019re charged)<\/h3>\n\n\n\n<p>Common pricing components include:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>Firewall instance charge (per hour)<\/strong><br\/>\n   You pay for the firewall resource while it is provisioned.<\/p>\n<\/li>\n<li>\n<p><strong>Data processed (per GB)<\/strong><br\/>\n   Traffic processed through the firewall incurs a per-GB charge.<\/p>\n<\/li>\n<li>\n<p><strong>Premium add-ons (if applicable)<\/strong><br\/>\n   Premium tier typically costs more per hour and\/or per GB due to deeper inspection features.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<blockquote>\n<p>Exact rates vary by region and tier\u2014do not hardcode numbers. Use the official pricing page for your region.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">9.2 Free tier<\/h3>\n\n\n\n<p>Azure Firewall generally <strong>does not have a free tier<\/strong>. Some related services (like Azure Monitor free allocations) may have limited free quotas, but Azure Firewall itself is a paid service.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">9.3 Key cost drivers<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Hours provisioned<\/strong>: Leaving a firewall running 24\/7 is a steady baseline cost.<\/li>\n<li><strong>Data processed<\/strong>: High-traffic environments can pay significant per-GB charges.<\/li>\n<li><strong>Number of firewalls<\/strong>: Multiple regions or segmented environments increase hourly costs.<\/li>\n<li><strong>Logging volume<\/strong>: Sending verbose logs to Log Analytics increases ingestion and retention costs.<\/li>\n<li><strong>Public IPs<\/strong>: Public IP resources can incur cost (depending on SKU and region).<\/li>\n<li><strong>Egress data transfer<\/strong>: Internet egress bandwidth charges still apply (Azure bandwidth pricing), independent of the firewall.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9.4 Hidden or indirect costs to plan for<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Log Analytics ingestion &amp; retention<\/strong>: Firewall logs can be high volume.<\/li>\n<li><strong>Microsoft Sentinel<\/strong>: If enabled, SIEM costs can be significant.<\/li>\n<li><strong>Operational overhead<\/strong>: Rule management, change reviews, testing pipelines.<\/li>\n<li><strong>Architecture costs<\/strong>: Hub-and-spoke may add VNet peering costs; Virtual WAN has its own pricing model.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9.5 Network\/data transfer implications<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Egress bandwidth charges<\/strong> apply for data leaving Azure regions to the internet.<\/li>\n<li><strong>Inter-region traffic<\/strong> and some peering patterns can incur charges\u2014review Azure bandwidth pricing.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9.6 How to optimize cost (practical guidance)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Right-size tier<\/strong>: Use Standard unless Premium features are required (e.g., TLS inspection\/IDPS). Basic may fit small environments\u2014verify constraints.<\/li>\n<li><strong>Control log volume<\/strong>:<\/li>\n<li>Enable only needed categories initially.<\/li>\n<li>Use reasonable retention.<\/li>\n<li>Consider Event Hub forwarding to cheaper storage\/processing patterns (architecture-dependent).<\/li>\n<li><strong>Reduce processed data<\/strong>:<\/li>\n<li>Don\u2019t hairpin traffic unnecessarily.<\/li>\n<li>Route only required subnets\/prefixes through the firewall.<\/li>\n<li><strong>Design for scale<\/strong>: Avoid unnecessary multi-firewall sprawl; use policy reuse and centralized design where appropriate.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9.7 Example low-cost starter estimate (how to think about it)<\/h3>\n\n\n\n<p>For a small lab:\n&#8211; 1 Azure Firewall instance running for a few hours\n&#8211; Minimal traffic (a few MB\/GB)\n&#8211; Short-lived Log Analytics workspace (optional)<\/p>\n\n\n\n<p>Use the Pricing Calculator with:\n&#8211; Your region\n&#8211; Tier (Standard)\n&#8211; Estimated hours (e.g., 4\u20138 hours)\n&#8211; Estimated data processed (e.g., &lt; 1 GB)\n&#8211; Log Analytics ingestion estimate (small for a lab)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">9.8 Example production cost considerations<\/h3>\n\n\n\n<p>In production, model:\n&#8211; 24\/7 hourly cost per region\n&#8211; Peak\/average data processed per day\/month\n&#8211; Expected logging volume (blocked traffic can generate lots of logs)\n&#8211; Retention requirements (30\/90\/180\/365 days)\n&#8211; Sentinel enablement and analytics rules\n&#8211; Additional hubs\/regions for DR<\/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 creates a small Azure environment where a VM\u2019s outbound internet access is forced through Azure Firewall. You\u2019ll configure an <strong>allow-only<\/strong> application rule (allow Microsoft\u2019s website) and verify that other sites are blocked by default.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Deploy <strong>Azure Firewall (Standard)<\/strong> with an <strong>Azure Firewall Policy<\/strong>, route a workload subnet through it, and enforce <strong>FQDN-based outbound control<\/strong> with logging.<\/p>\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>Resource group: <code>rg-afw-lab<\/code><\/li>\n<li>VNet: <code>vnet-afw-lab<\/code> (<code>10.10.0.0\/16<\/code>)<\/li>\n<li>Subnet <code>AzureFirewallSubnet<\/code> (<code>10.10.0.0\/26<\/code>)<\/li>\n<li>Subnet <code>WorkloadSubnet<\/code> (<code>10.10.1.0\/24<\/code>)<\/li>\n<li>Azure Firewall + Public IP<\/li>\n<li>Firewall Policy with an application rule: <strong>Allow <code>www.microsoft.com<\/code><\/strong><\/li>\n<li>Route table forcing <code>WorkloadSubnet<\/code> egress to firewall<\/li>\n<li>Ubuntu VM with <strong>no public IP<\/strong><\/li>\n<li>Validation using <strong>Run Command<\/strong> (no bastion needed)<\/li>\n<li>Optional: Log Analytics workspace + diagnostics<\/li>\n<\/ul>\n\n\n\n<blockquote>\n<p>Cost note: Azure Firewall is not \u201cmicro-cost.\u201d Do this lab in a non-production subscription and <strong>clean up<\/strong> afterward.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Create a resource group and choose a region<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Open <strong>Azure Cloud Shell<\/strong> (Bash): https:\/\/learn.microsoft.com\/azure\/cloud-shell\/overview<\/li>\n<li>Set variables (choose a region that supports Azure Firewall in your subscription):<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">RG=\"rg-afw-lab\"\nLOC=\"eastus\"   # change if needed\n<\/code><\/pre>\n\n\n\n<ol class=\"wp-block-list\" start=\"3\">\n<li>Create the resource group:<\/li>\n<\/ol>\n\n\n\n<pre><code class=\"language-bash\">az group create --name \"$RG\" --location \"$LOC\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Resource group <code>rg-afw-lab<\/code> exists.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create the VNet and subnets (including AzureFirewallSubnet)<\/h3>\n\n\n\n<p>Create the VNet and subnets:<\/p>\n\n\n\n<pre><code class=\"language-bash\">VNET=\"vnet-afw-lab\"\n\naz network vnet create \\\n  --resource-group \"$RG\" \\\n  --name \"$VNET\" \\\n  --address-prefixes 10.10.0.0\/16 \\\n  --subnet-name WorkloadSubnet \\\n  --subnet-prefixes 10.10.1.0\/24\n<\/code><\/pre>\n\n\n\n<p>Now create the required firewall subnet <strong>with the exact name<\/strong> <code>AzureFirewallSubnet<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network vnet subnet create \\\n  --resource-group \"$RG\" \\\n  --vnet-name \"$VNET\" \\\n  --name AzureFirewallSubnet \\\n  --address-prefixes 10.10.0.0\/26\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> VNet has two subnets: <code>WorkloadSubnet<\/code> and <code>AzureFirewallSubnet<\/code>.<\/p>\n\n\n\n<p><strong>Verification:<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">az network vnet subnet list --resource-group \"$RG\" --vnet-name \"$VNET\" -o table\n<\/code><\/pre>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create a public IP for Azure Firewall<\/h3>\n\n\n\n<p>Create a Standard public IP (zone settings can vary; keep it simple for labs):<\/p>\n\n\n\n<pre><code class=\"language-bash\">PIP=\"pip-afw-lab\"\n\naz network public-ip create \\\n  --resource-group \"$RG\" \\\n  --name \"$PIP\" \\\n  --sku Standard \\\n  --allocation-method Static\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> A static Standard public IP is created.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Create an Azure Firewall Policy<\/h3>\n\n\n\n<p>Create a firewall policy:<\/p>\n\n\n\n<pre><code class=\"language-bash\">POLICY=\"afwpol-lab\"\n\naz network firewall policy create \\\n  --resource-group \"$RG\" \\\n  --name \"$POLICY\" \\\n  --location \"$LOC\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> An Azure Firewall Policy exists and is ready to receive rule collection groups.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Deploy Azure Firewall into the VNet and attach the policy<\/h3>\n\n\n\n<p>Create the Azure Firewall instance:<\/p>\n\n\n\n<pre><code class=\"language-bash\">AFW=\"afw-lab\"\n\naz network firewall create \\\n  --resource-group \"$RG\" \\\n  --name \"$AFW\" \\\n  --location \"$LOC\" \\\n  --sku AZFW_VNet \\\n  --tier Standard \\\n  --firewall-policy \"$POLICY\"\n<\/code><\/pre>\n\n\n\n<p>Attach an IP configuration (bind firewall to VNet and public IP). This step can take time:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network firewall ip-config create \\\n  --resource-group \"$RG\" \\\n  --firewall-name \"$AFW\" \\\n  --name \"ipconfig1\" \\\n  --public-ip-address \"$PIP\" \\\n  --vnet-name \"$VNET\"\n<\/code><\/pre>\n\n\n\n<p>Get the firewall private IP:<\/p>\n\n\n\n<pre><code class=\"language-bash\">FW_PRIVATE_IP=$(az network firewall show \\\n  --resource-group \"$RG\" \\\n  --name \"$AFW\" \\\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> Azure Firewall is deployed and has a private IP in <code>AzureFirewallSubnet<\/code>.<\/p>\n\n\n\n<p><strong>Common issue:<\/strong> If firewall deployment fails, confirm:\n&#8211; Subnet name is exactly <code>AzureFirewallSubnet<\/code>\n&#8211; Address space is large enough for the firewall subnet\n&#8211; The region supports the selected tier<br\/>\nIf unsure, verify in official docs: https:\/\/learn.microsoft.com\/azure\/firewall\/<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Create a rule collection group to allow only <code>www.microsoft.com<\/code> (outbound)<\/h3>\n\n\n\n<p>Azure Firewall Policy uses <strong>rule collection groups<\/strong>. Create one with an <strong>application rule collection<\/strong>.<\/p>\n\n\n\n<blockquote>\n<p>Note: Azure Firewall\u2019s default behavior is deny if there\u2019s no matching allow rule (given typical rule design). You will explicitly allow <code>www.microsoft.com<\/code> and then test that other sites are blocked.<\/p>\n<\/blockquote>\n\n\n\n<p>Create the rule collection group:<\/p>\n\n\n\n<pre><code class=\"language-bash\">RCG=\"rcg-app-egress\"\nPRIORITY=100\n\naz network firewall policy rule-collection-group create \\\n  --resource-group \"$RG\" \\\n  --policy-name \"$POLICY\" \\\n  --name \"$RCG\" \\\n  --priority \"$PRIORITY\"\n<\/code><\/pre>\n\n\n\n<p>Add an application rule collection with a single allow rule for HTTPS to <code>www.microsoft.com<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network firewall policy rule-collection-group collection add-filter-collection \\\n  --resource-group \"$RG\" \\\n  --policy-name \"$POLICY\" \\\n  --rule-collection-group-name \"$RCG\" \\\n  --name \"app-allow-microsoft\" \\\n  --collection-priority 100 \\\n  --action Allow \\\n  --rule-name \"allow-msft-web\" \\\n  --rule-type ApplicationRule \\\n  --protocols Https=443 \\\n  --source-addresses 10.10.1.0\/24 \\\n  --target-fqdns \"www.microsoft.com\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Policy has an application rule allowing HTTPS from <code>WorkloadSubnet<\/code> to <code>www.microsoft.com<\/code>.<\/p>\n\n\n\n<p><strong>Verification idea (optional):<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">az network firewall policy rule-collection-group show \\\n  --resource-group \"$RG\" \\\n  --policy-name \"$POLICY\" \\\n  --name \"$RCG\" \\\n  --query \"ruleCollections[].name\" -o tsv\n<\/code><\/pre>\n\n\n\n<p>If CLI syntax differs due to version changes, <strong>use Azure Portal<\/strong>:\n&#8211; Firewall Policy \u2192 Rule collection groups \u2192 Add application rule collection \u2192 Add rule<br\/>\n(And <strong>verify in official docs<\/strong> for current portal steps.)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Create a route table to force outbound traffic through the firewall<\/h3>\n\n\n\n<p>Create a route table:<\/p>\n\n\n\n<pre><code class=\"language-bash\">RT=\"rt-workload-egress\"\n\naz network route-table create \\\n  --resource-group \"$RG\" \\\n  --name \"$RT\" \\\n  --location \"$LOC\"\n<\/code><\/pre>\n\n\n\n<p>Add 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  --resource-group \"$RG\" \\\n  --route-table-name \"$RT\" \\\n  --name \"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>Associate the route table to <code>WorkloadSubnet<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network vnet subnet update \\\n  --resource-group \"$RG\" \\\n  --vnet-name \"$VNET\" \\\n  --name WorkloadSubnet \\\n  --route-table \"$RT\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Any VM in <code>WorkloadSubnet<\/code> sends internet-bound traffic to Azure Firewall.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 8: Deploy a test VM with no public IP<\/h3>\n\n\n\n<p>Create an Ubuntu VM in the workload subnet without a public IP. Use SSH keys (Cloud Shell can generate them).<\/p>\n\n\n\n<pre><code class=\"language-bash\">VM=\"vm-workload-01\"\n\naz vm create \\\n  --resource-group \"$RG\" \\\n  --name \"$VM\" \\\n  --image Ubuntu2204 \\\n  --vnet-name \"$VNET\" \\\n  --subnet WorkloadSubnet \\\n  --public-ip-address \"\" \\\n  --admin-username azureuser \\\n  --generate-ssh-keys\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> VM is created, but it is not directly reachable from the internet.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 9: Validate outbound access (allowed vs blocked) using Run Command<\/h3>\n\n\n\n<p>Use Run Command to execute curl from inside the VM.<\/p>\n\n\n\n<p>1) Test the allowed destination:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az vm run-command invoke \\\n  --resource-group \"$RG\" \\\n  --name \"$VM\" \\\n  --command-id RunShellScript \\\n  --scripts \"set -e; echo 'Testing allowed site...'; curl -I https:\/\/www.microsoft.com | head -n 5\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> You should see an HTTP response header (e.g., <code>HTTP\/2 200<\/code> or a redirect like <code>301\/302<\/code>).<\/p>\n\n\n\n<p>2) Test a blocked destination (not in your allowlist), e.g. Google:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az vm run-command invoke \\\n  --resource-group \"$RG\" \\\n  --name \"$VM\" \\\n  --command-id RunShellScript \\\n  --scripts \"echo 'Testing blocked site...'; timeout 10 curl -I https:\/\/www.google.com || echo 'Blocked (expected)'\"\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> The request should fail (timeout\/connection error) and print <code>Blocked (expected)<\/code>.<\/p>\n\n\n\n<blockquote>\n<p>If Google still works, your traffic may not be traversing the firewall (routing issue) or you may have other allow rules. Re-check the route table association and firewall policy.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 10 (Recommended): Enable diagnostics to Log Analytics and query denies<\/h3>\n\n\n\n<p>Create a Log Analytics workspace:<\/p>\n\n\n\n<pre><code class=\"language-bash\">LAW=\"law-afw-lab\"\n\naz monitor log-analytics workspace create \\\n  --resource-group \"$RG\" \\\n  --workspace-name \"$LAW\" \\\n  --location \"$LOC\"\n<\/code><\/pre>\n\n\n\n<p>Get workspace resource ID:<\/p>\n\n\n\n<pre><code class=\"language-bash\">LAW_ID=$(az monitor log-analytics workspace show \\\n  --resource-group \"$RG\" \\\n  --workspace-name \"$LAW\" \\\n  --query id -o tsv)\n\necho \"$LAW_ID\"\n<\/code><\/pre>\n\n\n\n<p>Enable diagnostics on Azure Firewall (log categories can change; verify in docs if needed):<\/p>\n\n\n\n<pre><code class=\"language-bash\">AFW_ID=$(az network firewall show --resource-group \"$RG\" --name \"$AFW\" --query id -o tsv)\n\naz monitor diagnostic-settings create \\\n  --name \"diag-afw-to-law\" \\\n  --resource \"$AFW_ID\" \\\n  --workspace \"$LAW_ID\" \\\n  --logs '[\n    {\"category\":\"AzureFirewallApplicationRule\",\"enabled\":true},\n    {\"category\":\"AzureFirewallNetworkRule\",\"enabled\":true},\n    {\"category\":\"AzureFirewallDnsProxy\",\"enabled\":true}\n  ]' \\\n  --metrics '[{\"category\":\"AllMetrics\",\"enabled\":true}]'\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> Firewall logs start flowing to Log Analytics (may take several minutes).<\/p>\n\n\n\n<p><strong>Query example (in Log Analytics workspace \u2192 Logs):<\/strong>\n&#8211; Look for application rule denies\/allows (table names may differ by schema updates). A common table is <code>AzureDiagnostics<\/code> for classic schemas; newer resources may use resource-specific tables. If you\u2019re unsure, start by listing tables and searching for \u201cAzureFirewall\u201d.<\/p>\n\n\n\n<p>Example KQL starting point (verify table names in your workspace):<\/p>\n\n\n\n<pre><code class=\"language-kusto\">AzureDiagnostics\n| where ResourceType has \"AZUREFIREWALLS\"\n| where Category has \"AzureFirewallApplicationRule\"\n| sort by TimeGenerated desc\n| take 50\n<\/code><\/pre>\n\n\n\n<p>If your workspace uses a different table schema, <strong>verify in official docs<\/strong>:\nhttps:\/\/learn.microsoft.com\/azure\/firewall\/firewall-logs-and-metrics<\/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>You have successfully completed the lab if:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>WorkloadSubnet<\/code> has a route table with <code>0.0.0.0\/0<\/code> next hop to the firewall private IP.<\/li>\n<li>From the VM:<\/li>\n<li><code>https:\/\/www.microsoft.com<\/code> succeeds<\/li>\n<li><code>https:\/\/www.google.com<\/code> fails (blocked)<\/li>\n<li>(Optional) Firewall logs show allowed and denied attempts.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p>Common problems and practical fixes:<\/p>\n\n\n\n<p>1) <strong>Traffic bypasses Azure Firewall<\/strong>\n&#8211; Confirm the route table is associated with <code>WorkloadSubnet<\/code>.\n&#8211; Confirm the route next hop IP is the firewall <strong>private IP<\/strong>.\n&#8211; Confirm there is no conflicting route overriding your UDR.<\/p>\n\n\n\n<p>2) <strong>Azure Firewall deployment fails<\/strong>\n&#8211; Subnet name must be exactly <code>AzureFirewallSubnet<\/code>.\n&#8211; Subnet size must meet requirements (check official docs).\n&#8211; Verify region\/SKU availability.<\/p>\n\n\n\n<p>3) <strong>Allowed site is blocked<\/strong>\n&#8211; Ensure the application rule targets the correct FQDN (<code>www.microsoft.com<\/code> vs <code>microsoft.com<\/code>).\n&#8211; Some sites redirect across multiple hostnames. If your goal is \u201callow the full site,\u201d you may need to allow additional FQDNs used in redirects\/CDNs. Use logs to identify blocked FQDNs, then add them intentionally.<\/p>\n\n\n\n<p>4) <strong>No logs in Log Analytics<\/strong>\n&#8211; Wait 5\u201315 minutes after enabling diagnostics.\n&#8211; Confirm diagnostic settings are attached to the firewall resource.\n&#8211; Confirm workspace permissions and that categories are valid for your resource\/API version.<\/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 Azure Firewall hourly charges, delete the resource group:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az group delete --name \"$RG\" --yes --no-wait\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome:<\/strong> All lab resources are removed. Confirm in the Azure Portal that the resource group is gone.<\/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<\/strong> for centralized inspection in multi-VNet environments.<\/li>\n<li><strong>Minimize hairpinning<\/strong>: Route only necessary prefixes through the firewall to reduce latency and cost.<\/li>\n<li><strong>Plan for hybrid<\/strong>: If using VPN\/ExpressRoute, ensure routes are symmetric and documented.<\/li>\n<li><strong>Prefer Azure Firewall Policy<\/strong> over legacy per-firewall \u201cclassic rules\u201d for consistency and reuse.<\/li>\n<li><strong>Separate inbound publishing vs outbound control<\/strong>: Use Application Gateway\/Front Door for many web ingress patterns and Azure Firewall primarily for network control and egress.<\/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>Use <strong>least privilege RBAC<\/strong>:<\/li>\n<li>Security team: manage firewall policies\/rules<\/li>\n<li>Network\/platform team: manage routing and firewall instances<\/li>\n<li>Operations: read-only + log access<\/li>\n<li>Use <strong>Privileged Identity Management (PIM)<\/strong> for just-in-time elevation in production.<\/li>\n<li>Protect policy changes with <strong>change control<\/strong> and approvals (GitOps\/IaC).<\/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>Use the <strong>lowest tier<\/strong> that satisfies requirements.<\/li>\n<li>Avoid routing large internal east\u2013west traffic through the firewall unless required.<\/li>\n<li>Right-size diagnostics:<\/li>\n<li>Send only required logs<\/li>\n<li>Set retention deliberately<\/li>\n<li>Consider archive strategies for long-term compliance<\/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 sets clean and well-structured:<\/li>\n<li>Use meaningful priorities and naming<\/li>\n<li>Avoid overly broad rules that cause security drift<\/li>\n<li>Consider how application rule matching works (FQDN\/SNI\/Host header behavior).<\/li>\n<li>Validate throughput and scaling guidance in official docs for high-volume designs.<\/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>Use <strong>Availability Zones<\/strong> where supported if the firewall is business-critical.<\/li>\n<li>Consider multi-region strategies for DR (separate firewalls per region).<\/li>\n<li>Ensure routing is resilient (UDRs + consistent propagation patterns).<\/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>Enable diagnostics and build dashboards\/workbooks for:<\/li>\n<li>Top allowed\/denied destinations<\/li>\n<li>Threat intel hits<\/li>\n<li>DNAT attempts<\/li>\n<li>Create runbooks for:<\/li>\n<li>\u201cNew outbound domain request\u201d (how to evaluate and add safely)<\/li>\n<li>Incident response (log queries, isolation steps)<\/li>\n<li>Use tagging for ownership and chargeback:<\/li>\n<li><code>env<\/code>, <code>app<\/code>, <code>costCenter<\/code>, <code>owner<\/code>, <code>dataClassification<\/code><\/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>Use consistent names (example pattern):<\/li>\n<li><code>afw-{env}-{region}-hub01<\/code><\/li>\n<li><code>afwpol-{env}-baseline<\/code><\/li>\n<li><code>rcg-egress-web-allow<\/code><\/li>\n<li>Enforce:<\/li>\n<li>Required tags<\/li>\n<li>Diagnostics enabled<\/li>\n<li>Approved regions and SKUs<br\/>\nvia <strong>Azure Policy<\/strong>.<\/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>Azure Firewall is configured via ARM and controlled by <strong>Azure RBAC<\/strong>.<\/li>\n<li>Use separate roles\/scopes for:<\/li>\n<li>Policy authors<\/li>\n<li>Policy approvers<\/li>\n<li>Firewall operators<\/li>\n<li>Log readers (SOC)<\/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>Data plane encryption depends on protocols:<\/li>\n<li>HTTPS is encrypted end-to-end unless you implement <strong>TLS inspection<\/strong> (Premium).<\/li>\n<li>Logs in Azure Monitor and Log Analytics are stored encrypted at rest by Azure (verify your compliance needs in official docs).<\/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>Public IPs on Azure Firewall can accept inbound traffic if you configure DNAT rules.<\/li>\n<li>Restrict inbound with:<\/li>\n<li>Tight DNAT source restrictions (where possible)<\/li>\n<li>Upstream DDoS protections\/design (Azure DDoS Protection is separate)<\/li>\n<li>Prefer WAF services for HTTP ingress when appropriate<\/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>If using TLS inspection (Premium), certificate\/private key handling is sensitive:<\/li>\n<li>Store certificates securely (often in Key Vault depending on recommended patterns\u2014verify in official docs).<\/li>\n<li>Restrict access and audit retrieval\/rotation.<\/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 and retain them based on compliance requirements.<\/li>\n<li>Forward relevant logs to a SIEM (Microsoft Sentinel or another system).<\/li>\n<li>Monitor changes to policies and route tables (Azure Activity Log + alerts).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>TLS inspection can create privacy, regulatory, and legal obligations.<\/li>\n<li>Ensure appropriate consent and policy for decrypting traffic.<\/li>\n<li>Maintain auditable change history for firewall rules.<\/li>\n<\/ul>\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>Forgetting routing<\/strong>: Assuming rules apply when traffic never hits the firewall.<\/li>\n<li><strong>Over-broad allow rules<\/strong>: \u201cAllow Any Any\u201d defeats the purpose.<\/li>\n<li><strong>Not logging<\/strong>: No diagnostics = no audit trail.<\/li>\n<li><strong>Not accounting for redirects\/CDNs<\/strong>: Allowing one FQDN may not allow the full app; teams then \u201ctemporarily allow all,\u201d and it sticks.<\/li>\n<li><strong>Publishing web apps with DNAT<\/strong> without WAF considerations.<\/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 from <strong>deny-by-default<\/strong> outbound with explicit allowlists.<\/li>\n<li>Use baseline policies and environment overrides.<\/li>\n<li>Automate rule deployment through IaC with peer review.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<p>Azure Firewall is widely used, but there are practical constraints to plan for.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Known limitations \/ constraints (review before production)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Rule and object limits<\/strong> exist (numbers can change). Review: https:\/\/learn.microsoft.com\/azure\/firewall\/firewall-limits<\/li>\n<li><strong>Feature availability differs by tier<\/strong> (Basic vs Standard vs Premium).<\/li>\n<li><strong>Regional feature differences<\/strong>: Availability Zones and some features vary by region.<\/li>\n<li><strong>Traffic must be routed through the firewall<\/strong> (UDRs \/ Virtual WAN routing). Misrouting is the #1 cause of \u201cit doesn\u2019t work.\u201d<\/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><strong>FQDN allowlisting is not always \u201cone domain\u201d<\/strong>: modern apps use multiple domains for auth, CDNs, telemetry.<\/li>\n<li><strong>Asymmetric routing breaks stateful inspection<\/strong>: ensure return traffic follows the same path.<\/li>\n<li><strong>Logging costs can surprise you<\/strong>: blocked traffic storms can generate a lot of logs.<\/li>\n<li><strong>DNAT is not a WAF<\/strong>: it won\u2019t provide the same protections as a dedicated WAF service.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compatibility nuances<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Some protocols and applications don\u2019t behave cleanly with centralized inspection or require additional design (proxy behavior, DNS considerations, etc.). Validate with a pilot.<\/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>Migrating from NVA appliances requires mapping:<\/li>\n<li>NAT rules<\/li>\n<li>App rules vs network rules<\/li>\n<li>Logging differences<\/li>\n<li>Routing and HA design<br\/>\nExpect iterative testing.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Azure Firewall is one part of Azure\u2019s networking security toolbox. Here\u2019s how it compares to common alternatives.<\/p>\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<\/strong><\/td>\n<td>Centralized stateful filtering, egress control, hub security<\/td>\n<td>Managed scaling\/HA, policy-based management, strong Azure integration, centralized logging<\/td>\n<td>Costs can be significant; requires routing; not a full WAF replacement<\/td>\n<td>You need centralized inspection across VNets\/hybrid with strong logging<\/td>\n<\/tr>\n<tr>\n<td><strong>Network Security Groups (NSGs)<\/strong><\/td>\n<td>Subnet\/NIC-level L3\/L4 filtering<\/td>\n<td>Free\/low cost, simple, distributed, very common<\/td>\n<td>No centralized L7\/FQDN egress control; limited centralized visibility<\/td>\n<td>You need basic segmentation inside a VNet\/subnet<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Application Gateway (WAF)<\/strong><\/td>\n<td>HTTP\/S inbound app publishing<\/td>\n<td>L7 load balancer + WAF protections<\/td>\n<td>Not a general outbound firewall; not meant for broad L3\/L4 filtering<\/td>\n<td>You need inbound web protection and routing<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Front Door (WAF)<\/strong><\/td>\n<td>Global HTTP\/S entry point<\/td>\n<td>Global edge, WAF, acceleration<\/td>\n<td>Not for private network egress control<\/td>\n<td>You need global web entry and WAF at the edge<\/td>\n<\/tr>\n<tr>\n<td><strong>Third-party NVAs (Marketplace)<\/strong><\/td>\n<td>Advanced NGFW features or vendor standardization<\/td>\n<td>Familiar enterprise feature sets, vendor ecosystems<\/td>\n<td>Operational overhead, scaling\/HA design, licensing<\/td>\n<td>You need specific NGFW features or already standardize on a vendor<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS Network Firewall<\/strong> (other cloud)<\/td>\n<td>Similar managed firewalling in AWS<\/td>\n<td>Managed stateful filtering in AWS<\/td>\n<td>Not Azure-native; different integrations<\/td>\n<td>Multi-cloud comparison\u2014choose based on cloud location<\/td>\n<\/tr>\n<tr>\n<td><strong>GCP Cloud NGFW \/ firewall controls<\/strong> (other cloud)<\/td>\n<td>Similar capabilities in GCP<\/td>\n<td>Managed controls in GCP<\/td>\n<td>Not Azure-native<\/td>\n<td>Choose based on cloud platform<\/td>\n<\/tr>\n<tr>\n<td><strong>Self-managed firewall VMs (pfSense, iptables, etc.)<\/strong><\/td>\n<td>Small environments or special cases<\/td>\n<td>Full control, potentially lower base cost<\/td>\n<td>Patching, scaling, HA complexity, operational risk<\/td>\n<td>Only if you accept ops overhead and have a strong reason<\/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 (regulated hub-and-spoke)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A financial services company has 40+ spoke VNets across multiple subscriptions. Auditors require proof that outbound internet access is restricted and logged. Security team wants centralized enforcement with approvals.<\/li>\n<li><strong>Proposed architecture<\/strong>:<\/li>\n<li>Hub VNet per region with Azure Firewall (zone-redundant where supported)<\/li>\n<li>Azure Firewall Policy baseline (deny-by-default)<\/li>\n<li>Rule collection groups per business unit and environment (dev\/test\/prod)<\/li>\n<li>UDRs on spoke subnets forcing 0.0.0.0\/0 to the hub firewall<\/li>\n<li>Diagnostic logs to Log Analytics + Microsoft Sentinel<\/li>\n<li><strong>Why Azure Firewall was chosen<\/strong>:<\/li>\n<li>Managed HA and scaling reduces operational risk vs NVA clusters<\/li>\n<li>Policy-based model supports central security governance<\/li>\n<li>Native logging pipeline supports audit and IR<\/li>\n<li><strong>Expected outcomes<\/strong>:<\/li>\n<li>Consistent egress control with measurable compliance evidence<\/li>\n<li>Faster incident investigations with centralized logs<\/li>\n<li>Reduced drift vs distributed NSG-only approach<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example (simple egress allowlist)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A startup runs workloads in Azure and suffered a supply-chain incident where build agents downloaded unauthorized tooling. They want strict outbound controls for CI runners.<\/li>\n<li><strong>Proposed architecture<\/strong>:<\/li>\n<li>Single VNet with Azure Firewall Standard<\/li>\n<li>Allow outbound only to approved domains (artifact repos, source control, package registries)<\/li>\n<li>Logs retained for a short period for troubleshooting<\/li>\n<li><strong>Why Azure Firewall was chosen<\/strong>:<\/li>\n<li>Quick to deploy, managed service, strong logging<\/li>\n<li>Central enforcement without touching every workload\u2019s NSGs<\/li>\n<li><strong>Expected outcomes<\/strong>:<\/li>\n<li>Reduced exfiltration risk from build agents<\/li>\n<li>Better visibility into attempted outbound traffic<\/li>\n<li>A repeatable security boundary as the company grows<\/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 a WAF?<\/strong><br\/>\nNo. Azure Firewall is a network firewall (L3\u2013L7 depending on features) mainly for network\/app connectivity control. For web attack protection (OWASP, bot protection, etc.), use a WAF service such as Application Gateway WAF or Front Door WAF.<\/p>\n\n\n\n<p>2) <strong>Do I need Azure Firewall if I already use NSGs?<\/strong><br\/>\nOften yes for centralized egress control, FQDN filtering, NAT publishing, and centralized logging. NSGs are still important for local segmentation and least privilege inside subnets.<\/p>\n\n\n\n<p>3) <strong>Where do I deploy Azure Firewall in a hub-and-spoke design?<\/strong><br\/>\nTypically in the <strong>hub VNet<\/strong> in a dedicated subnet named <code>AzureFirewallSubnet<\/code>, with spokes peered to the hub and UDRs forcing traffic to the firewall.<\/p>\n\n\n\n<p>4) <strong>How do I make sure traffic actually goes through Azure Firewall?<\/strong><br\/>\nUse <strong>UDRs<\/strong> (route tables) on spoke\/workload subnets and validate effective routes. Without routing, firewall rules won\u2019t apply.<\/p>\n\n\n\n<p>5) <strong>Can Azure Firewall restrict outbound traffic by domain name?<\/strong><br\/>\nYes, via <strong>Application rules<\/strong> (FQDN-based) primarily for HTTP\/S. Validate how your application resolves and connects (redirects, multiple domains).<\/p>\n\n\n\n<p>6) <strong>Why does \u201callow <code>example.com<\/code>\u201d still break the application?<\/strong><br\/>\nModern apps often use multiple hostnames (CDNs, authentication providers). Use firewall logs to identify additional required FQDNs and allow them intentionally.<\/p>\n\n\n\n<p>7) <strong>Is Azure Firewall regional or global?<\/strong><br\/>\nAzure Firewall is primarily <strong>regional<\/strong>, though you can deploy per region and centralize management with policies\/manager.<\/p>\n\n\n\n<p>8) <strong>Does Azure Firewall support Availability Zones?<\/strong><br\/>\nIn many regions yes, but support varies. Verify zone support in official documentation for your region and chosen tier.<\/p>\n\n\n\n<p>9) <strong>Can Azure Firewall inspect east\u2013west traffic between spokes?<\/strong><br\/>\nYes, if you route that traffic through the firewall (for example, UDRs for RFC1918 prefixes). Be mindful of latency and cost.<\/p>\n\n\n\n<p>10) <strong>How does Azure Firewall logging work?<\/strong><br\/>\nYou enable <strong>diagnostic settings<\/strong> to send logs\/metrics to Log Analytics, Event Hub, or Storage. Then query\/alert with Azure Monitor and Sentinel.<\/p>\n\n\n\n<p>11) <strong>What are the biggest cost drivers?<\/strong><br\/>\nHourly firewall cost + data processed charges + logging (Log Analytics ingestion\/retention) + bandwidth egress.<\/p>\n\n\n\n<p>12) <strong>Can I use Azure Firewall with Azure Kubernetes Service (AKS)?<\/strong><br\/>\nYes, commonly for egress control, but you must design routing carefully (UDRs, SNAT, and cluster networking considerations). Pilot and validate.<\/p>\n\n\n\n<p>13) <strong>What\u2019s the difference between Azure Firewall and a third-party NVA?<\/strong><br\/>\nAzure Firewall is managed and Azure-integrated. NVAs can offer vendor-specific NGFW features but require more operational work and licensing management.<\/p>\n\n\n\n<p>14) <strong>Does Azure Firewall support DNAT for inbound publishing?<\/strong><br\/>\nYes, NAT rules can map a firewall public IP\/port to private IP\/port. For web apps, consider WAF services as a more appropriate edge layer.<\/p>\n\n\n\n<p>15) <strong>How do I organize rules at scale?<\/strong><br\/>\nUse <strong>Azure Firewall Policy<\/strong> with rule collection groups (by environment, app, team), consistent naming, priorities, and IaC-driven changes with approvals.<\/p>\n\n\n\n<p>16) <strong>Can I centralize management across multiple firewalls?<\/strong><br\/>\nYes\u2014use Azure Firewall Policy reuse and Azure Firewall Manager for centralized management patterns (especially with Virtual WAN secured hubs).<\/p>\n\n\n\n<p>17) <strong>What\u2019s the most common reason Azure Firewall \u201cdoes nothing\u201d?<\/strong><br\/>\nTraffic is not routed through it. Validate UDRs, effective routes, and return path symmetry.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Azure 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>Azure Firewall documentation<\/td>\n<td>Canonical setup, concepts, configuration, and troubleshooting: https:\/\/learn.microsoft.com\/azure\/firewall\/<\/td>\n<\/tr>\n<tr>\n<td>Official overview<\/td>\n<td>Azure Firewall overview<\/td>\n<td>Clear explanation of what it is and key concepts: https:\/\/learn.microsoft.com\/azure\/firewall\/overview<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>Azure Firewall pricing<\/td>\n<td>Current SKU\/tier pricing model: https:\/\/azure.microsoft.com\/pricing\/details\/azure-firewall\/<\/td>\n<\/tr>\n<tr>\n<td>Pricing tool<\/td>\n<td>Azure Pricing Calculator<\/td>\n<td>Build region- and usage-specific estimates: https:\/\/azure.microsoft.com\/pricing\/calculator\/<\/td>\n<\/tr>\n<tr>\n<td>Logs &amp; metrics<\/td>\n<td>Azure Firewall logs and metrics<\/td>\n<td>How to enable diagnostics and interpret logs: https:\/\/learn.microsoft.com\/azure\/firewall\/firewall-logs-and-metrics<\/td>\n<\/tr>\n<tr>\n<td>Limits<\/td>\n<td>Azure Firewall limits<\/td>\n<td>Rule\/object constraints to plan designs: https:\/\/learn.microsoft.com\/azure\/firewall\/firewall-limits<\/td>\n<\/tr>\n<tr>\n<td>Architecture center<\/td>\n<td>Azure Architecture Center<\/td>\n<td>Reference patterns for hub-spoke and security (search within): https:\/\/learn.microsoft.com\/azure\/architecture\/<\/td>\n<\/tr>\n<tr>\n<td>Virtual WAN secured hub<\/td>\n<td>Virtual WAN + secured hub docs<\/td>\n<td>For Virtual WAN deployment patterns (verify current pages): https:\/\/learn.microsoft.com\/azure\/virtual-wan\/<\/td>\n<\/tr>\n<tr>\n<td>Azure Firewall Manager<\/td>\n<td>Firewall Manager documentation<\/td>\n<td>Centralized management patterns: https:\/\/learn.microsoft.com\/azure\/firewall-manager\/<\/td>\n<\/tr>\n<tr>\n<td>Video learning<\/td>\n<td>Microsoft Azure YouTube channel<\/td>\n<td>Official talks and demos (search \u201cAzure Firewall\u201d): https:\/\/www.youtube.com\/@MicrosoftAzure<\/td>\n<\/tr>\n<tr>\n<td>Community (reputable)<\/td>\n<td>Microsoft Tech Community (Azure Networking)<\/td>\n<td>Real-world troubleshooting and announcements (validate with docs): https:\/\/techcommunity.microsoft.com\/t5\/azure-networking\/bd-p\/AzureNetworking<\/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<ol class=\"wp-block-list\">\n<li>\n<p><strong>DevOpsSchool.com<\/strong>\n   &#8211; <strong>Suitable audience<\/strong>: DevOps engineers, SREs, cloud engineers, platform teams\n   &#8211; <strong>Likely learning focus<\/strong>: Azure infrastructure, DevOps practices, CI\/CD, cloud operations (verify specific Azure Firewall coverage on site)\n   &#8211; <strong>Mode<\/strong>: Check website\n   &#8211; <strong>Website<\/strong>: https:\/\/www.devopsschool.com\/<\/p>\n<\/li>\n<li>\n<p><strong>ScmGalaxy.com<\/strong>\n   &#8211; <strong>Suitable audience<\/strong>: DevOps and SCM learners, build\/release engineers\n   &#8211; <strong>Likely learning focus<\/strong>: Source control, CI\/CD tooling, DevOps foundations (verify Azure networking offerings on site)\n   &#8211; <strong>Mode<\/strong>: Check website\n   &#8211; <strong>Website<\/strong>: https:\/\/www.scmgalaxy.com\/<\/p>\n<\/li>\n<li>\n<p><strong>CLoudOpsNow.in<\/strong>\n   &#8211; <strong>Suitable audience<\/strong>: Cloud operations and platform operations teams\n   &#8211; <strong>Likely learning focus<\/strong>: Cloud operations practices, monitoring, reliability (verify Azure Firewall content on site)\n   &#8211; <strong>Mode<\/strong>: Check website\n   &#8211; <strong>Website<\/strong>: https:\/\/www.cloudopsnow.in\/<\/p>\n<\/li>\n<li>\n<p><strong>SreSchool.com<\/strong>\n   &#8211; <strong>Suitable audience<\/strong>: SREs, operations engineers, reliability-focused teams\n   &#8211; <strong>Likely learning focus<\/strong>: SRE practices, observability, incident response (verify Azure networking modules on site)\n   &#8211; <strong>Mode<\/strong>: Check website\n   &#8211; <strong>Website<\/strong>: https:\/\/www.sreschool.com\/<\/p>\n<\/li>\n<li>\n<p><strong>AiOpsSchool.com<\/strong>\n   &#8211; <strong>Suitable audience<\/strong>: Operations teams adopting AIOps, monitoring engineers\n   &#8211; <strong>Likely learning focus<\/strong>: AIOps concepts, automation, monitoring analytics (verify Azure integration content on site)\n   &#8211; <strong>Mode<\/strong>: Check website\n   &#8211; <strong>Website<\/strong>: https:\/\/www.aiopsschool.com\/<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>RajeshKumar.xyz<\/strong>\n   &#8211; <strong>Likely specialization<\/strong>: DevOps\/cloud training content (verify specific Azure Firewall materials on site)\n   &#8211; <strong>Suitable audience<\/strong>: Beginners to intermediate engineers\n   &#8211; <strong>Website<\/strong>: https:\/\/rajeshkumar.xyz\/<\/p>\n<\/li>\n<li>\n<p><strong>devopstrainer.in<\/strong>\n   &#8211; <strong>Likely specialization<\/strong>: DevOps training and coaching (verify Azure networking coverage)\n   &#8211; <strong>Suitable audience<\/strong>: DevOps engineers and students\n   &#8211; <strong>Website<\/strong>: https:\/\/www.devopstrainer.in\/<\/p>\n<\/li>\n<li>\n<p><strong>devopsfreelancer.com<\/strong>\n   &#8211; <strong>Likely specialization<\/strong>: Freelance DevOps services and training resources (verify Azure content)\n   &#8211; <strong>Suitable audience<\/strong>: Teams seeking practical DevOps guidance\n   &#8211; <strong>Website<\/strong>: https:\/\/www.devopsfreelancer.com\/<\/p>\n<\/li>\n<li>\n<p><strong>devopssupport.in<\/strong>\n   &#8211; <strong>Likely specialization<\/strong>: DevOps support and enablement resources (verify Azure Firewall coverage)\n   &#8211; <strong>Suitable audience<\/strong>: Working professionals needing hands-on support\n   &#8211; <strong>Website<\/strong>: https:\/\/www.devopssupport.in\/<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>cotocus.com<\/strong>\n   &#8211; <strong>Likely service area<\/strong>: Cloud and DevOps consulting (verify service catalog)\n   &#8211; <strong>Where they may help<\/strong>: Landing zones, networking architecture, security implementations, operations\n   &#8211; <strong>Consulting use case examples<\/strong>:<\/p>\n<ul>\n<li>Hub-and-spoke Azure networking with Azure Firewall<\/li>\n<li>Logging\/SIEM integration for firewall events<\/li>\n<li>Migration from NVA appliances to managed services<\/li>\n<li><strong>Website<\/strong>: https:\/\/cotocus.com\/<\/li>\n<\/ul>\n<\/li>\n<li>\n<p><strong>DevOpsSchool.com<\/strong>\n   &#8211; <strong>Likely service area<\/strong>: DevOps and cloud consulting\/training (verify offerings)\n   &#8211; <strong>Where they may help<\/strong>: DevOps enablement, cloud operations, automation, IaC\n   &#8211; <strong>Consulting use case examples<\/strong>:<\/p>\n<ul>\n<li>Azure Firewall Policy deployment with IaC pipelines<\/li>\n<li>Operational runbooks and monitoring dashboards<\/li>\n<li>Cost governance for centralized egress and logging<\/li>\n<li><strong>Website<\/strong>: https:\/\/www.devopsschool.com\/<\/li>\n<\/ul>\n<\/li>\n<li>\n<p><strong>DEVOPSCONSULTING.IN<\/strong>\n   &#8211; <strong>Likely service area<\/strong>: DevOps consulting and implementation services (verify offerings)\n   &#8211; <strong>Where they may help<\/strong>: CI\/CD, cloud adoption, infrastructure automation\n   &#8211; <strong>Consulting use case examples<\/strong>:<\/p>\n<ul>\n<li>Secure egress design for build agents<\/li>\n<li>Route table\/segmentation design and validation<\/li>\n<li>Logging pipeline to Azure Monitor\/Sentinel<\/li>\n<li><strong>Website<\/strong>: https:\/\/www.devopsconsulting.in\/<\/li>\n<\/ul>\n<\/li>\n<\/ol>\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<\/h3>\n\n\n\n<p>To be effective with Azure Firewall, you should be comfortable with:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>IP addressing and subnetting<\/strong> (CIDR, RFC1918)<\/li>\n<li><strong>Routing fundamentals<\/strong> (default routes, longest prefix match, asymmetric routing)<\/li>\n<li><strong>Azure VNets and subnets<\/strong><\/li>\n<li><strong>Network Security Groups (NSGs)<\/strong> and how they differ from firewalls<\/li>\n<li><strong>Azure RBAC<\/strong> and resource organization (subscriptions, resource groups)<\/li>\n<li><strong>Azure Monitor basics<\/strong> (logs, metrics, diagnostic settings)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Azure Firewall<\/h3>\n\n\n\n<p>Once you understand Azure Firewall, expand into:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Hub-and-spoke landing zones<\/strong> and governance (Azure Policy)<\/li>\n<li><strong>Azure Firewall Manager<\/strong> and <strong>Virtual WAN secured hubs<\/strong><\/li>\n<li><strong>Microsoft Sentinel<\/strong> detections and incident workflows using firewall logs<\/li>\n<li><strong>Private endpoints\/Private Link<\/strong> and private DNS designs<\/li>\n<li><strong>WAF services<\/strong> (Application Gateway WAF, Front Door WAF)<\/li>\n<li><strong>Zero Trust networking patterns<\/strong> and segmentation strategies<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use Azure Firewall<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Network Engineer<\/li>\n<li>Cloud Security Engineer<\/li>\n<li>Platform Engineer<\/li>\n<li>SRE \/ Cloud Operations Engineer<\/li>\n<li>Solutions Architect<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (Azure)<\/h3>\n\n\n\n<p>Microsoft certifications change over time, so <strong>verify current certification names in official Microsoft Learn<\/strong>. Commonly relevant tracks include:\n&#8211; Azure Fundamentals (AZ-900)\n&#8211; Azure Administrator (AZ-104)\n&#8211; Azure Security Engineer (AZ-500)\n&#8211; Azure Network Engineer Associate (check current code\/name in Microsoft Learn)<\/p>\n\n\n\n<p>Microsoft Learn certifications: 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 lab with:<\/li>\n<li>Shared firewall policy baseline<\/li>\n<li>Separate dev\/prod spokes<\/li>\n<li>Egress allowlist + logging queries<\/li>\n<li>Add DNAT publishing for a private VM and compare with Application Gateway for web publishing.<\/li>\n<li>Create alerting:<\/li>\n<li>Spike in denied outbound traffic<\/li>\n<li>Threat intel hits<\/li>\n<li>Build IaC (Bicep\/Terraform) to deploy:<\/li>\n<li>Firewall + policy<\/li>\n<li>Route tables<\/li>\n<li>Diagnostics and retention<\/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<\/strong>: Managed, stateful network firewall service in Azure.<\/li>\n<li><strong>Azure Firewall Policy<\/strong>: Central policy object containing firewall rules\/settings, attachable to one or more firewalls.<\/li>\n<li><strong>Rule Collection Group<\/strong>: A container in a firewall policy that holds rule collections and sets evaluation priority.<\/li>\n<li><strong>Application Rule<\/strong>: L7 rule that allows\/denies traffic based on FQDN for supported protocols (commonly HTTP\/S).<\/li>\n<li><strong>Network Rule<\/strong>: L3\/L4 rule based on IPs, ports, and protocols.<\/li>\n<li><strong>NAT Rule<\/strong>: Rule defining address\/port translation (often DNAT for inbound publishing).<\/li>\n<li><strong>UDR (User Defined Route)<\/strong>: Custom route in an Azure route table to steer traffic (e.g., to a firewall).<\/li>\n<li><strong>SNAT<\/strong>: Source NAT\u2014outbound translation often to a firewall public IP.<\/li>\n<li><strong>DNAT<\/strong>: Destination NAT\u2014inbound translation from public IP\/port to private IP\/port.<\/li>\n<li><strong>Hub-and-spoke<\/strong>: Network topology where spokes connect to a central hub for shared services and security.<\/li>\n<li><strong>Virtual WAN Secure Hub<\/strong>: Virtual WAN hub with integrated security services such as Azure Firewall.<\/li>\n<li><strong>Azure Monitor Diagnostic Settings<\/strong>: Configuration that sends resource logs\/metrics to Log Analytics\/Event Hub\/Storage.<\/li>\n<li><strong>Log Analytics<\/strong>: Azure Monitor log store queried with KQL.<\/li>\n<li><strong>KQL<\/strong>: Kusto Query Language, used to query Azure Monitor logs.<\/li>\n<li><strong>Threat intelligence filtering<\/strong>: Blocking\/alerting based on known malicious indicators provided by Microsoft.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Azure Firewall is Azure\u2019s managed, stateful firewall service in the <strong>Networking<\/strong> category, designed to provide centralized traffic control, threat intelligence filtering, NAT capabilities, and deep operational visibility through Azure Monitor. It fits best as a hub security control for <strong>egress filtering<\/strong>, <strong>segmentation<\/strong>, and <strong>hybrid network enforcement<\/strong>, especially when you want consistent governance across many subnets and VNets.<\/p>\n\n\n\n<p>Cost-wise, plan for <strong>hourly firewall charges<\/strong>, <strong>data processed charges<\/strong>, and potentially significant <strong>logging costs<\/strong> (Log Analytics\/Sentinel). Security-wise, success depends on correct routing (UDRs\/Virtual WAN), least-privilege policy management, and intentional allowlisting (especially for modern apps that use many FQDNs).<\/p>\n\n\n\n<p>Use Azure Firewall when you need a centralized, auditable enforcement point that integrates cleanly with Azure\u2019s routing and monitoring ecosystem. Next, deepen your skills by implementing a hub-and-spoke or Virtual WAN secured hub design, enabling diagnostics, and building operational playbooks and alerts around firewall events.<\/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-492","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\/492","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=492"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/492\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=492"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=492"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=492"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}