Azure Container Apps vs AKS: A 2026 Decision Matrix

The "Container Apps or AKS?" question has come at me in different shapes from five different customers over the past year. The answer is not "AKS, because it is more enterprise" nor "Container Apps, because it is simpler". It depends on three things: number of workloads, workload type, and team maturity.

In this article I walk through the decision matrix I use with customers, plus three real scenarios where the decision landed differently.

TL;DR Decision Matrix

Scenario 1: Startup With 2 Microservices → Container Apps

At CostSentry.AI we started with an API gateway and a background worker. Two services, one team, zero Kubernetes experience. The decision was easy: Container Apps.

resource caEnv 'Microsoft.App/managedEnvironments@2024-03-01' = {
  name: 'cae-cs-prod'
  location: location
  properties: {
    appLogsConfiguration: {
      destination: 'log-analytics'
      logAnalyticsConfiguration: {
        customerId: laWorkspace.properties.customerId
        sharedKey: laWorkspace.listKeys().primarySharedKey
      }
    }
    workloadProfiles: [
      {
        name: 'Consumption'
        workloadProfileType: 'Consumption'
      }
    ]
  }
}
 
resource apiApp 'Microsoft.App/containerApps@2024-03-01' = {
  name: 'ca-api'
  location: location
  identity: { type: 'SystemAssigned' }
  properties: {
    environmentId: caEnv.id
    configuration: {
      ingress: {
        external: true
        targetPort: 8080
        transport: 'http'
        allowInsecure: false
      }
      secrets: [
        {
          name: 'cosmos-conn'
          keyVaultUrl: '${kv.properties.vaultUri}secrets/cosmos-conn'
          identity: 'system'
        }
      ]
    }
    template: {
      containers: [
        {
          name: 'api'
          image: 'csregistry.azurecr.io/api:1.2.3'
          resources: { cpu: 1, memory: '2Gi' }
          env: [{ name: 'COSMOS_CONN', secretRef: 'cosmos-conn' }]
        }
      ]
      scale: { minReplicas: 0, maxReplicas: 10 }
    }
  }
}

The properties that keep us on Container Apps:

• Scale to zero: night hours cost EUR 0 (development), production keeps minReplicas: 1
• Key Vault integration via Managed Identity: no connection strings in env vars
• Built-in HTTPS with a custom FQDN: no ingress controller to manage
• Revisions and traffic splitting: blue-green deployment in a single YAML

Monthly Azure invoice for the entire CostSentry stack: ~EUR 85. On AKS the cluster alone would cost 5× that.

Scenario 2: Christie's Platform Team, 30+ Microservices → AKS

Christie's is a different reality. Thirty microservices, ten teams, half using Helm, the other half kustomize, some with their own operators for deployment via Argo CD. Container Apps would only deliver a fraction of what the team needs.

Key factors that pushed for AKS:

The cost overhead disappears at 30 workloads – production runs on 9× D8s_v5 nodes, ~EUR 3 600/month, which comes out to ~EUR 120 per workload. On Container Apps 30 workloads would cost multiples of that.

Scenario 3: Nespresso With 9 J2C Applications → AKS With Headroom

Nine applications migrating from on-prem to Azure. The team has Kubernetes experience from a previous gig, uses Terraform, and has GitOps in place. Container Apps was not on the table – the team wanted full control over networking and the service mesh.

Why AKS won despite the lower workload count:

1. They invested in Kubernetes know-how up front – no learning curve cost
2. We plan to grow to 25+ applications by 2027 – AKS scales linearly
3. Compliance requires audit of the Kubernetes API server – Container Apps does not expose this
4. Cilium NetworkPolicy for mTLS and identity-aware ACLs (see March 2026 article)

Edge Cases Where the Decision Is Not Obvious

Event-driven worker with irregular load: Container Apps + KEDA against an Azure Service Bus queue. Zero infra to maintain, you pay only for processed messages. If the worker runs less than 4 hours per day, Container Apps is 3–5× cheaper.

Daily batch processing: Container Apps Jobs (GA since mid-2024). For periodic jobs better than a Kubernetes CronJob on AKS because it does not require a running cluster.

Frontend SPA with API backend: Container Apps for the API + Azure Static Web Apps for the SPA. No reason to reach for AKS.

Cost Comparison for Real Workloads

From my practice – same workload (REST API, 4 vCPU, 8 GB RAM, 8 hours of real traffic per day):

For one application AKS is twice as expensive. For five applications sharing a cluster AKS is cheaper.

Migration Path Container Apps → AKS

If you outgrow Container Apps, the migration is straightforward 90% of the time:

1. Container image – unchanged, same image in ACR
2. Bicep Container Apps definition → Kubernetes manifests:

   # From a Container App:
   #   ingress.external: true
   #   targetPort: 8080
   #   scale.minReplicas: 1
   #   scale.maxReplicas: 10
   apiVersion: apps/v1
   kind: Deployment
   metadata: { name: api }
   spec:
     replicas: 1
     selector: { matchLabels: { app: api } }
     template:
       metadata: { labels: { app: api } }
       spec:
         containers:
         - name: api
           image: csregistry.azurecr.io/api:1.2.3
           resources:
             requests: { cpu: "1", memory: "2Gi" }
   ---
   apiVersion: v1
   kind: Service
   metadata: { name: api }
   spec:
     selector: { app: api }
     ports: [{ port: 80, targetPort: 8080 }]
   ---
   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata: { name: api }
   spec:
     ingressClassName: nginx
     rules:
     - host: api.example.com
       http: { paths: [{ path: /, pathType: Prefix, backend: { service: { name: api, port: { number: 80 } } } }] }

3. Secrets: Container Apps secrets → AKS Secret Store CSI driver pointing at Key Vault
4. Dapr: if you use it, install Dapr on AKS via Helm (10 minutes)

Typically 2–3 sprints per application; the main time-sink is integration testing.

Conclusion

In 2026 Container Apps is a mature platform that covers ~70% of typical cloud-native workloads without the Kubernetes overhead. AKS remains the choice for enterprise environments with 5+ workloads, custom operators, and a need for the full Kubernetes API. Migration between the two is not expensive – the containers stay, only the deployment layer changes.

The rule I repeat to customers: start on Container Apps as long as you have ≤ 5 workloads. Move to AKS when the Container Apps platform overhead starts to bother you – not when you start to suspect it might.

Need help deciding between Container Apps and AKS for your specific stack? Check out our cloud architecture services or reach out for an architecture review.