How it works / architecture

Enforza is a network virtual appliance (NVA) you run as a Linux VM in your own cloud account — AWS, Azure, or GCP. The VM is the unit of deployment: run a single VM for simplicity, or multiple VMs across Availability Zones (or regions) when your redundancy and availability requirements call for it — you choose the posture, and you size each VM for your traffic. It classifies and enforces traffic in-kernel at line rate, and is managed entirely from the Enforza cloud. You never SSH in to operate it.

The packet-engine

The Enforza packet-engine sits in the packet path and enforces your policy across three directions relative to the firewall:

to-firewall — traffic destined to the VM itself (management, health checks).
through-firewall — traffic routed across the firewall. This is the normal forwarding case: egress, ingress, and east-west control.
from-firewall — traffic the VM itself originates (DNS, NTP, updates).

Rules within a section are evaluated first-match wins; if nothing matches, the section’s default action applies. The fail-closed posture is drop.

Single-pass packet classification and verdict engine

Each flow is classified once by the single-pass packet classification and verdict engine, in microseconds (p99 ~49.5 µs, verified), then enforced in-kernel at line rate — 98.5% of packets take the in-kernel fast path. This is microsecond-class, not millisecond-class: purpose-built for cloud, not a ported on-prem appliance.

The same engine extracts L7 signals inline — the TLS ClientHello SNI and the HTTP Host header — so you can write identity-aware, hostname-based rules (allow **.amazonaws.com, deny a SaaS domain) without terminating or breaking TLS.

Capabilities at a glance

Egress, ingress, and east-west control with first-match rules.
Identity-aware L7 / FQDN filtering (SNI / Host) without breaking TLS.
Secure NAT — global masquerade or per-rule SNAT, plus DNAT / port-forward (VIPs).
Threat hardening — connection-rate and flood meters that auto-tune to VM size.
Object manager — reusable address / port / hostname groups, including cloud-range objects that auto-track published AWS / Azure / GCP / GitHub / Cloudflare IP ranges.
Compliance — guardrail packs (25 packs, 210+ controls) that advise or enforce on every publish.
Logging — local traffic log, a live stream to the console, and exporters that tee events into your own SIEM / archive.

The control plane — outbound-only

The packet-engine connects out to the Enforza platform over a single secure channel — encrypted and mutually authenticated, on TLS 1.2+ over TCP/443 — and pulls everything it needs: policy, config, credential brokering. There is no inbound management port and no admin UI to expose. The firewall manages up, never in. That is a smaller attack surface than a self-managed box that needs a reachable management interface to administer it.

Logs that you export go engine → your destination directly. The Enforza control plane brokers config and credentials but is never in the data path and never sees your traffic events.

Sizing the VM

You choose the VM size, and you should size it to your traffic. Enforza is licensed per firewall — flat, never metered by vCPU, instance size, protected IPs, network objects, or protected devices — so you can scale the box up freely without the price changing. Match the instance to your expected egress throughput and new-connection rate; the threat-hardening meters auto-tune to the VM’s resources. Start modest and scale up as load grows — an undersized VM becomes your throughput ceiling, so right-size it and keep headroom for peaks.

Redundancy and availability

Because the unit of deployment is a VM, you choose your availability posture:

A single VM — the simplest deployment; ideal for dev or a single-AZ workload.
Multiple VMs across Availability Zones — for production resilience, run a VM per AZ with automatic route failover, or centralise egress for many networks behind a hub. Run as many as your redundancy and availability targets require.

Ready-to-use reference deployments (single VM, dual-VM AZ failover, and hub-and-spoke centralised egress) ship as Terraform and CloudFormation you can adapt.

Patching and reboots

Enforza auto-patches the operating system for you — security and package updates are applied automatically, so OS maintenance is not on your plate. When an update can only take effect after a reboot (for example a new kernel or updated linux-headers), the firewall does not restart unannounced: it raises a “reboot required” alert so you choose the maintenance window. We keep it patched; you stay in control of when it bounces. The packet-engine self-updates with rollback, and a reboot or VM replacement re-registers cleanly on its own — it never needs manual re-onboarding.

Next: the two ways to run it.