Add static IP address for outbound traffic without the use of App Service Environment
There are many reasons you may want to have a static IP address for outbound connections. For example, you may be accessing a system which requires you to whitelist IP address in a firewall, such as SQL Database or an external service.
Currently, the only way to get a static IP address for outbound connections is to use App Service Environment. App Service Environments are quite complex, and has a very high price tag. You need at least 4 instances, 2 of which must be P2, meaning you'll pay at least 1000 EUR/month. Paying 1000 EUR/month just because you want a static IP address is obviously ridiculous.
I'm looking forward to being able to use a static IP address without an App Service Environment.
Nitramafve
shared this idea
Still no news to share, just to add that we are investigating options on modifications for the App Service multi-tenant offering with enhanced capabilities.
Thanks,
Oded
35 comments
-
Anonymous
commented
3 vote for this, obviously there would be static IP for outbound traffic for whitelisting for third parties and Database
-
Jens Vestergaard
commented
This has become an issue for us as well, and we would very much like to know which direction you will be going with this.
Brgds
Jens -
Pedro Feio
commented
Can you please provide an update on this? At least an update mentioning if you're building this, pr planning to build this into the App Services or not.
Thanks!
-
Stephan van Rooij
commented
I can't believe this isn't possible yet. I don't like the fact that some 3th party systems require (manual) IP whitelisting, but for now I have to live with it.
-
GOPINATH THIRUVENGADAM
commented
With Azure Application gateway supporting static IP and traffic leaving the app gw v2 also having the same static public IP, we can get away with ASE's with a combination of splitting the web and mid tier across 3 application gateways. Web AppGW exposed to the internet and Mid AppGW with public static IP but NSG in front so it accepts traffic only from Web APPGW static IP, and the DB behind another APPGWV2 that is configured to receive traffic only from MiDAPPGWV2.
-
Yonathan
commented
This is a Key Feature to many clients of Microsoft. It is obviously for security that Microsoft's clients must use a whilelist in their external systems. For this reason, it is a great feature to improve the App Services.
-
Paul Broman
commented
Seriously, this seems like such a basic thing. I just assumed you could pin a service to an outbound IP somewhere quickly and easily. I have developers working on things and now we're looking at migrating to VMs. I suppose I should have done more homework on this, but it just seems like such a basic common need for so many developers. Why should it cost a pile of cash just so you can assign stuff to a static outbound IP? Terrible.
-
Matias Osca
commented
Another vote.. Be able to run a script to make outbound call from a static IP would help to white-list in my external systems
-
Anonymous
commented
Also really need this feature. We have several app services, and recently have gotten a requirement to have a static outbound IP. Wanted to use app service, but paying $1000+ for ASE would basically quadruple our costs.
We're ending up having to make a cloud service just to get static IP. Please add this, so we can stick to App Services.
-
Anonymous
commented
3 votes for this. The problem with ASE is it has features that smaller customers want but other features that are not needed such as high scalability.
For example, my company has web apps that for security reasons require traffic to pass through Azure's internal network only, we also require static IP addresses as the calls made from our web apps come from a range. Opening the entire range means that you expose the web app to others outside of our company.
We don't need high scalability for these apps, but we do require the security it comes with such as the isolation. Currently, we have to use IaaS which is a bit of a waste.
-
Anonymous
commented
any news or provision for this 7 months after the last post? forced to look into other options simply because of this
-
Jens Hellberg
commented
Urgent +1!
-
RMD
commented
If your site uses SSL and you're at least using the "Production" tier, you can assign the SSL cert using IP based bindings. This will lock down your IP address so that it won't change.
-
anonyme
commented
Hope this feature will be implemented soon.
-
See
commented
-
Pedro Feio
commented
Defining our outbound IPs is key feature for us. At least something that allows us to do some NAT equivalent for our App Services. What we can't do is ask our partners to whitelist 4-8 outbound IPs per app service. It's not secure, governable or practical.
I'm now on the verge of having to abandon a solution using App services because of this. The ASE is not economically viable, and makes no sense for financially. We don't need to scale to that level, we just need outbound IP isolation.
-
Ryan
commented
For those wanting more information, it looks like they are weighing up the different options of implementing this. Different options will likely have different time frames.
https://youtu.be/hTsspH9hzec?t=2218 -
George
commented
This is a must. You cannot have web apps without static outbound IPs. My apps are behind a WAF and i have a single inbound IP. But outbound IP changes just drives everyone crazy because i cant keep up with updating suppliers to update their firewalls (for a cost) because outbound connections to their APis are not routed through the WAF but the web app outbound IPs which change when scale up or down etc. Please add static outbound IPs for whatever reasonable cost or add an option to be able to route my web apps traffic through the WAF. Thank you.
-
Mohamed Zayed
commented
Thank You, Excellent
-
Anonymous
commented
On way of solving this that we have looked into is to setup a forward proxy on it's own VNET with a load balancer and attach an outbound static ip address to the VNET. The load balancer should manage outbound connections too. You then setup a point-to-site vpn between your app services and your VNET and route the traffic from your app instances through your forward proxy which will route the traffic to where ever you like. We haven't tried this out yet, but we will tell you more once it is up and running.