Guide

A Static Outbound IP for AWS Lambda

A Lambda function egresses from AWS's shared address space by default, and the address changes. If a partner needs to allow-list the source, the standard answer is a VPC plus a NAT Gateway plus an Elastic IP — which works, and costs more than most people expect for what is fundamentally one IP address. Here is what the AWS route really involves, what it costs at AWS's own published rates, and when routing the call through an address you rent instead is the cheaper and simpler answer.

Why the address moves

By default a Lambda function runs outside your VPC with AWS-managed networking. Outbound traffic leaves from AWS's shared pool for that region. Two consecutive invocations can come from different addresses; a redeploy can change it; AWS's published ranges change over time and are enormous.

So there is nothing stable to hand a partner. Sending them the region's whole published range is not an answer either — it permits every AWS customer in that region, which most security reviewers will refuse and the rest should.

The AWS answer, and what it costs

The supported way to fix the source address is:

This is correct and it works. Two things about it surprise people.

The bill is per-hour plus per-gigabyte. At AWS's published US East rates, a NAT Gateway is $0.045 per hour plus $0.045 per GB of data processed, and a public IPv4 address is $0.005 per hour. The hourly component alone is about $33 a month before you have moved a byte, and it is charged whether the function ran or not. Add data processing and a second gateway for a second availability zone — which the AWS documentation recommends, because a NAT Gateway is zonal — and it roughly doubles.

Rates read from AWS's VPC pricing page on 2026-09-17, US East. Check them yourself before budgeting; we do not control them and they change.

You have rebuilt your function's networking. A VPC-attached Lambda reaches the internet only through that NAT, needs VPC endpoints or NAT egress for AWS services it used to reach directly, and inherits subnet, route-table and security-group configuration that now has to be maintained and reviewed. For a function whose entire requirement was "call one partner API from a known address", that is a lot of surface.

None of that makes the AWS route wrong. If you are already running everything in a VPC with NAT for other reasons, adding one more function costs you nothing extra and you should stop reading here.

The other answer: send the call through an address you hold

The requirement is narrow — one partner API, called from one known source address — and it can be met without rebuilding the function's networking. Run a small always-on box (a $5 VPS, a machine you already own, a container on hardware in your office) with a TunnelNet address attached, and have the Lambda make that one outbound call through it.

What the partner sees is your dedicated address from 23.187.152.0/24, announced by AS396500. It does not change when you redeploy, it is not shared with anybody, and it does not depend on which AWS region or availability zone the function happened to run in.

Two honest caveats, because this is a real trade and not a free win:

Choosing between them

Use a NAT Gateway if you already have a VPC with NAT, or you need every outbound call from a whole account to come from a fixed address, or having AWS operate the component matters more to you than the monthly figure.

Use a rented dedicated address if the requirement is a handful of named partner endpoints, the function is otherwise happily outside a VPC, the NAT bill is out of proportion to the problem, or you want the same source address from more than one cloud — a NAT Gateway fixes the address for one region of one provider, and an address you hold is the same address from anywhere you attach it.

That last point is the one that decides it most often. If the same partner integration has to work from Lambda today, from a container platform next quarter, and from a box in an office after that, an address that belongs to you survives all three moves. An Elastic IP does not travel.

Verify the source address before you file it

Whichever route you take, do not tell the partner the address you configured. Tell them the address a remote server actually sees, from the code path that will really make the call:

curl -4 https://api.ipify.org

Run it from the function, or from the box the function will call through, and check it a second way (curl -4 https://ifconfig.co). The one expensive mistake in this whole exercise is assuming a source address instead of measuring it — and a mis-filed address fails as a total denial on the partner's side, not as a warning.

What this costs with us

A dedicated address is $20/month on TunnelNet Full, inbound and outbound on the same address, on a machine you already have. TunnelNet Business is $100/month for the same address with a written one-business-day support commitment, onboarding done with a person, and our measured uptime published — which is what you want if a payment partner's production access depends on the number.

Plainly: we have no uptime SLA and will not offer one until we have six months of measured history — 2027-03-10 at the earliest, and a hub failure that withdraws routes takes about 25 seconds to recover, measured. AWS will quote you better numbers than that and they will be true. Weigh it.