Azure landing zones in Terraform and ARM, with the firewall in the hub.

Yes. Microsoft's Cloud Adoption Framework traditional-networking-topology guidance says, in its design recommendations: deploy Azure Firewall or partner NVAs in the central-hub virtual network for east/west or south/north traffic protection and filtering. Enforza is a partner network virtual appliance, so putting it in the hub is an in-pattern substitution, not a workaround.

Four validated patterns that build the whole Azure network and place the Enforza gateway in it: a single gateway for dev, test and single-zone small production; a zone-redundant pair, two gateways across availability zones behind an internal Standard load balancer with HA Ports for production high availability; hub-spoke centralised egress, where a hub VNet carries the gateway pair and peered spoke VNets route their egress through it; and a scale-out fleet of three gateways across zones 1, 2 and 3 behind the internal load balancer. Each pattern ships in Terraform and in ARM, in two flavours. Every gateway registers itself on first boot, then you attach policy in the console.

The networking is identical, only the firewall image and its bootstrap differ. The deployment-key flavour boots a stock Ubuntu image and installs the engine with a one-time registration key from the console (install.sh with the key), so it needs no Marketplace subscription. The marketplace-image flavour boots the Enforza Azure Marketplace image and self-registers via the Azure Instance Metadata Service, then you claim it in the console by subscription ID plus VM ID. No key to manage.

Both. Every pattern ships in Terraform and in an ARM template (arm/azuredeploy.json), which is also the one-click Deploy-to-Azure button target. They build the identical topology, so pick whichever your team already runs. Terraform needs the Azure CLI authenticated and Terraform 1.0 or newer; ARM deploys from the portal button or the Azure CLI.

Each gateway VM registers itself on first boot with a deployment key from the console, and a key is one-time use per firewall. The single gateway takes one key, the zone-redundant pair and the hub-spoke pattern take two (one per gateway), and the scale-out fleet takes three. Reusing one key across gateways would fail to register the second and third.

No, and we are precise about this. The scale-out fleet is three gateways behind an internal Standard load balancer with an HA Ports rule, steered by user-defined route, so it is routed scale-out, not transparent inspection. Enforza's engine has the AWS Gateway Load Balancer GENEVE datapath, which is why the AWS GWLB fleet is transparent, but the Azure Gateway Load Balancer VXLAN datapath is not offered here. On Azure the fleet is an internal-load-balancer pattern.

With a user-defined route. In the single-gateway pattern you point each workload subnet's 0.0.0.0/0 at the gateway's private IP as a virtual appliance. In the zone-redundant, hub-spoke and scale-out patterns the template points 0.0.0.0/0 at the internal load balancer's private frontend, which spreads traffic across the gateways with HA Ports. Register each gateway in the console, then attach policy.

Deployed. The deployment-key patterns were built end-to-end in a real Azure subscription and proven to route and source-NAT live workload traffic through the firewall, not just validated on paper. The templates are the exact ones in the public repository.

On the core egress job, up to 60–80%. A two-network hub-and-spoke pushing 20 TB a month through one Azure Firewall Standard is about $1,232.50/month ($912.50 in deployment-hours at $1.25/hour plus $320 in data-processing at $0.016/GB). The same workload on Enforza is a flat $249 licence (£199) plus the VM you run it on, near $349/month all-in, roughly 72% less. Rates are US list, dated 2026-07-04, directional. Azure self-SNATs, so there is no separate NAT gateway stacked behind it. The full line-by-line maths is on the worked example.

Yes. Since 31 March 2026 Azure has retired default outbound access for new deployments, so every workload needs an explicit, deliberate egress path. Enforza as the hub NVA is exactly that: a controlled, filtered, secure-NAT outbound path with audit-ready logs to your own SIEM, rather than an implicit default route.