I was giving Azure Container Instances a try and it seemed to work okay. However, I launched the container in a VNET with a subnet that was empty but was supposed to be used for an Azure Cache for Redis deployment. Buried in the docs, Azure mentions a limitation that containers launched from an Azure Container Instances in a VNET, must be deployed to a subnet that cannot contain other resource types.

To deploy container groups to a subnet, the subnet can’t contain other resource types. Remove all existing resources from an existing subnet prior to deploying container groups to it, or create a new subnet.

So why is this a problem? The subnet was now delegated to be used by Azure Container Instances. Trying to find an empty subnet from a pre-allocated VNET with no overlaps can be quite a challenge, and the subnet was originally dedicated to Azure Cache for Redis, which also needs a dedicated subnet. When I tried to deploy the cache, I got the error message:

The subnet is delegated to the service(s) : Microsoft.ContainerInstance/containerGroups

I tried to remove the subnet delegation (read more about subnet delegation) using the steps mentioned in the docs but this also failed with another cryptic message about serviceAssociationLinks being present.

Trying to find details about serviceAssociationLinks lead to a dead end. Finally, I came across this GitHub issue which explains how you can delete the service association link using the Azure CLI.

az rest --method delete --uri https://management.azure.com/subscriptions/<subscription id>/resourceGroups/<resource group>/providers/Microsoft.Network/virtualNetworks/<vnet name>/subnets/<subnet name>/providers/Microsoft.ContainerInstance/serviceAssociationLinks/default?api-version=2018-10-01

once the Service association links were deleted, I was able to remove the Subnet delegation using Azure CLI

az network vnet subnet update --resource-group <resource group name> --name <subnet name> --vnet-name <vnet name> --remove delegations