Microsoft AZ-104: Designing Azure Firewall Egress
Azure Firewall egress design controls which workloads can reach external destinations, how that traffic is inspected, which source addresses outside systems see, and how operators prove that a flow was permitted. A strong design combines routing, Firewall Policy, network and application rules, DNS, FQDN handling, source NAT, private endpoints, logging, and workload identity or application controls where network information alone is insufficient.
Microsoft’s current Azure Firewall guidance distinguishes network rules from application rules and supports FQDN filtering in different ways. Application rules can filter HTTP/S and MSSQL traffic by requested FQDN using the application proxy path, while FQDN tags provide Microsoft-maintained destination groups for selected services. Network-rule FQDN handling has different behavior and should not be treated as equivalent to Layer 7 application filtering.
Egress architecture belongs inside Azure Architecture in Practice.
Force the intended path first
Routing must send workload egress through the firewall before any rule can control it.
Azure path troubleshooting should validate effective routes, UDRs, hub/spoke propagation, NVAs, and return path before firewall policy is changed.
A correct Firewall Policy cannot inspect traffic that reaches the internet through another route.
Use application rules for web destinations
Application rules are designed for HTTP/S and supported application protocols where FQDN-based control and application-layer context are useful.
They can match the original requested hostname using protocol information such as TLS SNI.
This is stronger than allowing broad destination IP ranges for SaaS endpoints that change frequently.
Use network rules for transport-level traffic
Network rules match Layer 3/4 properties such as source, destination, protocol, and port.
Use them for non-HTTP protocols, private destinations, or flows where application-layer proxy behavior is not appropriate.
Azure network controls should place Azure Firewall, NSGs, ASGs, and workload authorization at the layer where each control has the strongest context.
Use FQDN tags where Microsoft maintains the list
FQDN tags can simplify access to selected Microsoft services whose endpoints change over time.
Microsoft maintains the destination list behind each supported tag.
Use the tag only when the business need matches its documented scope; a broad service tag can allow more destinations than one workload actually requires.
Coordinate DNS and FQDN filtering
FQDN-based security depends on correct name resolution and, in some scenarios, firewall DNS proxy or consistent DNS behavior.
Hybrid DNS should be part of egress architecture because split-horizon or private DNS can cause the same hostname to resolve differently across networks.
Do not troubleshoot a hostname rule only by looking at the public DNS answer from an administrator workstation.
Prefer private access where it removes internet egress
Private endpoints can move supported PaaS access onto private addresses and reduce the number of destinations that need public egress rules.
Private endpoints still require DNS, routing, authorization, and governance; they do not automatically make the service safe.
Use private access when it aligns with the workload’s network and data requirements rather than merely to avoid firewall rule management.
Plan source NAT and public IPs
External partners may allowlist the firewall’s public egress addresses.
Design enough public IP capacity for expected connections and understand Azure Firewall SNAT behavior for the SKU and architecture in use.
Document which applications depend on a stable public source so a firewall-scale or IP change does not become an unexplained partner outage.
Use Firewall Policy as shared configuration
Firewall Policy can centralize rule collections and hierarchy across multiple firewalls where the enterprise design supports it.
Shared policy should contain genuinely shared controls while application-specific rules remain owned and reviewable.
Broad central rules should not become a shortcut that allows every workload to reach the same external destinations.
Operate egress through logs and ownership
Log rule matches, denies, threat detections, DNS/FQDN issues, and connection failures according to operational need.
For AZ-700, the durable egress design is route → rule type → destination identity → DNS → SNAT → logging → workload owner.
When one flow fails, operators should be able to show which route and rule evaluated it rather than adding a temporary allow-all rule.
Egress exceptions should have owners and expiry. Temporary access to vendor support, package repositories, or migration endpoints often becomes permanent when nobody revisits it. Keep exception scope narrow by source workload, protocol, and destination.
TLS inspection, IDPS, and premium firewall features can improve visibility but add cost, latency, and compatibility considerations. Apply them according to threat and data sensitivity rather than assuming every internet flow requires identical inspection.
Forced tunneling and on-premises inspection can be valid designs, but they add WAN and datacenter dependencies to cloud egress. Measure the resilience and latency tradeoff before routing every Azure internet connection back through a corporate perimeter.
Egress governance is mature when platform teams can publish a default route and firewall pattern, while application teams can request narrow destinations with enough business context for review and automated lifecycle.
Application and network rule collection order should be understood before troubleshooting. Azure Firewall evaluates rule collection groups and rule collections according to Firewall Policy priorities and rule-processing semantics. Central policy should keep priority ranges organized so platform rules, security controls, and application exceptions do not become an unpredictable ordering contest.
Service Tags can simplify network rules for Azure service address ranges, while FQDN tags simplify selected Microsoft-service application rules. These are different abstractions. Use the one appropriate to the layer and documented service behavior instead of treating all tags as interchangeable destination lists.
DNS proxy can help align FQDN resolution between clients and Azure Firewall in architectures that use FQDN filtering. If the firewall resolves a hostname to a different address set than the client uses, network-rule FQDN behavior can be surprising. Keep resolver path and TTL behavior part of the troubleshooting runbook.
SNAT port exhaustion should be considered for high-connection egress workloads. Large numbers of outbound connections can consume translated ports on public IP addresses. Capacity planning should include connection concurrency and scale, and the architecture should use enough public IP capacity or the supported design pattern for its traffic profile.
Premium TLS inspection and IDPS should have explicit exception governance. Some destinations may use certificate pinning or protocols that cannot be inspected transparently. Narrow exceptions by source and destination where possible and review them after application changes.
Firewall Policy inheritance can make enterprise rule management easier but can also hide why a rule exists. Base policy should contain universal controls; child policy should contain environment or workload-specific rules. Document rule ownership so an application team knows whether it can change a deny that originates centrally.
Forced tunneling should be evaluated carefully because it can make on-premises internet gateways, WAN circuits, and corporate firewalls dependencies for Azure workloads. If the security model requires centralized on-premises egress, test the availability and latency path under datacenter and WAN failure.
Azure Firewall logs should be tied to rule owners and application flows. A deny is actionable when operators can identify source workload, intended destination, matching collection, DNS result, and required business exception. Generic deny dashboards create noise if no team owns the remediation.
The best egress design is predictable: workloads use a known route, destination controls match at the correct layer, exceptions are narrow and expiring, SNAT capacity is sufficient, and private service access removes public egress where it meaningfully reduces risk.
Application owners should provide the destination intent rather than a raw list of IP addresses wherever possible. “Reach Microsoft Update” or “reach vendor API X” is easier to govern when the firewall policy uses supported FQDN tags or FQDNs than when administrators manually maintain changing address ranges.
Network-rule FQDN scenarios should be tested with DNS TTL and resolution behavior. A firewall can continue using resolved addresses until refresh while an external provider changes records. Time-sensitive services should be validated under address rotation rather than assumed to behave like static IP destinations.
Hub-and-spoke environments need clear ownership for spoke UDRs and central firewall policy. A spoke team can accidentally bypass the firewall by changing a route, while a platform team can break an application by changing a shared egress rule. Policy and route changes should therefore be reviewed together for critical flows.
Outbound architectures should document what happens if Azure Firewall is unavailable or reaches capacity. Zone-redundant deployment and autoscaling reduce some risk, but workloads still need retry behavior and service-level expectations for transient egress loss.
Keep a representative egress test suite for software updates, package repositories, SaaS APIs, identity endpoints, monitoring agents, and private PaaS paths. Run it after major firewall, DNS, routing, or policy changes so broad enterprise egress remains predictable.
Rules should be removed when the application or dependency is retired. Egress policies tend to accumulate faster than ingress because outbound requests are often added during troubleshooting. Periodic review of hits, owners, and expiry can reduce attack surface and simplify future incident analysis.
Document the default egress behavior for every workload class—private-only, firewall-filtered internet, forced tunnel, or approved direct service path—so new applications start from a known architecture rather than inventing connectivity during deployment.
Review egress architecture whenever routing, DNS, firewall policy, or provider endpoints change materially.