This chapter covers Azure Firewall, a managed, cloud-based network security service that protects your Azure virtual network resources. For the AZ-900 exam, understanding Azure Firewall is part of Objective 2.3 (Describe Azure architecture and services), specifically under 'Describe Azure networking services.' This objective area carries approximately 15-20% of the exam weight. Azure Firewall is a key service for securing outbound and inbound traffic, and the exam tests your knowledge of its features, deployment, and how it differs from other security services like Network Security Groups (NSGs).
Jump to a section
Imagine a large corporate office building with multiple floors, each floor representing a virtual network (VNet). Employees (data packets) need to move between floors to do their jobs. A security guard (Azure Firewall) is stationed at the main entrance and also roams the hallways. This guard does not just check IDs; he has a detailed rulebook that specifies exactly who can go where, at what times, and using which elevator (protocol). For example, the rulebook might say: 'Floor 2 (web servers) can only be accessed by employees from Floor 1 (front-end) using the HTTP elevator, and only during business hours.' The guard also inspects every employee’s bag (packet inspection) for prohibited items (malicious payloads). If an employee tries to take a shortcut through the stairwell (unauthorized port), the guard stops them. Unlike a simple gate that only checks a badge, this guard can also log every movement, generate alerts, and block suspicious patterns—like someone trying to access every floor in under a minute (threat intelligence). The guard is centrally managed by the building’s security office (Azure portal), so rules can be updated instantly across all floors. This is how Azure Firewall works: it’s a stateful, centralized network security service that inspects and controls traffic between VNets, to the internet, and on-premises, using a rule-based policy with threat intelligence integration.
What is Azure Firewall and What Business Problem Does It Solve?
Azure Firewall is a fully managed, cloud-native network security service that protects your Azure Virtual Network (VNet) resources. It is a stateful firewall as a service (FWaaS) with built-in high availability and unlimited cloud scalability. The primary business problem it solves is the need to control and inspect network traffic in and out of Azure workloads without managing underlying infrastructure. In on-premises environments, organizations deploy physical or virtual firewall appliances (e.g., from Cisco, Palo Alto, Fortinet) to enforce security policies. In the cloud, you need equivalent capabilities but with the agility to scale, reduce operational overhead, and integrate with Azure-native monitoring and management tools.
Azure Firewall provides centralized policy enforcement across subscriptions and VNets, enabling you to create, enforce, and log application and network connectivity policies. It filters traffic at layers 3-7 (network, transport, and application), supports threat intelligence-based filtering, and integrates with Azure Monitor and Azure Sentinel for logging and analytics.
How Azure Firewall Works – Step by Step
Azure Firewall operates as a stateful service, meaning it tracks the state of active connections and makes decisions based on the context of the traffic flow, not just individual packets. Here’s the mechanism:
Deployment: You deploy Azure Firewall into a dedicated subnet called AzureFirewallSubnet (minimum /26) within a VNet. The firewall is associated with a public IP address for outbound traffic and optionally with a management subnet.
Routing: To force traffic through the firewall, you create User-Defined Routes (UDRs) on subnets that point to the firewall’s private IP as the next hop. For example, all outbound internet traffic from a subnet is routed to the firewall.
Rule Processing: When a packet arrives, Azure Firewall checks its rules in a specific order: NAT rules (for inbound traffic) -> Network rules (based on source, destination, port, protocol) -> Application rules (based on FQDNs, HTTP/HTTPS). The first match is applied. If no rule matches, the traffic is denied by default.
Stateful Inspection: The firewall maintains a connection table. For outbound traffic, it allows return traffic automatically (stateful behavior). For inbound traffic, you must explicitly allow it via DNAT rules.
Threat Intelligence: Azure Firewall can integrate with Microsoft Threat Intelligence to block traffic from/to known malicious IPs and domains. This is enabled via threat intelligence-based filtering in the firewall policy.
Logging and Analytics: All traffic flows can be logged to Azure Monitor, Storage Accounts, or Event Hubs. You can analyze logs using Log Analytics, create alerts, and integrate with Azure Sentinel.
Key Components, Tiers, and Pricing
Azure Firewall has two SKU tiers: Standard and Premium. The Standard SKU is suitable for most enterprise scenarios, offering:
Layer 3-7 filtering
Threat intelligence-based filtering
Built-in high availability
Azure Monitor logging
Support for up to 10,000 rules (network + application)
The Premium SKU adds:
TLS inspection (decryption and inspection of HTTPS traffic)
IDPS (Intrusion Detection and Prevention System)
URL filtering (based on URL categories)
Web categories (e.g., social media, adult content)
Pricing is based on deployment hours and data processing (GB processed). There is no upfront cost; you pay as you go. For example, Standard costs approximately $1.25 per hour + $0.065 per GB processed (prices may vary by region).
Comparison to On-Premises Firewalls
Traditional on-premises firewalls are hardware appliances that require physical installation, configuration, and ongoing maintenance. They have fixed capacity and require scaling by purchasing new hardware. Azure Firewall is fully managed—Microsoft handles patching, updates, and high availability. It scales automatically with your traffic. However, some organizations prefer third-party NVA (Network Virtual Appliance) firewalls for advanced features like custom IDPS signatures or legacy integrations. Azure Firewall Premium closes many gaps but still may not match all features of specialized NVAs.
Azure Portal and CLI Touchpoints
In the Azure portal, you can create an Azure Firewall by searching for "Firewalls" and clicking "Create." You specify the resource group, VNet, and public IP. After deployment, you configure rules under "Firewall Policy" (recommended) or classic rules. Key CLI commands:
# Create a firewall
az network firewall create --name MyFirewall --resource-group MyRG --location eastus
# Create a firewall policy
az network firewall policy create --name MyPolicy --resource-group MyRG
# Add a network rule
az network firewall policy rule-collection-group add --name MyRuleCollectionGroup --policy-name MyPolicy --resource-group MyRG --rule-collections '[{"name":"MyNetworkRuleCollection","priority":100,"rules":[{"name":"AllowHTTP","protocols":["TCP"],"source_addresses":["10.0.0.0/24"],"destination_addresses":["*"],"destination_ports":["80"]}]}]'Business Scenario: E-Commerce Application
Consider an e-commerce application with a three-tier architecture: web servers, application servers, and database servers. You deploy each tier in separate subnets. Azure Firewall is placed in a hub VNet (hub-and-spoke topology). You create network rules to allow web servers to talk to app servers on port 443, and app servers to talk to database servers on port 1433 (SQL). Application rules allow outbound internet access from web servers only to specific FQDNs (e.g., payment gateway). Threat intelligence blocks known malicious IPs. This centralizes security and simplifies compliance auditing.
Deploy Azure Firewall
Navigate to the Azure portal, search for 'Firewalls', and click 'Create'. Select a resource group, region, and name. Choose the SKU (Standard or Premium). Create a new virtual network or select an existing one, but ensure a subnet named 'AzureFirewallSubnet' with at least /26 address space exists. Associate a public IP address for outbound traffic. Click 'Review + create' and then 'Create'. Behind the scenes, Azure provisions the firewall service, sets up high availability across two availability zones if supported, and assigns the public IP. The firewall is now ready to filter traffic, but no rules are configured yet, so all traffic is denied by default.
Create a Firewall Policy
After deployment, go to the firewall resource and select 'Firewall Policy' under 'Settings'. Click 'Create Firewall Policy' to define a set of rules that can be applied to multiple firewalls. Give the policy a name and choose the tier (Standard or Premium). In the policy, you can define rule collection groups, which are containers for rule collections. A rule collection has a priority (100-65000) and can be of type NAT, Network, or Application. The policy also allows enabling threat intelligence-based filtering and TLS inspection (Premium). Using a policy simplifies management—you can update rules in one place and propagate to all associated firewalls.
Configure Network Rules
In the firewall policy, go to 'Network rules' and add a rule collection. Specify a name, priority, and action (Allow or Deny). Each rule includes: name, protocol (TCP, UDP, ICMP, or Any), source IP addresses (or CIDR ranges), destination IP addresses (or FQDNs for network rules), and destination ports. For example, to allow HTTP traffic from a subnet 10.0.1.0/24 to the internet, set source to '10.0.1.0/24', destination to '*', port to '80', protocol to 'TCP'. Network rules are processed before application rules. Remember: network rules only filter based on IP/port; for FQDN filtering, use application rules.
Configure Application Rules
Application rules allow or deny outbound traffic based on fully qualified domain names (FQDNs) for HTTP/HTTPS (ports 80 and 443). In the firewall policy, go to 'Application rules' and add a rule collection. Each rule includes: name, source IP addresses, protocols (http or https), and target FQDNs (e.g., '*.microsoft.com' or 'www.contoso.com'). Optionally, for Premium SKU, you can specify URL categories (e.g., 'SocialNetworking'). Application rules provide more granular control than network rules. For example, you can allow VMs to access only '*.windowsupdate.com' and '*.microsoft.com' for updates, blocking all other internet access. If a rule is not matched, traffic is denied.
Route Traffic to the Firewall
To force traffic through the firewall, you must create User-Defined Routes (UDRs) on the subnets whose traffic you want to inspect. For each subnet, add a route with address prefix '0.0.0.0/0' (for internet traffic) or a specific IP range, and next hop type 'Virtual appliance', then enter the firewall's private IP address. This is critical—without UDRs, traffic bypasses the firewall. You can also create routes for specific on-premises IP ranges if using ExpressRoute or VPN. Ensure the firewall's subnet has a route to the internet via the public IP (automatic). Test connectivity by deploying a VM in the protected subnet and attempting outbound HTTP—it should be allowed only if rules permit.
Scenario 1: Secure Outbound Internet for Development VMs
A software company has a development environment in Azure with multiple VMs that need internet access for package downloads (e.g., npm, NuGet) and API calls. Without a firewall, VMs have direct internet access, posing a security risk if a VM is compromised. The team deploys Azure Firewall in a hub VNet and creates a firewall policy with application rules that allow specific FQDNs like *.npmjs.org, *.nuget.org, and *.microsoft.com. All other outbound traffic is denied. They create UDRs on the dev subnets pointing to the firewall. This ensures developers can work without exposing the environment to malicious sites. The firewall logs show all outbound traffic, enabling security audits. If a VM tries to access a blocked site, the firewall logs the attempt, and an alert can be configured. Cost considerations: For a small dev environment (10 VMs), the hourly cost of Standard firewall (~$1.25/hr) plus data processing (~$0.065/GB) is manageable. However, if left running 24/7, it costs ~$900/month, so companies often shut down non-production firewalls outside business hours using automation.
Scenario 2: Hub-and-Spoke Network with Centralized Security
A large enterprise runs multiple applications across several VNets (spokes) that all need to connect to a central VNet (hub) for shared services like Active Directory and monitoring. They deploy Azure Firewall in the hub VNet and peer all spoke VNets to the hub. They create network rules to allow inter-spoke traffic only through the firewall (by setting the hub as the next hop). For example, the finance spoke can only talk to the HR spoke on specific ports. Application rules control outbound internet from all spokes. This centralizes security policy management—one firewall policy applies to all spokes. The enterprise uses Azure Firewall Premium for TLS inspection to decrypt and inspect HTTPS traffic to detect malware. They also enable threat intelligence to block known malicious IPs. If the firewall is misconfigured (e.g., a rule is too permissive), a compromised VM in one spoke could attack another spoke. Therefore, they implement a change management process and use Azure Policy to enforce that all VNets must route through the firewall.
Scenario 3: Protecting PaaS Services with Private Endpoints
A company uses Azure SQL Database and Storage accounts with private endpoints to keep traffic within the Azure backbone. They still need outbound internet for VMs to access external APIs. They deploy Azure Firewall and create application rules for specific FQDNs. Additionally, they use the firewall's FQDN filtering to allow only approved SaaS endpoints. They also configure DNAT rules to expose a web application behind the firewall with a public IP, translating inbound traffic to an internal load balancer. This provides a secure publish pattern without exposing the VM directly. If the firewall is scaled incorrectly (e.g., insufficient SNAT ports), outbound connections may fail. They monitor SNAT port usage via Azure Monitor and scale the firewall by adding more public IPs or using Azure Firewall Manager to deploy multiple instances.
Exam Objective and What AZ-900 Tests
This section aligns with Objective 2.3: Describe Azure architecture and services, specifically under 'Describe Azure networking services.' The exam expects you to understand Azure Firewall as a managed, cloud-based security service that provides network and application layer filtering. You should be able to differentiate it from Network Security Groups (NSGs) and Azure DDoS Protection. Key exam topics include: features (stateful, high availability, cloud scalability), SKUs (Standard vs. Premium), use cases (centralized policy enforcement, outbound traffic control), and integration (Azure Monitor, Threat Intelligence).
Common Wrong Answers and Why Candidates Choose Them
"Azure Firewall is a network security group (NSG) for the entire subscription." – Candidates confuse NSGs (distributed, stateless, layer 4) with Azure Firewall (centralized, stateful, layer 7). NSGs filter traffic at the subnet or NIC level; Azure Firewall is a dedicated appliance.
"Azure Firewall blocks inbound traffic by default and allows outbound." – While default deny is true, the stateful nature means outbound traffic is allowed only if a corresponding rule exists. Many think outbound is allowed because of stateful behavior, but no rule = deny.
"Azure Firewall can replace all NSGs." – Actually, NSGs are still needed for intra-VNet traffic segmentation. Azure Firewall is for inter-VNet, internet, and on-premises traffic. They complement each other.
"Azure Firewall is free with Azure subscription." – No, it has hourly and data processing costs. Candidates may confuse it with Azure DDoS Protection Basic (free) or NSGs (free).
Specific Terms and Values
Stateful: Tracks connection state; allows return traffic automatically.
AzureFirewallSubnet: Required subnet name with minimum /26.
Standard SKU: Up to 10,000 rules; no TLS inspection.
Premium SKU: Adds TLS inspection, IDPS, URL filtering.
Threat Intelligence: Based on Microsoft Threat Intelligence feeds; can be set to alert or deny.
FQDN: Fully qualified domain name (e.g., *.contoso.com).
UDR: User-Defined Route to force traffic through firewall.
Rule Collection Group: Logical grouping of rule collections; priority 100-65000.
Edge Cases and Tricky Distinctions
Azure Firewall vs. Azure Firewall Manager: Manager is a management tool for central policy across multiple firewalls. The exam may ask which to use for multi-region deployments.
Availability Zones: Azure Firewall Standard and Premium can be deployed across zones for higher SLA (99.95% for multi-zone vs. 99.9% for single-zone).
SNAT: Source Network Address Translation is automatically performed for outbound traffic; you cannot disable it. This can cause issues with overlapping IPs.
DNS Proxy: Azure Firewall can act as a DNS proxy to resolve FQDNs. This is a Premium feature.
Memory Trick: "FANS"
To remember Azure Firewall features: Fully managed, Application layer (L7), Network layer (L3/L4), Stateful. Alternatively, think "FANS" blow away threats.
Decision Tree for Wrong Answers
If an exam question asks about a security service for a specific scenario:
If it's about filtering traffic between subnets within the same VNet → NSG.
If it's about controlling outbound internet access with FQDN filtering → Azure Firewall.
If it's about protecting against DDoS attacks → Azure DDoS Protection.
If it's about a web application firewall (WAF) for HTTP traffic → Azure Application Gateway WAF (not Azure Firewall).
Azure Firewall is a fully managed, stateful firewall as a service that provides centralized network and application layer filtering.
It requires a dedicated subnet named 'AzureFirewallSubnet' with at least /26 address space.
Traffic must be routed to the firewall via User-Defined Routes (UDRs) to be inspected.
Azure Firewall offers Standard and Premium SKUs; Premium adds TLS inspection, IDPS, and URL filtering.
Default rule behavior: deny all traffic unless explicitly allowed by a rule.
Azure Firewall integrates with Azure Monitor for logging and with Threat Intelligence for blocking known malicious IPs/domains.
Pricing includes hourly deployment cost and data processing cost per GB.
These come up on the exam all the time. Here's how to tell them apart.
Azure Firewall
Stateful firewall service (L3-L7)
Centralized across VNets and subscriptions
Supports FQDN filtering (application rules)
Built-in high availability and scalability
Paid service (hourly + data processing)
Network Security Group (NSG)
Stateless for inbound, stateful for outbound (L4)
Distributed, applied per subnet or NIC
No FQDN filtering; only IP/port/protocol
No built-in HA; relies on platform
Free (no additional cost)
Mistake
Azure Firewall is just a bigger NSG.
Correct
Azure Firewall is a stateful, centralized firewall service that operates at layers 3-7, while NSGs are distributed, stateless (for inbound) and stateful (for outbound), and operate only at layer 4. Azure Firewall provides application-level filtering (FQDNs), threat intelligence, and centralized management across VNets.
Mistake
Azure Firewall is automatically deployed in every VNet.
Correct
No, you must explicitly deploy Azure Firewall into a dedicated subnet. It is not automatically present. By default, VNets have no firewall; traffic flows freely unless restricted by NSGs or other controls.
Mistake
Azure Firewall can inspect all traffic including intra-subnet traffic.
Correct
Azure Firewall can only inspect traffic that is routed through it. Traffic within the same subnet (east-west) is not routed to the firewall unless you create specific UDRs. For intra-VNet traffic, NSGs are more appropriate.
Mistake
Azure Firewall Premium is required for all security features.
Correct
Standard SKU already provides network and application rules, threat intelligence, and high availability. Premium adds TLS inspection, IDPS, and URL filtering. Many basic scenarios can be addressed with Standard.
Mistake
Azure Firewall is always cheaper than third-party NVAs.
Correct
Azure Firewall has a predictable pay-as-you-go pricing, but for very high traffic volumes, third-party NVAs with reserved instances may be cheaper. Also, NVAs offer advanced features that may justify higher cost for some enterprises.
Azure Firewall is a centralized, stateful firewall that operates at layers 3-7, providing application-level filtering (FQDNs), threat intelligence, and centralized management across VNets. NSGs are distributed, stateless (inbound) and stateful (outbound) layer 4 filters applied per subnet or NIC. NSGs are free; Azure Firewall has a cost. They complement each other: NSGs for intra-VNet segmentation, Azure Firewall for perimeter and inter-VNet control.
Yes, but inbound traffic filtering is achieved through DNAT rules (Destination Network Address Translation). You create NAT rules to translate a public IP and port to an internal IP and port. This is typically used to publish services like web servers. For direct inbound filtering (not NAT), you would use NSGs or Azure Firewall's network rules for traffic coming from on-premises via ExpressRoute or VPN.
You must associate at least one public IP with Azure Firewall for outbound internet traffic (SNAT). However, if you only need to filter traffic between VNets or from on-premises, you can deploy it without a public IP, but you lose outbound internet filtering. For inbound DNAT, you also need a public IP.
The SLA for Azure Firewall is 99.9% for a single-zone deployment and 99.95% for a multi-zone deployment (across two or more availability zones). This covers connectivity to the internet and between VNets. The SLA does not cover performance or throughput guarantees.
Azure Firewall Standard supports up to 10,000 rules combined (network + application). Premium also supports up to 10,000 rules. However, there are limits on rule collection groups and collections per policy. You can have up to 200 rule collection groups per policy, each with up to 100 rule collections. For large deployments, use multiple policies or Azure Firewall Manager.
Yes, if you have a hybrid connection (VPN or ExpressRoute), you can route traffic from on-premises through Azure Firewall. Create UDRs on the gateway subnet or use Border Gateway Protocol (BGP) to propagate routes. The firewall can then apply rules to traffic coming from on-premises to Azure and vice versa.
Azure Firewall is the actual firewall service that filters traffic. Azure Firewall Manager is a management service that provides a central place to create, configure, and monitor multiple Azure Firewalls across different regions and subscriptions. It also supports hub-and-spoke network topologies. You can use Manager to deploy firewalls and apply policies globally.
You've just covered Azure Firewall — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?