Azure App Service Deployment Scenarios¶

Understanding the relationship between App Service SKUs and deployment architecture is essential for security, performance, and cost-effectiveness. This guide breaks down common scenarios based on networking requirements and tier capabilities.

Scenario Overview¶

The choice of deployment scenario typically follows a progression of networking complexity and isolation requirements.

graph TD
    Start[Choose Deployment Scenario] --> FreeBasic[Scenario A: Public Basic]
    FreeBasic --> |Add VNet Integration| StdPrem[Scenario B: VNet Integrated]
    StdPrem --> |Full Isolation| Isolated[Scenario C: Isolated ASE]

    subgraph "Scenario A"
    FreeBasic[Free/Basic Tiers]
    end

    subgraph "Scenario B"
    StdPrem[Standard/Premium Tiers]
    end

    subgraph "Scenario C"
    Isolated[Isolated v2/v3 Tiers]
    end

Matrix A: Networking and Security by SKU¶

Matrix B: Deployment Methods by SKU¶

Portal view: Deployment slots¶

The Deployment slots blade turns release strategy into concrete routing controls. Separate Production and staging rows, each with its own App URL, Status, and Traffic %, show that slots are distinct runtime targets even though they live under one app and plan boundary. The 70% / 30% split and the Swap button map directly to canary and cutover scenarios: you can shift live traffic gradually, then promote the staged build into production once behavior is verified.

Scenario A: Public-Only (Free/Shared tiers)¶

Best for early development, personal projects, or static-like sites where VNet integration and private ingress are not required.

graph TD
    User((User)) -->|HTTPS| PublicEndpoint[App Service Public IP]
    Developer((Developer)) -->|Push| GitHub[GitHub Actions]
    GitHub -->|ZIP Deploy| Kudu[Kudu SCM Site]
    Kudu -->|Deploy| AppInstance[App Service Instance]
    AppInstance -->|Outbound| Internet((Public Internet))

Key Characteristics¶

• Networking: All traffic enters via a shared public IP address.
• Security: Access control is limited to IP restrictions (allow/deny lists).
• SCM Access: The Kudu management site is publicly accessible. Warning: This management interface is exposed to the internet and should be secured with strong credentials or disabled if not in use.

Deployment Example (ZIP Deploy)¶

az webapp deployment source config-zip \
    --resource-group "myResourceGroup" \
    --name "myWebApp" \
    --src "project.zip"

Scenario B: VNet Integrated & Private Inbound (Basic/Standard/Premium)¶

The standard for production enterprise applications. This scenario allows the App Service to reach resources inside a Virtual Network and supports private ingress via Private Endpoints.

graph TD
    User((User)) -->|Private Link| PrivEnd[Private Endpoint]
    subgraph "Azure Virtual Network"
        PrivEnd --> AppService[App Service]
        AppService -->|Regional VNet Integration| Subnet[Integration Subnet]
        Subnet --> SQL[Azure SQL / Private Resource]
    end
    Developer((Developer)) -->|VPN/ExpressRoute| SCM[SCM Private Endpoint]
    SCM --> AppService

Key Characteristics¶

• Regional VNet Integration: Allows the app to access resources in a VNet (like SQL databases or Key Vaults with private endpoints).
• Private Endpoints: Provides a private IP for ingress. Note: Adding a private endpoint does not automatically disable the public endpoint; you must explicitly disable public network access in the Networking settings to achieve full isolation.
• Outbound Traffic: Can be routed through a NAT Gateway or Firewall for fixed outbound IPs (requires NAT Gateway on the integration subnet).

Enabling VNet Integration¶

az webapp vnet-integration add \
    --resource-group "myResourceGroup" \
    --name "myWebApp" \
    --vnet "myVNet" \
    --subnet "integrationSubnet"

Scenario C: Isolated (ASE)¶

The highest level of isolation. The entire App Service Environment (ASE) runs within your Virtual Network on dedicated hardware.

graph TD
    subgraph "Azure Virtual Network (ASE)"
        ILB[Internal Load Balancer] --> WebApps[App Service Instances]
        WebApps --> DataSubnet[Data/Backend Subnet]
    end
    Gateway[Application Gateway / Front Door] -->|Private| ILB

Key Characteristics¶

• Single Tenant: No shared infrastructure with other customers.
• Internal Load Balancer (ILB): Can be configured to have no public internet footprint at all.
• Scalability: Supports much larger scale-out compared to multi-tenant tiers.

Pre-Deployment Checklist¶

1. Verify SKU Compatibility: Ensure the chosen tier supports VNet integration (Basic+) or Private Endpoints (Basic+).
2. Subnet Delegation: The integration subnet must be delegated to Microsoft.Web/serverFarms and must be empty before configuration.
3. App Settings (Code Deploy): For ZIP or package-based deployments, configure WEBSITE_RUN_FROM_PACKAGE=1 for faster startup and atomic swaps only when the runtime supports it. On Linux code apps, it is supported for Node.js and .NET, but not for Python or Java. (Not applicable for custom containers).
4. DNS Resolution: Ensure private DNS zones (privatelink.azurewebsites.net) are linked to your VNet when using Private Endpoints.

See Also¶

• Networking features overview
• Zero-downtime deployments with slots
• Security baseline for App Service

Sources¶

• Microsoft Learn: App Service Environment Overview
• Microsoft Learn: VNet Integration
• Microsoft Learn: Deploy from Package
• Microsoft Learn: Continuous Deployment