Why?

A regular ContainerApp Environment has a managed VNET, but it’s not a VNET you can access or attach other resources to. If you want to be able to attach other Azure resources (e.g: Databases, ServiceBus, Storage Accounts, etc) to a shared VNET with your apps, you’ll need to create the VNET yourself and pass it as a parameter when creating a ContainerApp Environment. Additionally some scenarios are only possible in a custom VNET environment.

How?

First pick few values for our deployment

# azure stuff
export RESOURCE_GROUP="my-container-apps"
export LOCATION="eastus"

# container apps env stuff
export CONTAINERAPPS_ENVIRONMENT="my-environment"
export VNET_NAME="my-custom-vnet"

Then:

  1. Create the resourceGroup
az group create --name $RESOURCE_GROUP --location $LOCATION
  1. Create the VNET (skip if you already have a VNET)
az network vnet create \
  --resource-group $RESOURCE_GROUP \
  --name $VNET_NAME \
  --location $LOCATION \
  --address-prefix 10.0.0.0/16

az network vnet subnet create \
  --resource-group $RESOURCE_GROUP \
  --vnet-name $VNET_NAME \
  --name infrastructure-subnet \
  --address-prefixes 10.0.0.0/23
  1. Get the VNET ARM ID
export INFRASTRUCTURE_SUBNET=`az network vnet subnet show --resource-group ${RESOURCE_GROUP} --vnet-name $VNET_NAME --name infrastructure-subnet --query "id" -o tsv | tr -d '[:space:]'`

Once the VNET is done creating and we have its ID, we can create a Container Apps Environment that’s linked to that.

  1. Create the environment
az containerapp env create \
  --name $CONTAINERAPPS_ENVIRONMENT \
  --resource-group $RESOURCE_GROUP \
  --location "$LOCATION" \
  --infrastructure-subnet-resource-id $INFRASTRUCTURE_SUBNET

Now you have a VNET enabled environment. You can next check how to: