In this blog post, I will share my experience as an Azure architect who has consulted with customers on how to design and implement networking in Azure Container Apps environment. Azure Container Apps is a service that enables you to run containerized applications at scale, with minimal overhead and operational complexity. You can focus on your application logic, while Azure Container Apps takes care of the infrastructure, scaling, availability, and security. If you are confused about which service to select between AKS (Azure Kubernetes Service) and Azure Container Apps, please refer to my previous blog, ACA vs AKS: Which Azure Service Is Better for Running Containers? for more insights.
One of the key aspects of Azure Container Apps is the environment, which is a logical boundary that encapsulates one or more container apps or jobs. Each environment has its own virtual network (VNet) that provides network isolation and security. You can choose to use a generated VNet that is automatically created for you by Azure, or you can provide an existing VNet that you have already configured. Depending on your networking requirements, you can also decide whether your environment allows public ingress or ingress only from within your VNet.
In this post, I will cover the following topics:
- How to choose between external and internal environments
- How to configure custom VNet and subnet for your environment
- How to use network security groups (NSGs) and application gateway to control network access
- How to leverage DNS, ingress, WAF, and other features to optimize your network performance and security
Let's get started!
Environment selection
---------------------
When you create an Azure Container App, you need to specify an environment, which is a logical grouping of one or more container apps or jobs that share a common virtual network (VNet). The environment defines the network boundary and isolation level for your applications.
You can choose between two types of environments: 1. Consumption only and 2. Workload profiles.
Consumption only environments are optimized for cost and scalability, and they support user defined routes (UDR) and egress through NAT Gateway. The minimum required subnet size for consumption only environments is /27. Consumption only environments are suitable for stateless applications that do not need to communicate with other resources in your VNet or use advanced networking features.
Workload profiles environments are optimized for performance and flexibility, and they support all the networking features that are available in Azure Container Apps, such as integration with Application Gateway, Network Security Groups, private endpoints, peering through a remote gateway, and custom egress. The minimum required subnet size for workload profiles environments is /23. Workload profiles environments are suitable for stateful applications that need to communicate with other resources in your VNet or use advanced networking features.
Accessibility levels
--------------------
You can configure whether your container app allows public ingress or ingress only from within your VNet at the environment level. You can choose between two accessibility levels: external and internal.
External environments allow your container app to accept public requests over the internet. External environments are deployed with a virtual IP on an external, public facing IP address. You can use DNS names or custom domains to access your container app from outside your VNet.
Internal environments restrict your container app to accept requests only from within your VNet. Internal environments are deployed with a virtual IP mapped to an internal IP address. The internal endpoint is an Azure internal load balancer (ILB) and IP addresses are issued from the custom VNet's list of private IP addresses. You can use DNS names or private DNS zones to access your container app from inside your VNet.
Very important to note that a managed public IP resource(created) handles outbound requests and management traffic, regardless if you have an external or internal environment.
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 create a UDR that routes all outbound traffic through the firewall.
Custom VNet configuration
-------------------------
By default, Azure Container Apps creates a VNet for your environment automatically, which is inaccessible to you as it is created in backend by Azure. However, if you want more control over your network configuration, 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 cannot be changed.
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 is not 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.
When you use your own VNet, you can also leverage some of the Azure networking features that are not available with generated VNets, such as:
- Integration with Application Gateway: You can use Application Gateway as an ingress controller for your container apps, and benefit from its features such as SSL termination, URL-based routing, cookie-based session affinity, web application firewall (WAF), etc.
- Network Security Groups: You can use Network Security Groups (NSGs) to control the inbound and outbound traffic for your container apps at the subnet level. You can define rules to allow or deny traffic based on source and destination IP addresses, ports, protocols, etc.
- Communication with resources behind private endpoints: You can use private endpoints to securely connect your container apps to other Azure services such as Storage Accounts, Cosmos DB, etc., without exposing them to the internet.
- Peering through a remote gateway: You can use peering through a remote gateway to connect your container apps to other VNets or on-premises networks via VPN or ExpressRoute.
HTTP edge proxy behaviour
------------------------
Azure Container Apps uses Envoy as a network proxy for all HTTP requests. Envoy provides some capabilities such as:
- Scaling to zero: Envoy allows your container apps to scale to zero instances when there is no traffic, and scale up when there is demand. Envoy acts as a buffer between the clients and the container apps, and handles the cold start latency.
- HTTPS redirection: Envoy automatically redirects all HTTP requests to HTTPS, ensuring secure communication between the clients and the container apps.
- TLS termination: Envoy terminates the transport layer security (TLS) at the edge of the container app environment, and forwards the requests to the container apps over plain HTTP. This reduces the overhead of encryption and decryption for the container apps.
- Mutual TLS: Envoy supports mutual TLS (mTLS) when you use Dapr as a sidecar for your container apps. mTLS provides an additional layer of security by requiring both the client and the server to present valid certificates for authentication.
- Ingress controls: Envoy allows you to configure some ingress controls for your container apps, such as IP restrictions, CORS, WAF, etc.
Security
--------
Azure Container Apps provides several security features to protect your applications and data, such as:
- Encryption at rest: All data stored by Azure Container Apps is encrypted at rest using Microsoft-managed keys.
- Encryption in transit: All communication between Azure Container Apps and other Azure services is encrypted in transit using TLS.
- Private endpoints: You can use private endpoints to securely access Azure Container Apps from your VNet or on-premises network, without exposing it to the internet.
- Network security groups: You can use network security groups to control the inbound and outbound traffic for your container apps at the subnet level.
- Web application firewall: You can use web application firewall (WAF) to protect your container apps from common web attacks such as SQL injection, cross-site scripting, etc.
- DDOS protection: You can use Azure DDoS Protection for the Azure Container Apps Environment.
- Secure inbound connectivity: When publishing internet-facing services, use Azure Application Gateway (WAF_v2 SKU) or Azure Front Door (with Web Application Firewall) to secure inbound connectivity.
Summary
-------
In this blog post, I have explained some of the networking options and features that are available in Azure Container Apps, and how to use them effectively. Azure Container Apps provides a serverless and scalable way to run containerized applications, with different levels of network isolation and configuration. You can choose the environment type, accessibility level, and VNet configuration that best suits your application needs and requirements. You can also leverage Envoy as a network proxy to provide some capabilities such as scaling to zero, HTTPS redirection, TLS termination, mTLS, and ingress controls. Additionally, you can consider the security, and WAF aspects of Azure Container Apps to optimize your budget and protect your applications and data.