Networking Best Practices¶

Networking design in Azure App Service is primarily about controlling direction and trust boundaries: private inbound paths, predictable outbound paths, and reliable DNS behavior across those paths.

Why This Matters¶

Networking is the first control plane an App Service workload exposes to the outside world, and it is also the layer that most often fails silently in production. Getting these decisions right up front is materially cheaper than retrofitting them:

• Outbound IPs can change under scale operations, region moves, or SKU changes — hard-coded allowlists break with no explicit warning.
• Private Endpoint and VNet Integration solve different problems (inbound privacy vs outbound reachability); confusing them leads to either data-plane exposure or broken egress.
• SNAT port exhaustion presents as intermittent connectivity issues that are indistinguishable from remote-service faults without the right diagnostic signals in place.
• DNS resolution paths differ across shared-plan, VNet-integrated, and Private Endpoint topologies; a stale mental model causes reproducible-but-unexplained lookup failures.

This document consolidates the concrete design and validation practices that keep those failure modes from becoming incidents.

Prerequisites¶

• Existing Web App and App Service Plan
• Existing virtual network and required subnets
• Permissions to manage App Service, networking, and private DNS resources
• Variables set:
  • RG
  • APP_NAME
  • VNET_NAME
  • INTEGRATION_SUBNET_NAME
  • PRIVATE_ENDPOINT_SUBNET_NAME

Recommended Practices¶

Networking goals for production¶

Use App Service networking to achieve four outcomes:

1. Inbound exposure is intentionally restricted.
2. Outbound traffic to private dependencies is deterministic.
3. SNAT behavior is managed under concurrency.
4. DNS resolution aligns with your private topology.

graph TD
    Internet[Internet Users] --> WAF[WAF or Reverse Proxy]
    WAF --> PE[Private Endpoint for App Service]

    subgraph VNet[Azure Virtual Network]
        subgraph PE_SUBNET[Private Endpoint Subnet]
            PE
        end
        subgraph APP_SUBNET[VNet Integration Subnet]
            VNETINT[VNet Integration]
        end
        subgraph DEP_SUBNET[Private Dependency Subnet]
            SQL[(Azure SQL Private Endpoint)]
            REDIS[(Azure Cache Private Endpoint)]
            API[Internal API]
        end
        DNS[Private DNS Zones]
    end

    App[Azure App Service App] --> VNETINT
    VNETINT --> SQL
    VNETINT --> REDIS
    VNETINT --> API
    App --> DNS
    DNS --> PE
    DNS --> SQL
    DNS --> REDIS

1) Use VNet Integration for outbound traffic¶

VNet Integration is the primary App Service feature for private outbound connectivity.

Use it when your app must reach:

• Private endpoints for PaaS dependencies
• Internal services reachable through peering/express routes
• Internal DNS zones and split-horizon naming schemes

Configure integration:

az webapp vnet-integration add \
  --resource-group $RG \
  --name $APP_NAME \
  --vnet $VNET_NAME \
  --subnet $INTEGRATION_SUBNET_NAME \
  --output json

Route all app outbound through VNet path where required:

az webapp config appsettings set \
  --resource-group $RG \
  --name $APP_NAME \
  --settings WEBSITE_VNET_ROUTE_ALL=1 \
  --output json

Validate integration state:

az webapp vnet-integration list \
  --resource-group $RG \
  --name $APP_NAME \
  --output table

2) Use Private Endpoint for inbound privacy¶

Private Endpoint is the standard pattern for private inbound access to an App Service app.

Use it when:

• App must not be publicly reachable
• Access should originate only from approved VNets
• You need private IP resolution for app endpoints

Create private endpoint:

APP_RESOURCE_ID=$(az webapp show \
  --resource-group $RG \
  --name $APP_NAME \
  --query id \
  --output tsv)

az network private-endpoint create \
  --resource-group $RG \
  --name "pe-$APP_NAME" \
  --vnet-name $VNET_NAME \
  --subnet $PRIVATE_ENDPOINT_SUBNET_NAME \
  --private-connection-resource-id $APP_RESOURCE_ID \
  --group-id sites \
  --connection-name "pec-$APP_NAME" \
  --output json

Check connection status:

az network private-endpoint show \
  --resource-group $RG \
  --name "pe-$APP_NAME" \
  --query "{state:provisioningState,connection:privateLinkServiceConnections[0].privateLinkServiceConnectionState.status}" \
  --output json

3) Design for SNAT port efficiency¶

SNAT exhaustion is a frequent cause of intermittent outbound failures under concurrency.

Use these patterns to reduce SNAT pressure:

• Connection pooling for database and HTTP clients
• Async I/O patterns to avoid thread starvation and long-held sockets
• Reuse HTTP clients instead of creating per-request clients
• Bounded retries with jitter to avoid retry storms
• Short dependency timeouts to free sockets faster

Practical implementation guidance:

4) Own DNS behavior in private topologies¶

Private networking fails most often at DNS, not at routing.

For App Service private endpoint scenarios:

1. Configure privatelink.azurewebsites.net private DNS zone.
2. Link the zone to the correct VNets.
3. Ensure clients resolve app hostname to private IP.
4. Validate dependency hostnames resolve to private addresses where expected.

Create and link private DNS zone:

az network private-dns zone create \
  --resource-group $RG \
  --name privatelink.azurewebsites.net \
  --output json

az network private-dns link vnet create \
  --resource-group $RG \
  --zone-name privatelink.azurewebsites.net \
  --name "link-$VNET_NAME" \
  --virtual-network $VNET_NAME \
  --registration-enabled false \
  --output json

Validate DNS from private network context:

nslookup "$APP_NAME.azurewebsites.net"

Expected: private IP address in your VNet range.

5) Hybrid Connections vs VNet Integration¶

VNet Integration provides outbound private connectivity. Private Endpoint provides inbound private access. They solve different directions of traffic flow.

Decision guideline:

• Choose Hybrid Connections for a narrow, transitional requirement.
• Choose VNet Integration for strategic private networking.

flowchart TD
    A[Need private outbound connectivity?] --> B{Only a few specific host:port endpoints?}
    B -->|Yes| C[Consider Hybrid Connections]
    B -->|No| D[Use VNet Integration]
    C --> E{Long-term enterprise private architecture?}
    E -->|Yes| D
    E -->|No| F[Keep Hybrid Connections with explicit limits]
    D --> G[Plan DNS, routes, and subnet capacity]

6) Inbound control layering¶

Even with private endpoints, define layered inbound control:

• Edge control (WAF/reverse proxy)
• App access restrictions for explicit allow/deny where applicable
• Private endpoint approval workflow
• Monitoring for unauthorized or unexpected requests

Example access restriction rule:

az webapp config access-restriction add \
  --resource-group $RG \
  --name $APP_NAME \
  --rule-name AllowCorp \
  --action Allow \
  --ip-address 203.0.113.0/24 \
  --priority 100 \
  --output json

Portal view: Access Restrictions blade¶

Purpose: Show the inbound access state before any access restriction is added.

Look for: Public network access shows Enabled (using default behavior), Unmatched rule action is Allow, and the only rule is Allow all with priority 2147483647.

Expected result: With no custom rules, the displayed default-endpoint policy admits any source until you add rules or disable public network access. This is a configuration reading, not a measured reachability test.

The Access Restrictions blade is where the layered inbound model described above is enforced. The visible default state shows the two most important behaviors this guide warns against assuming away: Public network access is Enabled (using default behavior), which is the portal wording for an unset property whose documented default is enabled when no private endpoint exists, and the implicit Allow all rule at priority 2147483647 with Unmatched rule action: Allow means that without any explicit rules the main-site policy admits every source on the default endpoint. This displays configuration; it does not show whether any client can reach the app. The Main site and Advanced tool site tabs separate runtime traffic from SCM/Kudu management traffic — both must be hardened. After running the az webapp config access-restriction add command above with priority 100, the new AllowCorp rule should appear above the default Allow all row, and the Unmatched rule action should be flipped to Deny to convert the implicit allow-by-default posture into an explicit deny-by-default posture.

7) Troubleshooting patterns to pre-plan¶

Include these commands in runbooks:

az webapp show \
  --resource-group $RG \
  --name $APP_NAME \
  --query "{defaultHostName:defaultHostName,outboundIpAddresses:outboundIpAddresses}" \
  --output json

az network private-endpoint list \
  --resource-group $RG \
  --output table

az network private-dns record-set a list \
  --resource-group $RG \
  --zone-name privatelink.azurewebsites.net \
  --output table

8) Manage IP address changes proactively¶

App Service IP addresses are not static. Treating them as fixed causes allowlist drift, broken firewall rules, and silent connectivity failures after scale events.

Outbound IP allowlist strategy¶

Two CLI fields exist for outbound IPs — use the right one:

Query both to understand current vs. potential exposure:

az webapp show \
    --resource-group "$RG" \
    --name "$APP_NAME" \
    --query "{active:outboundIpAddresses,possible:possibleOutboundIpAddresses}" \
    --output json

Example output (PII masked):

{
  "active": "<13 outbound IPv4 addresses; run the command above to retrieve current values>",
  "possible": "<31 additional outbound IPv4 addresses; the union of active + possible is the full allowlist candidate set>"
}

Outbound IP behavior under VNet Integration¶

With route-all enabled (formerly WEBSITE_VNET_ROUTE_ALL=1, now exposed as a platform setting through the portal or CLI), all outbound traffic is routed through the VNet. The source IP remains one of the app's standard outbound IPs unless the integration subnet uses a NAT Gateway or forces traffic through a firewall or NVA, in which case the egress IP becomes that device's IP.

Verify after enabling:

# Confirm VNet integration is active
az webapp vnet-integration list \
    --resource-group "$RG" \
    --name "$APP_NAME" \
    --output table

# Confirm route-all setting
az webapp config appsettings list \
    --resource-group "$RG" \
    --name "$APP_NAME" \
    --query "[?name=='WEBSITE_VNET_ROUTE_ALL']" \
    --output table

Location       Name              ResourceGroup     VnetResourceId
-------------  ----------------  ----------------  -------------------------------------------------
Korea Central  snet-integration  rg-<masked>       .../virtualNetworks/vnet-<masked>/subnets/snet-integration

Name                    Value    SlotSetting
----------------------  -------  -------------
WEBSITE_VNET_ROUTE_ALL  1        False

Inbound IP and Private Endpoint behavior¶

Creating a Private Endpoint assigns a private IP from the endpoint subnet. Whether the default (public) inbound endpoint stays reachable depends on the raw publicNetworkAccess value, whether a private endpoint exists, and the main and SCM access restrictions: when the property is unset and a private endpoint exists the documented default is disabled, while an explicit Enabled value keeps it on. For private-only inbound access, set and verify publicNetworkAccess deliberately. Site access restrictions are not evaluated for private endpoint traffic, so they constrain only the default endpoint while it stays enabled. See Private Endpoint and Access Restriction Decisions.

Query the current inbound IP:

az webapp show \
    --resource-group "$RG" \
    --name "$APP_NAME" \
    --query "inboundIpAddress" \
    --output tsv

Query the Private Endpoint's assigned private IP:

az network private-endpoint show \
    --resource-group "$RG" \
    --name "pe-$APP_NAME" \
    --query "customDnsConfigs[0].ipAddresses" \
    --output json

Example output:

[
  "192.0.2.4"
]

Validate that DNS resolves to the private IP from within the VNet:

nslookup "$APP_NAME.azurewebsites.net"

When run from a VM inside the VNet with the private DNS zone configured, the response resolves to the Private Endpoint IP (for example, 192.0.2.4) instead of the public IP. The Private Endpoint IP was confirmed via az network private-endpoint show (koreacentral, 2026-05-01) and sanitized for publication.

az webapp config access-restriction add \
    --resource-group "$RG" \
    --name "$APP_NAME" \
    --rule-name "DenyPublic" \
    --action Deny \
    --ip-address 0.0.0.0/0 \
    --priority 65000 \
    --output json

9) Choose the right outbound path to Azure Storage¶

When your app connects to Azure Storage (Blob, Files, Queue, Table) and the storage account has a firewall, pick one of three supported patterns and configure all four connectivity layers — DNS, routing, storage firewall, and data-plane authorization — deliberately.

Common Mistakes / Anti-Patterns¶

• Enabling VNet Integration but forgetting DNS design.
• Creating private endpoints without private DNS zone links.
• Assuming private endpoint also controls outbound traffic.
• Treating intermittent timeouts as dependency faults without SNAT analysis.
• Using Hybrid Connections as a permanent architecture without review.

Validation Checklist¶

Before production cutover:

• [ ] App can resolve private dependency FQDNs correctly.
• [ ] App can connect to dependency private endpoints.
• [ ] Connection pooling is enabled and tuned.
• [ ] Dependency timeouts are explicit and bounded.
• [ ] Retry policy prevents connection storms.
• [ ] NAT/SNAT behavior is observed under peak load tests.

Advanced Topics¶

• Use Azure Front Door or Application Gateway with WAF for edge security plus private origin reachability.
• Add synthetic connectivity probes from inside trusted networks.
• Build dependency maps with expected DNS resolution source and fallback behavior.
• Track connection reuse metrics and tune pooling values with load tests.

See Also¶

• Best Practices
• Production Baseline
• Security Best Practices
• Operations - Networking
• App Service to Azure Storage connectivity

Sources¶

• App Service networking features
• Integrate App Service with virtual networks
• Use private endpoints for App Service apps
• Hybrid Connections in App Service
• Azure DNS private zones
• Configure Azure Storage firewalls and virtual networks
• Restrictions for IP network rules