A NAT gateway alternative, when what you needed was the address

Two charges, both published, neither of them usage-free. The hourly one runs whether or not anything is behind it.

Rates read from aws.amazon.com/vpc/pricing on 10 August 2026 for us-east-1, at AWS's own 730 hours to a month. Other regions differ, and this excludes the provider's own per-gigabyte egress charge, which you pay either way. Check it against your own bill rather than against this table.

It is a good product and this page is not an argument that it is not. A managed NAT gateway gives every private subnet in a VPC a route out, scales itself, survives hardware failures, and needs nothing installed on your instances. None of that is what we do.

Keep it if what you want is general outbound connectivity for a private network, if you would rather AWS operated that path than you, or if your traffic is large enough that a second hop matters more to you than the per-gigabyte charge does.

A NAT gateway's public address is an Elastic IP out of AWS's space. It is fixed as long as you stay where you are, which is usually fine — until it is not. Moving region, moving account or moving provider means a new address, and a new address means going back to every partner who allowlisted the old one and asking them to change a firewall rule. That request is slow when it is answered at all, and it is the reason an outbound identity is worth separating from the infrastructure that happens to be behind it today.

An address leased here is announced from our own AS41800 and stays yours while the lease runs, whatever you put behind it — EC2 today, a rack or another cloud next year. Reverse DNS is yours to set. The machines behind it can be any number and can change any time, because the partner's allowlist has one entry in it and that entry does not move.

Is this cheaper than a NAT gateway?

For a fixed outbound identity, yes and by a wide margin: $19 a month against $32.85 before a single byte moves, and nothing metered on our side. But it is only a fair comparison when the identity is what you were buying. A NAT gateway also gives every private subnet in a VPC a way out, managed and scaled by AWS, and we do not replace that.

Can I keep the NAT gateway and use this only for the calls that need it?

That is the arrangement we would suggest. Leave your egress as it is and route only the traffic that a partner has allowlisted through the tunnel, with source-based routing so the default route on the machine is untouched. One pod or one small instance holds the tunnel and the rest of the cluster is unchanged.

Why not just attach an Elastic IP?

An Elastic IP is a fine fixed address as long as everything stays inside that account and that region. It is AWS address space, so it moves when you move, it cannot follow you to another provider, and a partner who has allowlisted it has to be asked to change their firewall when you migrate. An address leased from our own AS41800 is yours across providers, which is the point of allowlisting one entry.

Does this work with EKS, GKE and AKS?

Yes, and with a cluster you run yourself. The tunnel terminates on a pod or a node rather than on the control plane, so there is nothing provider-specific about it. The Kubernetes documentation walks through the manifest.

What does it cost in bandwidth?

Nothing from us — we do not meter traffic. Your provider still charges you its own egress rate for the packets leaving their network, exactly as it does today; that part is unchanged whichever route you take.

Seven days on a real address out of the same range paying customers use, so the thing you test is the thing you would buy. No card, and nobody to talk to.