Muokkaa

Jaa

Create and use an Internal Load Balancer App Service Environment

  • Artikkeli

Important

This article is about App Service Environment v2, which is used with Isolated App Service plans. App Service Environment v1 and v2 are retired as of 31 August 2024. There's a new version of App Service Environment that is easier to use and runs on more powerful infrastructure. To learn more about the new version, start with the Introduction to the App Service Environment. If you're currently using App Service Environment v1, please follow the steps in this article to migrate to the new version.

As of 31 August 2024, Service Level Agreement (SLA) and Service Credits no longer apply for App Service Environment v1 and v2 workloads that continue to be in production since they are retired products. Decommissioning of the App Service Environment v1 and v2 hardware has begun, and this may affect the availability and performance of your apps and data.

You must complete migration to App Service Environment v3 immediately or your apps and resources may be deleted. We will attempt to auto-migrate any remaining App Service Environment v1 and v2 on a best-effort basis using the in-place migration feature, but Microsoft makes no claim or guarantees about application availability after auto-migration. You may need to perform manual configuration to complete the migration and to optimize your App Service plan SKU choice to meet your needs. If auto-migration isn't feasible, your resources and associated app data will be deleted. We strongly urge you to act now to avoid either of these extreme scenarios.

If you need additional time, we can offer a one-time 30-day grace period for you to complete your migration. For more information and to request this grace period, review the grace period overview, and then go to Azure portal and visit the Migration blade for each of your App Service Environments.

For the most up-to-date information on the App Service Environment v1/v2 retirement, see the App Service Environment v1 and v2 retirement update.

The Azure App Service Environment is a deployment of Azure App Service into a subnet in an Azure virtual network (VNet). There are two ways to deploy an App Service Environment (ASE):

  • With a VIP on an external IP address, often called an External ASE.
  • With a VIP on an internal IP address, often called an ILB ASE because the internal endpoint is an internal load balancer (ILB).

This article shows you how to create an ILB ASE. For an overview on the ASE, see Introduction to App Service Environments. To learn how to create an External ASE, see [Create an External ASE][MakeExternalASE].

Overview

You can deploy an ASE with an internet-accessible endpoint or with an IP address in your VNet. To set the IP address to a VNet address, the ASE must be deployed with an ILB. When you deploy your ASE with an ILB, you must provide the name of your ASE. The name of your ASE is used in the domain suffix for the apps in your ASE. The domain suffix for your ILB ASE is <ASE name>.appserviceenvironment.net. Apps that are made in an ILB ASE are not put in the public DNS.

Earlier versions of the ILB ASE required you to provide a domain suffix and a default certificate for HTTPS connections. The domain suffix is no longer collected at ILB ASE creation and a default certificate is also no longer collected. When you create an ILB ASE now, the default certificate is provided by Microsoft and is trusted by the browser. You are still able to set custom domain names on apps in your ASE and set certificates on those custom domain names.

With an ILB ASE, you can do things such as:

  • Host intranet applications securely in the cloud, which you access through a site-to-site or ExpressRoute.
  • Protect apps with a WAF device
  • Host apps in the cloud that aren't listed in public DNS servers.
  • Create internet-isolated back-end apps, which your front-end apps can securely integrate with.

Disabled functionality

There are some things that you can't do when you use an ILB ASE:

  • Use IP-based TLS/SSL binding.
  • Assign IP addresses to specific apps.
  • Buy and use a certificate with an app through the Azure portal. You can obtain certificates directly from a certificate authority and use them with your apps. You can't obtain them through the Azure portal.

Create an ILB ASE

To create an ILB ASE, see Create an ASE by using an Azure Resource Manager template.

Note

The App Service Environment name must be no more than 36 characters.

Create an app in an ILB ASE

You create an app in an ILB ASE in the same way that you create an app in an ASE normally.

  1. In the Azure portal, select Create a resource > Web > Web App.

  2. Enter the name of the app.

  3. Select the subscription.

  4. Select or create a resource group.

  5. Select your Publish, Runtime Stack, and Operating System.

  6. Select a location where the location is an existing ILB ASE.

  7. Select or create an App Service plan.

  8. Select Review and Create then select Create when you are ready.

Web jobs, Functions and the ILB ASE

Both Functions and web jobs are supported on an ILB ASE but for the portal to work with them, you must have network access to the SCM site. This means your browser must either be on a host that is either in or connected to the virtual network. If your ILB ASE has a domain name that does not end in appserviceenvironment.net, you will need to get your browser to trust the HTTPS certificate being used by your scm site.

DNS configuration

When you use an External ASE, apps made in your ASE are registered with Azure DNS. There are no additional steps then in an External ASE for your apps to be publicly available. With an ILB ASE, you must manage your own DNS. You can do this in your own DNS server or with Azure DNS private zones.

To configure DNS in your own DNS server with your ILB ASE:

  1. create a zone for <ASE name>.appserviceenvironment.net
  2. create an A record in that zone that points * to the ILB IP address
  3. create an A record in that zone that points @ to the ILB IP address
  4. create a zone in <ASE name>.appserviceenvironment.net named scm
  5. create an A record in the scm zone that points * to the ILB IP address

To configure DNS in Azure DNS Private zones:

  1. create an Azure DNS private zone named <ASE name>.appserviceenvironment.net
  2. create an A record in that zone that points * to the ILB IP address
  3. create an A record in that zone that points @ to the ILB IP address
  4. create an A record in that zone that points *.scm to the ILB IP address

The DNS settings for your ASE default domain suffix do not restrict your apps to only being accessible by those names. You can set a custom domain name without any validation on your apps in an ILB ASE. If you then want to create a zone named contoso.net, you could do so and point it to the ILB IP address. The custom domain name works for app requests but doesn't for the scm site. The scm site is only available at <appname>.scm.<asename>.appserviceenvironment.net.

The zone named .<asename>.appserviceenvironment.net is globally unique. Before May 2019, customers were able to specify the domain suffix of the ILB ASE. If you wanted to use .contoso.com for the domain suffix, you were able do so and that would include the scm site. There were challenges with that model including; managing the default TLS/SSL certificate, lack of single sign-on with the scm site, and the requirement to use a wildcard certificate. The ILB ASE default certificate upgrade process was also disruptive and caused application restarts. To solve these problems, the ILB ASE behavior was changed to use a domain suffix based on the name of the ASE and with a Microsoft owned suffix. The change to the ILB ASE behavior only affects ILB ASEs made after May 2019. Pre-existing ILB ASEs must still manage the default certificate of the ASE and their DNS configuration.

Publish with an ILB ASE

For every app that's created, there are two endpoints. In an ILB ASE, you have <app name>.<ILB ASE Domain> and <app name>.scm.<ILB ASE Domain>.

The SCM site name takes you to the Kudu console, called the Advanced portal, within the Azure portal. The Kudu console lets you view environment variables, explore the disk, use a console, and much more. For more information, see Kudu console for Azure App Service.

Internet-based CI systems, such as GitHub and Azure DevOps, will still work with an ILB ASE if the build agent is internet accessible and on the same network as ILB ASE. So in case of Azure DevOps, if the build agent is created on the same VNET as ILB ASE (different subnet is fine), it will be able to pull code from Azure DevOps git and deploy to ILB ASE. If you don't want to create your own build agent, you need to use a CI system that uses a pull model, such as Dropbox.

The publishing endpoints for apps in an ILB ASE use the domain that the ILB ASE was created with. This domain appears in the app's publishing profile and in the app's portal blade (Overview > Essentials and also Properties). If you have an ILB ASE with the domain suffix <ASE name>.appserviceenvironment.net, and an app named mytest, use mytest.<ASE name>.appserviceenvironment.net for FTP and mytest.scm.contoso.net for MSDeploy deployment.

Configure an ILB ASE with a WAF device

You can combine a web application firewall (WAF) device with your ILB ASE to only expose the apps that you want to the internet and keep the rest only accessible from in the VNet. This enables you to build secure multi-tier applications among other things.

To learn more about how to configure your ILB ASE with a WAF device, see Configure a web application firewall with your App Service environment. This article shows how to use a Barracuda virtual appliance with your ASE. Another option is to use Azure Application Gateway. Application Gateway uses the OWASP core rules to secure any applications placed behind it. For more information about Application Gateway, see Introduction to the Azure web application firewall.

ILB ASEs made before May 2019

ILB ASEs that were made before May 2019 required you to set the domain suffix during ASE creation. They also required you to upload a default certificate that was based on that domain suffix. Also, with an older ILB ASE you can't perform single sign-on to the Kudu console with apps in that ILB ASE. When configuring DNS for an older ILB ASE, you need to set the wildcard A record in a zone that matches to your domain suffix. Creating or changing ILB ASE with custom domain suffix requires you to use Azure Resource Manager templates and an api version prior to 2019. Last support api version is 2018-11-01.

Get started