Your partner's security team asks a simple question: "What are your outgoing IP addresses so we can whitelist them?" If you cannot answer that question in under thirty seconds, you have a problem that no amount of engineering will elegantly solve.
This is not a networking trivia question. It is a litmus test for how seriously your organization treats its external integrations — and by extension, how seriously it deserves to be treated by its partners.
The invisible handshake
Every B2B API integration begins with a contract — not just the legal kind, but the technical one. You agree on endpoints, authentication schemes, rate limits, and IP whitelisting. That last item seems mundane until you realize it is the foundation upon which mutual trust is built.
When your workloads run in a public cloud — AWS, Azure, GCP, or any other provider — your compute instances receive ephemeral public IP addresses by default. They change. They rotate. They belong to a pool shared with thousands of other tenants. Asking a partner to whitelist a dynamic IP range is asking them to leave their front door open and trust that only you will walk through it.
A NAT Gateway solves this with elegant simplicity. All outbound traffic from your private subnets routes through a fixed set of Elastic IPs (or their equivalent: Azure NAT Gateway with static public IPs, GCP Cloud NAT with manual IP allocation). You get predictable, communicable, stable outgoing addresses. Your partners whitelist them. The handshake is complete.
The real cost of not having one
Let me tell you what happens when you decide a NAT Gateway is too expensive.
I once integrated with a partner — a large Chinese technology company — that could not provide fixed outgoing IP addresses. Their engineering team argued, with genuine conviction, that dynamic IPs were "standard practice in cloud computing." They were not wrong about the practice. They were wrong about the standard.
Because they could not give us a finite set of IPs to whitelist, we were forced to build a bastion endpoint on our side. Not a lightweight proxy. A fully fortified gateway that accepted traffic from the entire Chinese IP address range — because that was the only way to ensure their requests would reach us regardless of which ephemeral address their cloud decided to assign that hour.
This bastion became a monument to compromise. It required:
- Threat detection layers to distinguish legitimate partner traffic from the noise of an entire country's IP space
- Traffic analysis engines running continuously, consuming compute and adding latency
- Rate limiting and behavioral analysis that inevitably slowed down legitimate requests
- Redundancy and failover mechanisms because this proxy had become a single point of failure — the one door through which all partner communication had to pass
The result? Our platform appeared sluggish. Response times suffered. The integration that was supposed to demonstrate technical capability instead showcased architectural weakness. We looked unreliable — not because our platform was unreliable, but because we had to compensate for a partner's refusal to spend a few hundred dollars a month on a NAT Gateway.
The irony was not lost on anyone involved.
A FinOps perspective: when cost avoidance is the real waste
The typical objection to NAT Gateway adoption is cost. And the cost is real — on AWS, a NAT Gateway runs approximately $32 per month for the gateway itself, plus $0.045 per GB of data processed. At scale, with significant outbound traffic, this adds up. Azure and GCP equivalents carry similar pricing structures.
But FinOps is not about minimizing every line item. It is about optimizing spend relative to business value. And the business value of a NAT Gateway is not measured in gigabytes processed — it is measured in partnerships maintained, integrations delivered on time, and security incidents avoided.
Consider the alternative costs:
- Engineering hours spent building and maintaining custom proxy solutions
- Compute costs for running bastion hosts, WAFs, threat detection, and traffic analysis — infrastructure that exists solely to compensate for the absence of fixed IPs
- Latency penalties that degrade your platform's perceived performance
- Reputational damage when a partner's security team flags your integration as high-risk because you cannot provide stable egress addresses
- Opportunity cost of delayed integrations while you architect workarounds
A NAT Gateway is not an infrastructure expense. It is an insurance premium against architectural debt that compounds with every new integration.
When to deploy: the first integration rule
The recommendation is straightforward: deploy a NAT Gateway the moment you have your first API integration — inbound or outbound.
Not when you have ten integrations. Not when a partner demands it. Not when your security audit flags it. On day one.
Here is why the timing matters:
Outbound integrations — When you consume a partner's API, they will ask you to identify yourself. Fixed IPs are the most fundamental form of identification at the network level. Without them, you are asking your partners to accept anonymous traffic, and sophisticated partners simply will not.
Inbound integrations — When partners consume your API, they need to know that the IPs they see in their logs are consistently yours. This matters for troubleshooting, for audit trails, and for the mutual confidence that underpins any long-term technical relationship.
Compliance and audit — Regulatory frameworks increasingly require organizations to demonstrate control over their network egress. A NAT Gateway provides a clean, auditable egress point that satisfies these requirements without additional tooling.
The cloud-native objection
Some architects argue that NAT Gateways are a relic of on-premises thinking — that truly cloud-native applications should use service meshes, API gateways with mutual TLS, or OAuth-based authentication that makes IP whitelisting unnecessary.
They are partially right. Modern authentication and zero-trust architectures reduce the reliance on IP-based controls. But they do not eliminate it. The world does not operate at the bleeding edge of your architecture. Partners have their own security policies. Financial institutions require IP whitelisting regardless of what other authentication you offer. Government agencies mandate it. And the Chinese technology company that cannot provide fixed IPs? They exist in every market, in every industry.
Your architecture must meet the world where it is, not where you wish it were.
The quiet confidence of fixed IPs
There is something that does not show up on any cost dashboard but matters enormously: the confidence you project when a partner asks for your egress IPs and you reply instantly with a short, stable list.
It signals operational maturity. It signals that your cloud infrastructure is intentional, not accidental. It signals that you have thought about the details that most organizations overlook until they become problems.
In a landscape where API integrations are the connective tissue of modern business, that signal is worth far more than thirty-two dollars a month.
The bottom line
A NAT Gateway is one of the least glamorous components in any cloud architecture. It does not scale your application. It does not improve your algorithms. It does not win architectural awards. But it does something that no microservice, no container orchestrator, and no serverless function can do on its own: it gives your organization a fixed address in a world that expects to know where you live.
The cost is real. The cost of not having one is greater. And if you are practicing FinOps with any rigor, you already know that the most expensive decisions are the ones where short-term savings create long-term architectural debt.
Deploy the NAT Gateway. Communicate your IPs. Be the partner that answers the simple question in under thirty seconds.
manneken think guides organizations through precisely these decisions — where the cost of inaction quietly exceeds the cost of action.