Cloud / Azure Firewall Interview questions

Azure Firewall is a managed, cloud-native network security service that filters traffic for resources in Azure virtual networks. It is stateful, so return traffic for an allowed connection is permitted automatically, and it comes with built-in high availability and autoscaling. There are no firewall VMs for you to patch or size.

It filters on IP address, port, protocol and FQDN, supports inbound DNAT and outbound SNAT, and uses Microsoft threat intelligence to flag or block known malicious destinations. Logs flow into Azure Monitor.

In most designs it sits in a hub virtual network, and spoke traffic is routed through it with user-defined routes.

Azure Firewall comes in three tiers: Basic, Standard and Premium. Pick the tier by the inspection depth and throughput you need.

Tiers can be upgraded in place, and a Standard policy can be attached to a Premium firewall, but a Premium policy cannot be attached to a Standard firewall.

Azure Firewall's core job is controlling traffic by identity of the destination rather than just IP address. The main features are:

• Stateful filtering of network (L3/L4) and application (FQDN) traffic
• Built-in high availability and autoscaling, with optional availability zones
• FQDN tags and service tags for Microsoft services
• Threat intelligence filtering using Microsoft's feed
• Outbound SNAT and inbound DNAT, with multiple public IPs
• DNS proxy, forced tunneling and IP Groups
• Central management through Firewall Policy and Firewall Manager
• Logs and metrics in Azure Monitor

Premium adds TLS inspection, IDPS, URL filtering and web categories on top of this list.

AzureFirewallSubnet is the dedicated subnet where Azure Firewall places its instances. The name must match exactly, otherwise deployment fails.

The subnet needs a prefix of /26 or larger, which leaves room for the firewall to scale out. The firewall's private IP address comes from this range, and that address is what you use as the next hop in route tables.

Treat the subnet as reserved. Do not deploy other resources into it, and do not attach an NSG to it, because filtering is done by the firewall's own rules.

Azure Firewall has three rule types, and each solves a different problem.

Rules live in rule collections, which have an action (Allow or Deny) and a priority. Collections sit in rule collection groups inside a Firewall Policy. Anything not allowed is denied by default.

A Firewall Policy is a standalone Azure resource that holds the configuration for one or more firewalls: rule collection groups, rules, threat intelligence mode, DNS settings, and on Premium the IDPS and TLS inspection settings.

Because it is separate from the firewall, one policy can be associated with many firewalls across regions and subscriptions. Policies can also inherit from a parent policy, so a central security team sets baseline rules while application teams add their own in a child policy.

Policies are the recommended model. The older classic rules stored directly on the firewall cannot be shared or inherited, and Firewall Manager only works with policies.

An FQDN tag is a Microsoft-maintained group of fully qualified domain names that a well-known Azure or Microsoft service needs to function. Examples include WindowsUpdate, AzureBackup, WindowsVirtualDesktop and AzureKubernetesService.

Instead of hunting down and maintaining dozens of domains, you reference the tag in an application rule and Microsoft keeps the list current.

You cannot create your own FQDN tags, and they work only in application rules. For your own domain lists, use FQDN targets directly.

A typical rule allows source 10.1.0.0/24 to use the WindowsUpdate tag over HTTP and HTTPS, so patching works without opening general internet access.

A service tag represents a group of IP address prefixes for an Azure service, such as Storage, Sql or AzureMonitor. Microsoft updates the prefixes as the service changes, so your rules do not drift.

In Azure Firewall you use service tags as the destination in network rules. They are IP-based, so they work for non-HTTP traffic as well.

For instance, a network rule can allow a subnet to reach the Storage tag on port 443 while everything else stays denied. When Microsoft adds a new storage prefix, the rule covers it without any edit from you.

Threat intelligence filtering compares traffic against Microsoft's feed of known malicious IP addresses, FQDNs and URLs. These are sources tied to botnets, malware distribution and similar activity.

It has three modes: Off, Alert only and Alert and deny. Alert only is the default, which logs a match without blocking it. Basic supports alert mode only.

Threat intelligence is evaluated before your NAT, network and application rules, so a flagged destination is caught even if a broad allow rule would otherwise permit it. You can add allow-listed FQDNs and IPs to handle false positives.

SNAT (source network address translation) rewrites the source address of outbound traffic to the firewall's public IP, so internet destinations see the firewall rather than your private VM addresses.

By default Azure Firewall does not SNAT traffic going to private ranges such as RFC 1918 addresses, since both sides can route to each other. You can change this with the policy's private IP ranges setting, for example to SNAT traffic to an on-premises range that cannot route back to your spoke addresses.

Each public IP provides a limited pool of SNAT ports, so high-volume outbound workloads may need more public IPs or a NAT gateway.

You need four things: a VNet with a subnet named AzureFirewallSubnet, a Standard static public IP, a Firewall Policy, and the firewall itself with an IP configuration tying them together.

az network vnet create -g rg-hub -n vnet-hub --address-prefixes 10.0.0.0/16 \
  --subnet-name AzureFirewallSubnet --subnet-prefixes 10.0.0.0/26
az network public-ip create -g rg-hub -n pip-fw --sku Standard --allocation-method Static
az network firewall policy create -g rg-hub -n fwpol-hub --sku Standard
az network firewall create -g rg-hub -n fw-hub --sku AZFW_VNet --tier Standard \
  --firewall-policy fwpol-hub
az network firewall ip-config create -g rg-hub -f fw-hub -n fw-ipconfig \
  --public-ip-address pip-fw --vnet-name vnet-hub

Older CLI versions need the azure-firewall extension. After deployment, note the firewall's private IP, because your route tables will point to it.

An IP Group is a named, reusable set of IP addresses, ranges or CIDR blocks that you reference in the source or destination of DNAT, network and application rules.

If ten rules refer to the same branch-office ranges, you can store those ranges once in an IP Group and update the group when a range changes. Every rule that uses it picks up the change, so there is no hunting through collections.

IP Groups keep rules readable and cut down on mistakes, especially when the same address sets appear across several policies.

A typical example is an IP Group named branch-offices that holds every branch CIDR range. Rules that allow branch access to a shared service all point to that group, and onboarding a new branch is a one-line change.

Azure Firewall Manager is a central management service for Azure Firewall deployments across subscriptions and regions. Its main object is the Firewall Policy, which you create once and associate with many firewalls.

It supports two architectures: a hub virtual network, where you run the firewall in your own VNet, and a secured virtual hub, which is a Virtual WAN hub with a firewall built in. Firewall Manager also handles route configuration to send traffic through the secured hub.

Policy inheritance is the other big draw, since a global base policy can be enforced while local teams manage child policies.

Azure Firewall Premium adds deeper inspection on top of Standard: TLS inspection, IDPS (signature-based intrusion detection and prevention), URL filtering and web categories.

You need it when filtering by domain is not enough. For example, compliance frameworks such as PCI DSS expect intrusion detection, and security teams often want to see inside encrypted traffic or block categories such as gambling or anonymizers.

Premium needs a Premium Firewall Policy and runs on higher-performance infrastructure, so it costs more per hour and per GB than Standard. If you only need FQDN and network filtering, Standard is enough.

When DNS proxy is enabled, the firewall listens on port 53 and forwards queries from your VMs to the DNS servers you configure, or to Azure DNS by default. You point the VNet's DNS setting to the firewall's private IP.

This matters for FQDN filtering. The firewall and the client resolve the same name through the same path, so the IP in a network rule that uses an FQDN matches what the client actually connects to.

It also gives you DNS query logging, and it lets you route queries to custom or on-premises DNS servers from one place.

To set it up, enable DNS proxy in the firewall policy, optionally add custom DNS servers, then change the VNet's DNS servers setting to the firewall's private IP. Restart or renew the VMs' DHCP lease so they pick up the change.

Azure Firewall only sees traffic that is sent to it, so you use a user-defined route (UDR). Create a route table with a default route 0.0.0.0/0, set the next hop type to Virtual appliance, set the next hop address to the firewall's private IP, and attach it to each spoke subnet.

az network route-table create -g rg-spoke -n rt-spoke --disable-bgp-route-propagation true
az network route-table route create -g rg-spoke --route-table-name rt-spoke \
  -n default-to-fw --address-prefix 0.0.0.0/0 \
  --next-hop-type VirtualAppliance --next-hop-ip-address 10.0.0.4
az network vnet subnet update -g rg-spoke --vnet-name vnet-spoke -n snet-app \
  --route-table rt-spoke

Spoke-to-spoke traffic also needs routes pointing at the firewall, and peerings must allow forwarded traffic. Without these, spokes may talk directly and bypass inspection.

A DNAT rule maps a destination address and port on the firewall's public IP to a private address and port behind it.

1. Pick a public IP attached to the firewall.
2. Create a DNAT rule collection in a rule collection group.
3. Set the source to the allowed clients, the destination to the firewall's public IP, and the destination port, for example 443.
4. Set the translated address to the web server's private IP, and the translated port, for example 8443.
5. Make sure the web subnet's route sends return traffic back through the firewall.

The firewall automatically allows the translated flow with an implicit network rule, so you do not add a second rule. Limit the source to known ranges rather than *, since a wide-open DNAT rule exposes the server to the whole internet.

Azure Firewall billing has two main parts: a fixed hourly deployment charge that depends on the SKU, and a data processing charge per GB for traffic that passes through. Premium rates are higher than Standard, and Basic is the cheapest.

Billing starts as soon as the firewall is deployed, whether or not it handles traffic. Public IP addresses, log storage and Log Analytics ingestion are billed separately, and so are data transfer charges for peered VNets or cross-region traffic.

A development firewall left running around the clock can cost more than the VMs it protects, so deallocating it when idle is worth considering.

Azure Firewall writes its logs through diagnostic settings, so nothing is stored unless you turn it on. Logs can go to a Log Analytics workspace, a storage account or an event hub.

The main categories are application rule logs, network rule logs, NAT rule logs, DNS proxy logs, and threat intelligence logs, plus IDPS logs on Premium. Each entry shows the source, destination, protocol, action and which rule matched.

In resource-specific mode, logs land in dedicated tables such as AZFWApplicationRule, AZFWNetworkRule, AZFWNatRule, AZFWThreatIntel, AZFWIdpsSignature and AZFWDnsQuery. This is easier to query and cheaper than the older single AzureDiagnostics table.

A handful of platform metrics tell you whether the firewall is healthy and right-sized.

• Firewall health state shows whether the firewall is healthy or degraded, for example from SNAT port pressure.
• Throughput shows how close you are to the SKU's capacity.
• SNAT port utilization warns you before outbound connections start failing.
• Data processed helps explain and forecast the bill.
• Application and network rule hit count shows which rules are actually used.
• Latency probe gives an indication of the firewall's average latency.

Create alerts on SNAT port utilization and firewall health at a minimum. Those are the two that most often precede an outage.

Both filter traffic, but they work at different scopes. An NSG is a free, distributed filter applied to a subnet or NIC that works on IP, port and protocol. Azure Firewall is a centralized, managed service that adds FQDN filtering, threat intelligence, central logging and shared policy.

They complement each other. Use NSGs for micro-segmentation inside a subnet or between tiers, and Azure Firewall for central egress control and east-west inspection between spokes.

Azure Firewall is a network firewall. It controls outbound, spoke-to-spoke and hybrid traffic for any protocol, and publishes services through DNAT. Application Gateway with WAF is a regional L7 reverse proxy that protects inbound HTTP and HTTPS applications from attacks such as SQL injection and cross-site scripting using OWASP rules.

For internet-facing web apps, a common pattern is WAF in front and Azure Firewall controlling the rest.

Azure Firewall stops at the first rule that matches, and anything unmatched is denied. With a Firewall Policy, the evaluation works like this:

1. Threat intelligence is checked first, and may alert or deny.
2. Rule collection groups are processed by priority, lowest number first (range 100 to 65000).
3. Inside a group, collections are processed by type: DNAT, then network, then application, and by priority within each type.
4. If no rule matches, the default is deny.

flowchart TD
  A["Packet arrives"] --> B{Threat intel match?}
  B -- Deny mode --> X[Drop]
  B -- No --> C{DNAT rule match?}
  C -- Yes --> T["Translate and allow"]
  C -- No --> D{Network rule match?}
  D -- Yes --> E["Apply allow or deny"]
  D -- No --> F{Application rule match?}
  F -- Yes --> G["Apply allow or deny"]
  F -- No --> H["Default deny"]

A practical result is that a network rule matching a flow means the application rules are never evaluated for it.

Use an application rule with the protocol (HTTP, HTTPS) and the target FQDN. Place it in a rule collection in a rule collection group on the firewall's policy.

az network firewall policy rule-collection-group create -g rg-hub \
  --policy-name fwpol-hub -n AppRuleGroup --priority 300

az network firewall policy rule-collection-group collection add-filter-collection \
  -g rg-hub --policy-name fwpol-hub --rule-collection-group-name AppRuleGroup \
  --name allow-docs --collection-priority 1000 --action Allow \
  --rule-name allow-learn --rule-type ApplicationRule \
  --source-addresses 10.1.0.0/24 --protocols Https=443 \
  --target-fqdns learn.microsoft.com

Wildcards such as *.contoso.com are supported. For HTTPS, Standard matches on the SNI in the TLS handshake, so it can filter by domain but not by URL path. URL paths need Premium with TLS inspection.

Remember that the rule collection group priority and the collection priority decide evaluation order, so place this allow above any broad deny.

Extra public IPs give you two things: more SNAT capacity and more control over outbound addresses.

Each public IP provides its own pool of SNAT ports, so adding IPs raises the number of simultaneous outbound connections to the same destination. This helps when the firewall serves many VMs calling a small set of endpoints.

Multiple IPs also let you expose several services on the same port through DNAT, each on its own address, and give you a fixed set of source addresses that partners can add to their allow-lists. Public IP prefixes are a convenient way to get a contiguous block.

Azure Firewall scales out and in automatically, with no instance count to configure. It watches throughput, CPU and connection counts, and adds capacity when utilization crosses internal thresholds.

Scale-out is not instant and takes several minutes, so very sudden spikes can see brief degradation. Standard handles up to about 30 Gbps and Premium up to about 100 Gbps.

If you know a big event is coming, such as a load test, send traffic ahead of time to warm the firewall up. Watch the throughput and health metrics, and make sure the AzureFirewallSubnet is large enough (/26) to allow instances to be added.

Azure Firewall is built on multiple instances behind the scenes and replaces failed ones without your involvement. With a single region deployment, you can improve resilience further with availability zones.

When you deploy across two or three zones, instances are spread across physically separate datacenters in the region, so a zone outage does not take the firewall down. The service-level agreement is higher with zones than without.

Zones must be chosen at deployment time, and there is no extra charge for the configuration itself, but cross-zone data transfer may be billed. For disaster recovery across regions, deploy a second firewall and share a policy between them.

When a DNAT rule forwards traffic to a backend server, the firewall rewrites the destination to the private IP and also translates the source to its own private IP. The backend sees the firewall as the client.

This keeps the flow symmetric. The server replies to the firewall's address, and the response returns through the same firewall instance, so the stateful session is preserved. Without it, the server might reply using its default route and the traffic would bypass the firewall and break.

The downside is that the original client IP is lost in the server's own logs. To keep it, use an Application Gateway in front, which adds an X-Forwarded-For header, or read the real client address from the firewall logs.

SNAT port exhaustion shows up as intermittent outbound failures or timeouts to a specific destination, even though rules allow the traffic. Start with the SNAT port utilization metric. A value near 100 percent confirms the problem.

Then fix it in order of effort:

1. Add more public IPs or a public IP prefix, since each IP brings its own SNAT ports.
2. Associate a NAT gateway with the AzureFirewallSubnet, which supports many more ports and IPs.
3. Reduce port usage in the application with connection pooling and keep-alives.
4. Check logs to find which source is opening the most connections to one destination.

Ports are allocated per destination, so many connections to the same IP and port consume them fastest.

Choose Azure Firewall when you want a managed service with minimal operations: no VMs to patch, built-in scaling and high availability, native Azure Monitor integration and rule changes through policy or IaC.

Choose a third-party network virtual appliance when you need a specific feature set or vendor tooling that Azure Firewall does not provide, for example advanced application-layer controls tied to an existing enterprise firewall vendor, or one consistent policy across on-premises and cloud from that vendor.

Many large organizations run both, with Azure Firewall for general egress and an NVA for specialized needs.

In hub-and-spoke, shared services live in a hub VNet and each workload lives in a spoke VNet peered to the hub. Azure Firewall sits in the hub, and every spoke subnet has a UDR sending 0.0.0.0/0 to the firewall's private IP.

That puts one inspection point on internet egress, spoke-to-spoke traffic, and traffic to or from on-premises through the gateway in the hub. Rules, logging and threat intelligence are managed in one place instead of per spoke.

flowchart LR
  S1["Spoke A VNet"] -- UDR 0.0.0.0/0 --> FW["Azure Firewall in Hub VNet"]
  S2["Spoke B VNet"] -- UDR 0.0.0.0/0 --> FW
  FW --> I[Internet]
  FW --> G["VPN or ExpressRoute Gateway"]
  G --> O[On-premises]

Peerings need allow forwarded traffic enabled, and spoke route tables should not learn gateway routes by BGP, or traffic may skip the firewall.

Forced tunneling sends all internet-bound traffic from the firewall to another next hop, such as an on-premises firewall or an NVA, instead of straight to the internet.

Azure Firewall needs a separate path for its own management traffic, so you must create a second subnet called AzureFirewallManagementSubnet (/26 or larger) with its own public IP. This management NIC keeps talking to Azure directly.

1. Create AzureFirewallManagementSubnet and a management public IP.
2. Deploy the firewall with the management IP configuration.
3. Add a route table on AzureFirewallSubnet with 0.0.0.0/0 pointing to the on-premises or NVA next hop, or learn the default route over BGP.

Remember that SNAT then happens at the next hop, so make sure return routes work, and that Basic always uses the management subnet.

A network rule works on IP addresses, so when you use an FQDN as the destination the firewall must resolve it to IPs. If the client resolves the name using a different DNS server or at a different moment, the two can get different answers, which is common with CDNs and geo-DNS.

The result is that the firewall allows one IP while the client connects to another, and the rule seems to randomly fail. Enabling DNS proxy makes clients resolve through the firewall, so both use the same answers and stay in step.

For this reason, FQDN in network rules is only supported when DNS proxy is on. For plain web traffic, an application rule avoids the problem because it matches on the name inside the request, not on a resolved IP.

Send logs to Log Analytics in resource-specific mode and query the rule tables. This example shows the top blocked web destinations in the last hour:

AZFWApplicationRule
| where TimeGenerated > ago(1h) and Action == "Deny"
| summarize Hits = count() by SourceIp, Fqdn, Rule
| top 20 by Hits desc

For non-web traffic, query AZFWNetworkRule the same way and group by DestinationIp and DestinationPort. If a flow does not appear in either table, it may have been dropped earlier by threat intelligence, so also check AZFWThreatIntel.

Look at the Rule, RuleCollection and Policy columns to see exactly which rule decided the outcome.

Start with what you must inspect, then size for throughput and budget.

• Basic: small environments with modest traffic, up to about 250 Mbps, and simple filtering with threat intelligence in alert mode.
• Standard: the usual choice for production egress control with FQDN, network rules and threat intelligence deny, up to about 30 Gbps.
• Premium: when you must see inside TLS, need IDPS, URL filtering or web categories, or work under compliance rules that require them, up to about 100 Gbps.

Moving from Standard to Premium is an in-place upgrade, so starting at Standard is low risk. Keep in mind that Premium needs a Premium policy, and that TLS inspection requires certificate setup with Key Vault and client trust of your CA.

A child policy inherits everything from its parent policy. This lets a central security team publish a baseline that application teams cannot weaken.

Rules from the parent are always evaluated before the child's rules, whatever priority numbers the child uses. The child can add its own rule collection groups, but cannot edit or remove inherited ones.

Settings such as DNS, threat intelligence mode and IDPS are inherited too, and the child can override them where allowed. Any change to the parent flows to all children automatically.

For example, a central team can enforce a parent rule that denies known risky categories, while each application team adds a child rule collection group to allow its own FQDNs.

IDPS inspects traffic for known attack patterns using a signature database with tens of thousands of signatures across dozens of categories, such as malware, exploits and command-and-control. Microsoft updates the signatures continuously.

You choose one of three modes in the policy: Off, Alert or Alert and deny. Start in Alert mode, review which signatures fire, then move to Alert and deny. You can override individual signatures when a legitimate application triggers a false positive, and bypass specific sources or destinations.

IDPS covers inbound, outbound, spoke-to-spoke and hybrid traffic. To inspect the content of encrypted sessions, it must be combined with TLS inspection, otherwise it can only see unencrypted payloads and headers.

With TLS inspection, the firewall acts as a trusted man-in-the-middle for outbound HTTPS. It ends the client's TLS session, inspects the clear text, then opens a new TLS session to the real server.

sequenceDiagram
  participant C as Client
  participant F as Azure Firewall Premium
  participant S as Web Server
  C->>F: TLS ClientHello for site
  F->>S: New TLS session to the real site
  S-->>F: Server certificate
  F-->>C: Certificate for site signed by your intermediate CA
  C->>F: Encrypted request
  F->>F: Decrypt, apply IDPS and URL filtering
  F->>S: Re-encrypted request

Setting it up needs a Premium policy, an intermediate CA certificate stored in Key Vault, a managed identity so the firewall can read it, and TLS inspection enabled in the application rules. Clients must trust your root CA, or they will see certificate warnings.

You can exclude sensitive categories such as banking or healthcare from inspection for privacy and compliance.

All three decide which web destinations are allowed, but at different levels of detail.

FQDN rules are blunt but cheap and need no certificates. Use URL filtering when only part of a site should be reachable, and web categories when managing thousands of domains by hand is impractical.

Traffic from on-premises arrives through a VPN or ExpressRoute gateway in the hub. To inspect it, you must make sure it goes to the firewall before reaching spokes, and that replies take the same path.

1. On the GatewaySubnet, add a route table with the spoke address prefixes pointing to the firewall's private IP.
2. On each spoke subnet, add a route sending on-premises prefixes (or 0.0.0.0/0) to the firewall, and disable BGP propagation on that route table.
3. Create network rules allowing the required on-premises and spoke ranges.
4. Review SNAT settings so replies return to the same firewall.

Without the gateway route table, traffic would be forwarded directly into the spoke by the peering and bypass the firewall.

Work from the symptom to the rule that made the decision.

1. Confirm traffic actually reaches the firewall. Check the VM's effective routes, or use Network Watcher next hop.
2. Search AZFWNetworkRule and AZFWApplicationRule logs by source IP and destination. Note the action and rule name.
3. If there is no entry, check AZFWThreatIntel and AZFWIdpsSignature, since these can block earlier.
4. Check the rule order. A broad deny or a higher-priority collection may match first.
5. For FQDN issues, verify DNS and whether DNS proxy is on, and look at AZFWFqdnResolveFailure if available.
6. Add or adjust the specific rule, then retest.

If there are no logs at all, the problem is usually upstream: the route table, an NSG or a peering setting.

Asymmetric routing happens when the request goes through the firewall but the reply takes a different path. Because the firewall is stateful, it sees a reply for a session it never saw and drops it. Typical symptoms are connections that hang after the SYN, or one-way traffic.

Common causes are a UDR on only one side of a spoke-to-spoke flow, on-premises routes that send replies straight to the spoke, or traffic within the same subnet that never leaves it.

• Check effective routes on both source and destination NICs.
• Make sure both sides route to the firewall for each other's prefixes.
• Use SNAT for the flow so replies return to the firewall's address.
• Review gateway route tables and BGP-learned routes that may override your UDRs.

The firewall logs often show only half of the flow, which is itself a clue.

By default, traffic to a private endpoint uses the more specific /32 system route and bypasses your UDR, so it never reaches the firewall.

There are two ways to bring it back:

• Enable network policies for private endpoints on the subnet that hosts the client, so UDRs and NSGs apply.
• Or add a /32 UDR for each private endpoint IP, pointing at the firewall.

az network vnet subnet update -g rg-spoke --vnet-name vnet-spoke -n snet-app \
  --private-endpoint-network-policies Enabled

Then allow the traffic with a network rule to the endpoint's private IP. Also SNAT this traffic so that replies come back through the firewall, as the endpoint would otherwise reply along a different path.

Over time, rule sets accumulate duplicates, overly broad allows and rules nobody uses. Policy Analytics in Firewall Manager helps by analyzing your logs against your policy.

It shows rule hit counts, finds unused and overlapping rules and suggests tighter source and destination scopes. It needs logs sent to Log Analytics in resource-specific mode.

• Remove or disable rules with no hits over a long period.
• Replace * sources and destinations with specific ranges.
• Use IP Groups and FQDN or service tags to reduce rule count.
• Merge rules that differ only by one address.
• Keep frequently hit rules at lower priority numbers within their type.

Smaller, cleaner rule sets are easier to audit and faster to change safely.

Cost is mostly the hourly deployment charge plus data processed, so reduce both.

• Share one firewall in a hub for many spokes instead of one per workload.
• Use the right SKU: Basic for dev or small sites, Standard by default, Premium only where required.
• Deallocate non-production firewalls outside working hours.
• Keep traffic that does not need inspection off the firewall, for example low-risk traffic within a spoke, which an NSG can handle.
• Avoid cross-region and unnecessary hairpin traffic through the firewall.
• Trim logging to what you use, and consider cheaper log tiers.

Review the data processed metric to see where the volume comes from before changing the design.

In Azure Virtual WAN, a hub that includes an Azure Firewall is called a secured virtual hub. Microsoft manages the hub infrastructure, and you manage the firewall through Firewall Manager and a Firewall Policy.

Traffic is steered by routing intent and policies. You choose whether private traffic (VNet-to-VNet, branch-to-VNet), internet traffic, or both go through the firewall, and Virtual WAN programs the routes for you.

The trade-off is less flexibility in exchange for much less routing work.

In Bicep you declare a firewallPolicies resource and an azureFirewalls resource that references it, together with the subnet and public IP IDs.

param fwSubnetId string
param pipId string

resource pol 'Microsoft.Network/firewallPolicies@2023-09-01' = {
  name: 'fwpol-hub'
  location: resourceGroup().location
  properties: {
    sku: { tier: 'Standard' }
    threatIntelMode: 'Alert'
  }
}

resource fw 'Microsoft.Network/azureFirewalls@2023-09-01' = {
  name: 'fw-hub'
  location: resourceGroup().location
  properties: {
    sku: { name: 'AZFW_VNet', tier: 'Standard' }
    firewallPolicy: { id: pol.id }
    ipConfigurations: [
      {
        name: 'fw-ipconfig'
        properties: {
          subnet: { id: fwSubnetId }
          publicIPAddress: { id: pipId }
        }
      }
    ]
  }
}

Rule collection groups are separate child resources of the policy. Keeping them in the same template means firewall changes go through code review and your pipeline.

Azure Firewall is capable, but a few limits are worth knowing before you design around it.

• IPv4 only. IPv6 traffic is not supported.
• No NSG on AzureFirewallSubnet, and the subnet is dedicated to the firewall.
• Application rules cover HTTP, HTTPS and MSSQL. Other protocols use network rules.
• Standard filters HTTPS by domain only. Full URL paths need Premium with TLS inspection.
• SNAT ports are finite per public IP, and heavy outbound use may need extra IPs or a NAT gateway.
• Scale-out takes minutes, so sudden spikes can briefly strain it.
• FQDN in network rules needs DNS proxy.
• It is not a WAF, so web application attack protection needs Application Gateway or Front Door.

Check the current service limits page before committing to large rule counts or throughput targets.

Take a VM in a spoke calling an external HTTPS site. Here is what happens:

sequenceDiagram
  participant VM as Spoke VM
  participant FW as Azure Firewall
  participant Web as Internet Site
  VM->>FW: Request sent via UDR next hop
  FW->>FW: Threat intel check
  FW->>FW: Network rules, then application rules
  FW->>Web: Allowed request, source SNATed to firewall public IP
  Web-->>FW: Response to firewall public IP
  FW-->>VM: Response translated back and returned

1. The VM's route table sends 0.0.0.0/0 to the firewall's private IP.
2. The firewall checks threat intelligence, then DNAT, network and application rules in order.
3. If allowed, it rewrites the source to one of its public IPs and records the session.
4. The reply arrives at the public IP, matches the session, and is translated back to the VM.

A deny at any stage drops the packet and writes a log entry with the rule that matched.

To control outbound traffic from an AKS cluster, route it through the firewall and allow only what the cluster needs.

1. Put the cluster in a subnet with a route table sending 0.0.0.0/0 to the firewall's private IP.
2. Create the cluster with --outbound-type userDefinedRouting so AKS does not create its own public egress.
3. Add an application rule using the AzureKubernetesService FQDN tag for required Microsoft endpoints.
4. Add network rules for items such as time sync and DNS, and rules for your container registries.

az aks create -g rg-aks -n aks1 --vnet-subnet-id $SUBNET_ID \
  --outbound-type userDefinedRouting

For inbound services exposed through a load balancer, use a DNAT rule, and make sure replies are SNATed to avoid asymmetric routing. Verify the required endpoint list in the current AKS documentation, since it changes.