When designing architectures in Azure, it is often important to accurately determine which public IP addresses are used for outbound network traffic. A commonly required requirement is to ensure that outbound traffic from the Azure virtual network occurs with established public IP addresses. This requirement is typically due to the need to explicitly authorize traffic from Azure on other resources. This article describes how in Azure you can govern this aspect, what are the elements to be taken into consideration and what innovations have recently been introduced in this area.
By default, outbound traffic from an Azure virtual network uses randomly allocated public IP addresses, and they can change.
Public IP Assignment to the Single Virtual Machine
When you need to fix the Public IP address for the outbound traffic of a single virtual machine, the easiest method is to assign a Public IP address to it. This IP address will be used for inbound traffic, if necessary, and for outbound traffic. Through Network Security Groups (NSGs), the primary tool to control network traffic in Azure, you can filter communications with deny and permit rules.
Public IP Assignment to Load Balancer
Instead of assigning a public IP address directly to a virtual machine, you can assign it to a load balancer. In this way, any virtual machine added to the load balancer back-end pool will use the public IP assigned to it for outbound network traffic.
Figure 1 – Load Balancer with Public IP
This approach is recommended if there is a real need to use a Load Balancer to balance inbound network traffic across multiple virtual machines. This also allows you to limit the number of public IPs required, configuring multiple virtual machines behind the same load balancer.
Using Azure Firewall
If you have Azure Firewall, if network traffic is appropriately channeled to this component through specific routes, you are sure that it will go out to the Internet using the Public IPs assigned to the Azure Firewall instance. You can associate to Azure Firewall up to 250 public IP addresses, However, consider that the Azure Firewall Source Public IP address used for connections is currently randomly chosen from the assigned IPs. This is something to consider when you need specific permissions for traffic from Azure Firewall and whether you need to manage access to FTP Passive (unsupported if Azure Firewall has multiple IP addresses assigned). Microsoft still has a roadmap of SNAT configurations by specifying the Public IP address to use.
Figure 2 – Azure Firewall overview
Azure Firewall is an increasingly popular component and its activation is recommended to better manage and govern network traffic. However, In the absence of this component it is possible to evaluate less expensive alternative methods if the only goal is to govern which IP addresses are used in outbound network traffic.
Virtual Network NAT
Virtual Network NAT is a new method that was recently introduced to simplify Internet connectivity in virtual networks and affects outbound network traffic only. If configured on a subnet, all outbound traffic will use the specified static public IP addresses. All this is possible without the adoption of public IP addresses directly linked to virtual machines and load balancers.
Figure 3 – Virtual Network NAT
A subnet can then be configured by specifying which NAT Gateway resource to use. When configuration is complete, all outbound network flows (UDP and TCP) from any virtual machine attested on that subnet, will use the Public IP (standard SKU), the Public IP Prefix or a combination of these. The same NAT Gateway resource can be used by multiple subnets, as long as they belong to the same Virtual Network.
Virtual Network NAT is compatible with the following resources, having Standard SKUs:
- Load balancer
- Public IP address
- Public IP prefix
These components, used in conjunction with Virtual Network NAT provide inbound Internet connectivity to subnets. Virtual Network NAT instead manages all internet connectivity outbound from the subnet. The joint use of these components is possible as they are aware of the direction in which the flow was started and allow them to be managed correctly.
Figure 4 – Virtual Network NAT flow direction
The guaranteed SLA for this feature is 99.9%, as it is automatically distributed by the platform on multiple fault domains to best support any fault.
Virtual Network NAT is by default a regional service and you can isolate it in a specific area (zonal deployment), when you have to contemplate scenarios that adopt different availability zones.
Figure 5 – Virtual Network NAT with availability zones
To monitor the usage of this component and to perform troubleshooting operations, you can review the metrics exposed in Azure Monitor:
- Bytes
- Packets
- Dropped Packets
- Total SNAT connections
- SNAT connection state transitions per interval.
NSG flow logging is not currently supported for Virtual Network NAT.
The cost of this component is due to two factors:
- Hours of resource existence
- Processed data
For more details on costs please visit the Microsoft pricing page for this component.
Conclusions
To govern which IP addresses are used by systems in Azure to communicate externally there are several possibilities, each with its own characteristics. If you are adopting the Hub-spoke network topology with an Azure Firewall in the Hub network, control is guaranteed by design. A great solution in the absence of Azure Firewall or other Network Virtual Appliances is the adoption of the methodology Virtual Network NAT recently introduced.
