Choose an Azure container service

Azure offers a range of container hosting services that are designed to accommodate various workloads, architectures, and business requirements. This container service selection guide can help you understand which Azure container service is best suited to your workload scenarios and requirements.

How to use this guide

This guide includes two articles: this introduction article and another article about considerations that are shared across all workload types.

This introduction article describes the Azure container services that are in scope for this guide and how the service models compare in terms of tradeoffs between configurability and opinionated solutions, such as customer-managed versus Microsoft-managed approaches. After you identify candidate services based on your service model preferences, the next step is to evaluate the options against your workload requirements by reviewing the article on shared considerations for networking, security, operations, and reliability.

This guide takes into consideration tradeoffs that you might need to make, based on the technical requirements, size, and complexity of your workload and the expertise of your workload's team.

Azure container services in scope for this guide

This guide focuses on a subset of the container services that Azure currently offers. This subset provides a mature feature set for web applications and APIs, networking, observability, developer tools, and operations. These container services are compared:

For a complete list of all Azure container services, see the container services product category page.

Service model considerations

The service model provides the broadest insight into the level of flexibility and control that any Azure container service provides, in exchange for its overall simplicity and ease of use.

For a general introduction into the terminology and concepts around service models, including infrastructure as a service (IaaS) and platform as a service (PaaS), see Shared responsibility in the cloud.

Comparing the service models of Azure container solutions

AKS

As a hybrid of IaaS and PaaS, AKS prioritizes control over simplicity. Though AKS streamlines the management of the underlying core infrastructure, this VM-based platform is still exposed to your applications and requires appropriate guardrails and processes, like patching, to ensure security and business continuity. The compute infrastructure is supported by additional Azure resources that are hosted directly in your subscription, like Azure load balancers.

AKS also provides access to the Kubernetes API server, which enables you to customize the container orchestration and thus deploy projects from the Cloud Native Computing Foundation (CNCF). Consequently, there's a significant learning curve for workload teams that are new to Kubernetes. If you're new to containerized solutions, this learning curve might be a deterrent. The following PaaS solutions offer a lower barrier to entry. You can move to Kubernetes when your requirements dictate that move.

Azure Container Apps

Container Apps, a PaaS offering, balances control with simplicity. It offers both serverless and dedicated compute options, which abstract away the need to patch the operating system or build guardrails around applications, relative to the operating system. Container Apps also completely abstracts away the container orchestration API and provides a subset of its key functionality through Azure APIs that your team might already be familiar with. Additionally, Layer 7 ingress, traffic splitting, A/B testing, and application lifecycle management are all fully available out of the box.

Web App for Containers

Web App for Containers is also a PaaS offering, but it provides more simplicity, and less control, than Container Apps. It abstracts away container orchestration but still provides appropriate scaling, application lifecycle management, traffic splitting, network integration, and observability.

Hosting model considerations

You can use Azure resources, like AKS clusters, to host multiple workloads. Doing so can help you streamline operations and thereby reduce overall cost. If you choose this path, here are a few important considerations:

• AKS is commonly used to host multiple workloads or disparate workload components. You can isolate these workloads and components by using Kubernetes native functionality, like namespaces, access controls, and network controls, to meet security requirements.

  You can also use AKS in single-workload scenarios if you need the additional functionality that the Kubernetes API provides and your workload team has enough experience to operate a Kubernetes cluster. Teams with less Kubernetes experience can still successfully operate their own clusters by taking advantage of Azure managed add-ons and features, like cluster auto-upgrade, to reduce operational overhead.

• Container Apps should be used to host a single workload with a shared security boundary. Container Apps has a single top-level logical boundary called a Container Apps environment, which also serves as an enhanced-security boundary. There are no mechanisms for additional granular access control. For example, intra-environment communication is unrestricted, and all applications share a single Log Analytics workspace.

  If the workload has multiple components and multiple security boundaries, deploy multiple Container Apps environments, or consider AKS instead.

• Web App for Containers is a feature of App Service. App Service groups applications into a billing boundary called an App Service plan. Because you can scope role-based access control (RBAC) at the application level, it might be tempting to host multiple workloads in a single plan. However, we recommend that you host a single workload per plan to avoid the Noisy Neighbor problem. All apps in a single App Service plan share the same allocated compute, memory, and storage.

  When you consider hardware isolation, you need to be aware that App Service plans generally run on infrastructure that's shared with other Azure customers. You can choose Dedicated tiers for dedicated VMs or Isolated tiers for dedicated VMs in a dedicated virtual network.

In general, all Azure container services can host multiple applications that have multiple components. However, Container Apps and Web App for Containers are better suited for a single-workload component or multiple highly related workload components that share a similar lifecycle, where a single team owns and runs the applications.

If you need to host disparate, potentially unrelated application components or workloads on one host, consider AKS.

The tradeoff between control and ease of use

AKS provides the most configurability, but this configurability comes at the cost of increased operational overhead, as compared to the other services. Although Container Apps and Web App for Containers are both PaaS services that have similar levels of Microsoft-managed features, Web App for Containers emphasizes simplicity to cater to its target audience: existing Azure PaaS customers, who find the interface familiar.

Rule of thumb

Generally, services that offer more simplicity tend to suit customers who prefer to focus more on feature development and less on infrastructure. Services that offer more control tend to suit customers who need more configurability and have the skills, resources, and business justification necessary to manage their own infrastructure.

Shared considerations across all workloads

Although a workload team might prefer a particular service model, that model might not meet the requirements of the organization as a whole. For example, developers might prefer less operational overhead, but security teams might consider this type of overhead necessary to meet compliance requirements. Teams need to collaborate to make the appropriate tradeoffs.

Be aware that shared considerations are broad. Only a subset might be relevant to you, depending not just on the workload type but also on your role within the organization.

The following table provides a high-level overview of considerations, including service feature comparisons. Review the considerations in each category and compare them against your workload's requirements.

After reviewing the preceding considerations, you still might not have found the perfect fit. That's perfectly normal.

Evaluating tradeoffs

Choosing a cloud service isn't a straightforward exercise. Given the complexity of cloud computing, the collaboration between many teams, and resource constraints involving people, budgets, and time, every solution has tradeoffs.

Be aware that, for any given workload, some requirements might be more critical than others. For example, an application team might prefer a PaaS solution like Container Apps but choose AKS because their security team requires deny-by-default network controls between colocated workload components, which is an AKS-only feature that uses Kubernetes network policies.

Finally, note that the preceding shared considerations include the most common requirements but aren't comprehensive. It's the workload team's responsibility to investigate every requirement against the preferred service's feature set before confirming a decision.

Conclusion

This guide describes the most common considerations that you face when you choose an Azure container service. It's designed to guide workload teams in making informed decisions. The process starts with choosing a cloud service model, which involves determining the desired level of control. Control comes at the expense of simplicity. In other words, it's a process of finding the right balance between a self-managed infrastructure and one that's managed by Microsoft.

Many workload teams can choose an Azure container service solely based on the preferred service model: PaaS versus IaaS. Other teams need to investigate further to determine how service-specific features address workload or organizational requirements.

All workload teams should use this guide in addition to incorporating due diligence to avoid difficult-to-reverse decisions. Be aware, however, that the decision isn't confirmed until developers try the service and decide based on experience rather than theory.

Contributors

This article is maintained by Microsoft. It was originally written by the following contributors.

Principal authors:

• Andre Dewes | Senior Customer Engineer
• Marcos Martinez | Senior Service Engineer
• Julie Ng | Senior Engineer

Other contributors:

• Mick Alberts | Technical Writer
• Martin Gjoshevski | Senior Customer Engineer
• Don High | Principal Customer Engineer
• Nelly Kiboi | Service Engineer
• Xuhong Liu | Senior Service Engineer
• Faisal Mustafa | Senior Customer Engineer
• Walter Myers | Principal Customer Engineering Manager
• Sonalika Roy | Senior Customer Engineer
• Paolo Salvatori | Principal Customer Engineer
• Victor Santana | Principal Customer Engineer

Next step

Learn more about shared architectural considerations for the services mentioned in this article.