Networking in Azure Container Apps environment

Azure Container Apps run in the context of an environment, with its own virtual network (VNet).

By default, your Container App environment is created with a VNet that is automatically generated for you. For fine-grained control over your network, you can provide an existing VNet when you create an environment. Once you create an environment with either a generated or existing VNet, the network type can't be changed.

Generated VNets take on the following characteristics.

They are:

• inaccessible to you as they're created in Microsoft's tenant
• publicly accessible over the internet
• only able to reach internet accessible endpoints

Further, they only support a limited subset of networking capabilities such as ingress IP restrictions and container app level ingress controls.

Use an existing VNet if you need more Azure networking features such as:

• Integration with Application Gateway
• Network Security Groups
• Communication with resources behind private endpoints in your virtual network

The available VNet features depend on your environment selection.

Environment selection

Container Apps has two different environment types, which share many of the same networking characteristics with some key differences.

Virtual IP

Depending on your virtual IP configuration, you can control whether your container app environment allows public ingress or ingress only from within your VNet at the environment level. This configuration cannot be changed after your environment is created.

Custom VNet configuration

As you create a custom VNet, keep in mind the following situations:

• If you want your container app to restrict all outside access, create an internal Container Apps environment.

• If you use your own VNet, you need to provide a subnet that is dedicated exclusively to the Container App environment you deploy. This subnet isn't available to other services.

• Network addresses are assigned from a subnet range you define as the environment is created.

  • You can define the subnet range used by the Container Apps environment.

  • You can restrict inbound requests to the environment exclusively to the VNet by deploying the environment as internal.

As you begin to design the network around your container app, refer to Plan virtual networks.

HTTP edge proxy behavior

Azure Container Apps uses the Envoy proxy as an edge HTTP proxy. Transport Layer Security (TLS) is terminated on the edge and requests are routed based on their traffic splitting rules and routes traffic to the correct application.

HTTP applications scale based on the number of HTTP requests and connections. Envoy routes internal traffic inside clusters.

Downstream connections support HTTP1.1 and HTTP2 and Envoy automatically detects and upgrades connections if the client connection requires an upgrade.

Upstream connections are defined by setting the transport property on the ingress object.

Ingress configuration

Under the ingress section, you can configure the following settings:

• Accessibility level: You can set your container app as externally or internally accessible in the environment. An environment variable CONTAINER_APP_ENV_DNS_SUFFIX is used to automatically resolve the fully qualified domain name (FQDN) suffix for your environment. When communicating between container apps within the same environment, you may also use the app name. For more information on how to access your apps, see Ingress in Azure Container Apps.

• Traffic split rules: You can define traffic splitting rules between different revisions of your application. For more information, see Traffic splitting.

For more information about different networking scenarios, see Ingress in Azure Container Apps.

Portal dependencies

For every app in Azure Container Apps, there are two URLs.

The Container Apps runtime initially generates a fully qualified domain name (FQDN) used to access your app. See the Application Url in the Overview window of your container app in the Azure portal for the FQDN of your container app.

A second URL is also generated for you. This location grants access to the log streaming service and the console. If necessary, you may need to add https://azurecontainerapps.dev/ to the allowlist of your firewall or proxy.

Ports and IP addresses

The following ports are exposed for inbound connections.

IP addresses are broken down into the following types:

Subnet

Virtual network integration depends on a dedicated subnet. How IP addresses are allocated in a subnet and what subnet sizes are supported depends on which plan you're using in Azure Container Apps.

Select your subnet size carefully. Subnet sizes can't be modified after you create a Container Apps environment.

Different environment types have different subnet requirements:

Subnet address range restrictions

Subnet configuration with CLI

As a Container Apps environment is created, you provide resource IDs for a single subnet.

If you're using the CLI, the parameter to define the subnet resource ID is infrastructure-subnet-resource-id. The subnet hosts infrastructure components and user app containers.

If you're using the Azure CLI with a Consumption only environment and the platformReservedCidr range is defined, the subnet must not overlap with the IP range defined in platformReservedCidr.

Routes

User defined routes (UDR)

User Defined Routes (UDR) and controlled egress through NAT Gateway are supported in the workload profiles environment. In the Consumption only environment, these features aren't supported.

• You can use UDR with workload profiles environments to restrict outbound traffic from your container app through Azure Firewall or other network appliances.

• Configuring UDR is done outside of the Container Apps environment scope.

Azure creates a default route table for your virtual networks upon create. By implementing a user-defined route table, you can control how traffic is routed within your virtual network. For example, you can create a UDR that routes all traffic to the firewall.

Configuring UDR with Azure Firewall

User defined routes is only supported in a workload profiles environment. The following application and network rules must be added to the allowlist for your firewall depending on which resources you're using.

Application rules

Application rules allow or deny traffic based on the application layer. The following outbound firewall application rules are required based on scenario.

Network rules

Network rules allow or deny traffic based on the network and transport layer. The following outbound firewall network rules are required based on scenario.

NAT gateway integration

You can use NAT Gateway to simplify outbound connectivity for your outbound internet traffic in your virtual network in a workload profiles environment.

When you configure a NAT Gateway on your subnet, the NAT Gateway provides a static public IP address for your environment. All outbound traffic from your container app is routed through the NAT Gateway's static public IP address.

Public network access (preview)

The public network access setting determines whether your container apps environment is accesible from the public Internet. Whether you can change this setting after creating your environment depends on the environment's virtual IP configuration. The following table shows valid values for public network access, depending on your environment's virtual IP configuration.

In order to create private endpoints on your Azure Container App environment, public network access must be set to Disabled.

Azure networking policies are supported with the public network access flag.

Private endpoint (preview)

Azure private endpoint enables clients located in your private network to securely connect to your Azure Container Apps environment through Azure Private Link. A private link connection eliminates exposure to the public internet. Private endpoints use a private IP address in your Azure virtual network address space.

This feature is supported for both Consumption and Dedicated plans in workload profile environments.

Tutorials

• To learn more about how to configure private endpoints in Azure Container Apps, see the Use a private endpoint with an Azure Container Apps environment tutorial.
• Private link connectivity with Azure Front Door is supported for Azure Container Apps. Refer to create a private link with Azure Front Door for more information.

Considerations

• Private endpoints on Azure Container Apps only support inbound HTTP traffic. TCP traffic is not supported.
• To use a private endpoint with a custom domain and an Apex domain as the Hostname record type, you must configure a private DNS zone with the same name as your public DNS. In the record set, configure your private endpoint's private IP address instead of the container app environment's IP address. When configuring your custom domain with CNAME, the setup is unchanged. For more information, see Set up custom domain with existing certificate.
• Your private endpoint's VNet can be separate from the VNet integrated with your container app.
• You can add a private endpoint to both new and existing workload profile environments.

In order to connect to your container apps through a private endpoint, you must configure a private DNS zone.

Environment security

You can fully secure your ingress and egress networking traffic workload profiles environment by taking the following actions:

• Create your internal container app environment in a workload profiles environment. For steps, refer to Manage workload profiles with the Azure CLI.

• Integrate your Container Apps with an Application Gateway.

• Configure UDR to route all traffic through Azure Firewall.

Peer-to-peer encryption in the Azure Container Apps environment

Azure Container Apps supports peer-to-peer TLS encryption within the environment. Enabling this feature encrypts all network traffic within the environment with a private certificate that is valid within the Azure Container Apps environment scope. These certificates are automatically managed by Azure Container Apps.

The following example shows an environment with peer-to-peer encryption enabled.

¹ Inbound TLS traffic is terminated at the ingress proxy on the edge of the environment.

² Traffic to and from the ingress proxy within the environment is TLS encrypted with a private certificate and decrypted by the receiver.

³ Calls made from app A to app B's FQDN are first sent to the edge ingress proxy, and are TLS encrypted.

⁴ Calls made from app A to app B using app B's app name are sent directly to app B and are TLS encrypted.

Applications within a Container Apps environment are automatically authenticated. However, the Container Apps runtime doesn't support authorization for access control between applications using the built-in peer-to-peer encryption.

When your apps are communicating with a client outside of the environment, two-way authentication with mTLS is supported. To learn more, see configure client certificates.

az containerapp env create \
    --name <environment-name> \
    --resource-group <resource-group> \
    --location <location> \
    --enable-peer-to-peer-encryption

az containerapp env update \
    --name <environment-name> \
    --resource-group <resource-group> \
    --enable-peer-to-peer-encryption

{
  ...
  "properties": {
       "peerTrafficConfiguration":{
            "encryption": {
                "enabled": "true|false"
            }
        }
  ...
}

DNS

• Custom DNS: If your VNet uses a custom DNS server instead of the default Azure-provided DNS server, configure your DNS server to forward unresolved DNS queries to 168.63.129.16. Azure recursive resolvers uses this IP address to resolve requests. When configuring your NSG or firewall, don't block the 168.63.129.16 address, otherwise, your Container Apps environment won't function correctly.

• VNet-scope ingress: If you plan to use VNet-scope ingress in an internal environment, configure your domains in one of the following ways:

  1. Non-custom domains: If you don't plan to use a custom domain, create a private DNS zone that resolves the Container Apps environment's default domain to the static IP address of the Container Apps environment. You can use Azure Private DNS or your own DNS server. If you use Azure Private DNS, create a private DNS Zone named as the Container App environment’s default domain (<UNIQUE_IDENTIFIER>.<REGION_NAME>.azurecontainerapps.io), with an A record. The A record contains the name *<DNS Suffix> and the static IP address of the Container Apps environment.

  2. Custom domains: If you plan to use custom domains and are using an external Container Apps environment, use a publicly resolvable domain to add a custom domain and certificate to the container app. If you are using an internal Container Apps environment, there is no validation for the DNS binding, as the cluster can only be accessed from within the virtual network. Additionally, create a private DNS zone that resolves the apex domain to the static IP address of the Container Apps environment. You can use Azure Private DNS or your own DNS server. If you use Azure Private DNS, create a Private DNS Zone named as the apex domain, with an A record that points to the static IP address of the Container Apps environment.

The static IP address of the Container Apps environment is available in the Azure portal in Custom DNS suffix of the container app page or using the Azure CLI az containerapp env list command.

Managed resources

When you deploy an internal or an external environment into your own network, a new resource group is created in the Azure subscription where your environment is hosted. This resource group contains infrastructure components managed by the Azure Container Apps platform. Don't modify the services in this group or the resource group itself.

Workload profiles environment

The name of the resource group created in the Azure subscription where your environment is hosted is prefixed with ME_ by default, and the resource group name can be customized as you create your container app environment.

For external environments, the resource group contains a public IP address used specifically for inbound connectivity to your external environment and a load balancer. For internal environments, the resource group only contains a Load Balancer.

In addition to the standard Azure Container Apps billing, you're billed for:

• One standard static public IP for egress if using an internal or external environment, plus one standard static public IP for ingress if using an external environment. If you need more public IPs for egress due to SNAT issues, open a support ticket to request an override.

• One standard load balancer.

• The cost of data processed (in GBs) includes both ingress and egress for management operations.

Consumption only environment

The name of the resource group created in the Azure subscription where your environment is hosted is prefixed with MC_ by default, and the resource group name can't be customized when you create a container app. The resource group contains public IP addresses used specifically for outbound connectivity from your environment and a load balancer.

In addition to the standard Azure Container Apps billing, you're billed for:

• One standard static public IP for egress. If you need more IPs for egress due to Source Network Address Translation (SNAT) issues, open a support ticket to request an override.

• Two standard load balancers if using an internal environment, or one standard load balancer if using an external environment. Each load balancer has fewer than six rules. The cost of data processed (in GBs) includes both ingress and egress for management operations.

Next steps

• Deploy with an external environment
• Deploy with an internal environment