Many engineers get lost in Azure’s services for running containers. Starting with the basic Azure container services, the cloud provider quickly developed other options like AKS and Azure Container Apps to give users even more options of where and how to run containers.
A high number of container-as-a-service solutions Azure offers address the needs of enterprises looking to move legacy monolithic applications to the cloud and containers, decreasing application deployment and management complexity at the same time. But Azure’s offering spans more than that.
You can find plenty of easily accessible information about Azure service offerings for running containers. But there aren’t many direct comparisons in terms of pricing. At the end of the article, we added a table of prices normalized based on compute resources. That way, you can compare these services like apples to apples. But first, let’s get through the high-level functionality of each service.
Only interested in pricing? Jump directly to the table with our calculations.
List of Azure compute services where you can run containers
Azure’s offer is so broad that it’s easy to quickly get lost in all of the available options. For compute, Azure prepared a handy breakdown of all the hosting models for the resources your application runs on.1
To run a container on Azure, you can choose from the following services:
- Azure Virtual Machines – deploy and manage VMs within an Azure virtual network. This option should be used as a last resort if there’re no other means to reach the desired customization level. This will require handling additional complexity and work around managing a virtual machine on your own.
- Azure App Service – a handy managed service for hosting all kinds of web apps, mobile app backends, RESTful APIs, or business automation processes.
- Azure Functions – this is a managed function as a service (FaaS) service, a popular choice for serverless architectures.
- Azure Kubernetes Service – AKS is a managed Kubernetes service for running containerized applications with advanced and highly customizable orchestration functionality.
- Azure Red Hat OpenShift – yet another flavor of Kubernetes in Azure. Red Hat OpenShift offers additional security and observability features out of the box, but at the expense of increased price.
- Azure Container Apps – this managed service was developed on top of Kubernetes to help devs simplify the deployment of containerized applications without worrying about orchestration or infrastructure.
- Azure Container Instances – an efficient, but pretty basic service for running containers in Azure. You don't have to dabble in virtual machine provisioning or adopt a higher-level service.
- Azure Spring Apps – a managed service created and optimized for hosting Java’s Spring Boot apps.
- Azure Service Fabric – a platform for distributed systems that can run in many environments, be it Azure or on-premises. It was developed as an Azure custom orchestration platform way before Kubernetes got mainstream.
- Azure Batch – a managed service for large-scale parallel and high-performance computing (HPC) applications. As the name implies, it is mostly suited for scheduled jobs.
Overview of Azure containers hosting options
Virtual Machine (i.e. running containers standalone)
You can adopt a DIY approach and provision an Azure VM, install a container runtime on it, and run your containers there. But you’ll have to deal with all the responsibilities around the configuration, management, and maintenance.
Going for a managed service just makes more sense – unless you need full control over the underlying operating system or you’re planning to customize things in a way that’s not supported by any of Azure’s PaaS services. Running a virtual machine on your own should be used as the last tool in the box.
Azure App Service
Container hosting from App Service mainly supports web apps or APIs. If that’s your case and you can make it work without complex orchestration, this may be a good option. You don’t need to deal with as much management and get many features in exchange.
But if your workload is anything else than a web app or API, you’re better off using a different service. App Service doesn't let you expose your service on ports or traffic different from HTTP(S). The service is also a bad choice if you expect large-scale bursting.
Price-wise App Service is only a little more expensive than standalone VMs. But its basic and standard plans support only Linux containers. If you’re planning to run Windows, you’ll need the Premium V3 plan, which can get pretty expensive.
Azure Functions
If you have a function-based or short lived serverless workloads and want to use containers to develop and deploy it, Azure Functions is a great pick. You’ll get all the features like vNet integrations, triggers, and bindings.
However, if your application doesn’t really fit into the serverless universe, there’s no point in choosing Azure Functions.
What about the price of Azure Functions? Custom containers often end up requiring a pricier premium or always-on consumption tiers that are bound to increase your expenses. It’s the priciest solution when comparing resources cost per runtime. But you only get charged for only what you run. Great cost optimization when running infrequent requests, but get extremely expensive when business grows. This behavior caught many people off guard
Azure Kubernetes Service (AKS)
This is the fully managed Kubernetes service from Azure, where you can still customize the machines where your workloads run. A great pick for containers that need comprehensive orchestration or use advanced Kubernetes features.
However, you still need to know your way around K8s and how deploying applications to this service works. So, if you aim to run a few containers, AKS will bring too much complexity and overhead. Pick an Azure PaaS offering instead like Azure Container Apps.
What about AKS pricing? The solution costs as much as the VMs where your containers run - but note that some space is reserved for Kubelet running on every node.
Azure Red Hat Openshift (ARO)
ARO gives you a bunch of extra management and integration services on top of Kubernetes. Plus it is fully integrated into the RedHat / IBM ecosystem. If you could use them, great – ARO is your choice. If you don’t, stick to a service like Azure Kubernetes Service.
This is a pricey option because you need to count in the costs for master, additional infrastructure nodes and licenses. Still, the cost of this service is justified for enterprises who look at the additional benefits:
- Managed observability stack out of the box. It runs on aforementioned infrastructure nodes. Which are automatically upscaled if/when the cluster grows.
- Advanced security and user management. It’s a more strict environment compared to kubernetes defaults to allow everything at the start.
- Cluster management is abstracted by an additional OpenShift orchestration layer. It prevents direct access to kubernetes API, hence lowering the possibilities of what could be customized there. It’s a pro and con at the same time, as you can do less and break less too.
- Enterprise-grade security – you get top compliance, operations, and security with SLA of 99.95% and plenty of certifications (PCI DSS, ISO 27001, SOC 2 Type II, and more).
Azure Container Apps (ACA)
This service was designed to offer the same benefits as AKS but with less complexity to deal with. If you need an orchestrator and ACA has the features you need, go for it. You’ll remove a lot of management and maintenance tasks from your schedule. This should be the first option to look at if kubernetes complexity is not required.
The service is also a good choice for applications that scale dynamically as it supports HTTP and KEDA scaling, as well as scaling to zero. If you want more control or require a feature that ACA doesn’t have – AKS is your next bet.
What about the costs? ACA charges you per container runtime instead of hourly pricing of VMs where your container runs. As you can see in the table below, it can get pricey, but you’d be actually using all these resources, where in kubernetes your cluster might run half empty if not configured properly.
Azure Container Instances (ACI)
This solution works well if you just need to run a container and not much else. ACI is also helpful for running many instances of the same container or dynamically scaling up the number of containers in use. It makes sense to pick ACI over other services if you have a job-based workload that runs for a limited time – or an on-demand service.
Note that ACI isn’t an orchestrator. If your containers need a bit more complicated orchestration, or you’d like to have more control over the underlying hardware, ACI isn’t a good choice. The same is true for scenarios like private container-to-container networking.
Another limitation is container size. If you need containers that are larger than 4 cores and 16 GB RAM, ACI can’t help you. Another issue relates to large container images - if you have them, expect a slow start time – that’s because ACU needs to download the container image every time it’s run.
What about the pricing? As you can see in the table below, ACI is slightly more expensive than an analogous VM.
Spring Apps
A fully managed service for Spring developers, which helps them to manage the lifecycle of Spring Boot applications. Choosing this service would be a good choice for migrating a Spring project from self-hosted infrastructure to the cloud since it wouldn’t require many additional engineering expenses to make applications cloud-ready.
Spring Apps includes monitoring and diagnostics, configuration management, service discovery, CI/CD integration, and blue-green deployments. The service also comes with its joint engineering, operation, and integration from Microsoft and VMware.
Service Fabric
This orchestrator had one advantage – it offered the Actor framework built into the platform. It is a custom Azure orchestration framework which was built ten years ago. If you don’t know what it is and why you should use it. You can achieve the same with AKS and DAPR.
Consider choosing it only if you require specific functionality that’s only available there. Or if your project is already built into this platform. Otherwise, Kubernetes with the help of AKS or ACA is a better alternative.
Azure Batch
If you’re after a service that meets your specific requirements around job processing, these will be more important than what you need as a container hosting platform. Using containers with Batch improves the management of development and deployment.
Pick it if you have a job-based batch workload and are looking to use containers for enhancing your development and deployment process. Workloads that don’t match the job-based approach better run elsewhere.
How to pick the right Azure containers service
Consider these aspects when reviewing the services Azure offers for containers:
- Your knowledge of and skills around container orchestrators like Kubernetes – are you ready to take on configuration tasks? Do you know the Kubernetes ecosystem well? If you don’t, Azure still offers a bunch of services you can use to run your application using this orchestrator.
- Your familiarity with the service offering from Azure – some Azure services are more complex, while others do the job for you. Having clarity around the service offering, together with its pros and cons, is a basic condition.
- The application you’re looking to containerize – Azure offers a bunch of services that clearly target the legacy modernization use case. The good news is that you can carry this process out gradually instead of migrating everything instantly (and facing a bunch of issues).
- The money you’re willing to spend – if you go through all of those services, the pricing will turn out to be the deciding factor. Azure makes moving applications to the cloud and containers easy, but you’ll always encounter some extra fees.
Azure provides a handy decision tree that helps to understand your options:
Source2
The diagram refers to two migration strategies:
- Lift and shift – where you don’t make any code changes or redesign your services for the cloud, just move it there.
- Cloud optimized – you refactor an application to fully benefit from the cloud-native capabilities of Azure.
I strongly recommend checking out Azure's materials if you need more information on the hosting models, networking, DevOps issues, scalability, availability, security, and other criteria.3
There’s one more aspect that’s worth considering here: pricing.
Pricing comparison for Azure containers services
To compare the pricing of these services, let’s normalize the price of each service.
I chose a pretty old general purpose family: Dv3-series. It’s the most common machine family throughout the Azure ecosystem and is suggested as the default instance for many services.
Let’s use the Standard_D4_v3 instance as an example. We’ll also use the East US region and Linux OS. This instance has 4 vCPUs and 16GiB of RAM and costs $0.192 per hour. Selecting a larger instance doesn’t give any price advantage per given resource.
Note: Normalizing Standard_D4_v3 to separate CPU and RAM usage per month requires a specific formula. We’re working on a detailed article on how it’s calculated and will share our results pretty soon.
Considering that the article is not read by robots we’ll use pricing units per month so it’s easier to comprehend for humans.
| Service Name | Normalized 1 vCPU / month | Normalized 1 GiB RAM / month | Resources Overhead |
Final 1 vCPU / month cost |
Final 1 GiB Ram / month cost |
| Virtual Machine | $22.81 | $3.06 | - | $22.81 | $3.06 |
| Azure App Service | $36.83 | $4.93 | - | $36.83 | $4.93 |
| Azure Functions | $126.29 | $8.98 | - | $126.29 | $8.98 |
| Azure Kubernetes Service | $22.81 | $3.06 | ¹ Kubelet reserved CPU 2% Mem 16% Optional $73 for control plane 99.95% SLA |
$23.27 | $3.55 |
| Azure Red Hat Openshift (ARO) | $22.81 | $3.06 | Red Hat Licensing ~+89% ¹ Kubelet reserved CPU 2% Mem 16% ² Master and Infra nodes. At least 6x Standard_D8s_v3 (+$1681.92/month) |
$43.98 | $6.71 |
| Azure Container Apps | $63.07 | $7.89 | - | $63.07 | $7.89 |
| Azure Container Instances | $29.57 | $3.25 | - | $29.57 | $3.25 |
| Azure Spring Apps | $55.78 | $6.28 | - | $55.78 | $6.28 |
| Azure Service Fabric | $29.57 | $3.25 | - | $29.57 | $3.25 |
| Azure Batch | $22.81 | $3.06 | - | $22.81 | $3.06 |
This table considers costs only related to compute resources.
¹ For a 4 CPU and 16 GiB node. The percentage is smaller if you use larger nodes.
² ARO requires running control-plane and infrastructure nodes - three of both, so six nodes in total. Their size depends on the cluster size. These nodes are upscaled vertically (ARO control plane requirements).4
Summary
There are plenty of offerings to choose from when thinking about where to run your containers in Azure. A wide range of options covers many different use cases. But at the same time, it’s not that easy to select which one is best suited for your use case now, let alone predict if your choice will work in the future.
Azure developed and released the above selection of services throughout the last decade. More legacy services like Service Fabric have technological disadvantages compared to Kubernetes orchestration, but they can’t be decomposed because of existing users and systems. So one has to be careful when choosing where to build a green field system to not select outdated technologies.
Lastly, as shown in the pricing table, there are big differences in how these services are priced. Choosing the Functions service might look cheap at first as you pay only for how long the application runs, but you might go broke once your application takes off and you achieve business success, but at the same time are locked into an unreasonable cloud deal.
At the same time choosing Kubernetes as a starting point for a simple application would create a lot of engineering and cost overhead, which would obviously be better spent on creating value for the product you’re developing.
At the end of the day, you’re the one responsible for choosing the right service because you’re the only person out there who fully understands the current and possible future states of your application.
Wherever you run Azure containers, don’t forget to secure them
Take a look around these Azure container services to pick the ones matching your needs and level of complexity. And no matter where you end up running them, don’t forget about security.
If you happen to pick Azure Kubernetes Service, here’s a handy guide to help you achieve airtight AKS security for your cluster. Download it here
References
- [1] - https://learn.microsoft.com/en-us/azure/architecture/guide/technology-choices/compute-decision-tree
- [2] - https://learn.microsoft.com/en-us/azure/architecture/guide/technology-choices/compute-decision-tree
- [3] - https://learn.microsoft.com/en-us/azure/architecture/guide/technology-choices/compute-decision-tree
- [4] - https://learn.microsoft.com/en-us/azure/openshift/support-policies-v4#control-plane-nodes
Top comments (1)
Hi, mean no offence on this article. The last paragraph is the major hurdle to containerisation on Azure - security.
Have gone through the initial joy and ultimate Azure pain of setting up containers for a client to run a .Net application. There are some major issues people forget to explain. For example - if you are not running Linux (i.e. an older version of .Net Framework), many of the ways to run a container aren't available. Another issue is that some features for Logic Apps behind a VPN Gateway are being removed. Azure Functions can only run Linux container images. Right now, I am experimenting with Azure Service Fabric, everything is a mountain to climb.
I avoided Kubernetes as a team member said they weren't a fan of it, but maybe that is a solution.
The probable solution will be to run a VM server instance and forget about Docker altogether as I see there being little chance that most developers will spend weeks maintaining certificates and container instances.
I could also just convert the console application to a web application and accept a secure key but it feels rubbish.
I heard that AWS does a far better job of securing containers.
Perhaps you could put out a more detailed overview of securing an application in a followup post?