7.3 Network Integration for App Service, Functions, App Service Environment & SQL Managed Instance

Two Directions, Two Different Controls

The recurring exam trap in this objective is mixing up inbound and outbound. For App Service and Azure Functions they are governed by completely different features:

A private endpoint on a web app does not change where the app’s outbound calls come from, and VNet integration does not stop anyone on the internet from reaching the app. Real hardening needs both.

---

Regional Virtual Network Integration

Requirements and behaviours to memorize:

• The integration subnet must be empty and delegated to Microsoft.Web/serverFarms. It cannot host other resources.
• Size it generously — the platform consumes addresses during scale-out and slot swaps. A /26 is the practical minimum for anything beyond a lab.
• By default only RFC 1918 private ranges and service endpoint traffic are routed into the VNet. Setting vnetRouteAllEnabled = true (historically the WEBSITE_VNET_ROUTE_ALL=1 app setting) sends everything, including internet-bound calls, through the VNet so an Azure Firewall or NVA can inspect and log it. That single setting is what makes egress filtering for App Service real.
• Plan support: VNet integration requires Basic, Standard, Premium, or Isolated App Service plans. For Azure Functions it requires Premium (Elastic Premium), Dedicated, or Flex Consumption; classic Consumption plan functions cannot integrate with a virtual network, which is a common scenario discriminator.

The SCM site is a separate attack surface

Every App Service has a companion SCM/Kudu site (<app>.scm.azurewebsites.net) used for deployment, the console, and log streaming. It has its own access restrictions, and by default they can be inherited from the main site or set independently. Locking the main site while leaving Kudu open to the internet is a real-world finding — and an exam distractor. When you create a private endpoint for the app, the SCM site is reachable over the same private endpoint.

---

App Service Environment v3

An App Service Environment (ASE) v3 is a single-tenant deployment of App Service injected into your own virtual network on dedicated infrastructure.

Key security properties:

• The ASE subnet is delegated to Microsoft.Web/hostingEnvironments and must be dedicated to the ASE. Microsoft recommends a /24.
• An ILB ASE needs a private DNS zone for its domain so clients resolve the internal address, and a certificate that matches that domain.
• Outbound traffic can be forced through Azure Firewall with a route table on the ASE subnet, subject to the platform dependencies the ASE requires.
• NSGs on the ASE subnet must permit the platform’s required management traffic; blocking it makes the ASE unhealthy rather than merely restricted.

Choose an ILB ASE when the requirement is "no public endpoint and dedicated compute"; choose a multi-tenant plan with a private endpoint when the requirement is only "no public endpoint" — it is far cheaper.

---

Azure SQL Managed Instance Networking

SQL Managed Instance (SQL MI) is not a public PaaS endpoint with an optional private endpoint. It is injected directly into a subnet of your virtual network, which changes how you secure it.

Mandatory conditions:

• The subnet is delegated to Microsoft.Sql/managedInstances and must contain no other resource type.
• Size it for the deployment plus growth — a /27 is the minimum, and larger is recommended because address consumption scales with instance count and updates.
• The subnet requires a route table and an NSG that preserve the mandatory inbound and outbound rules the service-aided subnet configuration creates for management traffic. Azure will maintain these for you under service-aided configuration; deleting or overriding them puts the instance into a failed state. This is also why AVNM security admin rules skip virtual networks containing SQL MI.
• You may add your own rules around the mandatory ones — for example, denying inbound 1433 from everything except the application subnet.

Public endpoint: SQL MI can optionally expose a public endpoint on port 3342 (the private VNet-local endpoint remains 1433). The public endpoint is disabled by default and, when the scenario says "management access from outside the VNet must not be possible", the answer is to leave it disabled and reach the instance through VPN, ExpressRoute, or a jump host. If it must be enabled, restrict it with an NSG rule allowing only known source prefixes and enforce Microsoft Entra-only authentication.

For connectivity, SQL MI supports Proxy and Redirect connection types. Redirect gives lower latency by connecting the client straight to the node after the initial handshake, but requires ports 11000–11999 to be open from the client subnet; Proxy uses only 1433 but adds a hop. Choosing Redirect without opening that port range is a classic troubleshooting scenario.