The same capability as the cloud-native firewall, and more.
FQDN/SNI-based L3/L4/L7 filtering, secure NAT, built-in threat hardening and cloud-object imports, on a purpose-built engine that classifies each flow once in microseconds, then enforces it in-kernel at line rate.
Run it your team's way.
One firewall instance underneath, two equal workflows, equal billing: policy-as-code through a GitHub pipeline, or hands-on in the Cloud Controller console. Run either — or both at once across different firewalls in the same account.
Drive the whole fleet from one console
Deploy firewalls, author L3/L4/L7 policy in a visual editor, push with one click and watch every flow stream back live — across AWS, Azure and Google Cloud, in a single pane of glass. Built for network-operations teams who want to see and steer, not hand-edit files.
- Visual rule editor with an object-aware picker — no YAML to hand-write
- One-click push with a compliance check before it ships
- Multi-firewall live log streaming, merged into one filterable feed
Policy as code, straight from your repo
Keep firewall policy where the rest of your infrastructure lives — in Git, reviewed in a pull request, gated by the same compliance checks, and applied through your pipeline.
- Human-readable YAML policy, version-controlled and peer-reviewed
- Compliance gating runs on the pull request, before merge
- Same NVA, same engine — GitOps is the workflow, not a different product
Pipeline preview coming soon
Available now as a workflow. A self-serve portal walk-through is on the way.
Microsecond-class classification, line-rate enforcement.
Every number here is measured on standard VM sizes — a 2-vCPU t3.micro and a 4-vCPU VM — and presented as a conservative floor. We could not make the engine the bottleneck in any test.
- ~49.5 µs p99 first-packet classification — measured on a 4-vCPU VM at sustained load, CPU 99% idle
- 98.5 % of packets decided in-kernel at line rate — only the first packet of a flow (plus SNI retries) reaches userspace
- ≥5,879 /s sustained new TLS handshakes — a conservative floor; testbed-limited, not firewall-limited
- 4.35 Gbps single-stream TCP on a t3.micro, sustained 60 s, with the firewall CPU 97.4% idle
- 999 Mbps UDP delivered at 0% loss across 2.59 M datagrams on the same t3.micro
- 0 dropped packets across the throughput run — userspace queue depth peaked at zero
Every layer, one ordered policy.
L3/L4 stateful filtering, FQDN/SNI-based L7, and TLS-metadata matching — composed in a single, human-readable policy and enforced with standard Linux network primitives. No TLS decryption, ever.
- L3 / L4
Stateful 5-tuple filtering
Source and destination IPv4 + CIDR, TCP / UDP / ICMP, ports and port ranges, in one ordered rule table across three sections — to-firewall, through-firewall and from-firewall — each with its own default verdict. List-valued source, destination and port matchers compile to native set lookups, so a rule against hundreds of CIDRs or ports matches in one pass, not a sequential scan.
- L7 · FQDN/SNI
SNI / HTTP-Host / DNS egress control
Allow or deny by destination domain read from the TLS SNI extension, the HTTP/1.x Host header, or the DNS question name — exact, single-label wildcard (*.example.com) or multi-label wildcard (**.example.com). DNS-query matching drops the question before it leaves the firewall, never waiting for a response. All read from data already in clear text on the wire.
- L7 · TLS metadata
JA3 / JA3S, TLS version, ALPN, cert fields
Match on the TLS ClientHello fingerprint (JA3) and ServerHello fingerprint (JA3S), negotiated TLS version, the offered ALPN list, and upstream leaf-certificate Subject / Issuer / serial / SHA-256 fingerprint. Block weak TLS versions outbound, pin a service to a certificate, or deny a known-bad malware C2 TLS stack — without ever decrypting a byte.
Advanced rule matchers (YAML)
A second tier of matchers for power users authoring policy directly, and for migrating an existing AWS Network Firewall / Suricata ruleset. All combine and validate at parse time.
-
sni_hostnameTLS SNI / HTTP Host — exact, *.wildcard, **.multi-label -
dns_query / dns_rrtypeDNS question name + record type (catch TXT exfiltration) -
http_requestCleartext HTTP/1.x method, URI, user-agent, cookie, referer, URI length -
tls_version / tls_alpnNegotiated TLS version and offered ALPN (e.g. block QUIC, h3) -
ja3 / ja3sClient / server TLS-handshake fingerprints, GREASE-filtered -
tls_cert_*Leaf cert Subject, Issuer, serial, SHA-256 fingerprint (pin upstreams) -
ratePer-rule packet-rate limit with burst -
dsize / flowPacket-length match and per-rule connection state
An import toolkit walks an existing AWS Network Firewall policy tree and
converts stateless and stateful 5-tuple, domain-list and readable
Suricata rule groups into validated Enforza policy — mapping
tls.sni, http.host, dns.query,
ssl_version, flow and dsize to
their native matchers, and flagging anything too wide to emit safely.
Decide each flow once. Run the rest at line rate.
Most firewalls re-inspect every packet of every connection. Enforza doesn't. The first time a connection appears, the engine classifies it once — in microseconds — then enforces that decision in-kernel for every packet that follows. The result is a firewall that does deep L7 work yet runs cold and cheap.
-
Classified once, in microseconds
A new flow is evaluated a single time — domain, TLS metadata, 5-tuple, all of it — at a measured p99 of about 49.5 µs. That's microsecond-class, not the millisecond-class round-trips of a proxy that re-parses every packet.
-
The rest fly through in-kernel
Once decided, the verdict is pinned to the connection and enforced with standard Linux network primitives at line rate — source-NAT included. 98.5% of packets never leave the kernel, so the engine only ever sees a fraction of your traffic.
-
So it runs cold, and cheap
Near-zero per-packet overhead means tiny VMs do real work — 4.35 Gbps held on a t3.micro with the CPU 97% idle. Lower CPU is lower cost, and it scales up cleanly: bigger VM, more headroom.
Egress filtering and source-NAT, one appliance.
Configure source-NAT (masquerade) per rule, right beside the policy rule it belongs to — no separate NAT gateway stacked in front of your firewall.
-
Per-rule SNAT, in-kernel
Opt in to source-NAT on the specific rules that need it; the default is none. Once a flow's first packet is decided, masquerade applies in-kernel at line rate for the rest of the flow — no engine round-trip per packet.
-
Global SNAT in one toggle
Or masquerade every forwarded flow to the firewall's egress IP with a single setting — the classic NAT-gateway role, with full L7 egress filtering on the same box.
-
Wide, unpredictable port spread
A widened source-port pool (~55k ports per egress IP) with fully random allocation keeps port assignment unpredictable and recycles fast under load — attach a second egress IP to double the pool.
Built-in protection, no configuration.
DDoS-class absorption and host hardening ship on by default and sit ahead of the policy chains, so they survive every policy reload and scale themselves to the VM size.
-
Anti-scan drops
FIN+RST, SYN+FIN, SYN+RST, NULL and Xmas scans, mid-stream non-SYN attempts, invalid connection-state packets and fragment abuse — dropped before policy evaluation.
-
SYN-flood absorption
A per-source-IP and per-destination-IP token-bucket meter on the forward and input paths drops excess new connections before they ever reach the engine, auto-scaled to the VM size on boot.
-
ICMP & SSH brute-force limits
Per-source ping-flood absorption and a new-SSH-connection rate cap on the input path, applied automatically with no configuration.
-
Host hardening on boot
SYN cookies on, strict reverse-path filtering, ICMP redirects and source routing off — applied at startup as an explicit closed posture, ahead of the policy chains so the guardrails survive every policy reload.
Write "allow egress to AWS S3 in eu-west-2" — and mean it.
Cloud providers publish exactly which IP ranges belong to each service. Enforza pulls those catalogues in for you, as named, reusable network objects — so you write egress rules against the service, not a wall of CIDRs you have to chase every time the cloud changes.
-
One-click import, AWS and Azure
Import any AWS service / region combination (e.g.
S3 · eu-west-2) straight from the official IP-ranges feed, or any Azure Service Tag (e.g.Storage.NorthEurope,AzureFrontDoor.Frontend) from Microsoft's published catalogue. The Azure download's signed URL is resolved on the fly, so you never host or maintain a mirror. Each import lands as a normal network group with full provenance — provider, region, service and the import timestamp. -
Stays current on its own
A scheduled job re-fetches both catalogues every 48 hours and only rewrites when the upstream version marker actually moves — AWS's
syncTokenor Azure'schangeNumber. When a catalogue shifts, the imported group picks up aSTALEpill; one click re-pulls fresh prefixes in place, and every rule that references the group is current immediately. No hand-edited CIDR lists, no drift. -
Use them by name, in plain rules
Reference an imported group by name from any egress rule —
allow tcp/443 to aws-eu-west-2-s3. The rule editor's picker is opinionated about safety: cloud-imported groups appear in the destination picker only, so you author "egress to AWS S3", never "accept from all of AWS". Operator-authored groups stay the only valid sources. -
Lean YAML, only what you use
Before policy ships to a firewall, the cloud renderer drops any cloud-imported group that no rule references — so the published policy carries only the prefixes in active use, not the entire provider catalogue. Full breadth in the library, minimal footprint on the wire.
- Network groupsCIDRs / hosts, reusable by name
- Port groupsNamed port sets, edit once
- Hostname groupsSNI / FQDN allow-lists
- AWS IP Ranges~10k prefixes, warm-cached
- Azure Service Tags~3k tags, signed-URL resolved
- 48h refreshChange-detected, stale-flagged
See every flow, across the whole fleet.
Live metrics, real-time multi-firewall log streaming, and a full verdict lifecycle on every record — so you can chase a problem across the fleet in seconds.
-
Metrics for every flow
A live metrics endpoint exposes classification-latency histograms, per-rule packet and byte counters read straight from the kernel, connection-table size, queue depth and drops, policy-apply age and watchdog activity — ready to scrape into your existing dashboards.
-
Multi-firewall live log streaming
Open any firewall and watch its traffic stream to your browser in real time — every flow, every verdict, every matched rule. Select multiple firewalls and merge them into one filterable feed by source, destination, host, protocol or rule comment. Works through your own NAT; no agents, no forwarding pipeline.
-
Full verdict lifecycle per record
Each traffic-log entry records who decided the packet and who enforces the rest of the flow, the matched rule index, policy SHA, connection state, TLS version, ALPN, and flow-close byte / packet totals — so kernel-decided and engine-decided flows are equally auditable.
-
Policy-apply feedback
Every apply attempt on every firewall reports back to the console. A failed push surfaces a parse / compile / apply error chip with the engine's own message inline — closing the silent-failure gap where YAML validates centrally but rejects on the host.
Stream logs to your SIEM — never through ours.
A separate log-shipping daemon, in its own failure domain, ships traffic logs directly from the firewall instance to your destination, with your identity and your bill.
Engine-direct, by design
The log-shipping daemon runs as its own hardened service with no kernel hook and no elevated network capability, reading the firewall's local traffic logs and batching them straight to your destination. The data plane never traverses Enforza's cloud — so your logs stay yours, and we pay nothing to move them.
A plugin architecture means new sink kinds drop in without touching the core. Every sink reports a 30-second health heartbeat that renders as an inline chip on the firewall row — events written, last write, buffer depth, and the engine's own error string if a circuit opens.
-
Azure Monitor / Sentinel
Logs Ingestion REST API with the VM's managed identity.
-
AWS S3
Signed PutObject with the instance role; gzipped NDJSON batches.
-
Splunk HEC
HTTP Event Collector with a token held in your cloud secrets.
Compliance gating on every publish.
Every policy change is checked against industry frameworks before it reaches a firewall — advise to warn, or enforce to block the publish entirely.
- 25 frameworks
- 210 firewall-applicable controls
- 33 best-practice hygiene checks
CIS, PCI-DSS v4, ISO 27001, NIST 800-53, FedRAMP, DORA, CMMC, HIPAA and more — attach whole frameworks or cherry-picked controls to any policy, each with an honest confidence score. The full named set is on the compliance page.
Drop-in to deploy, built to keep running.
A single static Linux binary, one install command, and an outbound-only control plane — on any cloud, with no management port to expose.
-
One-line install, any cloud
A single static binary with no runtime dependencies beyond standard Linux network primitives. The installer detects the distro, registers the instance and starts enforcing in minutes — on AWS, Azure, Google Cloud or on-prem.
-
Self-upgrade with rollback
Trigger an upgrade from the console; the instance swaps its binary atomically and reports success — or rolls back to the previous version automatically if the new one does not come up clean.
-
Fail-closed, self-healing
If the engine stops, new connections drop rather than pass unfiltered. Watchdogs restore flushed tables within seconds, and a lost control-plane credential re-enrols itself automatically — no remote access needed for unattended hosts behind NAT.
-
No exposed management plane
No inbound management port, no admin UI to expose. The control plane is outbound-only — the instance manages up, never in — so there is no reachable interface on the security device to find or harden.
One flat per-firewall line. That's the whole bill.
Everything above runs on a single flat per-firewall subscription — plus the Linux VM(s) you provision and size yourself. No per-GB tax, no metered add-ons.
-
Not CPU / instance-size limited
Run the firewall instance on any VM size — the price does not change. The cloud-native firewalls and the mega-NGFW VMs meter by vCPU, instance size or endpoint-hour. Enforza does not.
-
Not IP / object limited
No cap on protected IPs or network objects on the licensed plan, and no per-IP charge. Public-IP and endpoint charges add up on the cloud services; here they do not.
-
Not protected-device limited
Enforza is a gateway, not an agent on every host — and it is never licensed by how many devices sit behind it. Some plugins meter by device count; your firewall should not charge by how many things it protects.
-
Not complicated cloud pricing
One flat per-firewall line — no per-GB data-processing tax, no per-rule tiers, no per-AZ double-bubble. Predictable, like buying a box, not a metered maze you reconcile at month-end.
Technical questions
Does Enforza decrypt TLS to filter by domain?
No, and it never will. Domain, TLS version, ALPN, JA3 / JA3S fingerprint and upstream certificate fields are all read from data already in clear text on the wire — the TLS SNI extension, the ClientHello, and the certificate message that precedes the encrypted handshake. There is no man-in-the-middle, no private CA to push to every endpoint, and no custody of your production TLS keys.
What does 'single-pass packet classification and verdict engine' mean?
Each new flow is classified exactly once — its first packet is evaluated in userspace in microseconds (measured p99 around 49.5 µs at sustained load) — and the result is then enforced in-kernel at line rate for every following packet of that flow, using standard Linux network primitives. Measured on the development fleet, 98.5% of packets decide in-kernel and never touch userspace, so the engine sees a tiny fraction of total traffic.
How fast is it, really?
On a 4-vCPU VM the engine sustained at least 5,879 new TLS handshakes per second at p99 ~49.5 µs first-packet classification with the CPU 99% idle — a conservative floor, because the test harness could not drive it harder. On a small t3.micro, single-stream TCP held 4.35 Gbps for 60 seconds with the firewall CPU 97.4% idle, and UDP delivered 999 Mbps at zero loss across 2.59 million datagrams, with zero dropped packets throughout. These are measured floors on standard VM sizes, not ceilings.
Can Enforza both NAT and filter egress on one appliance?
Yes. Source-NAT (masquerade) is configured per rule, alongside the matching policy rule, and runs in-kernel at line rate once a flow's first packet is decided. One firewall instance does secure egress and source-address translation together — you do not stack a separate NAT gateway in front of it.
Can I keep my own SIEM?
Yes. A separate log-shipping daemon streams traffic logs directly from the firewall instance to Azure Monitor / Microsoft Sentinel, AWS S3 or Splunk HEC, using your own managed identity, instance role or token — and your bill. The data plane never traverses Enforza's cloud, and each sink shows a live health chip on the firewall row.
Does the firewall expose a management port?
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, harden or put behind a VPN.
The capability you actually use.
FQDN/SNI-based L7, secure NAT, compliance and fleet observability — on a single-pass engine measured in microseconds, at a fraction of the cloud-native firewall bill. Start free, no card.