Work out SNAT port utilisation per instance or across a NAT pool, using Azure's published allocation table and the real port hold-down timers.
Quoted from Azure Load Balancer's default port allocation table. Each backend instance receives this many ports per frontend IP, up to a maximum of 1,024 — so past that point, extra frontend IPs add nothing. Microsoft's own guidance is not to use default allocation for production.
| Backend pool size | Ports per instance, per frontend IP |
|---|---|
| 1–50 | 1,024 |
| 51–100 | 512 |
| 101–200 | 256 |
| 201–400 | 128 |
| 401–800 | 64 |
| 801–1,000 | 32 |
Azure holds a SNAT port for 65 seconds after a TCP FIN closes the connection, and 16 seconds after a TCP RST. An idle connection holds its port until the idle timeout, which is configurable from 4 minutes to 120 — and Microsoft advises against raising it precisely because long timers make exhaustion more likely. A NAT gateway sidesteps the preallocation problem entirely by pooling 64,512 ports per public IP and issuing them on demand.
You might also find these calculators useful
Network, broadcast, mask and usable hosts for any IPv4 subnet
Convert CIDR to a range, split a block, or aggregate blocks
Find the bandwidth-delay product and the TCP window a link needs
How many users one server holds, and what limits it
Outbound connections fail when a NAT device runs out of source ports to give them. On Azure that happens per backend instance rather than across the load balancer, which is why a pool with thousands of free ports can still refuse new connections from one VM. Enter your connection profile and this calculator works out how many ports each host or instance actually occupies — including the ones still in hold-down after a connection closes, which is where most of them go.
Every outbound connection needs a unique source port on the public IP it leaves from. A public IP has 65,535 ports; Azure makes 64,000 of them eligible for SNAT on a load balancer frontend, and 64,512 on a NAT gateway. A port is not free the instant the connection closes: Azure holds it for 65 seconds after a TCP FIN and 16 after a TCP RST. So the ports a workload occupies are the connections it has open PLUS the ones it opened recently and closed — which for short-lived connections is the larger half.
Ports occupied
The symptom is timeouts to one destination while everything else works. Check whether one instance's allocation is the constraint.
Work out how many public IPs a workload needs before it moves, rather than after it starts failing.
Compare a fixed preallocated slice against a pooled, on-demand inventory at your own connection profile.
See how much of your port budget short-lived connections spend in hold-down, which is the case for reusing them.
Microsoft is explicit: a backend instance can run out of its allocated ports while the load balancer still has plenty unused. A pool-wide average will not show you the failure.
A 300-instance backend pool gets 128 ports per instance per frontend IP. Not 64,000 — 128. The table on this page is Azure's own.
The default allocation is capped per instance. Attaching a third frontend IP to a small pool buys exactly nothing, which is not obvious from the portal.
A connection that lives five seconds and then holds its port for sixty-five spends most of its port's life closed. Connection reuse is the fix, and it is why the hold-down field here changes the answer.
Too many simultaneous outbound connections from one backend instance to the same destination, against the ports that instance was allocated. Every connection to a distinct destination IP and port needs its own SNAT port, and the port stays unusable for 65 seconds after a TCP FIN closes it. Applications that open a new connection per request rather than reusing one hit this first — the connections may be brief, but each one's port is tied up for a minute afterwards.
It depends on which outbound method you use. With a load balancer's default port allocation it comes from Azure's table by backend pool size: 1,024 ports per instance for a pool of 1–50, 512 for 51–100, 256 for 101–200, 128 for 201–400, 64 for 401–800 and 32 for 801–1,000 — per frontend IP, capped at 1,024 per instance in total. A NAT gateway instead pools 64,512 ports per public IP and issues them on demand with no preallocation.
On a NAT gateway, yes — each public IP adds 64,512 ports to the shared pool. On a load balancer using default allocation, only up to a point: the per-instance allocation is capped at 1,024 ports however many frontend IPs you attach, so a small backend pool already at the cap gains nothing. Past that you either allocate ports manually with an outbound rule or move to a NAT gateway, which is what Microsoft recommends.
Because the ports are preallocated per instance. Microsoft states it directly: exhaustion occurs when a backend instance runs out of its given ports, and the load balancer can still have unused ones. The pool-wide figure is not the number that decides whether your next connection succeeds — which is why this calculator's Azure mode reports per instance.
Yes, and raising it makes things worse. An idle connection keeps its SNAT port until the timeout expires, configurable from 4 minutes up to 120. Microsoft advises against increasing it for exactly this reason and suggests TCP keepalives instead, which refresh a long-lived connection without holding extra ports.