Control what leaves your network — without the per-GB tax.

A NAT gateway gives private workloads a path to the internet by translating their source address. A secure NAT gateway adds policy to that path: it decides which outbound connections are allowed, by destination domain, before translating and forwarding them. Enforza does both on one appliance — FQDN/SNI-based L7 egress filtering and source-NAT together — so you control what leaves your network, not just connect it.

Since March 31, 2026 (for API versions released after that date), new Azure virtual networks default to private subnets with no implicit outbound internet access. Workloads that rely on that default need an explicit egress method — a NAT Gateway, load-balancer outbound rules, a public IP, or a network virtual appliance reached via a user-defined route. It is a good moment to add a secure, filtered egress path rather than just restoring connectivity: route the subnet through the Enforza NVA and you get both outbound translation and FQDN/SNI-based L7 control in one step.

It can. A common pattern routes traffic to Azure Service Tags with a next hop of Internet to let workloads reach Azure services directly. Microsoft documents that, in a private subnet, those Service-Tag routes no longer provide outbound access on their own unless an explicit outbound method is also configured. Routing the subnet through the Enforza NVA restores that path and governs it: import Azure Service Tags (and AWS IP Ranges) as named objects in the object manager and write "egress to Azure Storage" as a rule that stays current on its own when the provider catalogue moves.

No. Destination domain is read from data already in clear text on the wire — the TLS SNI extension, the HTTP Host header and the DNS question name. There is no man-in-the-middle, no private CA to push to every endpoint, and no custody of your production TLS keys.

No. On AWS, securing egress through Network Firewall is metered by per-AZ endpoint-hours plus $0.065/GB — a bill that doubles across Availability Zones and grows with every byte. On Google Cloud, filtered egress still stacks Cloud NGFW and a separate Cloud NAT line — two metered products. Either way Enforza does secure source-NAT and FQDN/SNI-based L7 filtering in a single appliance at a flat per-firewall price, $0/GB. On Azure, the managed firewall already performs its own source translation; there the win is removing the per-GB data-processing charge.

Yes. A plain NAT gateway gives you outbound connectivity and no filtering, and still bills $0.045/hour plus $0.045/GB on every byte (us-east-1, dated 2026-06-14, directional). Enforza is a flat per-firewall licence at $0/GB, so at modest egress it costs less than the NAT gateway alone — and a full L3/L4/L7 firewall is included in the box, ready whenever you want to start filtering. The cross-over point depends on your egress volume; run your own numbers in the savings calculator.

Enforza is a flat per-firewall licence — £179/month per firewall, dropping to £149 from your sixth — with $0/GB, plus the Linux VM you provision. The cloud-native firewall bills a per-hour endpoint fee plus a per-GB data-processing charge on every byte, forever: AWS Network Firewall is $0.395 per endpoint-hour per Availability Zone (so a 2-AZ deployment is roughly $577/month before any traffic) plus $0.065/GB on top. The flat line typically lands 60–80% below the cloud-native firewall plus data-processing charges at modest egress. Rates are directional and dated — run your own numbers in the savings calculator.

AWS, Azure, Google Cloud and on-prem VMs, under one control plane. The same firewall instance enforces the same FQDN/SNI-based egress policy wherever it runs, so a multi-cloud estate is one fleet rather than three separate NAT-and-firewall products.

No. The firewall instance has no inbound management port and no admin UI to expose. Its control plane is outbound-only to the Enforza cloud — the instance manages up, never in — so there is no reachable management interface on the security device to find or harden.