Edit

Virtual network scenarios and resources

  • Article

Azure Virtual Network provides secure, private networking for your Azure and on-premises resources. By deploying container groups into an Azure virtual network, your containers can communicate securely with other resources in the virtual network.

This article provides background about virtual network scenarios, limitations, and resources. For deployment examples using the Azure CLI, see Deploy container instances into an Azure virtual network.

Important

Container group deployment to a virtual network is generally available for Linux and Windows containers, in most regions where Azure Container Instances is available. For details, see Resource availability and quota limits.

Scenarios

Container groups deployed into an Azure virtual network enable scenarios like:

  • Direct communication between container groups in the same subnet
  • Send task-based workload output from container instances to a database in the virtual network
  • Retrieve content for container instances from a service endpoint in the virtual network
  • Enable container communication with on-premises resources through a VPN gateway or ExpressRoute
  • Integrate with Azure Firewall to identify outbound traffic originating from the container
  • Resolve names via the internal Azure DNS for communication with Azure resources in the virtual network, such as virtual machines
  • Use NSG rules to control container access to subnets or other network resources

Unsupported networking scenarios

  • Azure Load Balancer - Placing an Azure Load Balancer in front of container instances in a networked container group is not supported
  • Global virtual network peering - Global peering (connecting virtual networks across Azure regions) is not supported
  • Public IP or DNS label - Container groups deployed to a virtual network don't currently support exposing containers directly to the internet with a public IP address or a fully qualified domain name
  • Managed Identity with Virtual Network in Azure Government Regions - Managed Identity with virtual networking capabilities is not supported in Azure Government Regions

Other limitations

  • 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.
  • To deploy container groups to a subnet, the subnet and the container group must be on the same Azure subscription.
  • You can't enable a liveness probe or readiness probe in a container group deployed to a virtual network.
  • Due to the additional networking resources involved, deployments to a virtual network are typically slower than deploying a standard container instance.
  • Outbound connections to port 25 and 19390 are not supported at this time. Port 19390 needs to be opened in your Firewall for connecting to ACI from Azure portal when container groups are deployed in virtual networks.
  • For inbound connections, the firewall should also allow all ip addresses within the virtual network.
  • If you are connecting your container group to an Azure Storage Account, you must add a service endpoint to that resource.
  • IPv6 addresses are not supported at this time.
  • Depending on your subscription type, certain ports may be blocked.

Required network resources

There are three Azure Virtual Network resources required for deploying container groups to a virtual network: the virtual network itself, a delegated subnet within the virtual network, and a network profile.

Virtual network

A virtual network defines the address space in which you create one or more subnets. You then deploy Azure resources (like container groups) into the subnets in your virtual network.

Subnet (delegated)

Subnets segment the virtual network into separate address spaces usable by the Azure resources you place in them. You create one or several subnets within a virtual network.

The subnet that you use for container groups may contain only container groups. When you first deploy a container group to a subnet, Azure delegates that subnet to Azure Container Instances. Once delegated, the subnet can be used only for container groups. If you attempt to deploy resources other than container groups to a delegated subnet, the operation fails.

Network profile

Important

Network profiles have been retired as of the 2021-07-01 API version. If you're using this or a more recent version, ignore any steps and actions related to network profiles.

A network profile is a network configuration template for Azure resources. It specifies certain network properties for the resource, for example, the subnet into which it should be deployed. When you first use the az container create command to deploy a container group to a subnet (and thus a virtual network), Azure creates a network profile for you. You can then use that network profile for future deployments to the subnet.

To use a Resource Manager template, YAML file, or a programmatic method to deploy a container group to a subnet, you need to provide the full Resource Manager resource ID of a network profile. You can use a profile previously created using az container create, or create a profile using a Resource Manager template (see template example and reference). To get the ID of a previously created profile, use the az network profile list command.

In the following diagram, several container groups have been deployed to a subnet delegated to Azure Container Instances. Once you've deployed one container group to a subnet, you can deploy additional container groups to it by specifying the same network profile.

Container groups within a virtual network

Next steps