Скачать или смотреть Networking considerations - Azure App Service Environment

Networking considerations for an App Service Environment

You can deploy applications in Azure App Service in multiple ways. By default, apps hosted in App Service are accessible directly through the internet and can reach only internet-hosted endpoints. But for many applications, you need to control the inbound and outbound network traffic. There are several features in App Service to help you meet those needs. The challenge is knowing which feature to use to solve a given problem. This article will help you determine which feature to use, based on some example use cases.

There are two main deployment types for Azure App Service:

The multitenant public service hosts App Service plans in the Free, Shared, Basic, Standard, Premium, PremiumV2, and PremiumV3 pricing SKUs.
The single-tenant App Service Environment (ASE) hosts Isolated SKU App Service plans directly in your Azure virtual network.
The features you use will depend on whether you're in the multitenant service or in an ASE.

Azure App Service Environment is a deployment of Azure App Service into a subnet in your Azure virtual network (VNet). There are two deployment types for an App Service environment (ASE):

External ASE: Exposes the ASE-hosted apps on an internet-accessible IP address. For more information, see Create an External ASE.
ILB ASE: Exposes the ASE-hosted apps on an IP address inside your VNet. The internal endpoint is an internal load balancer (ILB), which is why it's called an ILB ASE. For more information, see Create and use an ILB ASE.
All ASEs, External, and ILB, have a public VIP that is used for inbound management traffic and as the from address when making calls from the ASE to the internet. The calls from an ASE that go to the internet leave the VNet through the VIP assigned for the ASE. The public IP of this VIP is the source IP for all calls from the ASE that go to the internet. If the apps in your ASE make calls to resources in your VNet or across a VPN, the source IP is one of the IPs in the subnet used by your ASE. Because the ASE is within the VNet, it can also access resources within the VNet without any additional configuration. If the VNet is connected to your on-premises network, apps in your ASE also have access to resources there without additional configuration.
No Networking
Before we dive into these networking options, it’s worth knowing that you don’t have to use any of them. If all you want is a web application that is accessible to anyone on the internet, doesn’t need to talk to any service in a virtual network and doesn’t need to use anything behind a service endpoint, then you don’t need any extra complication. You can spin up a web app, and off you go.

Private Link
Private Link is in preview for Azure Web applications and provides a way to inject the ingress of your web application into your virtual network. It is important to note that this is purely about ingress. Using Private Link does not result in your web application being able to access resources in your vNet; it just means that things in your vNet can access the web app privately.

When you use private Link, your web application is injected into your virtual network and gets a private IP address. Resources in your virtual network can talk to this over the private IP, meaning you can now restrict egress from your network to your web app only, rather than having to allow it to all web apps. Using Private Link also means that you can disable access to your web application to only your Virtual network, making the ingress private. Previously this was only possible with an App Service Environment.

Private Link supports access over global vNet peering, VPN and ExpressRoute.
Outbound addresses
The worker VMs are broken down in large part by the App Service plans. The Free, Shared, Basic, Standard, and Premium plans all use the same worker VM type. The PremiumV2 plan uses another VM type. PremiumV3 uses yet another VM type. When you change the VM family, you get a different set of outbound addresses. If you scale from Standard to PremiumV2, your outbound addresses will change. If you scale from PremiumV2 to PremiumV3, your outbound addresses will change. In some older scale units, both the inbound and outbound addresses will change when you scale from Standard to PremiumV2.

#PaddyMaddy #cloudComputing #azuretutorial #microsoftazuretutorialforbeginners #azureforbeginners #azurebasics #microsoftazuretraining #Az900 #AZ500, #microsoftazurecertification, #AZ303 #300 #104 #paddyMaddy #azuretraining #AZ104