Ready-to-deploy reference architectures that put the Enforza firewall and secure NAT gateway in the hub of your cloud network.
Enforza is a network virtual appliance (NVA): a Linux VM in your own account that source-NATs outbound traffic and applies Layer 7 egress policy on the way out. These templates build the surrounding network correctly so the appliance actually works, which is the part most people get wrong the first time.
Everything here is free to use, in your own cloud account, under the MIT licence. You need an Enforza licence for the firewall itself.
| Size | Pattern | Shape | Use it when |
|---|---|---|---|
| S | aws/*/01-single-gateway |
One VPC, one firewall, two private subnets routed through it | Dev, test, or a small single-VPC production estate |
| M | aws/*/02-dual-gateway-az-failover |
Two firewalls across two Availability Zones, with an automatic route flip on failure | One production VPC that wants basic resilience without a Transit Gateway |
| L | aws/*/03-tgw-centralized-egress |
Transit Gateway hub, inspection VPC with a firewall per AZ, three workload VPCs | Multi-VPC or multi-account, wanting one inspected egress edge |
| XL | aws/*/04-gwlb |
Gateway Load Balancer with transparent GENEVE inspection across a 3-AZ fleet | Scale-out, per-AZ isolation, or an MSP running many tenants |
Every AWS pattern ships in both Terraform and CloudFormation, and in two
flavours depending on how you get the engine onto the instance. See
aws/README.md for the full explanation.
Pattern 02 is deliberately labelled basic, non-production resilience. It fails over on EC2 status checks, which catch a dead instance but not an in-appliance degradation, and in-flight connections reset on failover. If you need production grade high availability, use the GWLB pattern.
| Pattern | Shape | Use it when |
|---|---|---|
azure/simple-single-az |
One gateway VM, VNet, subnets and NSG | Dev, test, small deployments |
azure/ha-multi-az |
Two gateway VMs across zones behind an internal load balancer | Production wanting high availability |
azure/ha-multi-az-with-dnat |
The above plus an external load balancer for inbound DNAT | Production that also needs inbound published services |
See azure/README.md.
If you already have an Azure hub and only want the appliance dropped into it, deploy straight from the Azure Marketplace instead.
- A cloud account, and credentials able to create networking and compute.
- Terraform 1.5 or later, or the AWS CLI if you prefer CloudFormation.
- An Enforza account. Then either:
- a deployment key per firewall from the console (Onboard Firewall, then Deployment Keys). Keys are one-time use, so a two-gateway HA pattern needs two different keys; or
- an AWS Marketplace subscription, if you would rather boot the Enforza AMI and claim it by account and instance id.
# Terraform, from any pattern directory
terraform init
terraform apply -var deployment_key=efz_xxxxxxxxxxxx
# CloudFormation, AWS patterns only
aws cloudformation deploy \
--template-file cloudformation/template.yaml \
--stack-name enforza-landing-zone \
--parameter-overrides DeploymentKey=efz_xxxxxxxxxxxx \
--capabilities CAPABILITY_NAMED_IAMEach pattern directory has its own README with an architecture diagram, the packet path, exact deploy and teardown commands, and the design rationale.
Every pattern boots a stock base image and, on first boot, fetches the public installer and registers the engine with your account:
curl -fsSL https://dl.neon.efz.io/install.sh | bash -s -- --regkey="<deployment key>" --name="<name>"The firewall then appears in the console, where you attach policy. Deployment keys
are secret: keep terraform.tfvars out of version control. The Terraform variables
are marked sensitive, so keys are not printed in plan output.
- Source and destination checking is disabled on every firewall network interface, or IP forwarding is enabled on Azure. A forwarding appliance exists to handle packets addressed to other hosts, so this is the single most important requirement and it is commented at each occurrence.
- Each firewall has a stable public address so its outbound source-NAT identity does not move.
- Workload subnets send their default route at the firewall, or at a Transit Gateway or load balancer that forwards to it.
Enforza is priced flat per firewall with no per-GB data-processing charge, which is the main reason these architectures work out cheaper than the metered cloud-native equivalents at anything above light traffic. You still pay your own cloud provider for the VMs these templates create and for the network plumbing around them, such as Transit Gateway attachments, load balancer hours and data transfer. We do not remove those, and the READMEs are explicit about which charges are yours.
Current pricing is on enforza.io/pricing, and there is a savings calculator if you want to run your own numbers.
These are reference architectures. They are validated (terraform validate and
terraform fmt pass; the CloudFormation templates pass aws cloudformation validate-template), but review CIDRs, instance sizing and security group scope
against your own standards before production use.
Issues and pull requests are welcome. For product questions or a deploy review, get in touch at enforza.io/contact.