Container Apps vs AKS: the choice is who runs it

Most Container Apps vs AKS decisions are made before anyone asks the question. The application is described as cloud-native, cloud-native is heard as Kubernetes, and Kubernetes on Azure means AKS. The cluster gets provisioned in week two.

Microsoft’s own comparison starts from a different place. Container Apps is itself built on Kubernetes, along with Dapr, KEDA and Envoy. What it does not give you is direct access to the Kubernetes APIs, and Microsoft’s instruction is precise: if you require access to the Kubernetes APIs and control plane, use AKS. If you want Kubernetes-style applications without that, Container Apps provides a managed experience, and Microsoft notes that many teams prefer to start there.

So the question in Container Apps vs AKS is not whether the application is cloud-native. Both host cloud-native applications. The question is whether you need the control plane, and whether you have the people to run it.

What you are actually choosing between

The documentation makes the trade-off unusually concrete.

The six nodes are worth pausing on. Microsoft’s production recommendation is three in the system node pool and three for each user node pool. That is a floor of infrastructure that exists before your first application runs, and it has to be patched, upgraded and monitored whether or not the application is busy.

Container Apps has no equivalent floor. It scales to zero.

AKS Automatic narrows the gap, not the question

AKS now comes in two forms. With AKS Standard, the cluster lives in your subscription and you manage its configuration and operations. With AKS Automatic, Azure manages node management, scaling, security defaults and upgrades.

That is a real reduction in operational effort, and it changes the calculation for teams who need the Kubernetes API but not the burden. Microsoft is clear about the cost: Automatic limits the available topology options. It does not remove the learning curve of Kubernetes itself, which Microsoft describes as significant for teams new to it.

So Automatic answers “we need AKS but cannot staff it”. It does not answer “do we need AKS”.

The two reasons to need AKS

Reading the guidance closely, the case for AKS rests on a short list.

One: you genuinely need the Kubernetes API. Custom operators, specific Cloud Native Computing Foundation tooling, control over orchestration that an abstraction does not expose. This is the reason Microsoft states directly.

Two: you need security boundaries a Container Apps environment cannot provide. This one is subtler and more common, and it is where teams actually get caught.

A Container Apps environment is a single security boundary. Inside it, communication between applications is unrestricted, and every application shares one Log Analytics workspace. There is no finer-grained access control within the environment.

Microsoft gives a worked example that is worth repeating exactly. A team preferred Container Apps, and chose AKS anyway, because their security team required deny-by-default network controls between colocated workload components. That is an AKS capability, delivered through Kubernetes network policies.

There is a middle path Microsoft also names: if a workload has multiple components and security boundaries, deploy multiple Container Apps environments. That works when the components can be separated. It does not work when they must sit together and still be walled off from each other.

A related reason sits alongside these. AKS is commonly used to host several unrelated workloads on one platform, isolated by namespaces. Container Apps and App Service work best for a single workload component, or closely related components with a similar life cycle owned by one team. If the plan is a shared platform for many teams, that points towards AKS.

Outside those situations, the documentation does not give a reason to choose AKS. Wanting an application to be cloud-native is not one.

The cluster that did not need to exist

A recent platform review shows the pattern cleanly. A client was building an internal approvals workflow application: around a dozen endpoints, no custom operators, nothing specific to the Cloud Native Computing Foundation ecosystem. It ran on AKS because the team lead had run Kubernetes at a previous job, and it was the platform he knew.

Eighteen months later three different people had touched the cluster, and none of them owned the upgrade cadence. It was two minor versions behind, and nobody wanted to be the person who scheduled the maintenance window.

That position is more precarious than it sounds. AKS supports three generally available Kubernetes minor versions at once, the latest and the two before it, so two behind is the oldest version still in support. The Kubernetes community ships a new minor version roughly every four months, and once AKS adds it, the oldest version leaves support 30 days later. From then on the cluster receives only platform support, which excludes security patches and support for Kubernetes components. Catching up is not a single upgrade either: a supported cluster that is not on long-term support has to move one minor version at a time.

Nothing about that workload required AKS. There was no security boundary forcing the choice, no need for the Kubernetes API, and no plan to host other workloads alongside it. It would have fitted Container Apps from the first day. The choice was made on familiarity, and its cost arrived later, in a form nobody had budgeted for.

What it costs to reverse

This is the part most comparisons leave out, and it is the part that should decide how carefully the choice is made.

Microsoft is explicit that network design decisions have long-term consequences, because changing them often requires you to redeploy workloads. IP address planning, load balancing, service discovery and private networking all differ between these services. Moving from one to the other is not a configuration change. It is a migration.

That asymmetry matters in both directions, but not equally. Moving from Container Apps to AKS when a genuine need emerges is a planned piece of work with a clear reason. Running AKS for years on a workload that never needed it is a cost that never produces a decision point, because nothing breaks. The cluster just keeps needing upgrades.

Service levels add a quieter version of the same cost. Container Apps SLAs are simple to calculate. AKS has separate SLAs for the control plane and the node pools, which have to be compounded, so the availability you promise the business depends on arithmetic the team has to get right.

Our position: default to Container Apps, and make AKS earn its place

In our view the default for a new containerised workload on Azure should be Container Apps, and AKS should be chosen for a named reason from the short list above rather than by assumption.

The case is not that AKS is worse. It is more capable, and for the right workload it is the correct answer. The case is about who runs it. We think the most useful question in any compute choice is who operates this at 2am, eighteen months from now, and whether they can actually do it. It is the same question we ask about integration design, and it applies here for the same reason.

That makes the risk less an AKS problem than an ownership problem that AKS makes worse, because the platform never stops needing attention. A cluster without a dedicated owner does not fail. It quietly stops being current, and by the time anyone notices, bringing it back up to date is a bigger project than the original build was.

Version lag is the most measurable form of it. In the platform reviews we run, most clusters without a dedicated platform team are at least one minor Kubernetes version behind current, and it is rarely something anyone had flagged as a risk before the review looked. Part of that lag is built in: a cluster created through the Azure portal, CLI or PowerShell defaults to the version one behind the latest, so it starts a minor version behind before anyone has done anything wrong.

The reverse mistake is real too. We would not recommend Container Apps for a workload whose security model requires deny-by-default traffic between components that must share an environment. Forcing that into an abstraction that cannot express it produces a design that passes review and fails audit.

If the answer is AKS but the team is thin, AKS Automatic is the right starting point, accepting the topology limits. If the platform will outlive the project team, the question of who holds it afterwards is an operating model question as much as a technical one, and the difference between a managed service and a project is where that gets decided.

Two things that do not differentiate them

Worth saying, because both come up in comparisons as if they settle the matter.

Regions. Every platform in Microsoft’s compute guide, AKS and Container Apps included, is regional. Multiregion resilience needs an external router in front of multiple deployments either way. Neither choice gives you multiregion for free.

Security features in the abstract. AKS exposes more security controls, such as network policies and runtime threat protection. Container Apps exposes fewer, partly because Azure manages more of the underlying infrastructure and those components are not exposed to you. Fewer visible controls is not the same as less secure. The question is whether your specific requirement needs a control only AKS offers.

Where this connects

The compute choice sits inside a landing zone, and the boundaries around it matter as much as the platform. Choosing between the landing zone accelerator and a custom build covers the platform underneath.

For migrations rather than new builds, Microsoft recommends a like-for-like approach that defers optimisation unless the timeline and budget support redesign. That is a reasonable argument for not introducing Kubernetes during a lift and shift at all.

Where to start

Write down, in one sentence each, the answers to three questions before choosing.

Do we need direct access to the Kubernetes API, and for what specifically? Do we need deny-by-default network controls between components that must share an environment? Will this platform host several unrelated workloads for different teams?

If all three answers are no, start with Container Apps. If any answer is yes, AKS has earned its place, and the next question is whether Standard or Automatic fits the team that will run it.

Then, as Microsoft itself says, no decision is final until developers try the service. Build something small on the candidate before committing the estate to it.

Veratas does the enterprise architecture work behind platform decisions like this, and delivers on Microsoft Azure.

If you are running AKS and cannot name the reason, talk to our team. Sometimes the answer is that it is right. Sometimes it is a cluster nobody needed.

Frequently asked questions

What is the main difference between Container Apps and AKS? Container Apps is built on Kubernetes but does not give direct access to the Kubernetes APIs, and Azure manages the orchestration. AKS provides the Kubernetes API and control plane and runs any Kubernetes workload. Microsoft’s guidance is to use AKS if you require that API access, and notes many teams start with Container Apps.

When should I choose AKS over Container Apps? When you need direct Kubernetes API access, when your security model needs deny-by-default network controls between components that share an environment, or when one platform will host several unrelated workloads isolated by namespaces. A Container Apps environment is a single security boundary with unrestricted internal communication.

How many nodes does AKS need for production? Microsoft recommends a minimum of six for production: three in the system node pool and three for each user node pool. Container Apps is serverless and can scale to zero, so it has no equivalent infrastructure floor.

What is AKS Automatic? A form of AKS where Azure manages node management, scaling, security defaults and upgrades. It reduces operational effort for teams that need Kubernetes but cannot staff full cluster operations, at the cost of limiting the available topology options.

Is it easy to move from Container Apps to AKS later? Not trivially. Microsoft notes that network design decisions have long-term consequences because changing them often requires redeploying workloads. Moving between the two is a migration rather than a configuration change, which is why the reason for the choice should be written down.

Why do AKS clusters fall behind on Kubernetes versions? Usually because nobody owns the upgrade cadence. AKS keeps needing attention after the project team moves on, and a cluster without a dedicated owner does not fail, it just stops being current. In the platform reviews we run, most clusters without a dedicated platform team are at least one minor version behind. AKS only supports the latest three minor versions, and Microsoft’s documentation notes that upgrading at least once a year is what keeps a cluster on a supported version.

Does AKS give better multiregion resilience than Container Apps? No. Both are regional services, and multiregion topologies for either need an external router in front of multiple deployments, one per region.

Gaurav Aggarwal

Cloud and enterprise architect with 17 years of experience across data platforms, integration and application development. Focus areas include Azure architecture, cloud-native application design, and ERP to data platform integration.