Suppose we need to upload files to an SFTP from an Azure function. SFTP is configured such that all incoming IP addresses are blocked by default. To have read-write access, processes’ IP addresses must be whitelisted beforehand. Our Azure function therefore needs to present itself to the SFTP server with a fixed IP address.
The network configuration of our Function App holds the list of IP addresses that our function uses for outbound traffic:
In theory, therefore, all we need to do is whitelist these IP addresses. But the problem is that this list of addresses is subject to change; it is not fixed over time. This means that we in fact have to whitelist every address that could potentially be used by Azure datacenters, depending on their region. The complete list can be downloaded from the Microsoft website (https://www.microsoft.com/en-us/download/details.aspx?id=56519). But this approach imposes a burden, because not just one but potentially hundreds of IP addresses have to be added to the SFTP configuration.
We do have an alternative to avoid this, i.e. using a virtual network.
We need to create three resources, i.e. a public IP address, a virtual network and a NAT gateway.
Once the IP address has been created, we can create the NAT gateway by adding the new address to the Outbound IP section:
Then we can create the virtual network, add a subnet to it, and configure the link to the newly instantiated NAT gateway:
Finally, we can link our Function App to our virtual network and our subnet, in the Networking section:
All the functions that will be hosted in the Function App will now have a single, fixed, outbound IP address. All that remains is to whitelist that IP address for the SFTP. Note that only some Azure Functions plans can run on virtual networks (https://docs.microsoft.com/en-us/azure/azure-functions/functions-networking-options#matrix-of-networking-features).
