Azure Firewall for Small Business Berlin: Network Security in Azure Virtual Networks

Every Azure workload that connects to the internet or communicates between virtual networks needs a defined network perimeter. Azure Firewall is Microsoft’s managed, cloud-native network security service that filters and logs all traffic entering, leaving, or crossing your Azure Virtual Networks (VNets) — without requiring you to manage underlying firewall appliances or patch network operating systems.

For small and mid-sized businesses in Berlin running workloads in Azure — whether virtual machines, App Services, Azure Virtual Desktop, or hybrid connectivity via ExpressRoute — Azure Firewall provides centralised traffic control with built-in high availability and auto-scaling. This post covers architecture, rule configuration, key security features, and integration with Microsoft Defender for Cloud and Azure Policy.

What Azure Firewall Does

Azure Firewall is a stateful, fully managed firewall-as-a-service deployed inside your Azure VNet. All traffic to and from your subnets is routed through the firewall via User-Defined Routes (UDRs), and the firewall applies rules in a defined priority order before permitting or denying connections.

Key capabilities include network rules (Layer 3/4 IP and port filtering), application rules (Layer 7 FQDN and protocol filtering), NAT rules (DNAT for inbound traffic), threat intelligence-based filtering (Microsoft Threat Intelligence feed), DNS proxy, and TLS inspection (Standard and Premium SKUs).

Azure Firewall SKU Comparison

Feature	Basic	Standard	Premium
Network rules (L3/L4)	✓	✓	✓
Application rules (L7 FQDN)	✓	✓	✓
Threat intelligence filtering	Alert only	Alert + Deny	Alert + Deny
DNS proxy	✗	✓	✓
IDPS (Intrusion Detection)	✗	✗	✓
TLS inspection	✗	✗	✓
URL category filtering	✗	✗	✓
Typical monthly cost (2 AZs)	~€100	~€250	~€450

For most Berlin SMBs, Standard SKU provides the right balance: full application-layer filtering, threat intelligence deny mode, DNS proxy, and structured firewall logs — at a predictable monthly cost.

Hub-and-Spoke Architecture

Azure Firewall is typically deployed in a hub VNet using a hub-and-spoke topology. The hub contains shared services — firewall, VPN gateway or ExpressRoute, Azure Bastion — while spoke VNets contain workloads. VNet peering connects spokes to the hub, and User-Defined Routes force all spoke-to-internet and spoke-to-spoke traffic through the firewall.

This design ensures centralised traffic inspection and logging regardless of which spoke VNet originates the connection. Azure Firewall Manager extends this model to manage policies across multiple firewalls and Secured Virtual Hubs (Azure Virtual WAN integration).

Core Deployment Components

• AzureFirewallSubnet: Dedicated /26 or larger subnet in the hub VNet — reserved name, cannot be changed
• Public IP: One or more standard SKU static public IPs assigned to the firewall for SNAT and DNAT
• Firewall Policy: Separate ARM resource containing all rules — can be shared across firewalls and inherits from parent policies
• Route Tables (UDR): 0.0.0.0/0 next-hop set to firewall private IP on all spoke subnets — forces traffic inspection
• Diagnostic Settings: Route firewall logs to Log Analytics for KQL-based analysis and Microsoft Sentinel ingestion

Rule Types and Priority

Azure Firewall processes rules in strict priority order: NAT rules → Network rules → Application rules. Within each collection, lower priority numbers are evaluated first. Rules are grouped into Rule Collections within a Firewall Policy, and collections are grouped into Rule Collection Groups.

Application Rules — FQDN Filtering

Application rules inspect HTTP/HTTPS/MSSQL traffic at Layer 7 and allow or deny connections based on fully qualified domain names. Example: allow traffic from a spoke subnet to *.microsoft.com, *.windowsupdate.com, and *.azure.com while denying all other internet-bound HTTP/HTTPS. With Premium SKU, TLS inspection decrypts HTTPS to inspect the full request URI.

FQDN tags simplify common Microsoft service allowlisting — tags like WindowsUpdate, WindowsDiagnostics, and MicrosoftActiveProtectionService resolve all required endpoints automatically and update as Microsoft changes its service IPs.

Network Rules — IP and Port Filtering

Network rules operate at Layer 3/4 and filter based on source/destination IP, protocol (TCP/UDP/ICMP/Any), and port. Use network rules for non-HTTP traffic: on-premises to Azure RDP/SSH (complementary to Azure Bastion for management), inter-spoke database connectivity, or DNS forwarding. Network rules support IP Groups — logical groupings of IP ranges that simplify rule management across multiple rule collections.

DNAT Rules — Inbound Traffic

DNAT rules translate inbound connections from a firewall public IP to a private IP in your VNet. For example, translating public-IP:443 to an internal web server at 10.1.0.4:443. Note: for most scenarios, Azure Application Gateway or Azure Front Door provides a better inbound path with WAF capabilities — DNAT is more appropriate for simple TCP port forwarding not requiring HTTP-layer inspection.

Threat Intelligence and DNS Proxy

Threat Intelligence filtering uses Microsoft’s continuously updated feed of known malicious IPs and FQDNs. In Alert + Deny mode (Standard and Premium), connections to known malicious destinations are blocked before any other rule is evaluated and logged with threat category, source, and destination. This provides zero-configuration protection against command-and-control traffic, botnet callbacks, and connections to known malware distribution points.

The DNS proxy feature enables Azure Firewall to act as a DNS resolver for VNet resources, forwarding queries to Azure DNS or custom DNS servers. Enabling DNS proxy is a prerequisite for FQDN-based filtering in network rules (not required for application rules which perform their own DNS resolution). It also centralises DNS query logging — all DNS requests from VNet resources appear in firewall diagnostic logs.

Integration with Defender for Cloud and Azure Policy

Microsoft Defender for Cloud includes recommendations for Azure Firewall deployment — specifically flagging subnets that route internet traffic without firewall protection. The Microsoft Cloud Security Benchmark (MCSB) maps directly to Azure Policy built-in initiatives, and the “Azure Firewall should be deployed in VNets” recommendation surfaces automatically in Defender for Cloud when workloads exist without centralised network filtering.

Azure Policy can enforce firewall policy inheritance across subscriptions — for example, using a DeployIfNotExists policy to ensure all new VNets have a UDR routing 0.0.0.0/0 to the centralised firewall. Azure Firewall Manager’s Secured Virtual Hub configuration integrates with Azure Policy assignments for consistent enforcement at scale.

Logging and Monitoring

Azure Firewall generates structured logs via Azure Monitor Diagnostic Settings. Route logs to a Log Analytics workspace and query with KQL:

// Top denied application rule hits in last 24h
AzureDiagnostics
| where Category == "AzureFirewallApplicationRule"
| where msg_s contains "Deny"
| summarize Count = count() by Fqdn = extract(@"Fqdn: ([^,]+)", 1, msg_s)
| top 20 by Count

For threat intelligence alerts, the AzureFirewallNetworkRule and AzureFirewallThreatIntel log categories show blocked connections with threat category classification. Microsoft Sentinel’s Azure Firewall connector ingests these logs for SIEM correlation — connecting firewall denials to identity events, endpoint alerts, and other signals in a unified incident timeline.

Practical Deployment Steps for a Berlin SMB

1. Create hub VNet with AzureFirewallSubnet: Minimum /26 — larger if you plan to scale to multiple firewall instances or add Firewall Manager-managed policies
2. Deploy Azure Firewall (Standard SKU): Assign a Standard SKU public IP; enable DNS proxy; select or create a Firewall Policy
3. Create Firewall Policy with baseline rules: Allow FQDN tags (WindowsUpdate, MicrosoftActiveProtectionService), allow Azure management FQDNs (*.azure.com, *.microsoft.com), deny all other internet HTTP/HTTPS via application rules
4. Enable Threat Intelligence in Alert + Deny mode: Automatic protection against known malicious IPs/FQDNs with zero rule authoring
5. Configure UDRs on spoke subnets: 0.0.0.0/0 → firewall private IP; disable BGP propagation on the spoke route table
6. Route diagnostic logs to Log Analytics: Enable AzureFirewallApplicationRule, AzureFirewallNetworkRule, AzureFirewallThreatIntel, and AzureFirewallDNSProxy categories
7. Connect to Microsoft Sentinel: Enable Azure Firewall data connector in Sentinel for cross-signal correlation with Entra ID, MDE, and MDI alerts

Azure Firewall vs. Network Security Groups (NSG)

NSGs operate at the subnet and NIC level and provide basic Layer 4 allow/deny rules. Azure Firewall operates centrally across the entire VNet topology and adds Layer 7 application filtering, FQDN resolution, threat intelligence, and centralised logging. The two are complementary: NSGs provide defence-in-depth at the resource level (deny lateral movement between subnets) while Azure Firewall controls north-south traffic and enforces centralised egress policy. For regulated workloads or any environment with multiple VNets, using both is the recommended architecture.

Cost Management

Azure Firewall pricing has two components: a fixed deployment cost (per firewall-hour) and a data processing cost (per GB processed). Standard SKU costs approximately €1.20/hour plus €0.016/GB. For a small environment processing 500 GB/month, total cost is approximately €250-300/month. Using Firewall Policy (rather than classic rules) enables rule sharing across multiple firewalls — relevant if you manage more than one Azure subscription. Azure Firewall Manager Premium is an additional cost for policy management at scale.

IT Experts Berlin designs and deploys Azure Firewall policies for Berlin-based SMBs migrating workloads to Azure — including hub-and-spoke VNet architecture, Firewall Policy rule authoring, Log Analytics integration, and Microsoft Sentinel connectivity. Contact us to discuss your network security requirements.