There are times when you may require a fixed outbound public IP address for your Internet facing workloads. Usually this is required for whitelisting purposes so that external systems or customers can safely trust the source of the traffic they are accepting.
This is a straightforward enough process for a single virtual machine by using an associated instance level public IP address but how do you perform this at scale?
Before now we had a couple of options for performing source network translation (SNAT):
- You could route your outbound traffic through a firewall, either Azure Firewall or a network virtual appliance
- You could use a standard tier public load balancer and avail of the outbound NAT functionality this offers
Now we have another option – Azure NAT gateway.
Similar to the standard tier Azure load balancer it uses a standard tier public IP address or address prefix. After that it’s simply a matter of associating the NAT gateway with the subnet(s) you require on your virtual network.
This is a new service that allows you to apply outbound SNAT on the subnet level of a virtual network.
Note: You can combine NAT gateway with public IP addresses and Azure load balancers but only the standard tier. If you have a basic tier associated then the NAT gateway association will fail.
The NAT gateway will take precedence over a public IP address and a load balancer IP address so for example if you are using a load balancer for inbound NAT and a NAT gateway for outbound NAT then the NAT gateway IP address is the outbound address and the one you will want to whitelist.
One important limitation of this service is that NSG flow logs are not supported if you are using a NAT gateway. To me, this is an important feature and traffic analytics which use these logs would be something I would be reluctant to sacrifice in many cases.
Here I have a basic example where I have a NAT gateway with a standard tier public IP address associated.
Now I associate to the subnets I require on my virtual network.
To test, a simple Google search from a virtual machine on one of those subnets reveals that my outbound IP addresses matches the NAT gateway.
NAT gateway vs Standard Azure load balancer
So why would we deploy a NAT gateway over an Azure load balancer?
It comes down to how SNAT works in combination with Port Address Translation (PAT). There is a limitation on the number of ports available and how these ports are allocated and re-used. NAT gateways can use 64,000 ports per IP address up to a maximum 16 IP address or 1 million SNAT ports. These ports are then reused opportunistically.
In the case of an Azure load balancer, these ports are preallocated for each IP configuration of the NIC on the virtual machine. There is a maximum of 1,024 ports per IP configuration so if you have a lot of outbound connections you are more likely to experience SNAT port exhaustion, i.e. running out of SNAT ports. These ports are not reused as efficiently either.
From a pricing perspective, the data processed cost per GB charge is very slightly cheaper on the NAT gateway but there is also a cost for the service per hour. By my calculations this makes the service around twice as expensive as a standard tier Azure load balancer with 5 load balancing rules processing the same amount of data.
So really I think the decision comes down to how SNAT and PAT works for both of these services and what your exact requirements are.
I recommend the below links for further reading on this subject: