CloudNetworking.io
Home / Azure / Azure Firewall
Azure Networking Resource

Azure Firewall

Azure Firewall is one of the core security services in Azure networking. It is a managed, cloud-based, fully stateful firewall service that helps protect Azure virtual network resources and centralize traffic inspection and policy enforcement.

If Azure VNet gives you the network boundary, subnets give you structure, NSGs filter local traffic, route tables control path direction, Private Link gives private service access, and VNet peering links networks together, then Azure Firewall gives you centralized traffic inspection and policy control.

This page explains Azure Firewall in practical terms, with SKU guidance, Firewall Policy, DNAT, network rules, application rules, DNS proxy, forced tunneling, real-world examples, common mistakes, troubleshooting tips, and official Azure documentation links.

Start Learning Build Azure Firewall with Terraform Azure Official Docs

What is Azure Firewall?

Azure Firewall is a managed firewall service for Azure virtual networks. Microsoft describes it as a managed, cloud-based, fully stateful firewall-as-a-service with built-in high availability and unrestricted cloud scalability.

In simple terms, Azure Firewall is the service you use when you want centralized inspection and control for inbound, outbound, and east-west traffic patterns in Azure.

It is commonly used in hub-and-spoke designs, centralized egress control, internet publishing scenarios, and enterprise landing zones where traffic policy should be managed from one place.

Main purpose Centralized traffic inspection and policy enforcement.
Why it matters It helps protect workloads beyond what subnet-level controls alone can provide.
Typical use Hub firewalls, outbound filtering, DNAT publishing, and controlled enterprise traffic patterns.
Quick understanding: NSGs are usually local traffic filters around subnets or NICs. Azure Firewall is the centralized security checkpoint for broader network flows.

Why Azure Firewall matters

Azure networking grows more complex as environments scale. Teams often need more than simple subnet-level filtering. Azure Firewall matters because it gives central visibility and control over how traffic moves between Azure workloads, to the internet, and to hybrid-connected networks.

Centralized control

Policies and inspection logic can be managed in one place instead of being scattered across many subnets.

Stateful inspection

Azure Firewall is fully stateful and understands connection context rather than applying only simple stateless filtering.

Inbound publishing

DNAT rules can translate and filter inbound traffic to internal workloads.

Outbound control

It helps reduce data exfiltration risk and shape outbound internet access intentionally.

Hub-and-spoke fit

It is commonly deployed in a hub VNet or secured virtual hub to inspect traffic from many spokes.

Enterprise policy model

Firewall Policy lets teams standardize firewall behavior across regions, subscriptions, and multiple firewall instances.

Important idea: Azure Firewall is most valuable when you need central inspection and repeatable policy, not just a few isolated subnet rules.

Azure Firewall in the 5 Ws

What is Azure Firewall?

It is a managed, fully stateful firewall service for Azure virtual network resources.

Why do teams use it?

Teams use it for centralized inspection, outbound filtering, DNAT publishing, hub-and-spoke security, and enterprise policy standardization.

When should you use it?

Use Azure Firewall when network security should be centralized and controlled beyond what local NSGs alone can reasonably provide.

Where does it fit?

It commonly fits in a hub VNet, shared services VNet, or secured virtual hub, where it can inspect traffic between spokes, the internet, and hybrid destinations.

Who works with it?

Cloud engineers, network engineers, platform teams, security teams, Azure administrators, and architects all work with Azure Firewall in real enterprise designs.

How does it work?

Azure Firewall evaluates rule collections and policies to inspect matching traffic and then allows, denies, translates, or routes it according to the configured logic.

Azure Firewall SKUs

Microsoft documents three Azure Firewall SKUs: Basic, Standard, and Premium. The capabilities differ by SKU, so choosing the right one depends on the traffic patterns, inspection depth, and security features your design needs.

SKU Best fit Simple explanation
Basic Smaller environments and cost-sensitive workloads Entry-level managed firewall features for simpler scenarios.
Standard Most enterprise network security patterns General-purpose Azure Firewall SKU for common production designs.
Premium Advanced inspection and higher security requirements Extended capabilities for deeper traffic inspection and stronger enterprise controls.
Simple idea: Basic is lighter, Standard is the common middle ground, and Premium is for more advanced inspection and security needs.

Firewall Policy

Microsoft recommends Firewall Policy as the preferred way to configure Azure Firewall. Firewall Policy is a global resource that can be reused across multiple Azure Firewall instances, including hub VNets and secured virtual hubs, and it works across subscriptions and regions.

In practical terms, Firewall Policy helps teams avoid treating each firewall instance as a completely separate configuration island.

Why it matters

It helps standardize rule logic and security behavior across multiple firewalls.

Where it helps

It is especially useful in enterprise environments with shared policies, multiple subscriptions, or regional deployments.

Practical reminder: When designing new Azure Firewall deployments, think in terms of Firewall Policy first rather than only instance-local configuration.

Rule types: DNAT, network rules, and application rules

Azure Firewall uses three main rule types: DNAT, network rules, and application rules.

Rule type Main purpose Typical use
DNAT Translate and filter inbound traffic Publish internal services through the firewall’s public IPs
Network rules Filter traffic using IPs, ports, and protocols Control lower-level traffic patterns such as app-to-db or hybrid flows
Application rules Filter traffic using higher-level application logic such as FQDNs Control web and outbound internet access patterns

DNAT

DNAT rules manage inbound traffic through one or more firewall public IP addresses. Microsoft documents that DNAT rules translate a public IP and port to a private IP and port, and they implicitly add a corresponding network rule to allow the translated traffic.

Network rules

Network rules are useful when traffic should be controlled using IP ranges, ports, and protocols such as TCP or UDP.

Application rules

Application rules are useful for outbound web and application-aware filtering patterns where controlling destinations by FQDN or web context matters.

Important reminder: Good firewall design is not only about adding more rules. It is about choosing the correct rule type for the traffic you actually want to control.

DNS proxy and DNS settings

Azure Firewall can use Azure DNS by default, or you can configure a custom DNS server. Microsoft also documents DNS proxy support, which is disabled by default and can be enabled when you want the firewall to proxy DNS requests.

DNS behavior matters a lot when application rules, FQDN logic, private services, or hybrid name resolution are involved.

Default behavior

Azure Firewall uses Azure DNS unless you configure custom DNS settings.

Why DNS proxy matters

It can help centralize DNS behavior and make name-resolution-dependent firewall logic more predictable.

Simple idea: If your firewall policy depends on names, DNS behavior is part of your security design, not a side detail.

Forced tunneling

Azure Firewall supports forced tunneling, which Microsoft documents as routing internet-bound traffic to another firewall or network virtual appliance for further processing instead of going directly to the internet.

This is especially useful when an organization wants outbound traffic to pass through an on-premises edge firewall or another centralized inspection point.

Microsoft also documents an important limitation: DNAT is not supported when forced tunneling is enabled, because inbound internet access would otherwise create asymmetric routing problems in that mode.

Practical reminder: Forced tunneling is not just a routing checkbox. It changes the traffic model and affects how DNAT, egress, and hybrid inspection patterns behave.

Common Azure Firewall use cases

Centralized outbound filtering

Control which destinations workloads can reach on the internet or in hybrid-connected environments.

Inbound publishing with DNAT

Translate and filter internet traffic to internal application or infrastructure endpoints.

Hub-and-spoke inspection

Inspect spoke traffic through a firewall deployed in the hub VNet.

Enterprise landing zones

Standardize security policy and inspection patterns across multiple subscriptions and workloads.

Hybrid connectivity control

Inspect or shape traffic between Azure and on-premises-connected environments.

Application-aware web control

Use application rules and DNS-aware logic to shape outbound access patterns more intelligently.

Real-world Azure Firewall examples

Example 1: Hub-and-spoke enterprise firewall

A platform team deploys Azure Firewall in the hub VNet and uses route tables so spoke traffic goes through the firewall for outbound inspection and centralized security control.

Example 2: Azure Firewall plus Application Gateway

Microsoft documents Azure Firewall and Application Gateway in parallel as a common design when Application Gateway protects HTTP(S) applications and Azure Firewall protects other workloads and outbound traffic.

Example 3: Controlled outbound internet design

Application workloads can reach only approved web destinations, and all other outbound attempts are denied or inspected.

Example 4: DNAT for inbound access

The firewall publishes internal services through public IPs using DNAT while still filtering and controlling how inbound traffic reaches private workloads.

Example 5: Forced tunneling to on-premises inspection

An organization routes internet-bound Azure traffic to an on-premises security stack for extra inspection before that traffic continues outward.

Azure Firewall best practices

  • Use Firewall Policy as the primary configuration model for new designs.
  • Keep hub-and-spoke roles clear if you use centralized inspection.
  • Choose the correct rule type for the actual traffic pattern.
  • Be very deliberate with route tables when forcing traffic through the firewall.
  • Plan DNS behavior early, especially when application rules or DNS proxy matter.
  • Understand SKU differences before choosing Basic, Standard, or Premium.
  • Document why a rule exists, not only what it matches.
  • Test real traffic paths instead of relying only on deployment success.
  • Keep inbound DNAT, outbound control, and hybrid routing assumptions aligned.
  • Regularly review policy sprawl and remove old exceptions.
Most important best practice: Azure Firewall works best when it is part of a clear traffic architecture, not when it is added later as a disconnected security appliance.
Good next step: Once you understand Azure Firewall conceptually, the best way to reinforce learning is to build it with Terraform and test it with route tables and rule collections.

Common Azure Firewall mistakes

Wrong rule type

A network rule may be used where an application rule or DNAT rule would be the correct fit.

Ignoring route tables

The firewall may be deployed correctly, but traffic never reaches it because subnet routes do not send traffic there.

DNS assumptions

Application-aware logic can fail if DNS behavior is not aligned with the intended firewall design.

Forced tunneling misunderstandings

Teams may expect DNAT or internet path behavior that does not fit forced-tunneling mode.

No policy standardization

Managing each firewall instance separately can create avoidable inconsistency and sprawl.

Confusing NSGs and Firewall roles

NSGs and Azure Firewall solve different problems and should not be treated as identical tools.

Troubleshooting Azure Firewall issues

When traffic does not behave as expected through Azure Firewall, the goal is to check the full path: route tables, rule type, DNS behavior, inbound or outbound direction, and whether the design uses forced tunneling, DNAT, or centralized inspection in a hub.

Basic troubleshooting sequence

  1. Check whether the workload subnet actually routes traffic to the firewall.
  2. Confirm the correct rule type is being used: DNAT, network, or application.
  3. Check rule order and policy structure.
  4. Review DNS assumptions if FQDN logic or DNS proxy matters.
  5. Validate whether forced tunneling changes the expected behavior.
  6. Check whether the issue is inbound, outbound, east-west, or hybrid traffic.

Useful troubleshooting questions

  • Is the traffic actually reaching Azure Firewall?
  • Is the chosen rule type correct for the traffic?
  • Do the route tables steer traffic through the firewall?
  • Is DNS resolution aligned with the intended inspection logic?
  • Could asymmetric routing or forced tunneling be part of the problem?
Troubleshooting mindset

Firewall issue?
 ├─ Check subnet route tables
 ├─ Check rule type
 ├─ Check policy and rule order
 ├─ Check DNS behavior
 ├─ Check forced tunneling assumptions
 └─ Check inbound / outbound / hybrid path
Common trap: Teams often add more firewall rules first, when the real problem is that the traffic never reached the firewall at all.

Frequently asked questions

What is Azure Firewall in simple words?

It is Microsoft’s managed, centralized firewall service for Azure virtual network traffic.

What SKUs does Azure Firewall have?

Microsoft documents Basic, Standard, and Premium SKUs.

What rule types does Azure Firewall support?

It supports DNAT rules, network rules, and application rules.

What is the recommended way to configure Azure Firewall?

Microsoft recommends using Firewall Policy.

Can Azure Firewall do forced tunneling?

Yes, Azure Firewall supports forced tunneling for routing internet-bound traffic to another inspection point.

Does Azure Firewall replace NSGs?

No. Azure Firewall and NSGs solve different problems and are often used together.

Official Microsoft Azure documentation

These official Microsoft Azure references are useful if you want deeper platform details, SKU guidance, policy behavior, and deployment patterns for Azure Firewall.

Helpful next step: Use the official Microsoft Azure documentation above if you want deeper product details, deployment guidance, and architecture patterns for Azure Firewall.