Blog ENG - MS Azure - Post 2 2025
The moment a platform team tells me, “We’re standardizing on Fortinet. Can we make that our security perimeter in Azure?”, I smile. You absolutely can. The key is to anchor FortiGate in a Landing Zone foundation and choose the right steering mechanism – UDRs in hub‑and‑spoke or routing intent in Virtual WAN – so inspection stays clean as you scale.
Why start with the Landing Zone (and not the firewall)?
Azure Landing Zones give you enterprise‑grade guardrails: management groups, subscriptions, identity, governance, network topology, and a dedicated Connectivity subscription where shared services (DNS, VPN/ExpressRoute, Bastion) and inspection live. Spoke VNets attach to the hub for consistent traffic control and policy. Build this platform baseline first; then drop in FortiGate. When migrating, Microsoft’s CAF checklist calls out hybrid connectivity, identity, hybrid DNS, and hub firewall config as prerequisites. Do these before you deploy NVAs. It prevents “retrofit pain” later.
Two topologies that work brilliantly with FortiGate
1) FortiGate NVAs in Hub‑and‑Spoke VNet
You deploy FortiGate in the hub VNet and steer spoke traffic through it with UDRs for north‑south (internet/hybrid) and east‑west (spoke‑to‑spoke) inspection. Microsoft documents these inspection patterns and they scale across two hubs/regions with peering.
Operationally, UDRs can explode as you add spokes. Azure Virtual Network Manager (AVNM) now centralizes UDR creation/assignment across multiple hubs/spokes, reducing drift and cut‑and‑paste errors.
For transparent inline public inspection, front your FortiGate pool with Gateway Load Balancer (GLB). GLB is a “bump‑in‑the‑wire”: it preserves original IPs, guarantees symmetric flows, and simplifies service chaining from public endpoints.
Fortinet specifics you’ll use:
– HA patterns: Fortinet provides reference architectures (Active‑Active/Active‑Passive with ELB/ILB, autoscale, AZ support) and example code; start with their Azure solutions repo.
– ALZ accelerator: Microsoft’s Terraform NVA scenario pre‑wires hub subnets (NVA, Gateway, Bastion, Private DNS Resolver) and spoke route tables. Great for pilots.
Field note: I’ve rescued more than one environment from UDR sprawl and asymmetric flows. In my experience, GLB + AVNM turns a fragile design into a resilient, repeatable one.
2) FortiGate in Azure Virtual WAN (vWAN) Secured Virtual Hub
If you need global transit across regions and branches, vWAN is the simpler control plane. In a secured vHub, you enable routing intent to forward Internet and/or Private traffic to your security stack (Azure Firewall or FortiGate NVA). It’s declarative (one policy per hub per traffic type) and avoids bespoke UDRs in each spoke. Azure vWAN offers third‑party integrations: Integrated NVAs run inside the vHub as Microsoft‑managed scale sets, with vendor software you control (versioning, policies). This is where Fortinet’s Secure SD‑WAN and NGFW services plug in cleanly.
Fortinet specifics you’ll use:
– FortiGate NGFW for Azure vWAN: solution brief + architectures for integrated hub, peered security services VNet, and on‑prem SD‑WAN on‑ramps.
– Routing intent flows (egress/ingress via FortiGate, DNAT/SNAT as needed) are documented; the vHub advertises defaults and steers spokes/branches through your next hop.
Field note: Don’t mix on‑prem quad‑zero (0.0.0.0/0) advertisement with vWAN internet routing intent in the same hub; it’s not supported and leads to ambiguous forwarding. Pick one authority for the default route per hub.
Traffic inspection patterns (what I deploy most)
– North‑South: Internet ingress/egress and hybrid flows traverse FortiGate. In hub‑and‑spoke, use UDRs + GLB; in vWAN, turn on Internet routing intent and let the vHub steer spokes/branches automatically.
– East‑West: Lateral segmentation between spokes/environments (Dev/Test/Prod). Microsoft’s full inspection patterns apply. Enforce zero trust with FortiGate as the transit point.
High availability & scale: design choices that matter
– Gateway Load Balancer for transparent inline NVA insertion and flow symmetry on public paths.
– HA NVAs: use Microsoft’s patterns (LB, Route Server, GLB) and Fortinet’s Azure architectures (ELB/ILB, autoscale). If you run SD‑WAN or VPN, BGP with Route Server is handy; validate your FortiGate’s BGP settings.
– vWAN routing intent over UDRs in at‑scale hub deployments: cleaner, repeatable, and policy‑driven.
– AVNM for centralized UDR management in multi‑hub/multi‑region traditional designs.
Day‑2 ops: logging, policy, automation
– Observability: Stream Azure platform logs to Log Analytics/Event Hub and FortiGate telemetry to FortiAnalyzer/FortiManager; vendors also publish cloud logging integrations. Build one pane of glass.
– Policy‑as‑Code: Use Terraform (ALZ accelerator + Fortinet repos) for reproducible deployments and guardrails.
– Route hygiene: In traditional hubs, adopt AVNM to assign route collections centrally and boost UDR scale safely.
Common pitfalls (and how I avoid them)
– Dual default routes with vWAN: advertising 0.0.0.0/0 from on‑prem and enabling internet routing intent in the same hub is unsupported and breaks predictability. Define one source of truth per hub.
– UDR sprawl & asymmetric flows: hand‑crafted UDRs across dozens of spokes inevitably drift. Prefer GLB for public paths and AVNM for centralized UDR governance.
– Under‑scoped east‑west controls: NSGs aren’t a substitute for deep inspection. Put FortiGate in the path and follow Microsoft’s full inspection designs to suppress lateral movement.
Azure Firewall vs. FortiGate (when I pick what)
Microsoft is clear: Azure Firewall and third‑party NVAs coexist. Azure Firewall offers cloud‑native scale/SLA and tight vWAN coupling; FortiGate brings vendor‑specific security engines, SD‑WAN, and parity with your on‑prem tooling. Many enterprises run both (e.g., Azure Firewall for simple internet breakout via routing intent and FortiGate for deep application‑aware segmentation). Choose based on skills, feature needs, and ops model.
Closing thought
FortiGate fits naturally into Azure Landing Zones when you decide the control plane up front and keep traffic steering simple.
If global transit and branch connectivity are your priority, Azure Virtual WAN with routing intent gives you clean, declarative inspection paths; if you prefer customer‑managed routing, a hub‑and‑spoke VNet with UDRs works well (just make public flows transparent and resilient with Gateway Load Balancer, and keep east‑west segmentation intentional). The real differentiator is day‑two discipline: centralize telemetry in FortiManager/FortiAnalyzer alongside Azure logs, treat routing and policy as code, and use Azure Virtual Network Manager to prevent UDR sprawl as you scale across regions. Do this, avoid dual default‑route ownership, and you’ll have a Fortinet‑powered platform that stays secure, predictable, and repeatable as your estate grows.