Azure Firewall SNAT: From Single PIP to NAT Gateway

If your spokes do anything outbound at scale — calling SaaS APIs, pulling container images, hitting GitHub — you will eventually meet the SNAT port exhaustion error. The fix isn't "add a bigger firewall." It's a three-step ladder.

Step 1 — Single Public IP (default)

Azure Firewall gives you 2,496 SNAT ports per attached public IP. Fine for low-volume hubs. But every spoke shares the pool, and one chatty workload can hog it.

Step 2 — Public IP Prefix

Attach a /28 prefix to the firewall — that's 16 IPs and 39,936 ports, all in one allowlistable CIDR for downstream partners. Same product, better math.

Step 3 — NAT Gateway on AzureFirewallSubnet

This is the one most people miss. You can attach a NAT Gateway directly to the AzureFirewallSubnet. NAT Gateway then becomes the egress path:

• 64,512 SNAT ports per PIP (vs 2,496 on Firewall alone).
• Up to 16 PIPs supported.
• Total: ~1,032,192 outbound SNAT ports from a single hub.

Reference architecture (Microsoft):

Spokes → AzureFirewallSubnet
              → Azure Firewall (rules + threat intel)
              → NAT Gateway (SNAT scale)
                    → Internet

One thing to confirm: NAT Gateway runs the SNAT translation, the firewall still runs the rules. Don't see them as alternatives — they layer.