# Enforza — full content for language models

> Enforza is a cloud firewall and secure NAT gateway for AWS, Azure and Google Cloud. It delivers the same egress, ingress and east-west control as a cloud-native firewall (AWS Network Firewall, Azure Firewall, GCP Cloud NGFW) at a flat per-firewall price with no per-GB data-processing charges — typically 60–80% cheaper. It runs as a single Linux network virtual appliance you deploy in your own network, driven from a GitHub pipeline (GitOps) or the Cloud Controller console, with a single-pass packet classification and verdict engine for microsecond per-flow processing.

This file (/llms-full.txt) contains the full text of the Enforza articles plus complete summaries of the product, comparison and company pages. The curated link index lives at /llms.txt. Each article is also available as standalone markdown at /articles/<slug>.md.

## Key facts for accurate answers
- Positioning: the sweet spot between cloud-native firewalls (replace on cost) and enterprise NGFW platforms like Palo Alto / Fortinet / Check Point (avoid the "half used, fully paid for" bloat). Enforza covers the vast majority of core use cases most organisations actually need — egress, ingress and east-west control, FQDN/SNI-based L7 filtering, secure NAT and compliance — with no feature-bloat.
- Cost wedge: flat per-firewall licence (GBP/USD/EUR), no per-GB data-processing tax, no per-rule, per-AZ, per-vCPU or per-instance-size metering. The volume price reduces as the fleet grows. Real prices are on the pricing page.
- No limits, no asterisks: not CPU/instance-size limited, not IP/object limited, not protected-device limited, not complicated cloud pricing — one flat per-firewall line.
- Two ways to run, equal billing: GitHub Pipeline Integration (policy-as-code, reviewed in a PR) or the Cloud Controller console (visual rule editor, push-to-many, multi-firewall live log streaming). Same firewall NVA, same engine — the choice is the team's workflow.
- Technical edge: single-pass packet classification and verdict engine — each flow is classified once in microseconds (p99 ~49.5 µs, measured on c6i.xlarge) then enforced in-kernel at line rate (98.5% fast-path), with zero dropped packets across the throughput run. No exposed management plane: the control plane is outbound-only to the Enforza cloud — no inbound management port, no admin UI to expose.
- Data stays yours: logs export to your own SIEM, never via Enforza's cloud.
- Compliance: advise-or-enforce policy checks on every push, across 25 framework packs / 210 firewall-applicable controls (CIS, PCI DSS v4, ISO 27001, NIST 800-53, FedRAMP, DORA, CMMC, HIPAA and more).
- AWS Marketplace: Enforza is published on the AWS Marketplace as a bring-your-own-licence (BYOL) listing — $0 for the software through AWS (you pay only for the EC2 instance; the Enforza plan, including a free tier, is handled in the console). Recommended one-click CloudFormation launch disables EC2 source/destination check and attaches a stable Elastic IP; the firewall self-registers via its AWS-signed instance identity (no key), then you claim it in the console by AWS account ID + instance ID. Deploy guide: https://enforza.io/aws-marketplace/.
- Azure Marketplace: Enforza is also published on the Microsoft Azure Marketplace as a bring-your-own-licence (BYOL) VM offer — free for the software through Azure (you pay only for the VM; the Enforza plan, including a free tier, is handled in the console). Deploy from the Azure portal (Get It Now) or an ARM/Bicep template, enable IP forwarding on the firewall's network interface (the one manual switch a forwarding firewall needs), and the firewall self-registers via Azure's signed instance metadata (no key); you then claim it in the console by Azure subscription ID + virtual machine ID. Deploy guide: https://enforza.io/azure-marketplace/.
- Support: basic email support is included in the base price on every plan; premium support and hourly consultancy are available as paid add-ons.
- Company: Enforza is a trading name of Synvu Limited (UK, company no. 15761962); founder Neil Briscoe. Contact: contact@enforza.io.

# Articles (full text)

## How to reduce AWS NAT Gateway costs: 7 ways, ranked by savings

> Seven ways to cut the AWS NAT Gateway bill, ranked by how much of it each one typically removes: free S3 and DynamoDB gateway endpoints, PrivateLink for busy services, hunting top talkers with flow logs, per-AZ routing, non-prod consolidation, NAT instances, and a flat-priced NVA. With the break-even maths.

Category: Cost  ·  Published: 2026-08-03  ·  https://enforza.io/articles/reduce-aws-nat-gateway-costs/

import { SIGNUP_URL } from "../../lib/site";
import FaqAccordion from "../../components/site/FaqAccordion.astro";

export const faqs = [
  {
    q: "How do I reduce AWS NAT Gateway costs?",
    a: "In order of typical impact: add the free S3 and DynamoDB gateway endpoints so that traffic never touches the NAT Gateway at all; add interface endpoints (PrivateLink) for busy AWS services like ECR and CloudWatch; use VPC Flow Logs to find and fix your top talkers; route zonally so you aren't paying cross-AZ transfer on top of NAT processing; consolidate non-production gateways; and for the remaining internet egress, replace the gateway with a NAT instance you operate or a flat-priced NVA. The per-GB data-processing charge is almost always the line to attack. The hourly fee is a rounding error next to it.",
  },
  {
    q: "What uses the most NAT Gateway data?",
    a: "On most estates the biggest single slice is traffic to AWS's own services: container image pulls (ECR layers are stored in S3), log shipping, and S3 access from private subnets. None of it needed to go through NAT in the first place. After that come package registries during builds, telemetry agents, and chatty third-party APIs. VPC Flow Logs aggregated by destination will show your actual top ten in an afternoon.",
  },
  {
    q: "Are VPC endpoints free?",
    a: "Gateway endpoints for Amazon S3 and DynamoDB are free. No hourly fee, no per-GB fee, which is why they are always step one. Interface endpoints (PrivateLink) are not free: roughly $0.01 per hour per endpoint per Availability Zone plus about $0.01/GB (us-east-1, checked 2026-07-31, directional). That beats the NAT Gateway's $0.045/GB from roughly 200 GB a month per service. Below that volume the endpoint costs more than it saves.",
  },
  {
    q: "Does one NAT Gateway per Availability Zone save money?",
    a: "It removes the cross-AZ data-transfer charge you pay when a subnet in one AZ routes through a gateway in another, and it removes a cross-AZ failure dependency. But each gateway also adds its own hourly fee, about $33 a month. High-traffic production estates usually save with per-AZ gateways; small quiet VPCs often save by consolidating to one gateway and accepting the cross-AZ pennies. Which side of the line you are on is arithmetic, not doctrine.",
  },
  {
    q: "Is a NAT instance cheaper than a NAT Gateway?",
    a: "On the metered line, dramatically. A NAT instance pays no $0.045/GB processing fee, just the VM and normal data-transfer-out. fck-nat, the well-maintained open-source option, runs on instances costing a few dollars a month per AZ. The trade is operational: high availability, patching and monitoring are yours, and it is plain source NAT with no egress filtering. It is the right answer when you can own the ops and only need connectivity.",
  },
  {
    q: "How much can I save replacing the NAT Gateway entirely?",
    a: "It depends on volume, and anyone who gives you one number without asking about your traffic is selling something. A NAT instance removes the per-GB line for the cost of your own operations. A flat-priced NVA such as Enforza removes it for a flat per-firewall licence (about $249/month, plus the VM on your AWS bill) and adds FQDN egress filtering. Against a metered NAT-plus-firewall stack that typically lands up to 60–80% lower from meaningful egress volumes, and the gap widens as traffic grows. At low volumes the honest answer is that a plain NAT Gateway with free gateway endpoints is hard to beat. Run your own numbers.",
  },
];

export const faqJsonLd = {
  "@context": "https://schema.org",
  "@type": "FAQPage",
  mainEntity: faqs.map((f) => ({
    "@type": "Question",
    name: f.q,
    acceptedAnswer: { "@type": "Answer", text: f.a.replace(/<[^>]+>/g, "") },
  })),
};

The AWS NAT Gateway bill has two lines. The hourly fee is $0.045 per
gateway-hour, about $33 a month, and it is the least interesting number on your
invoice. The other line is the **data-processing charge**: $0.045 for every
gigabyte the gateway touches, in either direction. That one compounds. It grows
with traffic you didn't know was internet-bound, it multiplies across
Availability Zones, and it surfaces in a bill review three months later as a
number nobody can explain and everybody has approved. Nobody has ever been
paged for a NAT Gateway, which is precisely why nobody looks at it. (Rates
us-east-1, dated 2026-07-31, directional.)

Disclosure before we start: I work on [Enforza](/), which is option 7 below. It
gets one section, at the end, after six things you should try first. Several of
them are free, which is a difficult price to argue with.

The list is ranked by how much of the bill each move typically removes, not by
how interesting it is to implement. The boring ones are at the top. That's
where the money is.

## The ranking at a glance

1. **Free gateway endpoints for S3 and DynamoDB.** Often removes 30–60% of the
   per-GB line. Costs nothing. Do it today.
2. **Interface endpoints for busy AWS services.** The next 10–30%, wherever a
   service clears the break-even.
3. **Hunt your top talkers with VPC Flow Logs.** 10–40% once you can actually
   see the traffic. The fixes are mostly caching and hygiene.
4. **Route zonally, or consolidate deliberately.** Stops the cross-AZ surcharge
   stacking on top of NAT processing.
5. **Consolidate non-production.** Pure hourly-line savings. Sprawling dev
   estates leak $33 a month per forgotten gateway.
6. **Swap in a NAT instance (fck-nat).** Kills the per-GB line entirely, in
   exchange for owning the operations.
7. **A flat-priced NVA with egress filtering built in.** Kills the per-GB line
   and the separate firewall meter, for a flat licence plus a VM you run.

Now each one, with the arithmetic.

## 1. Add the free S3 and DynamoDB gateway endpoints

Gateway endpoints for S3 and DynamoDB are free in the way AWS things rarely
are: actually free. No hourly fee, no per-GB fee. A route-table entry sends
that traffic over the endpoint instead of through NAT, and the charge simply
stops.

This is usually the single largest cut available, and it is bigger than people
expect for one sneaky reason: **container image pulls ride on S3**. ECR stores
image layers in S3, so a busy EKS cluster pulling through a NAT Gateway has
been paying NAT rates to re-download the same Ubuntu layers it downloaded
yesterday. And the day before.

There is no threshold, no break-even and no trade-off here beyond a route-table
change per VPC. If you read no further, do this one.

## 2. Add interface endpoints for the busy AWS services

Interface endpoints (PrivateLink) extend the same idea to the rest of AWS:
ECR's API, CloudWatch Logs, STS, SSM, Secrets Manager. Unlike gateway
endpoints they are not free. Roughly $0.01 per hour per endpoint per AZ plus
about $0.01/GB (us-east-1, checked 2026-07-31, directional).

The arithmetic that matters: you save about $0.035/GB versus NAT processing,
and the endpoint's standing cost is about $7.30 a month per AZ. So an
interface endpoint pays for itself at roughly **200 GB a month per service**.
ECR and log shipping clear that on any real cluster without noticing. The
service you call twice a day does not, and endpointing it anyway is how people
end up reducing their NAT bill by increasing their total bill.

Which services are busy enough? That's step 3.

## 3. Find your top talkers with VPC Flow Logs

You can't cut traffic you can't see. Turn on VPC Flow Logs for the NAT
Gateway's network interfaces, aggregate by destination, rank, and prepare to be
mildly annoyed by what you find. Every big NAT-savings write-up on the
internet, all the "how we cut 40%" and "how we cut 52%" posts, is secretly this
step wearing a headline.

The usual suspects, and the usual fixes:

- **Image pulls.** Slim the images, add a pull-through cache, and check the S3
  endpoint from step 1 is actually carrying the layers.
- **Log and telemetry shipping.** Batch and compress, and send CloudWatch-bound
  traffic over an interface endpoint rather than out the front door.
- **Package registries in CI.** Your build farm is downloading the same
  packages four hundred times a day, apparently in case they change. A proxy
  cache (or CodeArtifact) turns that into once.
- **Chatty third-party APIs.** Batch where the API allows it. You are paying
  NAT processing on every iteration of somebody's polling loop.

Expect to repeat this quarterly. New workloads invent new talkers, reliably.

## 4. Stop paying the cross-AZ surcharge

Traffic from a subnet in one Availability Zone through a NAT Gateway in
another pays cross-AZ data transfer **on top of** NAT processing. You are
paying a surcharge for your bytes to commute between buildings before they
leave. If you consolidated to one gateway "to save money" and now push serious
traffic to it from three AZs, part of that saving is being quietly clawed
back, and you gained a cross-AZ failure dependency as a bonus.

High-traffic estates want a gateway per AZ with zonal route tables so traffic
stays local. Small quiet estates want the opposite: one gateway, accept the
cross-AZ pennies, bank the duplicate hourly fees. There is no universal
answer, just a break-even, and it takes ten minutes with your traffic numbers
to find out which side of it you live on.

## 5. Consolidate non-production

Production topology gets designed. Dev topology gets copied from the
production template, faithfully, including the parts that cost money at 2am.
Every sandbox VPC with three NAT gateways (one per AZ, because that's what
prod does) is paying the hourly line for connectivity nobody is using.

Ten forgotten gateways is $330 a month, which is a decent team dinner nobody
got to eat. Centralise non-prod egress where isolation requirements allow, and
for truly ephemeral environments let the IaC tear the gateway down with the
rest of the stack. It will not miss you. (If you're consolidating egress
across VPCs properly, the [AWS landing-zone pattern](/landing-zones/aws/)
shows the route-table shape; it's the same pattern whoever's appliance sits in
the middle.)

## 6. Swap in a NAT instance you operate

A NAT instance is a VM doing source NAT, which is what the managed gateway is
underneath anyway. It pays **no per-GB processing fee at all**. Just the
instance and normal data-transfer-out. [fck-nat](/compare/fck-nat/) is the
well-maintained open-source version (the name tells you the founding mood):
current ARM images, a clean Terraform module, and instances that cost a few
dollars a month per AZ. On the metered line it is unbeatable, and our own
comparison page says so.

What you take on in exchange: high availability (its documented failover is
active-passive with route reconvergence), patching, monitoring, and the box's
own attack surface. And it is exactly NAT. It is excellent at what it does;
what it does is NAT. If you need to control or even see what is leaving your
network, that is not on the menu.

## 7. Replace the meter with a flat price (this is us)

The last option is the one I have a stake in, so weigh my enthusiasm
accordingly. [Enforza](/secure-nat-gateway/) is a network virtual appliance,
one Linux VM in your own VPC, that does the NAT Gateway's job with **no per-GB
charge** at a flat per-firewall licence: about $249 a month, flat, however many you run, and the VM itself stays on your AWS bill because we are not magicians.
The difference from option 6 is that it's managed (HA, patching and fleet
policy handled) and it's also an egress firewall: FQDN/SNI-based allow and
deny on what leaves, with logs your auditor will accept. So it can replace a
separate firewall meter as well as the NAT one.

The honest boundaries. At low volumes a plain NAT Gateway with free endpoints
is hard to beat, and I'd rather tell you that here than have you discover it
in a renewal meeting. The "up to 60–80%" saving we quote is against a metered
NAT-plus-firewall stack at meaningful volume: dated, directional, and worth
checking against your own bill in the
[savings calculator](/savings-calculator/) rather than taking on faith. One
wrinkle worth knowing: since 2026-02-06 AWS waives the NAT Gateway fee when
the gateway sits behind AWS Network Firewall. If you're already paying Network
Firewall's $0.065/GB, filtered egress is one meter, not two, and that one
meter is the comparison to run.

## The short version

Measure first, take the free money, then decide how much of the remainder is
worth engineering away:

1. Gateway endpoints for S3 and DynamoDB. Free, immediate, often the biggest
   single cut.
2. Interface endpoints where a service clears ~200 GB a month.
3. Flow Logs, then fix the top talkers. Mostly caching and hygiene.
4. Zonal routing (or deliberate consolidation). Stop stacking cross-AZ on NAT.
5. Non-prod cleanup. The hourly line there is pure waste.
6. NAT instance / fck-nat, if you can own the ops.
7. Flat-priced NVA with egress filtering, if you want it managed or you were
   about to pay for a firewall anyway.

For the line-by-line anatomy of the bill itself, see
[what an AWS NAT Gateway actually costs](/articles/aws-nat-gateway-cost-and-alternatives/)
and the [rates-at-a-glance page](/aws-nat-gateway-cost/); for the mechanics of
NAT, [how NAT gateways work](/articles/how-nat-gateways-work/).

## FAQ

<FaqAccordion faqs={faqs} />

<Fragment set:html={`<script type="application/ld+json">${JSON.stringify(faqJsonLd)}<\/script>`} />

---

## How to reduce Azure Firewall costs: 7 ways, ranked by savings

> Seven ways to cut the Azure Firewall bill, ranked by how much of it each one typically removes: right-sizing the SKU, deallocating idle firewalls, consolidating deployments, keeping Azure-bound traffic off the meter, hunting top talkers, pruning forgotten floors, and a flat-priced NVA. With the break-even maths.

Category: Cost  ·  Published: 2026-08-03  ·  https://enforza.io/articles/reduce-azure-firewall-costs/

import { SIGNUP_URL } from "../../lib/site";
import FaqAccordion from "../../components/site/FaqAccordion.astro";

export const faqs = [
  {
    q: "How much does Azure Firewall cost?",
    a: "Two charges at once. A per-deployment-hour fee of $1.25/hr on Standard (about $912/month) or $1.75/hr on Premium (about $1,278/month), before any traffic, plus $0.016 per GB processed, uncapped. The cheaper Basic SKU is $0.395/hr (about $288/month) but pays a higher $0.065/GB. The same rates re-apply per secured virtual hub, so multi-region hub-and-spoke estates multiply the hourly line. Rates Central US, dated 2026-07-04, directional.",
  },
  {
    q: "Can I turn Azure Firewall off when I'm not using it?",
    a: "Yes, and almost nobody does. Azure Firewall supports deallocation: stop it and the per-hour billing stops with it; allocate it again when you need it, which takes a few minutes. For a dev or test firewall that nobody touches outside working hours, deallocating nights and weekends removes roughly 70% of that firewall's hourly line. It needs a small automation script and the willingness to wait a few minutes on Monday morning.",
  },
  {
    q: "Is Azure Firewall Basic cheaper than Standard?",
    a: "On the floor, yes: about $288/month versus about $912/month. On the meter, no: Basic processes data at $0.065/GB against Standard's $0.016/GB, four times the rate. The break-even is around 12 to 13 TB of processed data a month; below it Basic wins, above it Basic quietly becomes the expensive option. Basic also caps throughput and drops features, so check the limits before celebrating. Never mix the two rate cards in one estimate.",
  },
  {
    q: "Do I need Azure Firewall and a NAT Gateway?",
    a: "Usually not both for egress. Azure Firewall performs its own source NAT, so there is no AWS-style NAT-gateway-behind-firewall stacking. The question is becoming unavoidable anyway: Microsoft is retiring default outbound access (March 31, 2026), after which every workload needs an explicit egress path: Azure Firewall, a NAT Gateway, Load Balancer outbound rules, or an NVA. Which one you pick is now a costed decision rather than a default.",
  },
  {
    q: "What Azure Firewall traffic costs the most?",
    a: "Whatever you hairpin through it that never needed inspection. With a blanket 0.0.0.0/0 route through the firewall, backups to your own storage accounts, container image pulls and log shipping all pay $0.016/GB for the privilege of being waved through. Firewall logs (or the workbook) aggregated by destination will show your top ten. The fixes are routing granularity, service endpoints and caching, in that order.",
  },
  {
    q: "How much can I save replacing Azure Firewall?",
    a: "It depends on volume and how many deployments you run, and anyone quoting one number without asking is selling something. A flat-priced NVA such as Enforza does the same egress-firewall job (stateful L3/L4, FQDN/SNI filtering, its own source NAT) at a flat per-firewall licence, about $249/month, plus the VM on your Azure bill. Against Standard's $912/month floor plus metering, that typically lands up to 60–80% lower, and the gap widens with traffic and with every extra hub deployment. At low volume on Basic, the honest answer is the gap narrows. Run your own numbers in the savings calculator, or read the 20 TB worked example priced line by line.",
  },
];

export const faqJsonLd = {
  "@context": "https://schema.org",
  "@type": "FAQPage",
  mainEntity: faqs.map((f) => ({
    "@type": "Question",
    name: f.q,
    acceptedAnswer: { "@type": "Answer", text: f.a.replace(/<[^>]+>/g, "") },
  })),
};

Azure Firewall's bill has a floor and a meter. The floor is the
per-deployment-hour fee: $1.25/hr on Standard, which is about **$912 a month
before a single byte moves**. That is a strong interpretation of
"pay as you go". The meter is $0.016 per GB processed, uncapped, on
everything you route through it. And the floor multiplies: the same rates
re-apply per secured virtual hub, so a tidy multi-region hub-and-spoke
diagram is also a multiplication exercise. (Rates Central US, dated
2026-07-04, directional.)

Disclosure before we start: I work on [Enforza](/), which is option 7 below.
It gets one section, at the end, after six things you should try first. Most
of them are configuration, not products.

Same rules as the [AWS version of this guide](/articles/reduce-aws-nat-gateway-costs/):
ranked by how much of the bill each move typically removes, boring ones first,
because that's where the money is.

## The ranking at a glance

1. **Right-size the SKU.** Premium without TLS inspection in use is $365/month
   of nothing. Basic below ~12 TB/month beats Standard's floor.
2. **Deallocate what sleeps.** Azure Firewall has an off switch. Dev and test
   firewalls off nights and weekends drop ~70% of their hourly line.
3. **Count your deployments.** Every extra firewall or secured hub is another
   $912/month floor. Consolidate where the architecture allows.
4. **Keep Azure-bound traffic off the meter.** Service endpoints are free;
   stop paying $0.016/GB to inspect your own backups.
5. **Hunt your top talkers.** Firewall logs, aggregate, rank, be mildly
   annoyed, fix with caching and routing granularity.
6. **Prune the forgotten floors.** Idle POC and staging firewalls bill $912 a
   month for existing. Delete or deallocate them.
7. **A flat-priced NVA.** Same egress-firewall job, flat licence, no per-GB
   meter, one floor instead of several.

Now each one, with the arithmetic.

## 1. Right-size the SKU

Three rate cards, frequently mixed up, occasionally all paid at once.
Standard is $1.25/hr plus $0.016/GB. Premium is $1.75/hr plus the same
$0.016/GB: the extra $0.50/hr, about **$365 a month per deployment**, buys
TLS inspection and IDPS. Premium is excellent value right up until you check
whether anyone actually enabled those features. If they didn't, that's a
one-line change worth $4,380 a year.

Basic runs the other direction: a $0.395/hr floor, about $288 a month, but a
**$0.065/GB** meter, four times Standard's rate. The break-even sits around
**12 to 13 TB of processed data a month**. Below it, Basic's lower floor
wins. Above it, Basic is the expensive option wearing a budget name badge.
Basic also caps throughput and trims features, so read the limits first. The
one unforgivable move is quoting Standard's floor with Basic's meter, or vice
versa; the two rate cards never mix.

## 2. Deallocate what sleeps

Here is the rarest thing in cloud billing: an off switch. Azure Firewall can
be **deallocated**. Stopped, the per-hour fee stops with it; allocated again,
it comes back in a few minutes. AWS offers nothing like this for a NAT
Gateway, which makes it strange that so few Azure teams use it.

A dev firewall runs 730 hours a month. The team that uses it works maybe 200
of those. Deallocating outside working hours removes roughly **70% of that
firewall's hourly line**, which on Standard is around $640 a month per dev
firewall, for the cost of a small automation script and a few minutes of
patience on Monday morning. A firewall guarding an empty dev environment at
3am is protecting sleep nobody is having.

## 3. Count your deployments

The rates re-apply per deployment and per secured virtual hub. This is where
tidy architecture gets expensive: firewalls multiply the way meeting invites
do, one per region, one per environment, one per team that didn't want to
share, and each one brings its own $912 floor before traffic.

The consolidation play is standard hub-and-spoke: one firewall in the hub,
spokes peered to it, instead of a firewall per VNet. The honest caveats: VNet
peering carries its own per-GB charge, consolidation concentrates blast
radius, and cross-region traffic should stay regional. But the arithmetic is
blunt. Two Standard deployments doing the work of one is $912 a month of
duplicated floor; count yours, then justify each one out loud.

## 4. Keep Azure-bound traffic off the meter

With a blanket 0.0.0.0/0 route through the firewall, everything pays the
meter, including traffic to your own Azure services. Backups to your own
storage account, container image pulls from ACR, log shipping to your
workspace: $0.016/GB each, for the privilege of being inspected on the way
to your own resources.

**Service endpoints are free** and keep Azure-service traffic on the Microsoft
backbone without the firewall hairpin. Private endpoints cost roughly
$0.01/hr plus $0.01/GB (checked 2026-08-03, directional) and buy the same
bypass with a private IP where you need it. Route with some granularity
instead of one blanket default, and the meter only sees the traffic that
actually warrants inspection. Your security team keeps control of what
matters; your backups stop paying tolls.

## 5. Hunt your top talkers

Same discipline as on AWS, different console. Azure Firewall's logs (or the
built-in workbook) aggregated by destination will produce a top-ten list, and
the list will annoy you. The usual suspects: image pulls that a cache would
kill, telemetry sending the same heartbeat uncompressed every ten seconds,
CI downloading identical packages hundreds of times a day in case they
changed, and one chatty third-party API nobody remembers integrating.

Fix with caching, batching and compression, then re-check quarterly. New
workloads invent new talkers. They always do.

## 6. Prune the forgotten floors

Somewhere in your subscriptions there is a firewall from a proof of concept
that ended in March. It bills $912 a month for existing. The floor charges
whether bytes flow or not, which makes idle firewalls the purest waste on
this list: nothing is being protected, inspected or even routed. Sweep for
firewalls with near-zero processed data, then delete them, or deallocate the
ones somebody swears they'll need again. The POC will not miss it.

## 7. Replace the floor and the meter with one flat price (this is us)

The last option is the one I have a stake in, so weigh my enthusiasm
accordingly. [Enforza](/secure-nat-gateway/) is a network virtual appliance,
one Linux VM in your own VNet, that does the egress-firewall job: stateful
L3/L4, FQDN/SNI-based allow and deny on what leaves, and its own source NAT,
so it covers the outbound role too. Flat per-firewall licence, about $249 a
month, **$0/GB processed**, and the VM stays on your
Azure bill because physics and Microsoft both insist.

Against Standard's floor-plus-meter that typically lands **up to 60–80%
lower**, and the gap widens with traffic and with every consolidated hub
deployment, because a flat line doesn't multiply. Directional and dated, so
check it against your own bill: the [savings calculator](/savings-calculator/)
takes two minutes, and the [20 TB worked example](/worked-examples/azure-firewall-cost-example/)
prices the comparison line by line if you'd rather see the working.

The honest boundaries. At low volume on Basic the gap narrows, and if you're
deep into Premium's TLS inspection or Sentinel-native tooling, the native
integration is a real reason to stay. And a deadline worth knowing either
way: Microsoft is retiring default outbound access on **March 31, 2026**,
after which every workload needs an explicit egress path: Azure Firewall,
NAT Gateway, Load Balancer outbound rules, or an NVA. You'll be making this
decision anyway; the only question is whether you cost it first.

## The short version

Audit first, then take the configuration savings, then decide what the
remainder is worth:

1. Right-size the SKU. Premium unused features off; Basic only below
   ~12 TB/month.
2. Deallocate dev and test outside working hours. The off switch exists.
3. Count deployments; consolidate the duplicate floors.
4. Service endpoints and granular routes; stop metering your own backups.
5. Logs, top talkers, caching. Repeat quarterly.
6. Delete the POC firewall from March.
7. Flat-priced NVA if the floors and meters still add up to real money.

For the line-by-line anatomy, see [Azure Firewall pricing](/azure-firewall-cost/)
and the [Azure NAT Gateway breakdown](/azure-nat-gateway-cost/); for the same
exercise on AWS, [how to reduce AWS NAT Gateway costs](/articles/reduce-aws-nat-gateway-costs/);
for the multi-cloud view, [reducing cloud NAT costs](/articles/cloud-nat-costs/).

## FAQ

<FaqAccordion faqs={faqs} />

<Fragment set:html={`<script type="application/ld+json">${JSON.stringify(faqJsonLd)}<\/script>`} />

---

## AWS NAT Gateway: what it actually costs, and the alternatives

> A line-by-line look at AWS NAT Gateway pricing. The $0.045/hr plus $0.045/GB you don't budget for, why it multiplies per Availability Zone, and the honest alternatives: VPC endpoints, NAT instances and fck-nat, a flat-priced NVA, and when a plain NAT Gateway is simply right.

Category: Cost  ·  Published: 2026-07-31  ·  https://enforza.io/articles/aws-nat-gateway-cost-and-alternatives/

import { SIGNUP_URL } from "../../lib/site";
import FaqAccordion from "../../components/site/FaqAccordion.astro";

export const faqs = [
  {
    q: "How much does an AWS NAT Gateway cost?",
    a: 'Two charges. $0.045 per gateway-hour plus $0.045 per GB of data processed (us-east-1, dated 2026-06-14, directional). One gateway running all month is about $33 before any traffic; add the per-GB line and a workload pushing 5 TB/month lands near $258/month, for connectivity only, no filtering. Most teams run one gateway per Availability Zone for resilience, which multiplies the hourly line.',
  },
  {
    q: "What is the NAT Gateway data-processing charge?",
    a: "It is the $0.045-per-GB fee AWS applies to every gigabyte a NAT Gateway processes, separate from the per-hour fee. It applies to all traffic through the gateway regardless of destination, and it scales directly with how much your private subnets talk out. On a busy estate it is usually the larger of the two lines.",
  },
  {
    q: "Are VPC endpoints cheaper than a NAT Gateway?",
    a: 'For traffic to AWS services, usually yes. Gateway endpoints for Amazon S3 and DynamoDB are free and take that traffic off the NAT Gateway entirely. Interface endpoints (PrivateLink) cost roughly $0.01 per hour per endpoint per Availability Zone plus about $0.01/GB (us-east-1, checked 2026-07-31, directional), which beats $0.045/GB for heavy AWS-service traffic but is billed per service you create an endpoint for. Endpoints do nothing for traffic to the general internet.',
  },
  {
    q: "Is a NAT instance cheaper than a NAT Gateway?",
    a: "On the per-GB line, yes. A NAT instance is a NAT AMI on an EC2 VM you own, so you pay the instance and normal data-transfer-out, with no $0.045/GB processing fee. The open-source fck-nat is the well-made version of this. The trade-off is that you own the operations: high availability, patching, and the box's own attack surface. It does plain source NAT and nothing else.",
  },
  {
    q: "When should I just use a NAT Gateway?",
    a: "When egress is low or predictable and you would rather pay a few dollars a month than run anything. If your private subnets push a few hundred gigabytes and you want zero operational surface, the managed NAT Gateway is the right answer and the alternatives are not worth the effort. The case for changing shows up when the per-GB line becomes a real number on the bill.",
  },
  {
    q: "Does a NAT Gateway filter or secure egress?",
    a: 'No. A NAT Gateway gives outbound connectivity and nothing else: no allow/deny rules, no FQDN or hostname control, no logging of what left. To control egress you add a firewall in the path. On AWS that is usually AWS Network Firewall, which adds its own $0.065/GB (us-east-1, dated 2026-07-10). Since 2026-02-06 AWS waives the NAT Gateway fee when it sits behind Network Firewall, so filtered egress is one meter, not two.',
  },
];

export const faqJsonLd = {
  "@context": "https://schema.org",
  "@type": "FAQPage",
  mainEntity: faqs.map((f) => ({
    "@type": "Question",
    name: f.q,
    acceptedAnswer: { "@type": "Answer", text: f.a.replace(/<[^>]+>/g, "") },
  })),
};

An AWS NAT Gateway is the kind of line item nobody puts in the first budget. It
looks like plumbing, it costs a few cents an hour, and then a bill review three
months later finds it quietly running up a number that has nothing to do with the
work your servers were doing. This is a look at where that money actually goes,
and the honest set of alternatives, including the cases where the plain NAT
Gateway is the right call and you should leave it alone.

Full disclosure before we start: I work on [Enforza](/), which is one of the
alternatives further down. It gets one section, late, alongside the others, and
I have tried to be fair about where it is not the answer. If you want the
mechanics of NAT itself first, [how NAT gateways work](/articles/how-nat-gateways-work/)
covers the address-translation side; this article is about the bill.

## The two charges on a NAT Gateway bill

A managed NAT Gateway bills two ways, and only one of them is the one people
expect:

- **$0.045 per gateway-hour**. The fixed cost of the gateway existing, about $33
  a month if it runs all month.
- **$0.045 per GB processed**. The data-processing charge, on every byte that
  passes through, in or out, regardless of where it was going.

Rates are us-east-1, dated 2026-06-14, directional and subject to change; they
vary a little by region. The hourly charge is the one you notice at provisioning
time and then forget. The per-GB charge is the one that grows with your business,
and it is billed on volume, not on value. The gateway does not know or care
whether a byte was a critical API call or a container pulling the same base image
for the thousandth time. It is $0.045 either way.

A worked example, deliberately modest. One NAT Gateway, running the full 730
hours in a month, with 5 TB of egress behind it:

- Gateway-hours: $0.045 × 730 = about **$33**
- Data processing: $0.045 × 5,000 GB = **$225**
- **Monthly total: about $258**, for connectivity only

That $258 buys you exactly nothing except the ability for private subnets to reach
the internet. No filtering, no policy, no record of what left. And 5 TB is not a
large estate. Double the traffic and you have doubled the larger of the two lines,
because it scales linearly and never stops.

## Where the bill actually surprises people

The headline rates are not the surprise. These three are.

**It multiplies per Availability Zone.** AWS's own guidance is one NAT Gateway
per AZ, and for good reason: a gateway lives in a single zone, so a single shared
gateway is both a single point of failure and a source of cross-AZ data-transfer
charges (roughly $0.01/GB each way, directional) for every workload in the other
zones. Do the resilient thing across three AZs and you are now paying three lots of
the hourly charge, about $99/month, before a single byte moves. Try to save that by
centralising to one AZ and you pick up the cross-AZ transfer fee on all the traffic
from the other zones instead. It is a genuine trade-off, not a free lunch either
way.

**The per-GB charge applies to traffic that never needed the internet.** A large
share of what many workloads send out is not going to the internet at all. It is
going to AWS services: S3, ECR, CloudWatch, Systems Manager, Secrets Manager,
DynamoDB. If that traffic routes through the NAT Gateway, you are paying $0.045/GB
to reach a service that is sitting inside AWS the whole time. This is the single
most common source of a NAT bill that looks too high for the amount of real
internet traffic, and it is also the most fixable. More on that in the next
section.

**There is no off switch.** A managed NAT Gateway cannot be paused when idle the
way an instance can be stopped. The hourly charge runs whether traffic is flowing
or not, so a forgotten gateway in a dev account is a small standing charge that
nobody is watching. Not a disaster, but it adds up across accounts.

## VPC endpoints: take AWS-service traffic off NAT entirely

If a meaningful fraction of your egress is to AWS services, the cheapest thing you
can do is stop sending it through the NAT Gateway at all. That is what VPC
endpoints are for, and there are two kinds with very different economics.

**Gateway endpoints for S3 and DynamoDB are free.** No hourly charge, no per-GB
charge. You add a gateway endpoint, point the route at it, and traffic to
[S3](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html) or
[DynamoDB](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-ddb.html)
leaves the NAT path entirely. If your workloads move a lot of objects to and from
S3, this one change can take a large bite out of the per-GB line for nothing. There
is no reason not to do it.

**Interface endpoints (PrivateLink) are cheap but not free.** For the other AWS
services (ECR, CloudWatch, SSM, Secrets Manager and the rest) you use interface
endpoints, which cost roughly **$0.01 per hour per endpoint per AZ plus about
$0.01/GB** ([AWS PrivateLink pricing](https://aws.amazon.com/privatelink/pricing/),
us-east-1, checked 2026-07-31, directional). That per-GB rate is well under the
NAT Gateway's $0.045/GB, so for heavy service traffic it wins clearly. The honest
catch is that you pay per endpoint per AZ, so a dozen services across three zones
is a standing hourly cost of its own. Endpoints pay off when the traffic through
them is high relative to the number of endpoints, and they do nothing for traffic
to the general internet, which still needs a NAT path.

The practical read: gateway endpoints for S3 and DynamoDB are close to free money,
add them. Interface endpoints are worth it for the busy services and not worth it
for the quiet ones. Neither removes the need for a NAT path for genuine internet
egress; they shrink how much goes through it.

## NAT instances and fck-nat: cheaper, if you want the ops

The oldest alternative is to run NAT yourself. A NAT instance is a NAT AMI on an
EC2 VM: you pay for the instance and for normal data-transfer-out, and there is no
$0.045/GB processing fee, because the processing is just your own box forwarding
packets. For a lot of workloads that is a real saving.

The well-made modern version of this is [fck-nat](https://github.com/AndrewGuenther/fck-nat),
an open-source NAT instance with a current ARM/Graviton image, a clean Terraform
module and a responsive maintainer. If what you need is cheap outbound
connectivity for dev or for prod that can tolerate a brief blip, it is genuinely
good and I would point you to it before I pitched anything.

The trade-offs are real and worth stating plainly:

- **High availability is on you.** A single NAT instance is a single point of
  failure. The documented HA pattern is active-passive with a health check that
  swaps a route on failure, which severs in-flight connections and takes a few
  seconds to reconverge. That is fine for a lot of workloads and not fine for
  some.
- **Patching and lifecycle are on you.** It is an EC2 VM. It needs an OS, updates,
  and an eye on the AMI as base images get deprecated.
- **It is plain source NAT and nothing else.** No egress filtering, no FQDN or
  hostname rules, no audit log of what left. If you later need to control egress,
  you are adding another box.
- **It sits in a public subnet with a public path.** That is attack surface on
  the box that is carrying all your outbound traffic, and it is your job to lock
  it down.

None of that is a reason to avoid a NAT instance. It is a reason to be clear-eyed
that "cheaper" here means "cheaper plus operational work." For a homelab or a small
estate that is a fine deal. For a fleet across accounts it is a lot of boxes to
babysit.

## When a plain NAT Gateway is simply the right answer

It is worth saying, because articles like this tend to imply the managed service
is always a mistake, and it is not. A plain NAT Gateway is the correct choice when:

- Your egress is low or predictable, so $0.045/GB on a few hundred gigabytes is a
  rounding error you would happily pay to run nothing.
- You value zero operational surface more than the saving. No box, no patching, no
  HA design. AWS runs it and scales it.
- Most of your traffic is already off the NAT path via endpoints, so the per-GB
  line is small to begin with.

If that is you, add the free S3 and DynamoDB gateway endpoints, leave the NAT
Gateway alone, and spend your attention on something that matters more. The rest of
this only pays off once the per-GB line is a number you would notice.

## A managed middle: a flat-priced NVA

Between "rent the metered managed service" and "run your own box" there is a third
shape: a network virtual appliance that does the NAT for you, managed, but on a
flat licence instead of a per-GB meter. This is where Enforza sits, and, as
promised, here is the honest version.

Enforza is a single Linux VM in your own AWS network that does secure source NAT,
the same outbound translation a NAT Gateway provides, under a flat per-firewall
licence with **no per-GB data-processing charge**. Because it is a full firewall,
it also does egress filtering (FQDN and hostname rules) and logging on the same
box, which a NAT Gateway and a NAT instance both leave out. Migration is a
route-table change: point the route that currently exits via your NAT Gateway at
the Enforza instance instead.

What it does not do, so the comparison stays honest:

- **It does not remove your AWS bill.** You still pay AWS for the EC2 instance the
  appliance runs on, and for normal data-transfer-out where it applies. The flat
  licence replaces the per-GB NAT and firewall metering, not AWS's underlying
  infrastructure.
- **It is a box you deploy in your network.** Managed and self-upgrading, but it is
  still a VM you run, not a zero-footprint service. If you genuinely want nothing to
  deploy, the managed NAT Gateway wins on that specific axis.
- **The saving is directional.** Against a metered NAT-plus-firewall stack it
  typically lands **up to 60–80% lower** from meaningful egress volumes upward, and
  the gap widens as traffic grows because the flat line stays flat. At low volumes
  the difference is small and a NAT Gateway may be simpler. Run your own numbers in
  the [savings calculator](/savings-calculator/) rather than taking a range on
  faith.

If you are consolidating egress across several VPCs or accounts, the same appliance
is the point where you would centralise it. The [AWS landing-zone pattern](/landing-zones/aws/)
and the open [Terraform for it](https://github.com/enforza/landing-zones) show the
route-table and appliance-mode detail, which is the same regardless of whose
appliance you put in the path.

## The short version

The NAT Gateway hourly charge is not the problem; the $0.045/GB data-processing
charge is, and it multiplies quietly per AZ and on traffic that never needed the
internet. In order of effort-to-reward:

1. Add the free S3 and DynamoDB gateway endpoints. Do this regardless of anything
   else.
2. Add interface endpoints for the busy AWS services, skip them for the quiet ones.
3. If you want cheaper internet egress and can own the ops, a NAT instance or
   fck-nat removes the per-GB charge.
4. If you want it managed and want egress control on the same box, a flat-priced
   NVA removes the per-GB charge and adds the firewall, at the cost of running a VM.
5. If your egress is small, do step 1 and stop. The plain NAT Gateway is fine.

Knowing which of the two lines, the hourly or the per-GB, is actually driving your
bill is the whole game. For a step-by-step playbook ranked by impact, see
[how to reduce AWS NAT Gateway costs: 7 ways](/articles/reduce-aws-nat-gateway-costs/);
for the AWS-specific rates at a glance and a calculator,
see [AWS NAT Gateway cost](/aws-nat-gateway-cost/); for the same question across
AWS, Azure and GCP, see [reducing cloud NAT costs](/articles/cloud-nat-costs/).

## FAQ

<FaqAccordion faqs={faqs} />

<Fragment set:html={`<script type="application/ld+json">${JSON.stringify(faqJsonLd)}<\/script>`} />

---

## enforza-cockpit: a free web GUI for nftables on your homelab

> enforza-cockpit is a free, open-source Cockpit plugin that gives you a browser GUI for nftables: build a firewall policy, turn one Linux box into a router and NAT gateway, and watch per-rule logs, with no cloud account and nothing phoning home.

Category: Firewalls  ·  Published: 2026-07-31  ·  https://enforza.io/articles/nftables-gui-cockpit/

import FaqAccordion from "../../components/site/FaqAccordion.astro";

export const faqs = [
  {
    q: "Is enforza-cockpit really free?",
    a: 'Yes. It is MIT-licensed and open source, needs no account, no cloud connection and no subscription, and all firewall state stays on your machine. The repo is <a href="https://github.com/enforza/enforza-cockpit">github.com/enforza/enforza-cockpit</a>.',
  },
  {
    q: "What is it built on?",
    a: "It is a plugin for Cockpit, the web console that ships with most Linux distributions. The GUI renders your policy to a live nftables ruleset (in a table called inet enforza) and lets the kernel do the enforcing. A bootstrap script installs nftables, its JSON/Python bindings, ulogd2 for logging, and Cockpit itself.",
  },
  {
    q: "Which Linux distributions does it support?",
    a: "Debian and Ubuntu, Fedora, RHEL/Rocky/Alma, and openSUSE. The bootstrap script detects your package manager (apt, dnf, yum or zypper) so the same steps work across the common homelab and small-cloud distributions.",
  },
  {
    q: "Can a bad rule lock me out of the box?",
    a: "It is designed so it cannot, permanently. Every apply uses a confirm-or-revert model: after you click Apply you have 60 seconds to click Confirm, and if you do not, the previous ruleset is automatically restored. Keep a second way onto the box handy the first few times anyway. If you ever do get stuck, get on out-of-band and run nft flush ruleset or nft delete table inet enforza.",
  },
  {
    q: "Does it do FQDN or application-layer filtering?",
    a: "No, and it is worth being clear about that. It is a GUI over plain nftables: L3/L4 rules on the three chains (traffic to, through and from the host) plus SNAT. There is no FQDN, SNI or other L7 filtering, and it manages one host, not a fleet. If that is what you need, this is not the tool.",
  },
  {
    q: "Can it act as a router and NAT gateway?",
    a: "Yes. Turn on Enable routing (IP forwarding) and the box routes between its interfaces; mark a Network rule SNAT and it masquerades outbound traffic, so it works as an edge gateway for the machines behind it. That is the homelab use case it is happiest in.",
  },
];

export const faqJsonLd = {
  "@context": "https://schema.org",
  "@type": "FAQPage",
  mainEntity: faqs.map((f) => ({
    "@type": "Question",
    name: f.q,
    acceptedAnswer: { "@type": "Answer", text: f.a.replace(/<[^>]+>/g, "") },
  })),
};

nftables is the right tool for a Linux firewall and a genuinely nice piece of
engineering, but writing rulesets by hand is a niche pleasure. If you run a homelab
or a small cloud box and you want a firewall you can see and click, without pulling
in a whole appliance distribution or standing up something in the cloud, there is a
free, open-source option worth knowing about:
[enforza-cockpit](https://github.com/enforza/enforza-cockpit). It is a
[Cockpit](https://cockpit-project.org/) plugin that gives you a browser GUI over
nftables. Install it, build a policy, and watch per-rule logs land in your syslog.

This article walks through what it is and how to use it. It asks nothing of you and
there is nothing to buy, so read it as a how-to. The one-line disclosure of who
makes it is at the bottom where it belongs.

## What it actually is

enforza-cockpit turns a single Linux box into three things that usually come
separately, all on the one host and with nothing external to depend on:

- **A firewall.** Three rule sections compile to a live nftables ruleset that
  filters traffic to, through, and from the host.
- **A router and NAT gateway.** Turn on IP forwarding and the box routes between
  its interfaces; mark a rule SNAT and it masquerades outbound traffic, so it works
  as an edge gateway for whatever sits behind it.
- **A management console.** Cockpit's web UI is the console. You build, preview,
  apply and log every rule from the browser. There is no separate controller, no
  agent phoning home, and no cloud account.

Because it runs entirely on the one host and inside Cockpit's own authentication
and TLS, the result is a stand-alone appliance you happen to manage from a web
page. That is the whole idea: a clean GUI wrapper for a local nftables firewall,
nothing more clever than that.

## Installing it

You need a Linux server with root or sudo, inbound access to TCP 9090 (Cockpit's
web port) from wherever you browse, and a browser. On a cloud instance, open 9090
in the security group to your own IP only, not the world.

There are two scripts. The first clones the repo and installs the prerequisites,
detecting your package manager along the way:

```bash
git clone https://github.com/enforza/enforza-cockpit.git
cd enforza-cockpit
sudo ./bootstrap.sh
```

That pulls in nftables, its JSON/Python bindings (so the GUI can read and write the
ruleset programmatically), ulogd2 for userspace netfilter logging, and Cockpit
itself. It enables Cockpit's socket immediately, and enables the nftables service
but deliberately does not start it with an empty ruleset, so it cannot lock you out
before you have written a policy.

The second script installs the plugin into Cockpit:

```bash
sudo ./deploy.sh
```

That copies the built files into Cockpit's system package directory
(`/usr/share/cockpit/enforza`). Browse to `https://<your-host>:9090`, accept the
self-signed certificate warning on a fresh install, and log in with a local system
account that can use sudo. The firewall plugin needs administrative privilege, so
if Cockpit shows a "Limited access" banner, click it and re-authenticate. The
plugin then appears as **Firewall (enforza)** in the left-hand menu.

## The three chains, in plain terms

The reason a GUI over nftables is useful is that the mental model is simple once
someone lays it out. enforza-cockpit gives you three rule sections, and each maps
directly to one of nftables' filter hooks:

| Tab | nftables hook | What it controls |
|-----|---------------|------------------|
| **Management** | `input` | Traffic **to** the box itself: SSH, the Cockpit port, health checks. |
| **Network** | `forward` | Traffic passing **through** the box between other hosts and the internet. |
| **Local** | `output` | Traffic originating **from** the box: updates, DNS, outbound calls. |

Each section has a default action (accept or drop). First match wins; anything a
rule does not catch falls through to the default. There is also an **Objects** tab
for reusable named network (CIDR) and port sets: define `home-lan`, `mgmt`, `web`
once and reference them as `@home-lan`, `@web` and so on across any rule. Edit the
object and every rule using it updates, which is the same reason you use named sets
in a hand-written ruleset, minus the typing.

If you have ever stared at `input`, `forward` and `output` in the docs and not
been quite sure which one your rule belonged in, seeing them as three labelled
tabs is most of the value on its own.

## Building a first policy

The safe first policy is a locked-down Management section: allow SSH and the
Cockpit port from your own address, drop everything else. In the Management tab,
set the default action to **drop**, then add a rule:

- **Action** `accept`, **Protocol** `tcp`, **Destination port** `22`
- **Source** your admin IP or CIDR (or `any` to start with)
- Tick **Log matches**, which is what puts the rule in your syslog
- **Comment** `SSH from admin`, which is included in the log line, so make it mean
  something

Add a second rule the same way for TCP 9090 so you keep the Cockpit UI. And heed
the obvious warning: allow SSH **and** Cockpit from your own IP before you apply a
default-drop policy, or you will be relying on the auto-revert to get back in.

Then the apply flow, which is the part that makes this safe to do on a box you care
about:

1. **Preview** renders the policy to nftables JSON and dry-runs it against the
   kernel. A green "Valid" means the kernel accepts it.
2. **Apply** puts it live and starts a **confirm-or-revert** banner with a 60-second
   countdown.
3. **Verify you still have access.** Open a fresh SSH session, or just check the
   Cockpit page still responds.
4. **Confirm** to keep the ruleset. Do nothing and it auto-reverts to the previous
   one; there is also a Revert now button.
5. **Save** persists the policy document to `/etc/enforza/policy.json` so it reloads
   next time.

Your rules are now live in the `inet enforza` nftables table, and you can always
check what actually landed from a shell with `sudo nft list table inet enforza`.
The GUI is a front end; the kernel state is the truth, and nothing stops you
reading it directly.

## Turning it into a router and NAT gateway

The Network tab (the `forward` path) is where the box stops being just a host
firewall and becomes a gateway. Turn on **Enable routing** to switch on IP
forwarding, then add a Network rule and mark it **SNAT**. That masquerades outbound
traffic from the hosts behind the box out through its public interface, so a single
Linux instance becomes the edge gateway for a whole segment: a lab network, a set
of VMs, or the machines on a home LAN. Network rules can carry both a **LOG** flag
and the **SNAT** flag, so you can log and source-NAT the same traffic, and
reference `@objects` for source, destination and ports to keep the rules readable.

That is the same job a small cloud NAT instance does, on hardware you already have.

## Watching the logs

Any rule with **Log matches** ticked emits a kernel log line each time it matches,
and enforza-cockpit tags every line with three useful things: the section
(`to-firewall`, `through-firewall` or `from-firewall`), a plain verdict word
(`ALLOW`, `DENY` or `REJECT`), and your rule's comment. So a matched SSH accept
reads like:

```
kernel: enforza to-firewall ALLOW: SSH from admin IN=eth0 ... SRC=203.0.113.10 DPT=22 ...
```

Because the verdict is a plain word, grep does the rest:

```bash
sudo tail -f /var/log/syslog | grep 'enforza.*DENY'   # only denials
sudo tail -f /var/log/syslog | grep 'SSH from admin'  # one rule, by its comment
```

On distributions without `/var/log/syslog` (many dnf-based ones), read the kernel
log through the journal instead with `sudo journalctl -kf | grep enforza`.

One gotcha worth internalising, because it catches everyone once: a section's
**default** drop is not logged. If you want to see what is being denied, add an
explicit last rule with **Action** `drop` (or `reject`), **Source** `any` and
**Log matches** ticked, and make sure it sits at the bottom of the list. First
match wins, so a logging catch-all only works as the final rule.

## What it isn't

Since being honest about limits is more useful than a feature list, here is what
enforza-cockpit does not do:

- **No application-layer filtering.** It is plain nftables: L3/L4 rules plus SNAT.
  There is no FQDN or hostname filtering, no SNI inspection, no L7 anything. If you
  need to allow `github.com` but not the rest of the internet, this is not the tool.
- **One host, not a fleet.** It manages the box it runs on. There is no central
  console, no pushing one policy to many machines, and no policy-as-code pipeline.
  For a homelab that is exactly right; for fifty boxes it is fifty logins.
- **A static ruleset.** The kernel enforces the rules you compiled. It does not
  learn, score, or adapt, and it does not pretend to.

None of that is a criticism. It is a small, sharp tool that does one job well, and
knowing the edges is what lets you use it confidently.

## Who makes it

enforza-cockpit is a free, MIT-licensed community tool from the people behind
[enforza](https://enforza.io), a managed cloud-firewall platform. It needs no
account and no cloud connection, the code is open so you can read exactly what it
does to your box, and contributions and bug reports are welcome. That is the whole
disclosure. Go build a firewall.

## FAQ

<FaqAccordion faqs={faqs} />

<Fragment set:html={`<script type="application/ld+json">${JSON.stringify(faqJsonLd)}<\/script>`} />

---

## AWS Gateway Load Balancer firewall: how GWLB inspection works

> What AWS Gateway Load Balancer is, how the GENEVE datapath works, which firewalls work behind GWLB, how to use a third-party NVA — and the cost of GWLB inspection.

Category: Firewalls  ·  Published: 2026-06-25  ·  https://enforza.io/articles/aws-gateway-load-balancer-firewall/

import { SIGNUP_URL } from "../../lib/site";
import FaqAccordion from "../../components/site/FaqAccordion.astro";

export const faqs = [
  {
    q: "What firewalls work with AWS Gateway Load Balancer?",
    a: "A relatively short list, because the appliance must terminate the GENEVE tunnel. Palo Alto Networks VM-Series, Fortinet FortiGate-VM, Check Point CloudGuard, AWS Network Firewall, and Enforza all work as GWLB inspection appliances. Enforza is one of the few independent NVAs that can.",
  },
  {
    q: "How do I use a third-party NVA with GWLB?",
    a: "Run the NVA fleet in a dedicated appliance VPC behind a Gateway Load Balancer and its GENEVE target group, then place a GWLB endpoint (GWLBe) in each spoke VPC and point the workload route (<code>0.0.0.0/0</code>) at the AZ-local GWLBe. The route change inserts inspection transparently. For Enforza this ships as Terraform that builds the whole shape; CloudFormation is not provided for this scenario yet.",
  },
  {
    q: "Can a third-party firewall run behind AWS GWLB?",
    a: "Yes — if it can decapsulate GENEVE (UDP/6081), preserve the inner packet, keep both directions of a flow pinned, and re-encapsulate replies. Few firewalls do. Enforza is one that does, running as a transparent GENEVE inspection appliance.",
  },
  {
    q: "GWLB vs AWS Network Firewall — what's the difference?",
    a: 'They are different layers. GWLB is the <em>transport</em> that steers traffic to and from inspection appliances using GENEVE; AWS Network Firewall is an <em>appliance</em> that can sit behind a GWLB (or be deployed via its own endpoints). You can run GWLB with a third-party NVA instead of Network Firewall — see the <a href="/compare/aws-network-firewall/">AWS Network Firewall alternative</a> page.',
  },
  {
    q: "Does Enforza support multi-AZ behind GWLB?",
    a: "Yes. Enforza runs an engine per Availability Zone behind the GWLB. With cross-zone load balancing off, each AZ's traffic is inspected in-AZ, giving you AZ affinity, no cross-AZ data-transfer on inspected traffic, and an AZ-isolated blast radius.",
  },
  {
    q: "How much does GWLB inspection cost with Enforza?",
    a: 'Enforza is a flat per-firewall licence with no per-GB data-processing tax — the appliance cost does not grow with traffic. You still pay AWS\'s own GWLB and GWLBe hourly and data-processing charges (those apply to any appliance). What the flat licence replaces is the appliance licence and the per-GB inspection tax that a Network Firewall or mega-NGFW layer adds on top. Run your own numbers in the <a href="/savings-calculator/">savings calculator</a>.',
  },
];

export const faqJsonLd = {
  "@context": "https://schema.org",
  "@type": "FAQPage",
  mainEntity: [
    {
      "@type": "Question",
      name: "What firewalls work with AWS Gateway Load Balancer?",
      acceptedAnswer: {
        "@type": "Answer",
        text: "A relatively short list, because the appliance must terminate the GENEVE tunnel. Palo Alto Networks VM-Series, Fortinet FortiGate-VM, Check Point CloudGuard, AWS Network Firewall, and Enforza all work as GWLB inspection appliances. Enforza is one of the few independent NVAs that can.",
      },
    },
    {
      "@type": "Question",
      name: "How do I use a third-party NVA with GWLB?",
      acceptedAnswer: {
        "@type": "Answer",
        text: "Run the NVA fleet in a dedicated appliance VPC behind a Gateway Load Balancer and its GENEVE target group, then place a GWLB endpoint (GWLBe) in each spoke VPC and point the workload route (0.0.0.0/0) at the AZ-local GWLBe. The route change inserts inspection transparently. For Enforza this ships as Terraform that builds the whole shape; CloudFormation is not provided for this scenario yet.",
      },
    },
    {
      "@type": "Question",
      name: "Can a third-party firewall run behind AWS GWLB?",
      acceptedAnswer: {
        "@type": "Answer",
        text: "Yes — if it can decapsulate GENEVE (UDP/6081), preserve the inner packet, keep both directions of a flow pinned, and re-encapsulate replies. Few firewalls do. Enforza is one that does, running as a transparent GENEVE inspection appliance.",
      },
    },
    {
      "@type": "Question",
      name: "GWLB vs AWS Network Firewall — what's the difference?",
      acceptedAnswer: {
        "@type": "Answer",
        text: "They are different layers. GWLB is the transport that steers traffic to and from inspection appliances using GENEVE; AWS Network Firewall is an appliance that can sit behind a GWLB (or be deployed via its own endpoints). You can run GWLB with a third-party NVA instead of Network Firewall.",
      },
    },
    {
      "@type": "Question",
      name: "Does Enforza support multi-AZ behind GWLB?",
      acceptedAnswer: {
        "@type": "Answer",
        text: "Yes. Enforza runs an engine per Availability Zone behind the GWLB. With cross-zone load balancing off, each AZ's traffic is inspected in-AZ, giving you AZ affinity, no cross-AZ data-transfer on inspected traffic, and an AZ-isolated blast radius.",
      },
    },
    {
      "@type": "Question",
      name: "How much does GWLB inspection cost with Enforza?",
      acceptedAnswer: {
        "@type": "Answer",
        text: "Enforza is a flat per-firewall licence with no per-GB data-processing tax — the appliance cost does not grow with traffic. You still pay AWS's own GWLB and GWLBe hourly and data-processing charges (those apply to any appliance). What the flat licence replaces is the appliance licence and the per-GB inspection tax that a Network Firewall or mega-NGFW layer adds on top.",
      },
    },
  ],
};

AWS Gateway Load Balancer (GWLB) is the AWS-native way to insert a fleet of
inspection appliances into your traffic path — transparently, at scale, without
re-architecting every workload's routing. It is also one of the least understood
pieces of AWS networking, partly because the appliances that can sit behind it
are a short list. This article explains what GWLB is, how its GENEVE datapath
works, which firewalls work with it, how to put a third-party network virtual
appliance (NVA) behind it, and what GWLB inspection actually costs.

## What AWS Gateway Load Balancer is

AWS Gateway Load Balancer is a load balancer purpose-built for **transparent,
bump-in-the-wire traffic inspection**. Unlike an Application or Network Load
Balancer, it is not a front door for your applications — it is a way to steer
traffic *through* a pool of inspection appliances and back out again, invisibly
to the workloads on either side.

It has two halves:

- The **Gateway Load Balancer** itself lives in an appliance (inspection) VPC,
  in front of a target group of inspection appliances — firewalls, IDS/IPS
  sensors, or other network virtual appliances.
- The **GWLB endpoint (GWLBe)** is a Gateway Load Balancer endpoint placed in
  the spoke (workload) VPC. You point a route at the GWLBe, and traffic destined
  for that route is handed to the GWLB across a private link, inspected, and
  returned — with the original source and destination preserved.

Because the GWLBe is just a route target, you insert inspection by changing a
route table, not by re-addressing or proxying anything. The workload sends a
packet to the internet (or to another VPC); the route quietly diverts it through
the appliance fleet first. That is what "transparent" and "bump-in-the-wire"
mean here: the appliance sees the real packets, but neither end of the
conversation knows an appliance is in the path.

## How the GWLB datapath works

The mechanism that makes this transparency possible is **GENEVE encapsulation**.

When a flow reaches the GWLB endpoint, the GWLB **GENEVE-encapsulates** the
original packet — wrapping it, unchanged, inside a GENEVE header — and forwards
it over **UDP port 6081** to one of the appliances in the target group. GENEVE
(Generic Network Virtualization Encapsulation) carries the original packet plus
metadata identifying the flow, so the appliance receives the *real* inner packet
with its true source and destination intact.

At the appliance, the datapath is:

1. **Decapsulate.** The appliance strips the GENEVE header (UDP/6081) and
   recovers the original inner packet.
2. **Apply policy.** The firewall evaluates the inner packet against its
   L3/L4/L7 policy — allow, deny, log, FQDN/SNI checks, and so on.
3. **Forward or return.** For allowed egress, the appliance **source-NATs** the
   inner packet and sends it out via the appliance VPC's internet gateway.
   Return traffic comes back to the appliance, is un-NAT'd, **re-encapsulated**
   into the original GENEVE flow, and returned through the tunnel to the GWLB,
   which hands it back to the GWLBe and on to the originating workload.

The key property is that GENEVE encap/decap is **stateful per flow**: the GWLB
remembers which appliance handled a flow and pins both directions of that flow
to the same appliance, so the firewall sees the full conversation. The appliance
must terminate the GENEVE tunnel correctly — decapsulating, tracking the flow,
and re-encapsulating replies — which, as the next section explains, is exactly
why the list of compatible appliances is short.

## Multi-AZ and scale

GWLB inspection is designed to scale horizontally and to stay highly available
across Availability Zones.

- **Target group + health checks.** Appliances register in a GWLB target group.
  GWLB health-checks each appliance and automatically stops sending flows to one
  that goes unhealthy, distributing flows across the healthy members. To add
  capacity, you add appliances to the target group — the firewall fleet scales
  out, it does not scale up.
- **Cross-zone load balancing off → AZ affinity.** GWLB can run with cross-zone
  load balancing **disabled**, which keeps each flow inside its own Availability
  Zone: AZ-a's traffic is inspected by an AZ-a appliance, AZ-b's by an AZ-b
  appliance, and so on. This is the **appliance-mode / AZ-affinity** pattern, and
  it has three benefits — no cross-AZ data-transfer charges on inspected traffic,
  lower latency, and an **AZ-isolated blast radius** (losing one appliance only
  affects its own zone rather than failing flows across to another AZ).
- **Horizontal scale-out.** Because flows are load-balanced across a target
  group, throughput is a function of how many appliances you run, not how big a
  single box is. You scale the fleet to the traffic.

## Which firewalls work with AWS GWLB, and why few NVAs can

A common question is simply: **what firewalls work with AWS GWLB?** The honest
answer is that it is a relatively short list, because an appliance must terminate
the GENEVE tunnel — decapsulate UDP/6081, track each flow, and re-encapsulate
replies — and most firewalls were never built to do that.

Appliances that work as GWLB inspection targets include:

- **Palo Alto Networks VM-Series**
- **Fortinet FortiGate-VM**
- **Check Point CloudGuard**
- **AWS Network Firewall** (which AWS itself runs behind GWLB internally)
- **Enforza** — one of the few independent NVAs that can serve as a GWLB
  inspection appliance

The reason the list is short is that **GENEVE decapsulation is non-trivial**.
A GWLB appliance is not just "a firewall on a subnet" — it has to speak the GWLB
data plane: terminate the GENEVE tunnel, preserve the inner packet's true source
and destination, keep both directions of every flow pinned together, source-NAT
allowed egress, and re-encapsulate the return path. Most firewalls expect to be
routed *through* on plain IP, not handed GENEVE-wrapped packets to unwrap. That
engineering — a correct GENEVE tunnel datapath beside the policy engine — is what
separates a GWLB-capable NVA from one that simply runs in a VPC. It is why most
teams reaching for GWLB inspection default to the mega-NGFW vendors, and why a
flat-priced NVA that can do the same job is worth knowing about.

## How to use a third-party NVA with GWLB

If you want to put a **third-party NVA behind GWLB** rather than a cloud-native
service, the deployment shape is the same regardless of which appliance you
choose:

1. **Appliance VPC.** Stand up a dedicated inspection VPC with an internet
   gateway, and run your NVA fleet there — one appliance per Availability Zone is
   the common starting point.
2. **GWLB + target group.** Create a Gateway Load Balancer in the appliance VPC
   and register the appliances in its GENEVE target group, with health checks.
   Expose it through a VPC endpoint service, and decide cross-zone on or off
   (off, for AZ affinity, is the usual choice).
3. **GWLBe + route steering in the spoke.** In each spoke (workload) VPC, create
   a GWLB endpoint (GWLBe) and point the workload subnet's default route
   (`0.0.0.0/0`) at the AZ-local GWLBe. That single route change inserts the
   inspection fleet into the path — no workload re-addressing, no proxy.

The appliances must of course terminate GENEVE (see the previous section), and
the EC2 source/destination check must be **disabled** on each appliance so it can
forward transit traffic that is not addressed to itself.

For Enforza specifically, this is shipped as ready-to-run **Terraform** — a
GWLB scenario that builds the appliance VPC, the GWLB and target group, the
spoke VPC with per-AZ GWLBe endpoints and route steering, and the engines
themselves. CloudFormation is not provided for this scenario yet; the datapath
runs on a Debian 12 / Ubuntu 22.04+ base. You point the Terraform at a fleet
deployment key, apply, and enable the GWLB connector on each engine in the
console.

## Enforza as a GWLB inspection appliance

Enforza is one of the few independent NVAs that runs as a **transparent GENEVE
inspection appliance behind AWS GWLB**. Behind the GWLB, an Enforza engine
decapsulates GENEVE, applies the same L3/L4/L7 policy it enforces anywhere —
egress, ingress and east-west control, FQDN/SNI-based L7 filtering without
breaking TLS, secure NAT — source-NATs allowed egress via the appliance VPC's
internet gateway, and returns replies through the tunnel. Multi-AZ with cross-zone
off gives you per-AZ affinity and an AZ-isolated blast radius, and you scale by
adding engines to the target group.

You get the inspection capability of a GWLB-grade NVA without a mega-NGFW
licence. See the [GWLB inspection appliance](/gwlb-inspection/) page for the
deployment detail and the cost wedge.

## Cost vs the incumbents

GWLB inspection cost is really the cost of the *appliance* you put behind the
GWLB, because AWS charges for the GWLB and GWLBe separately and identically no
matter whose appliance you run. The appliance is where the bills diverge:

- **AWS Network Firewall** as the inspection layer bills **per-AZ
  endpoint-hours plus a per-GB data-processing charge** — $0.395/hr for the
  primary Availability Zone, $0.158/hr for each additional AZ (so a 2-AZ pair
  is about $404/month before a byte), plus $0.065/GB, uncapped. AWS waives the
  NAT Gateway's own fee when it's service-chained behind Network Firewall, so
  this is the whole AWS bill — but the $0.065/GB rate is itself 44% higher
  than the $0.045/GB NAT fee it replaces. Rates are us-east-1, dated
  2026-07-10, directional and subject to change.
- **Mega-NGFW VMs** (Palo Alto VM-Series, FortiGate-VM, CloudGuard) carry
  per-VM licences, often metered by vCPU or instance size, on top of the EC2
  cost — the comprehensive feature set most teams only half use, fully paid for.
- **Enforza** is a **flat per-firewall licence with no per-GB data-processing
  tax**. Your price does not move with traffic, instance size, or the number of
  protected IPs.

Be clear about what Enforza replaces: you **still pay AWS's own GWLB and GWLBe
hourly and data-processing charges** — those are AWS's, not the appliance's, and
they apply to every appliance choice. What the flat Enforza licence replaces is
the **appliance licence and the per-GB inspection tax** that a Network Firewall
or mega-NGFW layer adds on top. At modest egress that typically lands 60–80%
below the cloud-native firewall plus its data-processing charges.

For the worked numbers, see
[AWS Network Firewall alternative](/compare/aws-network-firewall/) and
[the Palo Alto comparison](/compare/palo-alto/), or run your own figures in the
[savings calculator](/savings-calculator/).

## FAQ

<FaqAccordion faqs={faqs} />

## Where to go next

If you are evaluating a GWLB inspection appliance, the
[GWLB inspection appliance](/gwlb-inspection/) page covers the datapath, the
multi-AZ pattern, the Terraform deploy, and the cost wedge in one place. To see
how Enforza deploys more broadly, read [how it works](/how-it-works/), or
compare egress paths on the [secure NAT gateway](/secure-nat-gateway/) page.

<a href={SIGNUP_URL}>Start free</a> — one firewall, no card — or estimate the
saving in the [savings calculator](/savings-calculator/).

<Fragment set:html={`<script type="application/ld+json">${JSON.stringify(faqJsonLd)}<\/script>`} />

---

## Azure Service Tags vs AWS IP Ranges for cloud network security

> How Azure Service Tags and AWS IP Ranges work, how they differ, and how to manage both from one place when you build firewall and NAT policy across clouds.

Category: Cloud networking  ·  Published: 2025-10-08  ·  Updated: 2026-06-15  ·  https://enforza.io/articles/azure-service-tags-aws-ip-ranges/

When you secure cloud infrastructure, you have to write precise firewall rules
for the cloud services your workloads talk to. Both Microsoft Azure and Amazon
Web Services publish a way to identify their service IP addresses: Azure
Service Tags and AWS IP Ranges. Understanding both is the difference between
network policy that stays correct on its own and policy that quietly drifts out
of date.

## What are Azure Service Tags?

An Azure Service Tag is a named group of IP address prefixes for a given Azure
service. Microsoft maintains the abstraction so you can reference a logical name
instead of tracking hundreds of individual prefixes by hand. Point a rule at the
tag and it always resolves to the current set of ranges for that service.

Service Tags cover a wide range of services, including:

- **AzureCloud** — all Azure datacentre IP addresses
- **Storage** — Azure Storage service IP addresses
- **Sql** — Azure SQL Database IP addresses
- **AzureKeyVault** — Azure Key Vault IP addresses
- **EventHub** — Azure Event Hubs IP addresses
- **ServiceBus** — Azure Service Bus IP addresses

Many tags are region-specific, which gives you granular control. For example,
`Storage.WestUS` contains only the storage service ranges in the West US region.

## What are AWS IP Ranges?

AWS takes a different approach. Rather than named tags, AWS publishes a single
JSON document listing every IP range it uses across all regions and services,
with metadata describing each one. You consume the document and filter it down
to the ranges you care about.

The AWS IP Ranges document includes:

- **Service identifiers** — EC2, S3, CloudFront, Route 53, and so on
- **Region information** — us-east-1, eu-west-1, ap-southeast-2, and so on
- **Network border groups** — a subset of regions for specific services
- **Create date and sync token** — for tracking updates

The metadata lets you build very specific filters — for example, allow only S3
traffic from us-east-1 while leaving other services and regions out.

## How they're used

### Azure Service Tags

Service Tags are used in Network Security Groups (NSGs), Azure Firewall rules,
and route tables. You write a rule that references the tag instead of a list of
addresses:

```text
Source:      Any
Destination: Storage.WestEurope
Port:        443
Protocol:    TCP
Action:      Allow
```

That rule automatically covers every Azure Storage range in West Europe, with no
list to maintain. Service Tags also work in user-defined routes (UDRs) and
virtual network service endpoints.

### AWS IP Ranges

AWS IP Ranges take more work to consume but give you more flexibility. Most
teams download the JSON, extract the ranges they need, and feed them into:

- Security Group rules
- Network ACL entries
- Route table entries
- Third-party firewall configurations
- Load balancer configurations

## Why teams use them

### Simpler management

Both systems remove the need to manually track and update IP addresses as cloud
providers grow their footprint. Providers add ranges continuously, so hand-kept
lists are obsolete almost as soon as they're written.

### Stronger security

Building on the official ranges keeps your rules current and complete. That
reduces both the connectivity breakage and the security gaps that come from
stale address lists.

### Operational efficiency

Tags and ranges cut configuration complexity, reduce human error, and speed up
rollout of consistent policy across environments.

## Where IP-range rules beat FQDN rules

IP-range filtering and hostname (FQDN) filtering solve different problems, and
the right answer is usually "both". For traffic to a cloud provider's own
services, IP ranges have real advantages:

- **No DNS dependency.** IP-based rules filter at the network layer with no DNS
  lookup in the path, so there's no resolver latency or availability to depend
  on.
- **Smaller attack surface.** Filtering below the application layer sidesteps
  DNS hijacking and cache-poisoning tricks aimed at hostname rules.
- **Broad device support.** Almost every firewall handles IP filtering
  efficiently; rich FQDN filtering is less universal.
- **Consistent behaviour.** IP ranges behave the same regardless of resolver
  configuration or caching.

For general internet egress to arbitrary SaaS endpoints, hostname
(SNI/FQDN) filtering is still the right tool — you want both in the
box.

## Key differences between the two approaches

### Format and structure

Service Tags use human-readable names that hide the underlying complexity. AWS
publishes raw range data that you process yourself. Azure is friendlier for
straightforward cases; AWS gives you more room for complex filtering.

### Granularity

AWS IP Ranges carry more metadata — network border groups and per-service
breakdowns. Service Tags offer broader categories with regional variants but
less service-level detail.

### Update mechanism

Service Tags update automatically inside the Azure platform — nothing to do on
your side. AWS expects you to re-download and re-process the JSON periodically to
stay current.

### Integration

Service Tags integrate natively with Azure networking through a name reference.
AWS IP Ranges need automation to extract and apply the right addresses to your
configuration.

## Access methods and update frequency

### Azure Service Tags

- **Azure Portal** — browse tags while building NSG rules
- **REST API** — programmatic access via Azure Resource Manager
- **PowerShell / CLI** — command-line automation
- **JSON downloads** — weekly files for offline processing

Microsoft updates tags automatically inside Azure and publishes the downloadable
JSON weekly, typically on Mondays.

### AWS IP Ranges

- **Direct download** — `https://ip-ranges.amazonaws.com/ip-ranges.json`
- **SNS notifications** — subscribe to update events
- **API integration** — automated download and processing
- **Third-party tooling** — community and commercial processors

AWS updates the document as needed — usually weekly, sometimes more often during
rapid expansion. The sync token and create date let you confirm you're on the
latest data.

## Best practices

### Automate ingestion

Consume the ranges through automation — Azure's native integration or an AWS
processing pipeline — so policy stays effective as the underlying
infrastructure changes.

### Test before production

Validate range-based rules in a non-production environment first. It surfaces
connectivity issues before they reach live workloads.

### Monitor for change

Watch for range updates that could affect existing connections — particularly on
the AWS side, where manual processing can introduce lag between an update and its
rollout.

## The cost catch with cloud-native firewalls

Service Tags and AWS IP Ranges integrate cleanly with the cloud-native
firewalls — Azure Firewall, AWS Network Firewall — but those services price on a
model that punishes traffic:

- **Azure Firewall** — an hourly deployment charge plus a per-GB
  data-processing charge on everything it inspects.
- **AWS Network Firewall** — a per-endpoint hourly charge plus a per-GB
  data-processing charge, and the per-AZ endpoint model multiplies that across
  availability zones.

The base charge is predictable. The per-GB data-processing tax is the line that
grows with every workload you put behind it, and it's the same whether the
firewall did anything useful with the packet or not.

## Managing both from one place with Enforza

Enforza's object manager imports **both** Azure Service Tags and AWS IP Ranges,
so you build cross-cloud network objects from the providers' own published data
in one console — no separate tooling, no hand-processing JSON.

### How it works

Enforza synchronises with Microsoft's weekly Service Tag publications and AWS's
IP Ranges document, and resolves a tag or range to its actual prefixes when you
reference it in a policy. Your rules stay current without manual intervention.

### Why it matters

- **Cut the cloud-firewall bill 60–80%.** Flat per-firewall licensing with no
  per-GB data-processing tax, instead of the metered model the cloud-native
  services use.
- **One place for cross-cloud objects.** Service Tags and IP Ranges side by
  side, applied consistently across AWS, Azure, and GCP.
- **Automatic updates.** Stay aligned with provider IP changes without manual
  re-import.
- **The control you actually need.** Egress, ingress, and east-west filtering,
  hostname (SNI/FQDN) rules, secure NAT, and compliance — the
  vast majority of core use cases most teams need, without the bloat (or invoice) of a six-figure platform.

Enforza is the way to replace your cloud-native firewall without going
full-blown enterprise security vendor: more capability than the CSP firewall,
far less cost than a mega-NGFW platform.

## Conclusion

Azure Service Tags and AWS IP Ranges both exist to keep network policy correct
as cloud infrastructure shifts under it. Azure favours ease of use and automatic
updates; AWS favours detailed, flexible control. Whichever clouds you run,
moving off hand-kept IP lists and onto the providers' official, automated
sources is a basic step toward mature cloud security — and consuming both from a
single firewall, on flat pricing, is how you do it without the cloud tax.

---

## Azure default outbound access retirement: what changed, who's affected, and how to migrate

> Azure's retirement of default outbound access is now live: new virtual networks get private subnets by default. Who is affected, the symptoms when a new VM has no internet, how to migrate legacy VNets — and why a plain NAT gateway leaves the pipe unfiltered.

Category: Azure  ·  Published: 2025-06-20  ·  Updated: 2026-07-11  ·  https://enforza.io/articles/azure-network-changes-october-2025/

Azure has retired **default outbound access** for virtual machines — the
implicit outbound connectivity that gave a VM a Microsoft-owned public IP it
never asked for. The change is no longer an announcement to prepare for: it is
live. New virtual networks now default to **private subnets**, and a VM in a
private subnet cannot reach the internet until you add an **explicit outbound
method**. Existing virtual networks are unaffected — which makes them the
legacy estate you should now be migrating deliberately.

This guide covers what actually happened and when, exactly who is and isn't
affected, the symptoms when a new VM has no internet access, how to migrate
existing VNets off default outbound, and how the replacement options compare —
including the one thing most migration guides skip: security.

## What actually happened, and when

The timeline matters because most of what ranks for this topic was written
before the change landed:

- **September 2023** — Microsoft announces "Default outbound access for VMs in
  Azure will be retired", initially dated **30 September 2025**.
- **The retirement is postponed** and re-mechanised: instead of a hard cut-off,
  it ships through Azure's API versioning. Virtual networks created with API
  versions released **after 31 March 2026** default to private subnets.
- **1 April 2026** — the Azure portal starts creating new subnets as private by
  default.
- **API version 2025-07-01** — the first affected resource API version. VNets
  created with it (or newer) set the subnet property
  `defaultOutboundAccess: false` by default.

So as of today: create a virtual network in the portal, or with a current API
version in your pipeline, and its subnets are **private by default**. A VM
deployed there with no explicit outbound configuration cannot reach public
endpoints — no package mirrors, no activation, no updates.

One nuance worth knowing: templates and tools pinned to **older API versions**
still leave `defaultOutboundAccess` unset, which implicitly allows outbound
access. That is an escape hatch for an unprepared deployment — not a strategy.
Treat default outbound as gone for anything you build now.

## Who is affected — and who isn't

The single biggest point of confusion, judging by what people ask Microsoft
Q&A, is whether existing workloads break. They don't:

- **Existing virtual networks: unchanged.** Existing VMs — and *new* VMs
  deployed into existing VNets — continue to receive default outbound access
  unless you make the subnets private yourself. Nothing stops working. These
  are your legacy-to-be-migrated networks, not an outage.
- **New VNets (portal since 1 April 2026, or API 2025-07-01+): private subnets
  by default.** New VMs there have no internet until an explicit outbound
  method exists.
- **Virtual Machine Scale Sets in Flexible orchestration:** never had default
  outbound access — they have been "secure by default" all along.
- **AKS:** cluster egress was already explicit (`outboundType` of load
  balancer, NAT gateway or user-defined routing), so supported configurations
  need no action. From 31 March 2026 AKS no longer supports default outbound
  access for new managed-VNet clusters.
- **PaaS services on delegated or managed subnets:** not applicable — the
  service manages its own outbound connectivity.
- **Known issue:** load-balancer backend pools configured **by IP address**
  still use default outbound access.

### "Action recommended: transition to a new method of internet access"

If you received that email or portal notification from Microsoft and are
wondering whether your estate is about to break: it isn't. The notification
flags subnets where VMs still rely on default outbound access (surfaced by the
NIC-level `defaultOutboundConnectivityEnabled` flag and Azure Advisor's "Add
explicit outbound method to disable default outbound" recommendation). It is a
migration prompt for existing networks, not a breakage warning — but it is a
prompt worth acting on, because Microsoft owns those implicit IPs, can change
them without notice, and has retired the model for everything new.

## New VM has no internet access? The symptoms

If a freshly deployed VM can't reach the internet in 2026, suspect a private
subnet before you suspect NSGs. The tell-tale symptoms:

- **Windows activation fails** — commonly error `0xC004F074` — because the VM
  cannot reach the KMS endpoint (`azkms.core.windows.net:1688`). Windows Update
  fails the same way. Microsoft documents both as services that don't function
  in a private subnet without explicit egress.
- **Package installs and outbound API calls time out** on Linux VMs that
  worked identically in an older VNet.
- **Routes to Azure Service Tags with next hop `Internet` stop providing
  access.** The classic pattern of steering service-bound traffic around a
  firewall with a UDR no longer supplies outbound connectivity on its own in a
  private subnet.
- **A pipeline-created VNet behaves differently from last month's** — check
  whether the template's API version crossed 2025-07-01.

Two operational notes: same-region Azure Storage remains reachable from a
private subnet even without explicit egress (worth an NSG if that surprises
you), and switching an existing subnet to private only takes full effect after
its VMs are **stopped and deallocated**.

## Your options for explicit outbound

Microsoft lists four sanctioned methods. In its order:

### 1. Azure NAT Gateway

Centralises outbound connectivity for a subnet behind one public IP — and it is
Microsoft's recommended default, with the newer zone-redundant StandardV2 SKU
positioned for the job.

**Roughly:** a fixed hourly charge per gateway, plus a per-GB data-processing
charge.

**Good for:** keeping VMs private behind a single egress point, and avoiding
the SNAT port exhaustion that dogs load-balancer outbound rules.

**Watch out for:** it provides connectivity only — no inspection, no
firewalling, no hostname filtering — and it's Azure-only.

### 2. Standard load balancer with outbound rules

Outbound translation tied to a load-balancer front end.

**Good for:** estates that already front workloads with a Standard load
balancer.

**Watch out for:** SNAT port allocation is finite and shared; port exhaustion
under connection-heavy workloads is a well-worn failure mode, and there is
still no filtering.

### 3. Standard public IP on the NIC

Direct egress for an individual VM.

**Roughly:** a small fixed monthly charge per static IP, plus per-GB outbound
data transfer.

**Good for:** simple, direct connectivity on small workloads.

**Watch out for:** it exposes VMs directly unless you wrap them in Network
Security Groups, there's no central management across many VMs, and there's no
traffic inspection or filtering.

### 4. A firewall or network virtual appliance via a user-defined route

Microsoft's fourth listed method: route the subnet to an NVA with a UDR. This
is where inspected egress lives — either Azure Firewall or a third-party
appliance.

**Azure Firewall, roughly:** a fixed hourly deployment charge that adds up to a
substantial monthly base, plus a per-GB data-processing charge on inspected
traffic. Full L3/L4 control, FQDN filtering and threat intelligence — at
platform prices, on Azure only.

**Enforza** runs as exactly this method — an NVA reached via a user-defined
route — and combines the NAT and the firewall in one appliance at a flat
per-firewall price:

- NAT for outbound connectivity
- L3/L4 firewalling for traffic control
- Hostname (SNI/FQDN) filtering for granular domain control
- Full traffic visibility and live log streaming to your own SIEM
- One console across the fleet, or policy-as-code through a GitOps pipeline
- The same firewall whichever cloud you run it on

## The part most migration guides skip: the pipe is still unfiltered

Microsoft's stated rationale for the retirement is security — implicit
internet access contradicts Zero Trust principles, and explicit connectivity
beats silent defaults. We agree; it's the right change.

But look at what the standard migration does: it replaces an implicit
unfiltered pipe with an explicit unfiltered pipe. A plain NAT gateway inspects
nothing, filters nothing and logs no destinations. If a workload is
compromised, it exfiltrates through your shiny new explicit egress exactly as
it would have through the old implicit one — you've made the source IP static,
and that's all.

The migration itself is the cheapest moment you will ever get to fix that,
because you are already touching the route tables. Routing the subnet through
a [secure NAT gateway](/secure-nat-gateway/) — a NAT gateway with L3/L4 and
FQDN filtering in one — gives you the explicit outbound method Microsoft
requires *and* control over what leaves the network, in the same change
window. Allow egress to your package mirrors and APIs by hostname; deny and
log everything else.

## Migrating legacy VNets deliberately

For the estate that predates the change — still working, still on default
outbound — a sensible migration plan looks like:

1. **Find the exposure.** Azure Advisor flags VMs relying on default outbound
   ("Add explicit outbound method to disable default outbound"), and the
   NIC-level `defaultOutboundConnectivityEnabled` flag shows it per interface.
2. **Choose the explicit method per subnet** — connectivity-only (NAT gateway)
   or inspected (NVA via UDR). Decide the security question now, not after the
   second migration.
3. **Make the subnet private as you cut over**, so the implicit path is
   actually closed rather than lingering behind your new route:
   - Portal: subnet → "Default outbound access" → Disabled
   - CLI: `az network vnet subnet update ... --default-outbound false`
   - ARM/Bicep: `defaultOutboundAccess: false` on the subnet
   - Terraform: `default_outbound_access_enabled = false` — noting the
     provider currently plans this as a subnet **replacement** even though the
     underlying API updates in place, so review the plan carefully.
4. **Stop and deallocate VMs** for the subnet privacy change to take effect,
   and schedule accordingly.
5. **Re-test the awkward cases**: Windows activation and updates, service-tag
   UDRs with next hop `Internet`, and anything that hard-codes an outbound IP
   — the default outbound IP was never yours and never stable anyway.

## Where the cost goes

The pattern across the cloud-native options is the same: a predictable base
charge plus a **per-GB data-processing tax** that grows with every workload you
put behind it. A dedicated public IP is the cheapest line item but gives you no
security. NAT Gateway is moderate but inspects nothing. Azure Firewall gives you
inspection but carries both a high base and the per-GB tax.

| Capability | Standard public IP | Azure NAT Gateway | Azure Firewall | Enforza |
|---|---|---|---|---|
| Outbound connectivity | Yes | Yes | Yes | Yes |
| NAT included | No | Yes | Yes | Yes |
| L3/L4 firewalling | No | No | Yes | Yes |
| Hostname (FQDN) filtering | No | No | Yes | Yes |
| Traffic inspection & logging | No | No | Yes | Yes |
| Flat pricing (no per-GB tax) | Per-GB transfer | Per-GB processing | Per-GB processing | Yes |

Enforza's flat per-firewall model breaks the link between traffic volume and
cost: the licence is the same whether you process a hundred gigabytes or a
hundred terabytes. For egress-heavy workloads, that's where the 60–80% saving
against the cloud-native firewall comes from.

## Common questions

### Has Microsoft retired default outbound access, or was it postponed?

Both, in sequence. The original 30 September 2025 date was postponed, and the
retirement then shipped through API versioning: virtual networks created with
API versions released after 31 March 2026 (the first is 2025-07-01) — and
anything created in the portal since 1 April 2026 — default to private
subnets. For new deployments, the retirement has happened.

### Will this affect VMs created before 31 March 2026?

No. Existing virtual networks are unchanged, and even new VMs deployed into
existing VNets keep default outbound access until you make those subnets
private. The pressure on existing estates is migration hygiene, not breakage.

### Does the retirement affect AKS?

Supported AKS configurations already use an explicit `outboundType` (load
balancer, NAT gateway or user-defined routing), so they need no action. New
AKS-managed VNets follow the private-by-default model from 31 March 2026.

### Can I just keep using an old API version?

For a while — older API versions still create subnets with implicit outbound
allowed. But you'd be building new networks on a model Microsoft has retired,
with an outbound IP Microsoft owns and can change without notice. Use the
escape hatch to schedule a proper migration, not to avoid one.

## Conclusion

The retirement of default outbound access is done deal for anything new, and a
migration queue for everything old. Whether you land on a NAT gateway, a load
balancer, the cloud-native firewall or an NVA, you now choose your egress path
on purpose — and since you're choosing anyway, it's worth choosing one that can
say no. If you want inspected, filtered egress without the per-GB tax, a
[secure NAT gateway](/secure-nat-gateway/) at a flat per-firewall price is the
lever.

---

## Egress FQDN Filtering in the Cloud

> How egress FQDN filtering differs from URL category filtering, when to use each, and why hostname rules are the right control for cloud workloads.

Category: FQDN filtering  ·  Published: 2025-06-20  ·  https://enforza.io/articles/egress-fqdn-filtering-in-the-cloud/

Two filtering approaches get conflated in cloud security: egress FQDN filtering
and URL category-based filtering. They solve different problems for different
environments. For cloud workloads with predictable destinations, FQDN filtering
is almost always the right tool — here is why.

## Nature of the control

### Egress FQDN filtering

FQDN filtering controls outbound traffic by specific hostname. It fits
environments where workloads talk to well-defined destinations. A payments
service on AWS might need to reach only `api.paymentsgateway.com` and
`analytics.financedata.com`; you allow exactly those and deny everything else,
sharply reducing the risk of exfiltration or accidental connections to unknown
endpoints.

It is the natural fit for API integrations. An application on Azure that should
only ever talk to Salesforce and Microsoft Dynamics 365 can be pinned to those
hostnames, so a misconfiguration or a compromise cannot quietly reach somewhere
else.

### URL category-based filtering

URL category filtering groups domains into buckets — "Social Media", "Gaming",
"Streaming", "Malware" — and applies allow/deny rules to whole categories. It
suits general web browsing, where the set of destinations is large and
unpredictable. A corporate network might block "Streaming Media" to preserve
bandwidth, or "Adult Content" and "Phishing" for policy and safety, without
maintaining a per-domain list.

## Use-case scenarios

**FQDN filtering for cloud services.** A logistics platform on Google Cloud that
must reach only its shipment-tracking API and an analytics service can allow just
`trackingapi.logistics.com` and `data.analyticsplatform.com`. DevOps teams use
the same approach to pin Kubernetes clusters to approved image registries and
external APIs, which also helps with compliance and audit.

**URL category filtering for end-user computing.** On shared workstations or
virtual desktops, category filtering manages user behaviour — blocking
"Gambling" or "Adult Content" for policy compliance — without IT maintaining a
detailed allowlist for thousands of users.

## Precision vs. flexibility

FQDN filtering is precise: allow a short list of known hostnames and everything
else is denied by default. That tight posture is exactly what cloud workloads
want, because their legitimate destinations are knowable in advance.

URL category filtering trades precision for flexibility. Blocking a whole
category covers a broad, shifting set of sites in one rule — ideal when you are
governing diverse human browsing, weaker when you need to guarantee a workload
only ever reaches three endpoints.

## Which fits where

| | Egress FQDN filtering | URL category filtering |
| --- | --- | --- |
| **Best for** | Cloud workloads, APIs, microservices | End-user browsing, VDI |
| **Destinations** | Known, predictable | Broad, unpredictable |
| **Precision** | High — explicit allowlist | Lower — whole categories |
| **Maintenance** | Small, specific rule set | Category subscriptions |

## Doing it without breaking TLS

The hard part of cloud FQDN filtering is enforcing it without sitting in the
middle of every encrypted connection. Enforza filters on the hostname presented
during connection setup, so it can allow or deny by FQDN without terminating or
decrypting the session. You get precise egress control without the latency, cost,
and operational weight of full TLS interception — and it runs on **flat
per-firewall pricing with no per-GB data-processing fee**.

See the [features](/features/) page for the egress and object-manager
capabilities, or [Traffic Flows in the Cloud](/articles/flows-in-the-cloud/) for
where egress fits among the other flows.

## Conclusion

For cloud-native applications and services, egress FQDN filtering provides the
precision and predictability you want — pin workloads to the hostnames they
legitimately need and deny the rest. For governing broad human web browsing, URL
category filtering is the more flexible tool. Match the approach to the
environment, and for cloud workloads that almost always means FQDN.

---

## Understand Cloud Firewalls & Your Options

> The four ways to firewall a cloud network — FWaaS, native cloud firewalls, third-party NVAs, and open source — with the trade-offs and where each fits.

Category: Firewalls  ·  Published: 2025-06-20  ·  https://enforza.io/articles/cloud-firewalls-your-options/

A cloud firewall filters and monitors the traffic in and out of your cloud
infrastructure. Unlike a hardware appliance on a rack, it is delivered as
software inside virtualised environments, which lets you apply controls directly
in the cloud and scale them as you grow. There are four broad ways to do it, and
they differ sharply on cost, control, and operational weight. Here is how to tell
them apart.

## What a cloud firewall is for

The job is the same as any firewall: inspect traffic, enforce policy, and contain
threats. What changes in the cloud is that the firewall has to keep up with
dynamic, software-defined, often multi-cloud environments where the old fixed
perimeter no longer exists. The good options share three traits:

- Real-time traffic analysis and threat detection.
- Scalability that tracks the infrastructure it protects.
- Integration with the cloud platforms you actually run on.

## Option 1: Firewall as a Service (FWaaS)

FWaaS delivers firewall functionality as a cloud-hosted service rather than
something you deploy and run yourself. It abstracts away the appliance and gives
you consistent policy across locations from a central dashboard — attractive for
distributed teams.

**Strengths:** scales automatically with traffic; reachable from anywhere with
consistent policy.

**Trade-offs:** routing traffic through a provider's points of presence can add
latency, and integrating with existing on-premises systems takes planning.

## Option 2: Native cloud firewalls

These are the firewalls built into the cloud platforms — AWS Network Firewall and
Security Groups, Azure Firewall, Google Cloud NGFW. They are tightly integrated
with their provider and quick to stand up inside a single platform.

**Strengths:** seamless integration with the rest of the provider's services and
automated configuration.

**Trade-offs:** two real ones.

- **Vendor lock-in.** Each is single-cloud. Run more than one provider and you
  operate a different firewall — different concepts, console, and bill — in each.
- **The metered bill.** Pricing is usage-based: a base charge plus a **per-GB
  data-processing fee** on inspected traffic, often multiplied per availability
  zone. It looks cheap at low volume and scales into a large, unpredictable line
  as your workloads grow. This cost wedge is covered in
  [The Problem with Cloud-Native Firewalls](/articles/problem-with-cloud-firewalls/).

## Option 3: Third-party network virtual appliances (NVAs)

NVAs are virtualised versions of the big cybersecurity vendors' firewalls —
Fortinet, Palo Alto Networks, Check Point. They bring next-gen firewall depth to
the cloud: deep packet inspection, VPN, intrusion prevention, advanced threat
protection, and a consistent platform across cloud and on-premises.

**Strengths:** comprehensive feature set; one platform and policy model
everywhere. On AWS they are among the few appliances that can run behind a
Gateway Load Balancer for transparent inspection — though a flat-priced NVA can
do the same job; see
[how AWS Gateway Load Balancer inspection works](/articles/aws-gateway-load-balancer-firewall/).

**Trade-offs:**

- **Cost.** Licensing, support contracts, and instance metering by vCPU or
  instance size add up to a significant — often six-figure — investment.
- **Complexity, and features you never switch on.** These platforms carry
  hundreds of capabilities. Most organisations use a fraction of them and pay for
  all of them — half used, fully paid for.

## Option 4: Open-source firewalls

pfSense, OPNsense, and similar projects are community-built, highly customisable,
and free to acquire. They appeal to teams that want full control and no licensing.

**Strengths:** no licence cost; full access to configuration; no vendor lock-in.

**Trade-offs:**

- **Steep learning curve.** They demand real networking expertise to deploy and
  run well.
- **Limited support.** Community forums, not a vendor SLA, when something breaks
  in production.
- **Management plane to defend.** A self-managed box needs a reachable admin
  interface to administer it — that is attack surface on the security device
  itself, and one more thing to keep patched and locked down.

See the worked comparisons for [pfSense](/compare/pfsense/) and
[OPNsense](/compare/opnsense/).

## Matching the option to the need

The expensive mistake is over-buying. Organisations routinely pay for advanced
threat and forensic capabilities aimed at nation-state adversaries when their
actual need is solid egress, ingress and east-west control with FQDN filtering
and segmentation. Three questions cut through it:

- **Scalability:** does it scale with your infrastructure, or will you outgrow it?
- **Operability:** does your team have the expertise the option demands, or do you
  need something simpler to run?
- **Total cost:** what is the real bill once you include data-processing fees,
  per-AZ multipliers, licensing, and the features you will never use?

## Where Enforza fits: the sweet spot

Enforza is built for exactly the gap these four options leave. It is the way to
**replace your cloud-native firewall without going full-blown enterprise security
vendor**:

- **More than the native firewall, far less cost.** The same egress, ingress and
  east-west control — plus hostname (SNI/FQDN) filtering, secure
  NAT, threat hardening, and compliance — on **flat per-firewall pricing with no
  per-GB data-processing tax**, typically 60–80% less than the cloud-native
  firewall plus its data charges.
- **Right-scoped, not bloated.** The core capability most teams actually use,
  without the cost and complexity of a mega-NGFW platform you will half-fill.
- **One console across clouds.** Consistent policy on AWS, Azure and GCP, instead
  of a different service per provider.
- **No exposed management plane.** The firewall manages outbound to the Enforza
  cloud — there is no inbound admin port to expose, unlike a self-managed box.
- **FQDN/SNI-based without breaking TLS.** Hostname filtering that allows or
  denies by FQDN without terminating encryption, so you get precision without the
  cost and latency of full interception.

## Conclusion

Choosing a cloud firewall is a decision about cost, control, and operational
weight as much as security. FWaaS, native firewalls, NVAs, and open source each
fit a particular shape of need. For teams that want serious control over cloud
traffic without the cloud-native metered bill or the mega-NGFW's sprawl, Enforza
is the deliberate middle ground. Compare the numbers on the [pricing](/pricing/)
page.

---

## How NAT Gateways Work

> How NAT gateways translate private addresses to public ones, why RFC 1918 ranges need translation, port-mapping limits, and what the gateway costs you.

Category: NAT gateways  ·  Published: 2025-06-20  ·  https://enforza.io/articles/how-nat-gateways-work/

A NAT gateway is the component that lets resources in a private subnet reach the
internet without being reachable from it. It does that by translating private IP
addresses to public ones on the way out, and back again on the way in.
Understanding the mechanics makes the [cost model](/articles/cloud-nat-costs/)
and its alternatives far easier to reason about.

## Why translation is needed at all

Private subnets use addresses from the ranges reserved by RFC 1918, the IETF
standard for internal networking. There are three:

- **10.0.0.0/8** — suited to large networks
- **172.16.0.0/12** — common in medium-sized networks
- **192.168.0.0/16** — popular for home and small-business networks

These addresses cannot route on the public internet. A packet with a 10.x.x.x
source has nowhere to go once it leaves your network — so something has to swap
that source for a routable public address. That something is the NAT gateway.

## The translation process

NAT gateways perform Source Network Address Translation (SNAT):

1. A private resource initiates an outbound request.
2. The gateway replaces the private source IP with its own public IP.
3. It assigns a unique source port so multiple connections can share one public
   address.
4. The request reaches the destination server, which sees only the public IP.
5. The response comes back to the gateway, which maps it to the original private
   address and forwards it on.

The destination never sees — and cannot initiate a connection to — the private
resource. That one-way property is what makes NAT a security control as well as
a connectivity one.

## Port-mapping capacity

Each public IP supports up to roughly 64,000 unique source ports. Because a port
identifies each tracked connection, a single public IP caps the number of
simultaneous outbound connections it can multiplex. High-traffic environments
that need 100,000+ concurrent connections assign multiple public IPs to spread
the load.

## What it costs

A managed NAT gateway bills on two lines:

- An **hourly usage fee** for running the gateway.
- A **per-GB data-processing charge** on the traffic it handles.

The per-GB charge is the one that scales with your workloads, and it applies to
every byte regardless of whether the gateway did anything other than translate
an address. Managed gateways also cannot simply be toggled off when idle without
deleting and re-provisioning them, so the hourly charge runs whether you are
using the gateway or not.

## Where Enforza fits

Enforza provides the same secure outbound NAT, but as a single firewall instance
on **flat per-firewall pricing** — no per-GB data-processing tax — and it adds
egress, ingress and east-west filtering plus hostname (FQDN)
rules in the same place. See the [secure NAT gateway](/secure-nat-gateway/) page
for how the replacement works, or
[Reducing Cloud NAT Costs](/articles/cloud-nat-costs/) for the full cost
comparison.

---

## Traffic Flows in the Cloud

> The four traffic flows that matter in cloud networks — east-west, ingress, egress, and traffic to service endpoints — and how to control each one.

Category: Cloud networking  ·  Published: 2025-06-20  ·  https://enforza.io/articles/flows-in-the-cloud/

Securing a cloud network starts with knowing how traffic moves through it. Most
flows fall into four categories: east-west (lateral) traffic between workloads,
ingress from outside, egress to the internet and SaaS, and traffic to cloud
service endpoints. Each has a different risk profile and a different set of
controls.

## East-west (lateral) flows

East-west traffic is communication between resources inside the same network or
subnet — virtual machines, containers, and microservices talking to each other.
It never crosses the perimeter, which is exactly why traditional perimeter
security misses it.

### Why east-west control matters

Lateral movement is how a single compromised workload becomes a breach. Once an
attacker is on one host, they pivot toward the valuable targets — databases,
secret stores, identity services. Controlling east-west traffic isolates the
initial foothold and contains the blast radius before it spreads.

### How to control it

Network virtual appliances from vendors like Fortinet and Palo Alto can inspect
lateral traffic, at the cost of complexity and licensing. Enforza offers a
lighter path: centralised policy and FQDN/SNI-based filtering that segments
workloads from each other without the overhead of a full enterprise platform.

## Ingress flows

Ingress is traffic entering the cloud from outside — through firewalls, load
balancers, or public IPs. This north-south traffic needs protection against
denial-of-service, malware, and unauthorised access.

### How to control it

- **Network Security Groups (NSGs):** granular allow/deny at the subnet or VM
  level, filtering on source, protocol, and port.
- **Web Application Firewalls (WAFs):** defence against web attacks such as SQL
  injection and cross-site scripting.
- **A network firewall:** stateful inspection and threat hardening on the
  traffic entering your networks.

## Egress flows

Egress is outbound traffic to the internet, SaaS, and external services.
Monitoring it matters because egress is the path data exfiltration takes —
controlling it both prevents unauthorised transfers and trims bandwidth cost.

### How to control it

- **Firewall rules:** restrict outbound connections by destination IP, domain,
  or protocol.
- **Network ACLs:** stateless subnet-level filters for coarse control.
- **Egress FQDN filtering:** restrict outbound traffic to known, trusted
  hostnames — the most precise option for cloud workloads with predictable
  destinations. See
  [Egress FQDN Filtering in the Cloud](/articles/egress-fqdn-filtering-in-the-cloud/).

## Traffic to service endpoints and SaaS

These flows connect your infrastructure to cloud provider services and
third-party SaaS. Providers offer private paths — AWS PrivateLink, Azure Private
Link / service endpoints — that keep this traffic off the public internet.

### How to manage it

- **Route tables:** direct traffic to the right endpoints.
- **Private link services:** secure connectivity without public exposure.
- **NSGs:** ensure only authorised traffic reaches the endpoint.

For provider services, filtering on the provider's own published IP ranges is
often cleaner than hostname rules — see
[Azure Service Tags vs AWS IP Ranges](/articles/azure-service-tags-aws-ip-ranges/).

## Getting the balance right

Traffic controls prevent unauthorised access and data loss and keep performance
predictable — but overly tight rules break legitimate traffic, and loose ones
leave gaps. The goal is precise, FQDN/SNI-based policy that you can manage in one
place rather than a patchwork of per-flow tools.

## One place for every flow

Enforza handles all four flows — east-west, ingress, egress, and service-endpoint
traffic — from a single console, across AWS, Azure and GCP, with hostname
(SNI/FQDN) rules and secure NAT, on **flat per-firewall pricing with no
per-GB data-processing fee**. It is the control you actually need for cloud
traffic without the cloud-native firewall's metered bill or a mega-NGFW's bloat.
See the [features](/features/) page for the full capability set.

---

## The Problem with Cloud-Native Firewalls and NAT Gateways

> Cloud-native firewalls and NAT gateways meter you per gigabyte and lock you into one provider. Here's the cost wedge and the flat-priced alternative.

Category: Firewalls  ·  Published: 2025-06-20  ·  https://enforza.io/articles/problem-with-cloud-firewalls/

The cloud-native firewalls and NAT gateways — AWS Network Firewall, Azure
Firewall, AWS and Azure NAT gateways — are convenient and well integrated. They
also share two problems that get worse as you grow: the way they bill, and the
fact that you manage a different one in every cloud.

## The cost problem

Every one of these services charges on the same shape: a base charge plus a
**per-GB data-processing fee** on the traffic it handles.

- **AWS Network Firewall** charges per firewall endpoint per hour — multiplied
  per availability zone — plus a per-GB data-processing fee.
- **Azure Firewall** charges an hourly deployment fee plus a per-GB
  data-processing fee.
- **NAT gateways** add their own hourly charge and their own per-GB
  data-processing fee on top.

The base charges are predictable. The per-GB lines are not — they scale directly
with how much your workloads talk, and they apply whether or not the firewall
did anything useful with the packet. This is the wedge: the metered model means
your security bill grows with your business, indefinitely, with no relationship
to the value delivered. For the detail on each, see
[Understanding AWS Network Firewall](/articles/understanding-aws-network-firewall/)
and [Reducing Cloud NAT Costs](/articles/cloud-nat-costs/).

## The operational problem

The cloud-native services are single-cloud by design. Run AWS and Azure and you
operate two separate firewalls, with two different sets of concepts, two
consoles, two rule formats, and two bills. Every cloud you add is another tool
to learn and another place policy can drift out of alignment.

## Enforza's approach

Enforza replaces the cloud-native firewall and NAT gateway with one firewall
instance that delivers the same core capabilities — stateful inspection, traffic
filtering, secure NAT, hostname (SNI/FQDN) rules — and more, while
removing both problems:

| | Cloud-native firewall + NAT | Enforza |
| --- | --- | --- |
| **Base charge** | Hourly, often per-AZ | Flat per firewall |
| **Data-processing fee** | Per GB, scales with traffic | None |
| **Multi-cloud** | One service per cloud | One console across clouds |
| **Operations** | Provider-specific concepts | One consistent model |

- **No per-GB data-processing tax.** Flat per-firewall licensing — typically
  60–80% less than the cloud-native firewall plus its data-processing charges.
- **No instance-size, IP, or device limits.** Run it on any VM size; the price
  does not change with vCPUs, protected IPs, or hosts.
- **One pane of glass across clouds.** Consistent policy and terminology on AWS,
  Azure and GCP, instead of a different service per provider.
- **Comparable capability, lower cost.** You are not trading away security to
  drop the bill — Enforza covers the vast majority of core use cases most teams actually use.

Enforza is the way to replace your cloud-native firewall on cost without going
full-blown enterprise security vendor: more than the CSP service, far less than —
and far cheaper than — a six-figure mega-NGFW platform. Compare the numbers on
the [pricing](/pricing/) page or the
[AWS Network Firewall comparison](/compare/aws-network-firewall/).

---

## Understanding AWS Network Firewall

> How AWS Network Firewall works, its Suricata-based rule engine, the per-endpoint and per-GB pricing model, and where a flat-priced alternative fits.

Category: Firewalls  ·  Published: 2025-06-20  ·  https://enforza.io/articles/understanding-aws-network-firewall/

AWS Network Firewall is Amazon's managed network firewall service. It does
stateful inspection, intrusion detection, and egress control for traffic inside
your AWS networks. It is capable — and its pricing model is the reason a lot of
teams go looking for an alternative. Here is how it works and where the costs
land.

## How it works

AWS Network Firewall is built on **Suricata**, the open-source threat-detection
engine, and accepts Suricata-compatible rules. That gives it deep packet
inspection, intrusion detection, and the ability to write detailed,
signature-style rules for traffic passing through it.

You deploy a firewall endpoint into a dedicated subnet in each availability zone
you want to protect, then steer traffic through it with route tables. Rules are
grouped into rule groups and managed centrally.

## Pricing structure

AWS Network Firewall charges on two mechanisms:

- An **hourly fee per firewall endpoint**.
- A **per-GB data-processing charge** on everything it inspects.

Two things make this add up. First, the per-GB charge scales directly with
traffic — the more your workloads talk, the more you pay, whether or not a rule
ever matched. Second, the endpoint model is **per availability zone**: a
multi-AZ deployment multiplies the hourly endpoint charge across zones. For
environments with significant east-west or egress volume, the data-processing
line dominates the bill.

## What it does well

- **Native AWS integration.** It plugs into CloudFormation, CloudWatch, and
  Security Hub, so monitoring and provisioning sit inside tooling AWS teams
  already use.
- **Automatic scaling.** The managed service scales with traffic without you
  sizing instances.
- **Expressive rules.** Suricata-compatible rules support detailed inspection
  and detection logic.

## Where it gets heavy

- **Cost at volume.** The per-GB data-processing charge plus per-AZ endpoints
  make high-traffic environments expensive.
- **AWS only.** It secures AWS networks. If you run more than one cloud, you
  manage a different service — with different concepts and a different
  bill — everywhere else.
- **Lock-in.** Rules and operational patterns are tied to the AWS service.

## The alternative

A network virtual appliance (NVA) from a vendor like Fortinet or Palo Alto gives
you cloud portability and a deep feature set, but brings complex deployment,
manual scaling, and licensing that most teams only half-use.

Enforza sits deliberately between the two. It delivers the egress, ingress and
east-west control you actually need — hostname (SNI/FQDN)
filtering, secure NAT, threat hardening, compliance — on **flat per-firewall
pricing with no per-GB data-processing tax**, and the same console works across
AWS, Azure and GCP. It is the way to replace the cloud-native firewall on cost
without buying a six-figure mega-NGFW platform you will never fully switch on.

Network Firewall can also run behind an AWS Gateway Load Balancer as the
inspection layer — but you can put a flat-priced third-party NVA there instead.
See [how AWS Gateway Load Balancer inspection works](/articles/aws-gateway-load-balancer-firewall/),
or the Enforza [GWLB inspection appliance](/gwlb-inspection/) page.

See the side-by-side on the
[Enforza vs AWS Network Firewall](/compare/aws-network-firewall/) page, or the
broader [Problem with Cloud-Native Firewalls](/articles/problem-with-cloud-firewalls/).

---

## Reducing Cloud NAT Costs

> Practical ways to cut cloud NAT gateway spend, compare the alternatives, and improve outbound security without the per-GB data-processing tax.

Category: Cost  ·  Published: 2025-06-18  ·  Updated: 2026-06-15  ·  https://enforza.io/articles/cloud-nat-costs/

Managed cloud NAT gateways are convenient, but their pricing model rewards
nobody but the cloud provider. Beyond an hourly charge, you pay a per-GB
data-processing fee on every byte your workloads send out — and that line grows
with every workload you put behind it. Here are practical ways to reduce that
spend, the trade-offs of each alternative, and a flat-priced option that removes
the per-GB tax entirely.

## What a cloud NAT gateway does

A NAT (Network Address Translation) gateway is a managed service that lets
resources in a private subnet reach the internet or external services without
exposing them to inbound traffic. Your virtual machines talk out securely while
staying hidden from the outside. For a deeper walk-through of the mechanics, see
[How NAT Gateways Work](/articles/how-nat-gateways-work/).

## From NAT instances to managed gateways

Before managed gateways, teams ran NAT instances — virtual machines configured
to forward outbound traffic. They worked, but you owned the OS configuration,
the scaling, the patching, and the failure modes. Managed NAT gateways removed
that overhead with provider-run scaling and resilience, which is why they became
the default.

The convenience came with a pricing model that meters traffic.

## The costs: where the money goes

A managed NAT gateway has two cost components:

1. An hourly charge for the gateway itself.
2. A per-GB data-processing charge on everything that passes through it.

The hourly charge is predictable. The per-GB charge is the one that scales with
your business — and it applies whether the traffic was useful or not. For an
environment moving a few terabytes of egress a month, the data-processing line
routinely dwarfs the hourly cost. The exact rates vary by provider and region,
so check current published pricing; the shape of the bill does not change.

This article is the cross-cloud overview. For AWS specifically — the exact
$0.045/hr plus $0.045/GB rates, why they multiply per Availability Zone, VPC
endpoints as a way to skip NAT for AWS-service traffic, and NAT instances and
fck-nat as real alternatives — see
[AWS NAT Gateway: what it actually costs, and the alternatives](/articles/aws-nat-gateway-cost-and-alternatives/).

## Ways to cut NAT spend

**Consolidate traffic.** Route through a central gateway rather than several,
to reduce the hourly component across the environment.

**Cut unnecessary egress.** Examine your traffic and remove redundant outbound
data. Local caching or a CDN for frequently fetched content takes load off the
metered path.

**Right-size workloads.** Over-provisioned instances generate more outbound
traffic than they need to. Scaling efficiently reduces what you pay to process.

**Turn on monitoring.** Logging on the gateway shows you which flows are
expensive, so you can target the worst offenders.

These help at the margins. They do not change the fundamental problem: you are
billed per gigabyte for address translation.

## The alternatives

**NAT instances** still suit some cases — development environments, or workloads
that can tolerate lower resilience:

- They avoid the per-GB data-processing fee, charging only standard egress
  rates.
- They can be shut down during idle periods to save money.
- They give you full control over configuration.

The catch is that you are back to owning Linux networking, scaling, and
availability — the operational overhead managed gateways were created to remove.

## A flat-priced NAT replacement: Enforza

Enforza replaces the cloud NAT gateway with a single firewall instance that does
secure NAT, egress control, and hostname (FQDN) filtering — on
flat per-firewall pricing, with **no per-GB data-processing tax**.

- **Flat licensing.** One predictable per-firewall line instead of a metered
  per-GB bill. Forecast it like buying a box, not like reading a utility meter.
- **More than NAT.** Secure NAT plus egress, ingress and east-west filtering and
  hostname (SNI/FQDN) rules in one place — see the
  [secure NAT gateway](/secure-nat-gateway/) and
  [features](/features/) pages.
- **Runs anywhere.** AWS, Azure, GCP — one console across clouds, no per-cloud
  retraining.
- **No exposed management plane.** The firewall manages outbound to the Enforza
  cloud — there is no inbound admin port to expose, unlike a self-managed NAT
  instance.

Enforza is the way to replace your cloud-native NAT and firewall without taking
on either the per-GB tax of the managed service or the maintenance burden of
rolling your own.

## A note for Azure users

Azure has **retired default outbound internet access** for virtual machines; the
change took effect on **31 March 2026**. New VMs no longer get an implicit
outbound IP, so you now choose an explicit egress path — a NAT gateway, a public
IP, or a firewall instance. That makes the cost of the path you pick a live
decision rather than a default you inherited. The trade-offs are covered in
[Azure default outbound retirement](/articles/azure-network-changes-october-2025/).

## Final thoughts

Cloud NAT gateways buy convenience and charge for it by the gigabyte. You can
trim that bill with consolidation and caching, drop the data-processing fee by
running NAT instances at the cost of operational overhead, or move to a
flat-priced firewall instance that removes the per-GB tax and adds real egress
control. Knowing where your money actually goes — the hourly charge or the
per-GB tax — is the first step to spending less of it.

---

## Product and comparison pages

### Home — https://enforza.io/
Headline: Secure NAT gateway and cloud firewall, up to 80% cheaper than the cloud-native option.
Key points:
- Same egress, ingress and east-west control as the cloud-native firewall, at a flat per-firewall price with no per-GB data-processing tax.
- One Linux VM in your own network, deployed your team's way (GitOps or console).
- Drop-in replacement for the cloud-native firewall, with secure NAT included; minutes to deploy via a low-risk route-table/UDR change.

### Features — https://enforza.io/features/
Headline: FQDN/SNI-based cloud firewall, secure NAT and egress control — without the cloud-native price.
Key points:
- L3/L4/L7 filtering including FQDN/SNI-based egress control without breaking TLS.
- Secure source-NAT gateway, threat hardening, and an object manager with AWS IP-range and Azure Service-Tag imports.
- Single-pass packet classification and verdict engine; compliance gating across 25 frameworks; fleet management; log export to your own SIEM.
- Two equal workflows over one firewall NVA: GitHub Pipeline Integration and the Cloud Controller console.

### Cloud Controller — https://enforza.io/controller/
Headline: The console way to run Enforza.
Key points:
- Fleet view across every firewall, a visual policy editor, push-to-many deployment, and multi-firewall live log streaming in real time.
- A 20-version ring buffer of policy history per firewall; advise-or-enforce compliance on every publish.
- Same firewall NVA and engine as the GitOps workflow — the console is a workflow choice, not a feature tier.

### Secure NAT gateway — https://enforza.io/secure-nat-gateway/
Headline: Secure, filtered outbound for AWS, Azure and Google Cloud — without the data-processing tax.
Key points:
- Replaces a managed NAT gateway with a flat-priced appliance that also filters egress (FQDN/SNI), so outbound is controlled, not just translated.
- Relevant to the Azure default-outbound-access retirement (in effect since 31 March 2026): a deliberate, secure outbound path.

### Egress filtering on DigitalOcean — https://enforza.io/digitalocean-egress-filtering/
Headline: FQDN/SNI-based outbound control and audit-ready egress logs for DigitalOcean droplets.
Key points:
- DigitalOcean Cloud Firewalls are free but L3/L4 only (IP, port, protocol) — no FQDN, no SNI, no L7, no destination-level audit trail. Enforza adds FQDN/SNI-based egress filtering (without breaking TLS), secure NAT and audit-ready outbound logs to your own SIEM, on a droplet in your own DigitalOcean network, with managed lifecycle and 25 compliance frameworks.
- This is a capability/compliance page, not a cost claim: DigitalOcean now has a managed NAT gateway and cheap egress, so there is no cost wedge — the value is domain-aware egress control and audit-grade logs.
- Deploy: registration-key install on a droplet. Honest friction — DigitalOcean VPCs have no custom route tables, so you set the default route on each backend droplet to exit via the Enforza droplet (preserving the metadata-service route), re-applied as droplets are added; and DigitalOcean's anti-spoofing requires the appliance to do secure source NAT, which Enforza does by design.

### Egress firewall on Hetzner Cloud — https://enforza.io/hetzner-cloud-egress-firewall/
Headline: Managed, auditable outbound control for Hetzner Cloud — the SOC 2 CC6.1 evidence a security review asks for.
Key points:
- Hetzner's Cloud Firewall is free but IP/port only (no FQDN, no L7), and Hetzner has no managed NAT (its own answer is a do-it-yourself tutorial). Hetzner data centres carry ISO 27001 but not SOC 2, so controlling and evidencing outbound access falls on the application owner. Enforza adds FQDN/SNI-based egress control, secure NAT and audit-ready outbound logs to your own SIEM, managed and centralised across servers.
- Honest scope: the DIY alternative (free firewall plus a hand-rolled gateway) is genuinely free — Enforza's value is managed lifecycle, centralised policy and audit-ready logs, not a lower price. This is a capability/compliance page, not a cost claim.
- Deploy: registration-key install on a Hetzner Cloud server; the route lives on the network object (a 0.0.0.0/0 route with the Enforza server's private IP as target, not set on the instance) with IP forwarding enabled; Hetzner private networks do not reverse-path-filter, so there is no anti-spoofing toggle to disable.

### How it works — https://enforza.io/how-it-works/
Headline: GitOps or console, one firewall — minutes to deploy on any cloud.
Steps: (1) Install on a Linux VM with a single command; (2) it registers with the Enforza cloud over an outbound connection and pulls its bound policy; (3) point a route at it and it enforces egress, ingress and east-west traffic in minutes.
Key points:
- No inbound management port and no admin UI to expose — the control plane is outbound-only; the firewall manages up, never in.
- Self-upgrade with automatic rollback, runs on any cloud, fail-closed by default with an encrypted local policy cache for control-plane outages.
FAQ:
- Two ways to run? GitHub Pipeline Integration (policy-as-code in a repo, reviewed and merged like any change) or the Cloud Controller console (GUI-driven). Same firewall NVA and billing underneath.
- Need GitHub? No — the console manages policy and the fleet entirely through the GUI, no repository required.
- Where does it run? A single Linux VM in your own AWS/Azure/GCP/on-prem network; log export streams to your own SIEM, never via Enforza's cloud.
- How fast to deploy? Minutes — install, register, route.
- Management port on the firewall? No inbound management port and no admin UI; control plane is outbound-only.
- Multiple clouds? Yes — same instance on any cloud, managed from one console with push-to-many and live multi-firewall log streaming.

### Compliance — https://enforza.io/compliance/
Headline: 25 frameworks, checked on every policy push.
Key points:
- Advise or enforce on every publish across 25 framework packs / 210 firewall-applicable controls (CIS, PCI DSS v4, ISO 27001, NIST 800-53, FedRAMP, DORA, CMMC, HIPAA and more).
- Compliance is evaluated at publish time in both the GitOps and console workflows.

### Pricing — https://enforza.io/pricing/
Headline: Flat per-firewall pricing, no per-GB tax.
Key points:
- One flat per-firewall licence in GBP/USD/EUR; no per-GB, per-rule, per-AZ, per-vCPU or per-instance-size metering; volume price falls as the fleet grows.
- Free tier and trial available. Basic email support included; premium support and hourly consultancy available as paid add-ons.
- Not CPU/instance-size limited, not IP/object limited, not protected-device limited — predictable, like buying a box.

### Savings calculator — https://enforza.io/savings-calculator/
Estimates the saving versus the AWS/Azure/GCP native firewall plus NAT gateway, based on your data volume.

### Deploy from the AWS Marketplace — https://enforza.io/aws-marketplace/
Headline: Deploy Enforza from the AWS Marketplace — bring-your-own-licence, $0 through AWS.
Key points:
- BYOL listing: AWS charges $0 for the Enforza software; you pay AWS only for the EC2 instance the firewall runs on. The Enforza plan, including a free tier, is handled in the console, separate from AWS billing.
- Recommended path is one-click CloudFormation: it disables EC2 source/destination check (mandatory for a forwarding firewall, or EC2 silently drops forwarded traffic), attaches a stable Elastic IP, enables IMDSv2 + instance metadata tags, and uses a least-privilege role (SSM core only). The bare AMI is also supported, but then you must disable source/dest check and enable instance metadata tags yourself.
- No registration key: the firewall self-registers to the Enforza control plane using its AWS-signed EC2 Instance Identity Document, then you claim it in the console by AWS account ID + EC2 instance ID (or pre-set the enforza:claim tag at launch).
- Instance types: any x86_64 (amd64) — ARM/Graviton and Mac are excluded by architecture. Use a non-burstable family (c6i/m6i) in production; burstable T-family (t3) is fine for evaluation but its CPU credits throttle a firewall under sustained load. The image self-patches OS security updates and surfaces a passive "reboot pending" badge in the console — Enforza never reboots your instance.
FAQ:
- What does it cost on the AWS Marketplace? Bring-your-own-licence — $0 for the software through AWS; you pay AWS only for the EC2 instance. Your Enforza plan, including a free tier, is handled in the console.
- Do I need a licence or registration key? No — it self-registers via its AWS-signed EC2 instance identity, then you claim it in the console by AWS account ID + instance ID.
- I launched the bare AMI and nothing is forwarded — why? Almost always EC2 source/destination check is still enabled; the one-click CloudFormation template disables it for you.

### Deploy from the Azure Marketplace — https://enforza.io/azure-marketplace/
Headline: Deploy Enforza from the Azure Marketplace — bring-your-own-licence, free through Azure.
Key points:
- BYOL VM offer ("Enforza Secure NAT Gateway & Firewall (BYOL)", publisher enforza): Azure charges nothing for the Enforza software; you pay Azure only for the VM the firewall runs on. The Enforza plan, including a free tier, is handled in the console, separate from Azure billing.
- Deploy from the Azure portal (Get It Now → Create) or your own ARM/Bicep template, then enable IP forwarding on the firewall's network interface — the one manual switch a forwarding firewall needs, or Azure silently drops forwarded packets. If the firewall is your egress point, associate a static public IP. Route workload subnets to the firewall's private IP with a user-defined route (UDR).
- No registration key: the firewall self-registers to the Enforza control plane using Azure's signed instance metadata (the attested document from the Instance Metadata Service), then you claim it in the console by Azure subscription ID + virtual machine ID (or pre-set the enforza:claim tag at deploy time).
- VM sizes: any x86_64 (amd64) — Arm-based families are excluded by architecture. Use a non-burstable general-purpose or compute-optimised size (Dsv5/Fsv2) in production; B-series burstable VMs are fine for evaluation but their CPU credits throttle a firewall under sustained load. The image self-patches OS security updates and surfaces a passive "reboot pending" badge in the console — Enforza never reboots your VM.
FAQ:
- What does it cost on the Azure Marketplace? Bring-your-own-licence — free for the software through Azure; you pay Azure only for the VM. Your Enforza plan, including a free tier, is handled in the console.
- Do I need a licence or registration key? No — it self-registers via Azure's signed instance metadata, then you claim it in the console by Azure subscription ID + virtual machine ID.
- I deployed the VM and nothing is forwarded — why? Almost always IP forwarding is still disabled on the network interface; enable it and confirm your UDR points at the firewall's private IP.

## Landing zones

### Landing zones hub, https://enforza.io/landing-zones/
Headline: Pre-built cloud landing zones with a flat-priced firewall in the hub.
Key points:
- Ready-to-deploy AWS and Azure reference architectures that put the Enforza firewall and secure NAT in the hub: same egress, ingress and east-west control as the cloud-native firewall, at a flat per-firewall price with no per-GB data-processing tax.
- A "which size are you" chooser routes to four AWS patterns and the Azure patterns. Links out to the cost, compare and capability pages; a "Get the templates" route points at the public repository (github.com/enforza/landing-zones), and deploy CTAs point at the console and the Marketplace listings.

### AWS landing zones, https://enforza.io/landing-zones/aws/
Headline: AWS landing zones, Terraform and CloudFormation, with the firewall in the hub.
Key points:
- Four real, validated patterns as paired-label anchored sections (friendly T-shirt size plus the technical pattern name): Small single gateway (#single-gateway), Medium dual-AZ failover (#az-failover, basic non-production resilience, NOT production HA), Large TGW centralised egress (#centralized-egress), Extra-large GWLB fleet (#gwlb, a teaser to the GWLB inspection page).
- Two deploy flavours build identical networking: marketplace-ami (boots the Enforza Marketplace AMI, self-registers via the EC2 Instance Identity Document, claim by AWS account id plus instance id) and deployment-key (boots a stock base image, installs the engine with a one-time registration key, no Marketplace subscription). Both ship in Terraform and CloudFormation.
- Every firewall's network interface has its source and destination check disabled, because a forwarding appliance handles packets addressed to other hosts.
- Cost: up to 60–80% off the firewall and NAT metering versus AWS Network Firewall or NAT Gateway (flat per-firewall licence at $0/GB, real USD $249, GBP £199, EUR €239). This is a firewall-and-NAT-metering claim, not a claim on the whole AWS bill: the customer still pays AWS for the EC2 instance, internet gateway, Transit Gateway attachment and data, GWLB endpoint hours and processing, inter-AZ transfer and data-transfer-out. Figures are dated, US list, directional.
- Downloads: the templates are validated and public, in the repository at github.com/enforza/landing-zones. You can also deploy via the AWS Marketplace listing plus the console.

### Azure landing zones, https://enforza.io/landing-zones/azure/
Headline: Azure landing zones in Terraform, with the firewall in the hub.
Key points:
- Three from-scratch Terraform patterns (in the public repository at github.com/enforza/landing-zones) that build the whole network (a VNet, a public gateway subnet and two private workload subnets, plus a network security group) and place the Enforza gateway in it. Each gateway boots a stock Ubuntu image and registers on first boot with a deployment key from the console; a key is one-time use per firewall, so the two HA patterns take two different keys. The patterns are validated (terraform validate and terraform fmt both clean).
  - simple-single-az: one gateway VM with IP forwarding on and a Standard static public IP for egress. Dev, test and small production. Indicative Azure infrastructure cost about $30/month (excludes the Enforza licence, region-dependent).
  - ha-multi-az: two gateway VMs, one in each of two availability zones, each with a zonal Standard static public IP, behind an internal Standard load balancer (private frontend 10.0.1.100) with a TCP health probe; route tables on both private subnets send 0.0.0.0/0 through the load balancer. Production HA. Makes no specific failover-time or session-synchronisation claim. Indicative Azure infrastructure cost about $70/month.
  - ha-multi-az-with-dnat: the ha-multi-az pattern plus an external internet-facing Standard load balancer with a static public IP and an Azure DNS name (the gateways do the DNAT), and a private test workload. Production plus published services. Indicative Azure infrastructure cost about $90/month.
- Also a drop-in single-appliance route into a hub you ALREADY run, one-click from the Azure Marketplace or via the ARM template: it enables IP forwarding on the network interface (the Azure analogue of disabling the AWS source and destination check), gives the VM a Standard static public IP, applies a network security group, and can optionally create (but does not auto-associate) a route table sending 0.0.0.0/0 at the firewall's private IP. Claim it in the console by Azure subscription ID plus VM ID.
- In-pattern proof: Microsoft's Cloud Adoption Framework recommends deploying Azure Firewall or partner NVAs in the central-hub virtual network, so Enforza in the hub is the supported pattern, not a workaround.
- Cost: a two-network hub-and-spoke at 20 TB/month through one Azure Firewall Standard is about $1,232/month; the same on Enforza is a flat $249 licence (£199) plus your VM, near $299 all-in, roughly 76% less (US list, dated 2026-07-04, directional). Azure self-SNATs, so there is no separate NAT gateway stacked behind it. The indicative Azure infrastructure figures above are your own Azure costs, exclude the Enforza licence, and are region-dependent.

## Comparisons

### Compare hub — https://enforza.io/compare/
Enforza versus the cloud-native firewalls, open-source firewalls, and enterprise NGFW vendors. Two distinct pitches: a drop-in cost-and-capability replacement for cloud-native firewalls, and a right-scoped, no-bloat alternative to the enterprise NGFW platforms.

### vs AWS Network Firewall — https://enforza.io/compare/aws-network-firewall/
Same egress/east-west control and more, without AWS Network Firewall's per-GB processing charge and the separate NAT Gateway per-GB tax. Flat per-firewall pricing replaces the metered stack.

### vs Azure Firewall — https://enforza.io/compare/azure-firewall/
Same control at a flat price. Azure self-SNATs, so the cost wedge is the per-GB data-processing tax rather than a separate NAT charge.

### vs Google Cloud NGFW — https://enforza.io/compare/google-cloud-ngfw/
Replaces Cloud NGFW plus Cloud NAT metering with one flat-priced appliance.

### vs OCI Network Firewall — https://enforza.io/compare/oci-network-firewall/
OCI Network Firewall is a Palo-Alto-powered, fully managed service billed at a flat $2.75/hr (about $2,007.50/month) per instance, plus $0/GB for the first 10 TB then $0.01/GB (rates dated 2026-07-21, directional). Enforza does the everyday egress-firewall job — FQDN/SNI-based L7, stateful L3/L4 and secure NAT — on your own OCI VM at a flat per-firewall licence (about $249/month) plus the VM, all-in around $227–253/month — roughly 87% off the firewall layer. Honest scope: OCI's NAT Gateway is free, so no NAT saving is claimed; the wedge is purely the firewall layer. Concede plainly where Oracle Cloud wins: it is fully managed (no VM to run, Oracle runs HA), has Palo-Alto-powered signature IDS/IPS and curated threat intelligence, offers decrypting TLS inspection and URL-category filtering, and is deeply OCI-native. Enforza wins on flat per-firewall price, no per-instance-hour meter, FQDN/SNI L7 without TLS decryption, multi-cloud single console, GitOps policy-as-code and 25 compliance frameworks. Deploys today via a registration-key install on any OCI compute VM (no OCI marketplace listing yet).

### vs Palo Alto / Fortinet / Check Point — https://enforza.io/compare/palo-alto/
The focused, right-scoped alternative to the enterprise NGFW platforms: the core capability most organisations actually use, without the six-figure platform you half-fill ("half used, fully paid for"). Enforza does not claim to match their full breadth — and is built not to.

### vs pfSense / OPNsense — https://enforza.io/compare/pfsense/
Cloud-managed and GitOps-driven with built-in compliance and fleet operations, rather than a self-managed box that needs a reachable (often internet-exposed) management interface. Confidently ahead on single-pass classification speed and a no-exposed-management-plane security posture.

## Company

### About — https://enforza.io/about/
Mission and the cost/bloat problem Enforza solves; company timeline (founded September 2023). Enforza is a trading name of Synvu Limited (UK, company no. 15761962); founder Neil Briscoe.

### Partners — https://enforza.io/partners/
White-label and reseller programme for MSPs, MSSPs and consultancies.

### Contact — https://enforza.io/contact/
Talk to the team or start free. Email: contact@enforza.io.