VNet-Integrated Deployment Support for AzUrlShortener Container App via Private Endpoint

Question

We want to deploy the AzUrlShortener container app in the production environment with VNet integration, so that it can access resources (Storage Account) through Private Endpoints with public access disabled.

Are there any changes required in the existing Bicep deployment template to support VNet integration for the Container App Environment, or can this configuration be handled after deployment in portal only?

Answer 1

Hello Sharma, Ritika,

To get your AzUrlShortener Container App talking to a Storage Account over private endpoints with public access off, you’ll need to bake the VNet integration into your Container App Environment at deployment time. You can’t retrofit a completely new VNet into an existing environment via the portal alone. Here’s what you should do:

1. Use a workload-profiles Container App Environment • Consumption-only environments don’t support VNet integration – make sure you’re on a “Workload profiles” (dedicated) plan.
2. Update your Bicep template on the Microsoft.App/managedEnvironments resource to include vnetConfiguration and disable public access:

resource env 'Microsoft.App/managedEnvironments@2023-06-01' = {
  name: envName
  location: location
  properties: {
    // Disable public network access so only your VNet + private endpoints can talk to this env
    publicNetworkAccess: 'Disabled'
    // VNet integration settings
    vnetConfiguration: {
      infrastructureSubnetId: resourceId('MyRg','Microsoft.Network/virtualNetworks/subnets','myVnet','infrastructure-subnet')
      appSubnetIds: [
        resourceId('MyRg','Microsoft.Network/virtualNetworks/subnets','myVnet','app-subnet')
      ]
    }
    // Optional: internal load balancer if you want fully internal ingress
    internalLoadBalancer: {
      enabled: true
    }
  }
}

1. Deploy that updated Bicep. This creates an environment that’s already wired into your VNet subnets.
2. In the same or a follow-up Bicep/CLI/template, deploy your container app into that environment.
3. Configure the Storage Account with a private endpoint in the same VNet, disable its public access, and ensure your VNet’s private DNS zone is resolving the storage account FQDN.

After doing the above, your AzUrlShortener app will be able to reach the storage account over the private link, and nothing externally will be exposed.

Follow-ups if you hit any snags: • Are you already on a workload-profiles environment or on consumption-only? • Can you share your current Bicep snippet for the managedEnvironment resource? • How have you set up your subnets / NSG – do you have the required allow-list for Azure platform traffic? • Have you configured the private DNS zone and linked it to your VNet so that the storage account’s privatelink zone resolves?

Reference list • Provide a virtual network to an Azure Container Apps environment (Bicep) – https://aka.ms/container-apps-vnet-custom-bicep

• How to use private endpoints with Container Apps – https://aka.ms/container-apps-private-endpoint

• Securing a custom VNet in Azure Container Apps – https://aka.ms/container-apps-firewall-integration

• Integrate your App Service with a VNet (Windows Containers guidance) – https://aka.ms/appservice-vnet-integration

Networking in Azure Container Apps environment

Networking in Azure Container Apps environment

Please accept as answer and do a Thumbs-up to upvote this response if you are satisfied with the community help. Your upvote will be beneficial for the community users facing similar issues.

 

Answer 2

VNet integration and private endpoint support for Azure Container Apps environments is determined at environment creation time and by the environment type, so changes are required in the Bicep template rather than only in the portal after deployment.

Key points from the context:

1. Environment type and VNet requirements
   • Private endpoints are only supported for workload profile environments (the default for new environments).
   • When using an existing VNet, a dedicated subnet must be provided for the Container Apps environment, and for workload profiles the minimum subnet size is /27.
   • Once an environment is created with either the default Azure network or an existing VNet, the network type cannot be changed later.
2. Private endpoints and disabled public access
   • To use a private endpoint on the Container Apps environment, public network access must be disabled on that environment.
   • This can be done via CLI or portal, but in an IaC scenario it should be expressed in Bicep (for example, by updating the environment with --public-network-access Disabled as shown in the CLI flow).
3. VNet and private endpoint setup
   • For the scenario where the container app must reach a Storage Account via private endpoint with public access disabled, the infrastructure must include:
     • A VNet with appropriate subnets (one for the Container Apps environment, and one for the storage private endpoint if following the deployment-script example).
     • A Storage Account with public network access disabled.
     • A private endpoint for the Storage Account in the VNet.
     • A private DNS zone for the Storage Account’s private endpoint and a link to the VNet.
4. What must be in Bicep vs. portal
   • Because the Container Apps environment’s VNet integration and subnet and the environment type are fixed at creation, these must be modeled in the Bicep template. They cannot be retrofitted purely via portal after the environment exists.
   • Disabling public network access and enabling private endpoints on the Container Apps environment can be done via CLI/portal, but for a repeatable production deployment they should also be represented in Bicep.
   • The Storage Account, its private endpoint, and the required private DNS zone should likewise be defined in Bicep to ensure the container app can resolve and reach the Storage Account privately.

Therefore, to support VNet integration and private endpoint–based access for the AzUrlShortener container app in production, the existing Bicep deployment template must be updated to:

1. Create or reference a VNet and dedicated subnet sized at least /27 for the Container Apps environment (workload profile environment).
2. Create the Container Apps environment integrated with that subnet (network type set at creation).
3. Disable public network access on the Container Apps environment and enable private endpoints for it.
4. Create the Storage Account with public network access disabled, plus its private endpoint and private DNS zone configuration.

This cannot be fully handled after deployment in the portal alone if the environment was originally created without VNet integration or with the wrong environment type.

---

References:

• Networking in Azure Container Apps environment
• Private endpoints and DNS for virtual networks in Azure Container Apps environments
• Use a private endpoint with an Azure Container Apps environment (azure-portal)
• Use a private endpoint with an Azure Container Apps environment (azure-cli)
• Run Bicep deployment script privately over a private endpoint