Azure Deploy Targets in 2026: App Service vs Container Apps vs AKS

Quick decision tree

• <10K requests/day, single ASP.NET Core service, no special runtime needs → App Service
• Multi-container or non-.NET runtimes, want autoscale and Dapr but not Kubernetes → Container Apps
• You need raw Kubernetes for operator-pattern workloads or extreme scale (>1M req/min) → AKS

If you don't recognise the AKS row from your own pain, you don't need AKS yet.

App Service: the default starting point

The simplest deploy target Azure offers. Push a container or a .NET artifact; managed TLS, custom domain, slot-based deploys, autoscale up to 30 instances.

az webapp up \
  --name prepstack-api \
  --runtime "DOTNETCORE:9.0" \
  --location centralindia

Cost: ~$13/mo for B1 (always-on, 1.75 GB RAM) up to ~$280/mo for P1V3 (premium, 8 GB RAM, scaling).

You outgrow App Service when:

• Need sidecars (a Dapr proxy, an auth proxy)
• Workload is not always-HTTP (background workers without a separate Service Bus consumer)
• Cold start on consumption tier hurts UX

Container Apps: the modern middle ground

Built on Kubernetes + Dapr + KEDA but Microsoft hides 90% of it. You get scale-to-zero, traffic splitting between revisions, and event-driven autoscale without running your own cluster.

# containerapp.yaml
properties:
  configuration:
    ingress:
      external: true
      targetPort: 8080
    secrets:
      - name: db-conn
        value: "{{cli-injected}}"
  template:
    containers:
      - name: api
        image: ghcr.io/myorg/api:1.4.2
        resources: { cpu: 0.5, memory: 1Gi }
        env:
          - name: ConnectionStrings__Default
            secretRef: db-conn
    scale:
      minReplicas: 1
      maxReplicas: 20
      rules:
        - name: http-rule
          http:
            metadata:
              concurrentRequests: "30"

The HTTP scale rule says "spin up a new replica when concurrent requests exceed 30". KEDA-driven, runs entirely on Azure's managed cluster.

Cost: pay-per-vCPU-second + memory-second. For a workload that idles 80% of the time, you'll pay less than App Service.

You outgrow Container Apps when:

• You need fine-grained pod scheduling, custom CNI, or your own ingress controller
• Workload has tight latency SLOs and you can't tolerate cold-start
• You need GPUs, Windows containers, or sidecars that Container Apps doesn't support

AKS: full Kubernetes

The full ride. Worth it when you genuinely need:

• Custom operators (e.g. Strimzi for Kafka)
• Direct kubelet access for high-performance workloads
• Multi-tenant clusters with namespace isolation
• Hybrid scheduling across Azure + on-prem

A baseline AKS cluster runs ~$70/mo just for the control plane (if you use the "Standard" tier). Add nodes from there. Total cost-of-ownership including SRE labour is 5-10x Container Apps.

The migration ladder

Most apps follow this path:

1. App Service for the first 6-12 months
2. Container Apps when you split into 2-5 services or need event-driven scale
3. AKS only if a specific workload demands it — and even then, only that workload

Skipping straight to AKS for "future-proofing" is the most expensive mistake I see.

Cost reality check

For a typical small SaaS (1M req/month, mostly HTTP, no exotic requirements):

Target	Monthly cost (rough)	Engineering hours to operate
App Service B1 + SQL Basic	$40	0–2
Container Apps + Azure SQL S0	$80	2–5
AKS Standard + SQL S0	$300+	20+

Pick the smallest tier whose ceiling you'll hit within a year. Upgrade in place when the time comes — Azure makes the App Service → Container Apps path painless.