Do you want to optimise your containerised workloads but feel overwhelmed by the vast number of container services available in Azure? Look no further!
In this article, we’ll give you a high-level look at each option so you can decide when to use which Azure Container Services.
Reading time 16 minutes Published: 25 July 2025
If you want to host containers on Azure, you can use these services:
As you can see, there are many options for hosting containers.
Let’s dive deeper into each of them.
The first and probably one of the simplest way to run containers on Azure is by using Azure Container Instances (ACI). It is easy to use, and especially suitable for creating ephemeral workloads. This means, when you start it, you run it for a while to then shut it down.
ACI has a serverless billing model. In other words, you only pay for what you consume, which in specifically, implies you’re paying for the number of seconds that your container is actually running – no more and no less.
Use ACI when:
ACI is best for simple, standalone containers. If your app grows in complexity, consider moving to Azure Kubernetes Service (AKS) or Azure Container Apps.
You might not have thought Azure Function Apps when it comes to containers.
Azure Functions is a serverless option in Azure designed for event-driven workloads. You write small units of code (called functions) that respond to events like HTTP requests, queue messages, or database changes.
By default, you write Functions using supported languages like Node.js, .NET, or Python. But if you need a custom runtime or an unsupported language, you can containerise your entire Function App. Azure will run that container as it would a native Function App.
Note: It’s the entire Function App that’s containerised – not each individual function.
This approach gives you more control over the environment and allows you to run Function Apps outside of Azure (e.g., on-prem or in another cloud). However, it's tightly coupled to the Azure Functions runtime, so it's not ideal for general-purpose APIs.
Function App is very specific, use it when:
If your workload looks more like a standard API, you're better off using services like App Service, AKS, Container Apps, or ACI, which give you broader flexibility and are less opinionated.
Web Apps for Containers is a feature which runs on top of Azure App Services that lets you deploy containerised applications on either Windows or Linux. It is best suited for traditional, monolithic web applications.
Traditionally, in web development, you’d write your app in a scripting or compiled language, deploy it to a web server, and the server would handle incoming requests, then forward those requests onto a runtime environment that would execute that request and then return a response.
App Services typically follows that same paradigm. It's useful for that style of application and works well with frameworks like PHP, ASP.NET, Node.js, and Python and many other languages that it supports natively.
If your application uses a language not supported out of the box (like Ruby), you can containerise it and deploy it to App Services. The platform will run that container the same way it handles native apps.
The point is that it allows you to bring your own code to Azure using containers.
It’s often a sensible choice when you're moving to the cloud and want to keep using the structure and stack you’re used to.
Azure Kubernetes Services (AKS) is undeniably the flagship offering for running containerised workloads in Azure.
AKS is a managed Kubernetes service that gives you full control over Kubernetes clusters.
You can think of it as a managed infrastructure as there's a shared responsibility between you as a user and Microsoft as a service provider for running Kubernetes:
AKS is recommended for complex, large-scale, or enterprise workloads that need full Kubernetes capabilities. Especially ideal if you already work with Kubernetes or need advanced orchestration, scaling, and integrations.
With AKS, you can manage and scale containerised apps that’s by no means possible with other Azure container services. No wonder, it’s most widely used for running containers on Azure.
To counter the complexity of managing clusters and the required Kubernetes expertise in AKS, Microsoft launched Azure Container Apps, which in some way provides a managed Kubernetes experience.
In other words, it's going to be Kubernetes under the cover as it runs on top of a Kubernetes cluster, which is managed for you (by Microsoft).
Instead of managing clusters, you deploy your containerised workloads, define scaling rules, and specify app requirements. At the same time, Container Apps provides all the infrastructure and abstractions you need so that you never really have to manage any of the clustering technology.
This means that:
“While Kubernetes is about how to deploy, Container Apps is about what to deploy.”
You're basically saying: "Here are my services, here are my containers—run them for me."
It's more opinionated than a Kubernetes environment, but it does give you the ability to have a managed platform for running highly scalable applications in containers. Although it’s squarely designed for microservices, it can also run general web apps, as long as they're running inside a container.
Azure Container Apps is a solid choice for containerised apps that need auto-scaling and simple deployment (and when you can afford to don’t have access to the API, nor control).
Azure Service Fabric is Microsoft’s in-house orchestration platform, developed way before Kubernetes went mainstream. It powers many Azure services behind the scenes and was later released for public use.
Service Fabric is a distributed platform for deploying and managing scalable, reliable microservices and containers. It helps handle the complexity of building and operating cloud-native applications.
Service Fabric is not the most typical choice for running containers alone. However, if you’re already using it for existing applications and want to run containers alongside them, it serves this purpose well. It’s best used in mixed scenarios where Service Fabric is already part of your stack. Otherwise, there are better options for container-only workloads in Azure, such as AKS and ACA.
Azure Red Hat OpenShift lets you deploy fully managed OpenShift Clusters. It’s a fully managed service built through the partnership between Microsoft and Red Hat. We can think of this as Kubernetes plus DevOps, as it basically extends Kubernetes with other tools and resources.
Whereas Kubernetes handles container orchestration, scaling, and infrastructure, it doesn’t have DevOps built into the platform. To cover for this, you’d normally rely on third-party tools or build custom integrations. OpenShift brings all of that together. It gives you a single platform where you can build, deploy, secure and monitor all your container hosting and registries, without needing to set up and connect separate tooling and services.
Choose OpenShift if you want a one-stop shop container platform with DevOps tooling and everything needed to run containers. It makes a strong use case for organisations already using OpenShift on-premises or those with complex compliance and operational requirements. In any other case, you might be better off with AKS.
Instead of using a managed container service, you can also adopt a DIY approach where you run containers directly on virtual machines (VMs). This approach gives you full control over the OS (operating system), runtime, network and storage configuration.
You install Docker or another container runtime on the VM, deploy your containers manually or via scripts, and manage updates, scaling, and monitoring yourself.
Now, you can imagine that this method gives you as much control and flexibility as well as operational overhead…
In all other cases where you don’t require that extreme level of control, other options, such as AKS or ACA, will be a better fit.
Although we didn’t mention it as the last one, running containers on a virtual machine should be a last resort.
Azure Spring Apps is specifically for running applications that use the Spring framework. This includes Spring Boot applications and other modern Spring-based applications. These are designed to run microservices and web apps, typically written in Java.
That said, you don’t always have to stick with Java to use Spring Apps. There are Spring-compatible implementations for other languages like .NET and Node.js.
To use those, you containerise your app and deploy it to Spring Apps on Azure. As long as your app follows Spring principles and patterns, it can run on the platform – even without Java.
Azure Spring Apps is recommended when your team is already invested in the Spring Framework.
Then, it’s a great managed service that provides the supporting infrastructure for the Spring Framework (like session management, deployment orchestration, and scaling) without the need to build or maintain that infrastructure yourself. Therefore, you focus on building and running your apps.
If you’re not using Spring, it won't be useful to you.
Azure Batch is designed for high-performance computing. Batch processes large amounts of data across a cluster of VMs on Azure.
It enables you to orchestrate VMs, run them for a specified period, and then shut them down. Hence, your costs can stay in line with what you're actually trying to do.
This is designed for processing large datasets that you wouldn't otherwise handle with tools like Data Factory or Databricks. It’s designed to scale up, potentially dozens or even hundreds of VMs, providing you with thousands of cores to process data.
Sometimes your workload involves a complex software setup. In those cases, you don’t want Azure Batch to install everything from scratch across every node. Instead, you can build the environment inside a container. Azure Batch pulls that container, runs the job inside it, and then shuts everything down when the job’s complete.
Akin to Spring Apps or App Services, you’re running third-party code inside a container. Yet, in this case, it’s optimised for data processing at scale.
Use Azure Batch when you need to run large-scale, parallel, or high-performance computing (HPC) jobs across multiple virtual machines. It's specifically designed for workloads that can be broken down into smaller tasks and processed independently.
It’s also a strong option if you need to extend a control plane or process large datasets using containers. By running jobs inside pre-configured containers, you avoid scripting complex software installs on every VM.
Typical use cases include:
When the scale increases, so does the complexity. The best way to elaborate on this further is by laying out all the Azure container services on a single view, which results in this:
As visible in the visual above, there are many options for running containers, but with increasing complexity as scale increases.
AKS is the most scalable yet complex solution. But between the simplicity of services like ACI and the full control of AKS, there’s a broad middle ground with more balanced trade-offs.
Before thinking about choosing a container solution, ask yourself these two questions:
The table below breaks down the Azure container services and helps you decide on the right container option for your workloads:
The table below breaks down the Azure container services and helps you decide on the right container option for your workloads:
| Service Name | Choose when... |
| Azure Web Apps | You want to deploy traditional web apps without managing infrastructure, using built-in scaling and deployment slots. |
| Azure Container Instances | You need to run a container quickly without managing servers or orchestration (short-lived, simple workloads). |
| Azure Function Apps | You want to run event-driven, serverless code with automatic scaling and minimal infrastructure concerns. |
| Azure Container Apps (AKS) | You want to run microservices or containerised apps at scale, with Kubernetes benefits and simplicity, but without managing clusters, and you don't need control. |
| Azure Kubernetes Service (AKS) | You need access to the Kubernetes API and full control over orchestration, scaling, and container infrastructure for complex or enterprise-grade workloads. |
| Azure Service Fabric | You're already invested in Service Fabric or need to run stateful microservices with fine-grained control. |
| Azure App Services | You’re deploying monolithic or traditional web apps and want to move to containers without changing the app model. |
| Azure Red Hat OpenShift | You need an all-in-one Kubernetes platform with built-in CI/CD, monitoring, security, and registry integration. |
| Azure Batch | You need to process large datasets or run parallel jobs at scale using containers, often for HPC or scheduled tasks. |
| Azure Spring Web Apps | Your team is heavily invested in Spring and wants a managed environment with built-in Spring support and scaling. |
| Azure VMs | You need complete control over the OS and runtime, or are running legacy workloads that don’t fit PaaS models. |
Microsoft also has a great decision tree to help you further decide for the right solution:
As is visible above, the diagram includes a focus on Lift and Shift and Cloud-optimised scenarios:
There are also some other, more niche options for container offerings on Azure. These are slightly different from the ones discussed before.
Although Azure Arc isn’t a container platform, it’s worth including. It’s more like a control plane extension for managing Kubernetes clusters, regardless of where they run.
You can use it with:
Wherever your Kubernetes cluster runs, Azure Arc lets you:
It doesn’t run containers itself, but it provides orchestration, visibility, and control over container workloads across distributed Kubernetes setups, eliminating the need to manage each cluster manually.
Normally, Databricks doesn’t come to mind when discussing container platforms, but it can run containers.
Databricks is primarily used for writing data processing jobs (batch or streaming) using languages such as R, Python, and SQL-like expressions.
However, if you want to use a language that Databricks doesn’t natively support, or run a tool that isn’t built into Databricks, you can put that code in a container. Then Databricks can orchestrate that container the same way it runs its native jobs.
Example: You write data processing logic in C, containerise it, and run it inside Databricks as if it were a native component.
Nearly everyone wants full scalability and flexibility, especially modern applications that require on-demand scaling. However, not all Azure solutions offer this.
Azure Container Apps (ACA) for example, doesn't offer the level of control or scaling options some applications demand. Other options, such as App Service, Azure Functions, or ACI, also won't move the needle here.
AKS offers infinite scalability, plus that control. However, it also comes with complexity, a steep learning curve, and the need for in-house Kubernetes expertise, which is not an option for every organisation. That’s where AKS control steps in.
If you want maximum scalability and run your workloads in AKS with complete control, without having to manage Kubernetes, Intercept offers you a fully managed Kubernetes solution with AKS Control.
With AKS control, we provide a fully managed AKS. From containerisation to AKS cluster management, we manage setup, scaling, maintenance and optimise performance so you can grow your business with ease.
Discover how AKS control benefits your organisation!