Skip to content
eSHARS Operations

INFRA-0002: Dedicated Subnet for App Service VNet Integration

Status

Accepted

Date

2026-03-25

Context

Azure App Service VNet Integration requires a subnet delegated to Microsoft.Web/serverFarms. When implementing INFRA-0001, we needed to determine what subnet the App Service should use.

The nonprod VNet (rg-eshars-nonprod, 10.1.0.0/16) had existing subnets:

  • default (10.1.0.0/24) — hosting VMs including the SSRS VM (vm-sql16-np at 10.1.0.4) and App Gateway
  • sn-agw-eshars-np — dedicated to App Gateway

The prod VNet (rg-eshars-prod, 10.0.0.0/16) had:

  • default (10.0.0.0/24) — hosting VMs including the SSRS VM (vm-ssrs16-prod at 10.0.0.5)
  • AzureBastionSubnet (10.0.1.0/26)

Decision

Create a new, dedicated subnet for App Service VNet integration in each environment rather than reusing an existing subnet.

  • Nonprod: sn-webapp-eshars-np at 10.1.3.0/24
  • Prod: sn-webapp-eshars-prod at 10.0.3.0/24
  • Both delegated exclusively to Microsoft.Web/serverFarms

Alternatives Considered

Alternative 1: Reuse the default subnet

Place the App Service delegation on the existing default subnet alongside the VMs.

Rejected: Azure does not allow a subnet with existing resources to be delegated to Microsoft.Web/serverFarms. The delegation would require the subnet to be empty first, which would mean migrating or deleting the existing VMs. High disruption, high risk.

Alternative 2: Reuse the App Gateway subnet

Share sn-agw-eshars-np with the App Gateway.

Rejected: Subnets delegated to Microsoft.Web/serverFarms cannot host other resource types. App Gateway requires its own subnet and cannot share with delegated subnets.

Consequences

Positive

  • Clean separation of concerns — VMs, App Gateway, and App Services each have their own subnet
  • Delegation is unambiguous — no resource conflicts
  • Future App Services or slots can use the same subnet without changes

Negative

  • Consumes additional address space. Chose /24 (254 usable addresses) which is more than needed now, but provides room for expansion without subnet changes.

Neutral

  • Subnet size choice (10.1.3.0/24 / 10.0.3.0/24) was selected to leave address ranges 10.1.1.0/24, 10.1.2.0/24, 10.0.2.0/24 available for future use. Avoids backing into a corner if more subnets are needed later.