Consolidate redundant NAT Gateways

A NAT Gateway is a piece of network plumbing that lets internal systems reach the internet. The relevant fact for finance is that each one carries a fixed charge of roughly $32 a month before a single byte of traffic flows through it. That charge appears whether the gateway is necessary or duplicated. This finding isn't about gateways doing nothing — it's about VPCs (the isolated networks workloads run in) that are carrying more of these gateways than their design needs, so you're paying the fixed fee several times for capacity one gateway could provide.

It happens because there's a sensible engineering default — run one gateway in each data-centre zone so a single zone failure can't take the whole network offline — and teams apply that default everywhere, including test environments and small workloads where the extra zones add cost but no real protection. So you end up paying for production-grade redundancy on a dev sandbox, or running two gateways in the same zone where one would do. Individually it's $32 a month; across an organisation with hundreds of these networks it lands in five figures a year for resilience nothing is using.

The important nuance — and the reason this isn't a simple delete — is that the redundancy is real in production: the per-zone gateways exist to keep critical systems online and, just as importantly, to avoid an internal data-transfer surcharge (~$0.01/GB) that gets added when traffic from one zone has to cross to a gateway in another. Consolidating too aggressively can replace a $32 fixed saving with a larger variable transfer bill, or weaken a production failure boundary. So the right framing for finance is environment-by-environment: aggressive consolidation in non-production, careful pruning of genuine duplicates in production.

Raj is the finance partner for the platform org at a logistics company. At the monthly cost review the networking line is flat, and he asks the question that's now standard: "Of our NAT Gateways, how many are there for production resilience versus duplicated defaults we don't need?" The platform lead pulls the report: across the dev and staging accounts there are 40-odd gateways, and the per-zone pattern was applied uniformly — including on environments with no uptime requirement at all.

The conversation isn't about which AZ or which route. Raj asks three things: which of these environments actually need zone-level resilience, what the saving is if non-prod drops to one gateway each, and — critically — whether consolidating adds any internal data-transfer charge that eats the saving. The lead confirms dev/staging egress is low-volume, so the cross-zone surcharge is negligible there; production stays as-is. That's enough to act: a consolidation pass on non-prod, production left untouched.

The point Raj holds onto is that this is a resilience-sizing decision dressed as a cost line. He doesn't push to minimise gateways everywhere — that would trade a $32 fixed saving for a larger variable transfer bill or a weaker production boundary. He pushes to make the redundancy match the environment's importance, and he adds a recurring line to the finance pack so non-prod doesn't silently drift back to the expensive default.

Per resource the number is small and in aggregate it's material. An org applying a uniform per-AZ default across many environments typically carries a few thousand dollars a month of NAT provisioning, a meaningful slice of it redundant. It rarely moves a quarterly number alone, but it's the kind of steady, defensible saving that builds credibility for the FinOps function — and it recurs every month until someone acts.

The budgeting subtlety is that the saving is not risk-free, and finance needs to hold that distinction. Cutting a gateway saves a fixed ~$32/month, but if the consolidation pushes traffic across AZ boundaries it adds a variable charge that scales with usage. So a 'saving' booked in provisioning can quietly reappear, larger, on the data-transfer line. When engineering proposes a consolidation, the right finance question is "does this add any cross-AZ transfer, and at what volume?" — not just "how many gateways does it remove?"

The second impact is on how resilience spend is justified. Production per-AZ NATs are a deliberate availability investment; non-prod copies of them are an accident of templating. Treating both the same — either cutting both or sparing both — is the error. A defensible budget distinguishes resilience the business is choosing to pay for from redundancy it inherited by default, and only the second is a saving.

Finally, it's a leading indicator of templating discipline. If non-prod environments are quietly inheriting production-grade networking, the same uniform-default habit is almost certainly inflating other categories — oversized instances, prod-tier databases, multi-AZ everything — in environments that don't need them. Watch this line as a proxy for whether the org sizes infrastructure to purpose.

Cloud networks use small managed gateways to let internal systems reach the internet, and each one carries a fixed monthly charge. The default engineering pattern runs one per data-centre zone for resilience. When that pattern gets copied onto environments that don't need it — test systems, small workloads, old layouts never cleaned up — the business pays the resilience premium several times over with nothing protecting it.

This is a right-sizing-of-resilience question, not pure waste. The per-zone pattern is correct for production and protects against real failures, so the move isn't to strip it out everywhere — it's to make sure the level of redundancy matches the importance of each environment. Done well, it trims a recurring cost and signals that the org is matching its spend to actual risk rather than applying one expensive default to everything.

At one company the cloud review used to carry a flat networking number that nobody questioned — it was "just infrastructure." When an exec finally asked what was inside it, the answer was that a single expensive resilience pattern had been applied uniformly to every environment, production and throwaway alike, because it was the template default.

The leadership move wasn't "cut networking spend." It was "make resilience proportional to importance." Production kept its per-zone redundancy; everything non-critical dropped to the minimum that still worked. The recurring saving was real but modest — the bigger win was that the org stopped paying production prices for sandbox risk, and the same proportionality thinking spread to other duplicated defaults.

That's the right outcome state. "Fewest possible gateways" is the wrong goal — it would weaken production or add transfer cost. "Resilience matched to the value of what it protects" is the right one, and once it's the norm the line stops being a question.

The dollar amount is modest; the reason it's tracked is what it reveals about discipline. A network where resilience spend is proportional to importance — production protected, throwaway environments lean — signals an org that sizes infrastructure to purpose. A network where one expensive default is stamped everywhere signals the opposite, and that same habit is almost certainly inflating bigger categories that don't show up as cleanly.

There's a risk dimension too: this is explicitly not a 'cut to the minimum' exercise. The per-zone redundancy protects production from a zone failure, and over-consolidating to save a few dollars can create an avoidable outage or shift cost onto an internal-transfer line. So the leadership read is balance — resilience matched to risk — not minimisation. That balance is the thing worth confirming, not the dollar figure.