Azure Web Apps – Outgoing IP Question/Answer

A colleague of mine called me the other day and had a conceptual networking issue with an Azure WebApp and their use case. The webapp was going to call an external 3rd party API which was protected by firewall rules based on IP-address. He needed to supply the 3rd party product supplier with the correct IPs of his callers IP address. He was however uncertain on how this could be done. I had no immediate answer to this and we started discussing.

Some ideas discussed and dropped was:

  • Could one set a static IP on the WebApp? – No that would not work as 1) the instances would have different IPs anyway and by setting the internal IP on a specific instance which would not help you at all because you are likely to use more than one instance. I am also not sure that a webapp would be able to use such an internal IP for outgoing calls anyway. 2) You would like to set it for all instances on the webapp but the one thing holding your instances together is the loadbalancer – but outgoing calls will not go through any load balancer. 3) Using static IPs for WebApp instances (or most PaaS services) does not make sense due to the abstraction of servers in the PaaS offering.
  • Could one set up a VM with a reserved IP and make all calls through that VM? Yes that might work for this scenario to produce a known IP for the 3rd party API. But it had some disadvantages with 1) having to pay for an extra VM (or at least two for High Availability) as well as 2) it did not fit very well as the web app was supposed to get SAML tokens from the api and to route that through an extra server seemed unsuitable.

So whats the answer then?

The real answer is that there is no full proof way to do this – the solution presented below is depending on a couple of factors to keep the IP permanently and there are things you can do to get another IP if you are not aware of the inner mechanics. On the other hand as long as you are aware of how it works you can in most cases avoid or mitigate the issue.

The most important part of the solution is that each web app has a set of outbound IP addresses. These are the ones that you should use and supply in the firewall rules of the firewall at the 3rd party supplier. You find these in the WebApp in the portal

WebApp Outgoing IP
How to find the Outgoing IP for a WebApp

Part answer: So copy the IPs and send them to the API provider.

So whats the problem then?

So far everything seems good but there are some catches.

  1. The IPs are not yours alone. These ports are also used by other WebApps (I mention this more below and the references will explain it even better)
  2. While this will affect all your instances of your webapp, it MIGHT! not stick if you scale-up/down the application.It is important to clarify this – so just to repeat: scale out/in will be fine (which you will do most…often with autoscaling rules) – but scale up/down might cause this to change. So if you change the app service plan any change as the below picture shows you will possibly get new outgoing IPs.
Beware if changing scale
Beware if changing scale

The change above caused the Outgoing IPs to change to the below…

Scale Changed = IP Changed
Scale Changed = IP Changed (this time)

So is this a big deal? Not unless you change the scale often. And if and when you do – make sure the api supplier is ready to instantly change the firewall settings again to the new address (should it change).

But I just tried and the IP remained when scaling up/down!

After the test above I tried changing the scale again a number of times and in all these scenarios I ended up with the same outgoing IPs. So I am assuming that I was allocated to another scale unit the first time but subsequent calls put me in the same one.

Final conclusion:

  1. You can use the outgoing IP of your webapp to supply to firewall information based on IP to 3rd party providers.
  2. Be aware that changing the service plan MIGHT change the outgoing IPs. So have any such providers ready to change the configuration on their end if you need to change the service plan.
  3. Scale Out/In including auto-scale is not subject for causing changes for outgoing IP.
  4. In case of regional disasters I wouldn’t feel 100% confident of getting the same outgoing IP.
  5. I would recommend some custom logging to Application Insights and related alerts when you get failures with the 3rs party supplier apis and the first thing you should look at is whether the outgoing IP addresses are still the same.


Previously the list of all possible IPs for different was listed on this URL. If you are looking for more details about this topic I suggest you head over there.


5 thoughts on “Azure Web Apps – Outgoing IP Question/Answer

    1. Not in this case this would not be sufficient. The problem was that we needed to know the IP that was used from our web app (i.e. when it called) to the external web service which was protected IP address by firewall that needed to be opened for our caller. In other words the external service had to enter the allowed IPs and we had to supply it. Changing the inbound address would not affect the outgoing address from our web app. And as far as I know you still cannot set the OUTGOING ip address on a web app.


  1. An extra problem to this is it seems that there are also .0 ip numbers that are also used. So if you give the 4 ips in the azure properties to a 3rd party you may also have to give them the x.x.x.0 ones as well or you will get errors connecting returned in your logs. And those .0 ips are definately shared with other azure users.


    1. Interesting comment. I have not noticed this myself or heard anything suggesting that before. It would be very interesting to get some more information about this. Like logs, what type of communication you call etc. But either way (x.x.x.0 IP) or not your 3rd party supplier will open firewall to more than your app service so one should ideally combine the firewall rules with secure communication and authorization/authentication also to increase security.


    2. Jon L, have you found a solution to the connection issues? We’re having similar problems with a x.x.x.0 outbound address in Azure.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s