Zero Trust has become one of the most overused terms in enterprise IT. Every vendor claims their product is "Zero Trust ready." Every security framework references it. And yet, for a business actually trying to implement it in Azure, the question of which services to use, in what order, and configured how, is rarely answered clearly.
This post is about three specific Azure services — Azure Firewall, Azure DDoS Protection, and Azure Web Application Firewall — and how they fit together to create a genuine layered defence. Not in theory. In practice, with real attack scenarios and configuration guidance that applies to businesses operating in Germany and the broader EU.
What Zero Trust Actually Requires at the Network Layer
The Zero Trust model, as originally defined by John Kindervag at Forrester Research, starts from a single assumption: the network perimeter does not exist. Any device, on any network, could be compromised. Therefore, every access request must be verified, and no traffic should be implicitly trusted because it originates inside your infrastructure.
At the network layer, this translates into three concrete requirements:
- Inspect all traffic, including traffic between internal services — not just traffic entering from the internet.
- Apply least-privilege access at the network level, so a compromised VM in one subnet cannot freely communicate with a database in another.
- Assume breach — design your architecture so that a successful intrusion in one layer does not automatically give an attacker access to everything else.
This is where Azure Firewall, WAF, and DDoS Protection each play a specific role. They are not redundant — they operate at different layers of the OSI model and protect against fundamentally different attack classes.
Azure DDoS Protection: Defence at the Edge
A Distributed Denial of Service attack floods your infrastructure with traffic volume that legitimate users cannot compete with. Azure DDoS Protection Network operates at Layer 3 and Layer 4 — the network and transport layers — absorbing and scrubbing attack traffic before it reaches your Virtual Network.
Azure provides a basic level of DDoS protection to all customers at no cost. The Standard tier (now part of Azure DDoS Protection) adds adaptive tuning — the system learns your application's normal traffic patterns and adjusts mitigation thresholds automatically. It also provides attack telemetry and post-attack reports useful for incident documentation.
For most DACH businesses, the question is whether Standard is necessary. The answer depends on what you expose publicly. If you run public-facing web applications, APIs, or customer portals in Azure, Standard is worth considering. The cost is significant — roughly €2,500 per month for the first 100 protected resources — so it needs to be weighed against the actual risk profile of your applications.
NIS2 Note: Under the NIS2UmsuCG, organisations in scope must implement measures proportionate to their risk. For businesses running critical digital infrastructure, documented DDoS protection is increasingly part of what supervisory authorities expect to see in a security assessment. Azure DDoS Protection Standard provides the logging and reporting needed to demonstrate compliance.
Azure Web Application Firewall: Protecting Your Applications at Layer 7
WAF operates at the application layer — Layer 7 — inspecting HTTP and HTTPS request content rather than just IP addresses and ports. It sits in front of your web applications via Azure Application Gateway or Azure Front Door and blocks attacks that a network firewall simply cannot see.
What WAF Blocks
- SQL Injection: An attacker appends SQL syntax to a form field or URL parameter to manipulate your database. WAF detects the payload pattern and blocks the request before it reaches the application.
- Cross-Site Scripting (XSS): Malicious scripts injected into your web pages to steal session tokens or redirect users to phishing sites.
- Remote File Inclusion and Path Traversal: Attacks that attempt to access files outside the web root — a common vector against PHP applications and content management systems.
- Bot traffic: Azure WAF includes bot management rules that distinguish between legitimate crawlers (like Googlebot) and malicious scrapers or credential-stuffing bots.
Core Rule Sets and Custom Rules
Azure WAF uses the OWASP Core Rule Set (CRS) as its foundation. The current default is CRS 3.2, which maps directly to the OWASP Top 10 vulnerabilities. You can run WAF in Detection mode first — logging rule matches without blocking — to identify false positives before switching to Prevention mode.
Custom rules let you add business-specific logic: blocking requests from specific geographic regions, requiring specific headers, or rate-limiting aggressive IPs. For a German B2B application that has no legitimate reason to receive traffic from certain regions, geo-blocking via WAF custom rules is an effective first line of defence.
Azure Firewall Premium: Deep Inspection and Outbound Control
Azure Firewall is the central inspection point for all traffic flowing through your Virtual Network. The Premium tier adds capabilities that are essential for a genuine Zero Trust implementation:
- TLS inspection: Decrypts outbound HTTPS traffic to inspect it for malware and data exfiltration before re-encrypting. Without this, encrypted traffic bypasses all content inspection.
- IDPS (Intrusion Detection and Prevention System): Uses Microsoft's threat intelligence feed to identify and block known malicious patterns in network traffic — including command-and-control traffic from malware that has already gotten past endpoint defences.
- URL filtering: Blocks access to known malicious sites and allows you to enforce an allowlist approach for outbound web access from servers.
- East-west traffic control: Enforces segmentation between subnets. A compromised application server cannot reach your database subnet unless explicitly permitted by a Firewall rule.
BSI IT-Grundschutz Alignment
The BSI IT-Grundschutz building block NET.3.2 (Firewall) and NET.3.4 (Network Separation) both apply to Azure Firewall deployments. Specifically, NET.3.2.A1 requires that firewall rules follow the principle of minimal communication — only explicitly permitted traffic should flow. Azure Firewall's default-deny approach satisfies this requirement, but the rule base needs to be designed and documented to demonstrate compliance. Using Azure Firewall Policy and Azure Policy assignments provides the audit trail the BSI expects.
How the Three Services Work Together: A Reference Architecture
A complete Azure network security architecture positions these services in a specific order:
- Internet traffic arrives and is first processed by Azure DDoS Protection at the Virtual Network level — volumetric attacks are absorbed before reaching any service.
- HTTP/HTTPS application traffic then hits Azure Application Gateway with WAF enabled — SQL injection, XSS, and bot traffic are blocked at Layer 7.
- All remaining traffic — including outbound traffic from VMs and east-west traffic between subnets — is inspected by Azure Firewall Premium, which enforces segmentation, blocks known bad IPs, and inspects encrypted outbound traffic.
This is the Hub-and-Spoke or Azure Virtual WAN topology recommended by Microsoft for enterprise Azure deployments. The Firewall sits in a central hub Virtual Network and all spoke VNets route through it. This means you get centrally logged, centrally enforced network security policy rather than managing security groups on every individual subnet.
How IDE Solutions Can Help
Designing this correctly requires understanding which services your applications actually use, what your compliance obligations are, and how to balance security with the cost of running Azure Firewall Premium continuously. A misconfigured Firewall policy that is too permissive provides false confidence; one that is too restrictive breaks applications.
We design, deploy, and manage Azure network security architectures for DACH businesses. Our engagements include a threat model for your specific environment, a BSI IT-Grundschutz gap analysis, and a documented rule base that satisfies both technical and compliance requirements.
Reference: Microsoft Tech Community: Zero Trust with Azure Network Security