IP management in Azure with Private Endpoints or App Service Environment?

Question

IP management in Azure with Private Endpoints or App Service Environment?

Michel Gagnon 20

Hi, I am looking for help with Azure. I work for a company and we are trying to manage IP addresses in a subnet but not sure if we should go with a Private Endpoint or an App Service Environment. We have multiple subscriptions and resource groups. Our developers are using DevOps (Bifrost) to deploy fonctions in Azure and IPs have to be managed. I wonder if we should go with Private Endpoints or an App Service Environment. Since we have multiple resource groups involve in that project, I feel that Private Endpoints will be really expensive (could be up to 12 RG needed). Also, since we have resources in different subscriptions and different subnets, I assume that if we go with an ASE we will need to do some peering between the subnets in order to see or use resources from different subscriptions? If so, does peering between subnets could create any weakness security-wise? Thanks !!

Juul Hobert 0 Reputation points

2024-01-25T07:04:06.1733333+00:00

Hi Michel, can you explain clearly what you're trying to accomplish? What makes security / isolation a big concern for you? I read that your developers want to deploy functions. Are those functions internet facing or do you want to access them from a private network?

Accepted answer

0 additional answers

Your answer

Juul Hobert 0 Reputation points

2024-01-25T07:04:06.1733333+00:00

Hi Michel, can you explain clearly what you're trying to accomplish? What makes security / isolation a big concern for you? I read that your developers want to deploy functions. Are those functions internet facing or do you want to access them from a private network?

Answer 1

Ben Gimblett 4,560 Microsoft Employee

Hi - Thanks for the question Michel

So firstly some differences between ASEv3 (you need the v3 version) and regular App Service Plans

*Probably the number one difference is turn-key-networking - you deploy into a given subnet (ensure you read the doc to size it correctly) and there's no proliferation of subnets as we find today in GA app service (one for private endpoints, one per plan for regional vnet integration).
On that last point , note there's a preview now on regular plans to remove the 1:1 limit for regional vnet integration so this will improve

*ASE is "single tenant" - so , if you have a workload to host where you need to meet compliance or will be audited for compliance then ASE is often the way to go. Limited/to no shared resources

*ASE scales to 200 overall and 100 instances per plan. So scale out is very good

*ASE offers a huge choice of larger machines for scale-up where you need lots of cores/RAM on the Iv2 plans (Isolated v2)

*ASE does take a fair amount of time to provision (can be around 4 hours) and it doesn't scale out and scale back as quickly as a regular ASP plan (if rapid scale out is required, ASE may not be suitable)

*Cost wise, ASEv3 is roughly on a par with standalone Premium App Service Plans BUT if you go for Availabilty zone support there's a min standing charge of 9 (3x3) of the lowest scale instance . However, if you intend to run an ASE chances are you will have more than 3 plans and each plan would anyway need to have min 3 instances to be zone resilient. That's covered in more detail in the docs. There is a charge for private endpoints yes, but you also need to be cognizant of bandwidth charges too (whether you use private endpoints or not)

It is possible (but only via template deployment) to deploy ASE in one subscription and a plan(s) for the ASE from another. However the same network/region is required for all.

On the other hand if you go for non ASE then you will (in GA terms) need a subnet for private endpoints - and a subnet per plan for regional vnet integration (for outbound traffic into your vnet - if you need it)

There is no great security risk in peering VNETs - but this does need to be planned out. There's some great advice in the Enterprise Landing Zone Guidance

So overall I would say networking is a factor - but there's much more that you need to consider before making a choice

Ben Gimblett 4,560 Reputation points Microsoft Employee

2024-01-25T14:31:48.3766667+00:00

Links for that answer
https://learn.microsoft.com/en-us/azure/app-service/overview-vnet-integration
https://learn.microsoft.com/en-us/azure/app-service/environment/overview#feature-differences
https://techcommunity.microsoft.com/t5/apps-on-azure-blog/announcing-app-service-multi-plan-subnet-join/ba-p/3971493
https://learn.microsoft.com/en-us/azure/architecture/landing-zones/landing-zone-deploy
https://azure.microsoft.com/en-gb/pricing/details/app-service/windows/
Michel Gagnon 20 Reputation points

2024-01-25T14:58:41.87+00:00

Hi Ben and thanks for reaching out. This is great information and I'll go over the links provided. Yesterday we have deployed an ASE in a test environment just to see if that covers the needs. The only thing is that we couldn't figure out how to mange the IP. We need a static IP that will be allowed from the firewall to make it easy for the functions to be deployed and hit the SQL database. Otherwise the functions won't deploy. Hope that makes sense.
Ben Gimblett 4,560 Reputation points Microsoft Employee

2024-01-25T15:25:56.9233333+00:00

Hi Michel - the info you need is here

https://learn.microsoft.com/en-us/azure/app-service/environment/networking#addresses

So the thing to keep in mind, like regular app service , the networking for INBOUND is treated differently from the networking for OUTBOUND (this is a result of the web farm type architecture pattern which app service uses)

So as you will learn in the link above you have an IP from your ASE for inbound traffic (either public or private, you choose)

AND

You have outbound VIPs for the outbound traffic BUT this is ONLY for traffic reaching outside the VNET. In this case that traffic is NAT to one of the specified outbound IP (as per doc). As also noted in the doc, use a natgw (or route via a firewall/NVA) if you want control over this

For traffic that stays on the VNET (and again, assuming it's not going via a firewall or some other gateway) it will not be NAT, so it will retain a private IP drawn from the ASE subnet prefix
For this reason any downstream service which needs to check the source ip (that's on the same network) should use the ASE subnet prefix to allow/deny and not an individual private ip address - this is because private ips are allocated dynamically as the plans scale in and out (and this is non deterministic) .

This is generally speaking how most Azure vnet injected PaaS works - not just ASE for outbound traffic.

Does that make sense?
Michel Gagnon 20 Reputation points

2024-01-25T18:41:56.31+00:00

Wow thank you. That makes perfect sense. I really appreciate your responses and the time you put answering most of the questions we had. Have a great day !!

Share via

IP management in Azure with Private Endpoints or App Service Environment?

0 additional answers

Your answer