Azure Container Apps Virtual Network Integration release announcement
At Ignite, we announced Azure Container Apps, a serverless application-centric hosting service that enables users to quickly deploy containerized applications and microservices to Azure without the need to configure and manage underlying infrastructure resources or container orchestrators. Azure Container Apps runs on Azure Kubernetes Service, and includes several open-source projects: Kubernetes Event Driven Autoscaling (KEDA), Distributed Application Runtime (Dapr), and Envoy. This open-source foundation enables teams to build and run portable applications powered by Kubernetes and open standards without the operational overhead and management complexity of working with the platform directly.
Since its preview release, the Azure Container Apps service has continued evolving to address customer needs and respond to customer feedback. One point of focused investment has been addressing asks related to network isolation. For security and compliance reasons, many enterprise customers require isolation to ensure internal, mission critical applications are inaccessible from the public internet. In addition, customers typically have existing cloud resources like databases, queues, file shares, etc. that an application needs to integrate with over this internal, private network. Today, we are excited to announce that Azure Container Apps can be deployed into your custom Azure Virtual Network! In the remainder of this blog, we will walk through configuring inbound and outbound virtual network integration for an Azure Container Apps environment and subsequently deploying Container Apps to the running environment.
Configure Virtual Network for an Azure Container Apps Environment
To host your containerized applications using Azure Container Apps, you must first deploy an Azure Container Apps environment. The environment can host one or more applications and establishes the network boundary, meaning all applications within the shared environment are deployed to the same Azure virtual network.
As of today, you have the option to bring your own virtual network when creating a new Azure Container Apps environment. If you choose to do so, you will need to provide the network along with a designated subnet: the control plane subnet. The control plane subnet will be used to provide IP addresses from your internal network to the Azure Container Apps control plane infrastructure components as well as your application containers.
It is important to note that currently, the size of the subnet provided should be at least /23. This subnets should not overlap with the following reserved ranges:
- 169.254.0.0/16
- 172.30.0.0/16
- 172.31.0.0/16
- 192.0.2.0/24
In addition to defining where the service will be deployed, you also have the option to configure inbound access: Internal or External.
External
If you choose to deploy an external Azure Container Apps environment, the environment will be accessible via a public endpoint. This endpoint is an Azure Public IP address.
Internal
If you would like to lock down your environment from the public internet, you can deploy an internal environment instead. The internal deployment will create an environment that only exposes applications via an IP address from within your virtual network. The list of traffic dependencies required can be found here: Securing a custom VNET in Azure Container Apps | Microsoft Docs.While UDR support is not available today, it is on our roadmap.
Keep in mind, an internal environment will have public IPs, however they will be used solely for outbound connectivity.
Managed resources
When you deploy an internal or an external environment into your own network, you will see a new Resource Group with the “MC_” prefix created in the Azure subscription where your environment is hosted. This resource group contains infrastructure components managed by the Azure Container Apps platform. This resource group should not be modified. You will see Public IP addresses which are used specifically for outbound connectivity from your environment as well as an internal or external load balancer depending on your environment configuration. Because the load balancer is created in your subscription, there are additional costs associated with deploying the service to a custom virtual network.
DNS Resolution for Internal Container Apps Environments
As mentioned in the previous section, an internal-only Azure Container Apps environment will receive an IP address directly from the network provided. By default, there is no domain registration for the internal load balancer (ILB) that is created. This means customers will be responsible for configuring DNS resolution for the environment endpoint. In Azure, this can be accomplished by creating and configuring an Azure Private DNS Zone.
After deploying the Container Apps environment into a virtual network, you can retrieve the static, internal IP and the default domain. To start hosting the domain in Azure DNS and creating DNS records, the first step is to create the Private DNS Zone. To publish the private DNS zone to your virtual network, you will need to provide a list of virtual networks that are allowed to resolve records within the zone. This list should include the network where your environment is deployed. Once you have created the network link, you can add a wildcard DNS record which will resolve traffic bound for the default domain to the IP address of the environment’s ILB. After completing these steps, your environment will be resolvable by other services in the list of linked networks using the default domain.
Deploying Container Apps to the Container Apps Environment
At this stage, you can begin deploying your application workloads to the deployed environment! The accessibility level you selected for the environment will impact the available ingress options for your container app deployments. Azure Container Apps provides HTTPS ingress with TLS termination as a built-in feature, so you do not need to deploy an Azure Load Balancer, Public IP address, or any other Azure resources to enable HTTPS ingress.
If you are deploying to an external environment, you have two options for configuring ingress traffic to your container app: Limited to Container Apps Environment or Accepting traffic from anywhere. You will allow traffic from anywhere if you want the application to be accessible from the public internet. Otherwise, you can choose to allow only traffic from other container apps deployed within the shared Container Apps environment.
If you are deploying to an internal environment, you also have two options for configuring ingress traffic to your container app: Limited to Container Apps Environment or Limited to VNet (Virtual Network). You will allow traffic from the VNet if you want your container app to be accessible from other Azure resources or applications within the virtual network or connected to the virtual network through Peering or some type of VPN connectivity. Otherwise, you can choose to allow only traffic from other container apps deployed within the shared Container Apps environment.
Next Steps
If you’re looking to learn more about Azure Container Apps and when to use it, check out the latest episode of Microsoft Mechanics. Jeff Hollan shares how the container apps platform plays a critical role in enabling modern applications in the cloud.
If you are interested in learning more about the VNet integration feature specifically, visit the Azure Container Apps custom virtual network Microsoft Docs. We encourage you to share your feedback via our GitHub microsoft/azure-container-apps repo, connect with us on discord and join our mailing list so we can continue enhancing your experience with Azure Container Apps!