Connecting two App Services within the same VNet

Question

I have two NodeJS App Services.

They can connect to each other with no problem using the URL which is created for App Services by default. (That is through the public internet.)

Then I successfully enabled VNet Integration for both App Services, and assigned the same VNet and also subnet two both of them.

How should I modify the connection URL now to connect to appservice2 from appservice1 (without using the URLs which are publicly available on the internet)?

I could not find any host name or IP address information in Azure Portal using which I could have successfully established the connection.

Thanks for any suggestions!

Embrace

Vnet integration is only for outbound connections. You have to also enable service endpoints or private endpoints to allow inbound traffic. Either way the URL always stays the same as is shown in the portal. – Reorganization

Answer 1

When you want two app services to connect to each other over a private network, there are generally two steps you have to take to set this up correctly. Note that the app service URL will always stay the same, it is only the networking part that changes.

1. Both app services should have vnet integration enabled, which allows the app service to route its traffic through the vnet.

2. If you want others (e.g. another app service) to connect to an app service via a vnet you can choose between:

   a) Service endpoints

   b) Private endpoints

Reading your question, I assume you completed the first step correctly. But you have to complete either step 2a or 2b to get this to work properly. I would recommend you choose service endpoints because they are more straightforward than working with private endpoints. Below you'll find a detailed description and considerations for every step.

1. Vnet Integration

• The subnet you use as an integration subnet has to be a dedicated subnet. This means it is only used for vnet integration.
• Only one app service plan can be used with this dedicated subnet, this one app service plan may include multiple app services.
• If there is a network security group attached to that subnet, it needs to allow outbound traffic.
• If there is an azure firewall attached to your vnet and you want to make a call to a public endpoint, it should allow outbound traffic.
• Vnet route all should be enabled if you want all the outbound traffic to travel over the vnet.
• If you want to read more, I would recommend reading this documentation.
• Here is a simple example of how you would create vnet integration by selecting the dedicated subnet:

Service Endpoints

• Service endpoints allow you to lock down inbound access to your app so that the source address must come from a set of subnets that you select.
• Service endpoints are automatically provisioned by azure when you enable access restrictions to the app service.
• This is a much simpler alternative to private endpoints.
• Does not work in large-scale networks where you want to connect from an on-prem network to an azure vnet.
• You may turn to this documentation to read about all the features and limitations of service endpoints.
• Here is an example of how you would enable services endpoints for your app service by creating an access restriction:

Private Endpoints

• Private endpoints also need a subnet, but you can connect as many private endpoints to the subnet as there are IP addresses available.
• When you use private endpoints, you also need to have a private DNS zone. Otherwise, the app service URL does not resolve correctly to an IP address.
• Private endpoints are more complex than service endpoints because of the extra subnet and DNS requirements.
• Here is a nice tutorial that let's you set up an app service with private endpoint.
• The following example shows you how to create a private endpoint for your app service. You have the option to let azure create a private DNS zone automatically, or you can do this manually:

Reorganization

Great answer! Would having both app services in the same app service plan make any difference in how you could implement this? – Series

Yep it does, because you would only need one integration subnet in this scenario. Also, it might be cheaper in most scenario's. – Reorganization

Are you suggesting the app services all use the same subnet, or would each use their own subnet and have a service endpoint, for example, tie them together? – Series

You could use on or more subnets. It really depends on how far you want to isolate independent services and how much room you have left in your vnet. The integration vnet is the entry point of an app service, but you could also allow traffic from that same subnet to go to the app service. Allowing other integrated app services to access eachother over the same subnet. You could split this up in different subnets, as per your requirements. – Reorganization

Answer 2

If you want to access app services without public internet, then enabling VNET integration in those services alone won't be enough. You need to create a private endpoint that provides the IP from the virtual network to access the app service internally within the VNET and it also disables public access to the app service over the internet. Also please be aware that the private endpoint implementation will have some cost implications as well.

If your requirement is just to establish a secure connection between your virtual network & app service and to avoid access over the public internet, a service endpoint is the simplest solution. If you also need to access the app service from on-premises through an express route or Azure Gateway, a regionally peered virtual network, or a globally peered virtual network, Private Endpoint is the solution.

Steps to set up a service endpoint are detailed in the provisioning service endpoint link

Steps to set up a private endpoint are detailed in the connect to the web app using private endpoint link

Also if you want to deep dive into private endpoint configuration for app service, I would recommend you to read through the following tutorial

Hypersensitize