How do you configure Azure App Service Environment for an ASP.NET Core API?

Question

0

Isolating Your Backend in Azure

Running a public-facing ASP.NET Core API on shared infrastructure invites unnecessary risk. A dedicated App Service Environment (ASE) gives you isolated compute and networking inside Azure's backbone, which is exactly what compliance-heavy workloads need.

Prerequisites and Deployment

You will need an existing Azure subscription, an active App Service plan, and the Azure CLI or portal access. The ASE itself is a separate resource group that must be provisioned before you attach any app to it.

// Create the ASE resource group and environment using the Azure CLI.
// This command provisions the isolated virtual network and dedicated App Service plan.
var ase = await Azure.Resources.CreateAppServiceEnvironmentAsync(
    resourceGroupName: "ase-rg",
    name: "my-ase",
    location: "East US",
    sku: new AppServiceEnvironmentSku(SkuName.StandardS1, SkuTier.Standard),
    subnetResourceId: "/subscriptions/.../subnets/ase-subnet");

// Configure the web app to run inside the ASE by linking its App Service Plan.
var webApp = await Azure.WebApps.Define(webAppName: "api-ase")
    .WithRegion(Region.USEast)
    .WithExistingResourceGroup("ase-rg")
    .WithAppServicePlan(planName: "ase-plan")
    .CreateAsync();

After deployment, verify connectivity by curling the app's private endpoint from a VM inside the same subnet. If the request fails, check the network rules and the ASE's outbound IP restrictions.

1 Answer

Write Your Answer

Answer 1

An Azure App Service Environment (ASE) gives your App Service apps an isolated, VNet-hosted environment. For an ASP.NET Core API, the main decisions are the ASE’s network exposure, its subnet and DNS, and the App Service plan and runtime you deploy into it.

Set up the environment

Choose the ASE version and access model. For a new deployment, use ASE v3. Choose an internal load balancer (ILB) ASE when the API should be reachable only from your VNet or connected networks. Choose an external ASE when it needs a public ingress path. You can still put an Application Gateway or another gateway in front of either design.
Prepare a dedicated ASE subnet. Create a subnet used only by the ASE, delegate it to Microsoft.Web/hostingEnvironments, and allow enough address space for the environment and its scale needs. A /24 is a common recommended starting size. Apply NSG rules and routes carefully: blocking platform-required traffic can prevent the ASE or apps from operating correctly.
Create the ASE in that VNet and subnet. In the Azure portal, create an App Service Environment, select the VNet and subnet, and choose the ILB or external configuration. Review the current ASE v3 networking requirements for the region and features you plan to use before locking down NSGs, routes, or DNS.
Create an Isolated v2 App Service plan in the ASE, then create the Web App for your API in that plan. Select the matching operating system and configure the ASP.NET Core runtime version, or publish the API as a container if that better fits your deployment process.

Make the API reachable

With an ILB ASE, configure private DNS records for the app hostname so clients on the permitted networks resolve it to the ASE’s private address. If you use a custom domain, bind the hostname and its TLS certificate to the app. For public access, put an approved ingress service in front of the API or use the external ASE’s public endpoint, then restrict access according to your security model.

For outbound calls, check that the app can resolve names and reach the services it depends on, such as databases, identity providers, and monitoring endpoints. If the VNet uses custom DNS, user-defined routes, or firewall egress, test those paths from the deployed app rather than assuming they work because the app starts.

Deploy and validate

Deploy the API with your usual method—such as a CI/CD pipeline, ZIP deployment, or a container registry. Configure secrets and environment-specific values through App Service settings or a managed secret store, not in source control. Add a health-check endpoint and enable App Service health checks so unhealthy instances can be identified as the plan scales.

Before production, test hostname resolution and HTTPS from the same network your clients will use, confirm required outbound dependencies, and verify scaling and deployment behavior. An ASE does not require special ASP.NET Core code; the differences are primarily in hosting, networking, and access control.