While choosing Azure container services for your use case/functional/non-functional requirements, you first need to understand the shared responsibility model (you can call it cloud provider service model) and how it shifts across different Azure container service offerings. That way you do not need to overengineer, worry about scale, save time, reduce cost, and run your app with clarity and confidence. Refer Shared responsibility in the cloud public documentation page to understand how Azure progressively takes over more responsibilities as you move up the abstract layers.

In this section, we tabulate Azure container service offerings-as-a-service model to provide insight into the level of flexibility and control that these services provide, in exchange for their overall simplicity and ease of use. We will break down to show you how it applies to the popular services such as Azure Container Instances (ACI), Azure Container Apps (ACA) and Azure Kubernetes Service (AKS) and categorize them appropriately. We also present sample use cases for you to relate and then focus on what you take care of and what Azure handles.

ACI lets you run an individual container or a container group (ACI term for pod) without managing any underlying compute infrastructure. It provides a serverless environment for individual containerized workloads. Think of it as providing just your container or a single pod running on demand. From a shared responsibility outlook, Azure is responsible for the security OF the cloud and runtime environment, and you are responsible for the security IN the container and application.

For example, assume you need to run one-off isolated environment for tasks such as unit testing or CI/CD pipelines or data/batch processing script etc. ACI is a better option for this case. You would take care of the test runner application within the container and Azure handles everything else below such as the underlying physical servers, the host operating system, and the container runtime environment, ensuring secure isolation between your container and others. You focus solely on what’s inside your container and its basic configuration. However, you should consider other Azure container services if operations such as autoscaling, self-healing, service discovery are important for your use case.

Azure Container Apps, categorized as PaaS

Building on ACI’s simplicity, ACA also lets you focus just on your container but takes the “running on demand” concept to the next level for web apps and microservices. While ACI handles a single container or pod, ACA provides critical operations such as auto-scaling, traffic management, and native integrations (like Dapr and KEDA) for more complex, dynamic workloads. From a shared responsibility outlook, Azure is responsible for the security OF the platform, and you are responsible for the security IN the container and application.

For example, assume you have an API backend that experiences unpredictable traffic spikes and need to scale to handle thousands of requests per second, connect to a database, and might use pub/sub messaging. ACA is a better option for this case. You would take care of the API backend application, container image and autoscaling configuration and Azure handles everything else such as the auto-scaling capability, underlying physical servers and Kubernetes management, high availability of the ACA service, and built-in ingress controller that routes traffic to your API. However, you should consider other Azure container services if operations such as orchestrator control, extensibility with open-source projects etc. are important for your use case.

Azure Kubernetes Service, categorized as PaaS with significant IaaS elements

AKS moves beyond the individual container or serverless app model by providing a managed Kubernetes cluster where you have control over the orchestration of your containers. Unlike ACI and ACA where Azure hides the orchestration layer, with AKS, Azure manages the Kubernetes control plane (the “brain” of Kubernetes, such as the API server, scheduler, controller manager, and etcd database). However, you’re responsible for the worker nodes (the virtual machines where your containers run) and everything deployed on them. This gives you the full power of Kubernetes for complex deployments, custom networking, and advanced configurations. Though ACA is built on top of Kubernetes, note that the difference between ACA and AKS is who is responsible for managing Kubernetes and how much control you have over it. In summary, if ACI is like running a single container directly on a managed host, and ACA is like having an intelligent manager for your individual containers, AKS provides the entire, sophisticated “container orchestra conductor” for you. From a shared responsibility outlook, Azure is responsible for the security OF the control plane and underlying infrastructure, and you are responsible for the security IN the worker nodes and application.

For example, assume you have a monolithic legacy application, and you like to migrate it to a microservices architecture, involving interconnected services, stateful components (like databases running in containers), and a complex CI/CD pipeline. You require control over resource allocation, network segmentation, and the CNCF open-source flexibility for this distributed system. AKS is a better option for this case. You would take care of the Kubernetes configurations (such as designing your Pods, Deployments, Services, Ingresses, Network Policies, and RBAC rules), managing the worker node virtual machines (including their sizing, ensuring OS patches are applied, and configuring their network security groups), and securing your application code and container images. Azure handles everything else such as the Kubernetes control plane, ensuring its high availability, security, and automatic patching, along with the underlying physical infrastructure that supports this control plane.

Additional references

1. Azure public documentation page – Choose an Azure container service
2. Azure public documentation page – General architectural considerations for choosing an Azure container service
3. Azure public documentation page – Choose a Compute Option for Microservices – Azure Architecture Center | Microsoft Learn
4. Product description page – https://azure.microsoft.com/en-us/products/category/containers/