Choosing the right tool for the job is hard, especially in the Azure container landscape. Microsoft already provides some great documentation, like Choose an Azure container service and General architectural considerations for choosing an Azure container service. Interestingly, they make a comparison between Azure Kubernetes Service (AKS), Web App for Containers and Container Apps, while leaving out Azure Container Instances.
In this article, the focus is running a single container image, exposed on a private network with private ingress, on Azure, with as little overhead as possible.
This case rules out additional tools like Application Gateways or any other ingress controllers outside of the resource, as that would not make it a fair comparison. We can also rule out Azure Kubernetes Service (AKS), as it is simply a managed Kubernetes service, which is short for: you get a whole cluster of VMs.
We're adding Azure Container Instances to the comparison, as it is suitable for running a single container image.
What defines secure traffic? It simply is the ability to verify certificates, tokens and network origin of requests, all while having an identity and reliable endpoint on it's own. This boils down to the following comparison:
Let's summarize the downsides of each offering. Container Instances are not an option if you;
- require private inbound connections, since the dynamic nature of the private IP is not practical. FQDN's are static, however, they only apply to the public IP.
- require a Microsoft managed certificate without much complexity, it can be done but involves using a sidecar container and API configuration.
- require easy validation of authorization tokens, as it doesn't come with Easy Auth or anything similar
Container Apps are not an option if you;
- require to call by IP and not by FQDN, it is not possible to use IP routing via the Container Apps environment to the Container App itself if you require VNet-scoped traffic.
- don't like the complex DNS setup it requires. It involves setting up dns zones for each Container Apps environment. To add to the complexity, each time a Container Apps environment is being built from the ground up, a new name has to be used, as there is randomness added to the FQDN.
- require a managed custom domain certificate while securing your ingress endpoint, it has to be accessible by the certification authority.
Web App for Containers is not an option if you;
- require secure connections from any other port other than 443, since you are not allowed to configure this at all.
- require a managed custom domain certificate if secured by private DNS.
Web App for Containers seems like the offering that ticks most requirements in this particular scenario, you have easy out of the box HTTPS support, secure and easy networking via private endpoints with a fixed endpoint and Easy Auth support. However, every scenario is different and should be closely examined per requirements.
To see how easy it is setting up Web App for Containers in IaC, please see my fork of the darklynx/request-baskets image, which includes a bicep deploy template with Azure Deployment Environments support.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
