AKS vs Container Apps vs Azure Functions vs App Service: The 2026 Decision Framework

Four compute options, one tired engineer

Azure has, depending on how you count, about 14 ways to run your code. But for 95% of applications the real choice is between four: Azure Kubernetes Service (AKS), Azure Container Apps, Azure Functions, and App Service. Each one trades off developer control, scaling flexibility, and cost in a different way.

The wrong choice costs you months of migration pain and thousands in wasted spend. The right choice sometimes looks boring but ages beautifully. Let's go.

This guide is opinionated. I've shipped production systems on all four. Where I say "use X" I mean it. Where I say "it depends" I'll tell you exactly what it depends on.

The one table you'll screenshot

Memorise this table. It answers 70% of the "which should I use?" questions that come up in architecture reviews.

AKS, when you need everything

AKS is managed Kubernetes. Microsoft manages the control plane; you manage everything else. In 2026 that "everything else" is less painful than it used to be, Azure Linux node images, autoupgrade channels, Karpenter-style node autoprovisioning, and native Azure Monitor for containers make the operational floor manageable.

When AKS is the right call

• You have more than ~6 microservices, each with independent scaling needs.
• You need GPU scheduling (ML training, inference at scale).
• You need node-level controls (taints, tolerations, topology spread).
• You have multi-tenant workloads with strict isolation (Kata containers).
• You rely on the open-source K8s ecosystem (Argo, Istio, Crossplane).

When AKS is the wrong call

• You have a small team and a single monolith. The ops overhead is not free.
• Your traffic is bursty with long quiet periods, you're paying for idle nodes.
• You want to hide Kubernetes from your developers.

Cost reality

Minimum viable production AKS: 2 × Standard_D2s_v5 nodes + Standard Load Balancer + Azure Firewall = ~$350-500/month before you deploy anything. Adding observability (Azure Managed Prometheus + Grafana), backup (Velero), and policy (Azure Policy + OPA) pushes it to ~$700. Budget 1 full-time SRE for every 30-50 production workloads.

Container Apps, the 2026 default for most teams

Azure Container Apps (ACA) is where most new microservices should live in 2026. It's Kubernetes without Kubernetes, built on AKS internally, exposed as a flat environment with apps and revisions. It integrates KEDA for event-driven autoscaling and Dapr for service-to-service calls, state, and pub/sub.

The killer features

• Scale-to-zero. If no traffic, you pay $0 (Consumption plan). Cold start is 1-5 seconds for most container sizes.
• Dapr built in. Sidecar patterns (retry, circuit breaker, distributed tracing) without writing any infrastructure code.
• Blue/green by default. Revisions give you instant rollback.
• KEDA scalers. Autoscale on queue depth, HTTP QPS, or any custom metric.
• Jobs. Run a container-to-completion (batch or cron). Great for Pandas workloads too heavy for Functions.

Limits to know

4 vCPU / 8 GB RAM per replica maximum on the Consumption plan. Dedicated workload profiles (2026) let you go larger (32 GB, GPU) at higher cost. No DaemonSets, no privileged containers, no persistent local disk. For stateful workloads: put state in Cosmos DB or Azure Files.

When Container Apps is the right call

• Event-driven microservices (order events, IoT telemetry).
• HTTP APIs where scale-to-zero saves real money.
• Teams that want Kubernetes benefits without Kubernetes days.
• Multi-language stacks (Go, Python, Node, .NET in the same environment).

Cost reality

Consumption plan: $0.000024/vCPU-second + $0.000003/GiB-second + $0.40 per million requests. A modest microservice (0.5 vCPU, 1 GB, 1M req/month, 24/7) costs ~$32/month. Three services: ~$100/month. No LB fees, it's included.

Functions, still the right answer for small, bursty, integration-y code

Azure Functions is pure FaaS: upload a function, pick a trigger (HTTP, queue, timer, Cosmos change feed, Event Grid, Service Bus), and it runs on demand. The 2026 improvements worth knowing: Flex Consumption (better cold start + VNET at Consumption pricing), OpenAI binding (inject completions without SDK plumbing), and Durable Functions v3 with better observability.

The test for Functions

Ask three questions:

1. Does the work finish in < 10 minutes on Consumption (or < 60 min on Premium)?
2. Is it event-triggered, not a long-running server?
3. Is it stateless (or does it use Durable orchestration for state)?

If yes to all three: Functions. If you're writing a full REST API with 20 endpoints and shared middleware, you will fight Functions. Move to Container Apps or App Service.

Sweet spots

• Webhook handlers (Stripe events, GitHub pushes, SharePoint changes).
• ETL steps (blob-in → transform → queue-out).
• Scheduled jobs (nightly rollups, retention cleanup).
• Glue between SaaS (Salesforce → Dynamics, Slack → Teams).

Cost reality

Consumption: 1M executions free, then $0.20/M + $0.000016/GB-s. Most small apps stay under $5/month. Premium: $170+/month for always-warm instances (kill cold start, add VNET). Flex Consumption: middle ground, pre-warm instances with per-second billing.

Rule of thumb: if your Functions bill is approaching $200/month, you're on the wrong plan. Move to Flex Consumption or reconsider Container Apps.

App Service, the unfashionable workhorse

App Service is the oldest of the four and still the right answer for a surprising number of workloads. It runs Windows or Linux, supports .NET, Java, Node, Python, PHP, and Ruby natively, and handles TLS, autoscale, staging slots, and backups without you writing a line of YAML.

Who still picks App Service in 2026

• Line-of-business apps, internal tools with 50 users. Over-engineering with K8s would be cruel to the team inheriting it.
• WordPress and Drupal, still millions of these, and App Service's managed WordPress offering (with MySQL Flexible Server) is genuinely the cheapest path to production.
• .NET monoliths, App Service's deep .NET integration (native MSDeploy, Application Insights zero-config) beats Container Apps for Windows-based .NET Framework apps.
• Teams that never wanted containers, `git push` and you're deployed.

Cost reality

When App Service is wrong

Anything highly elastic, App Service autoscale is instance-level and coarse. Anything needing custom OS packages, use a container platform. Anything multi-tenant at scale, you'll outgrow the model within a year.

The decision tree

In practice I walk clients through these five questions:

1. Is your workload event-driven and short (<10 min)? → Functions.
2. Is your workload HTTP and bursty (zero traffic at night)? → Container Apps (Consumption).
3. Do you need GPUs, DaemonSets, or advanced K8s features? → AKS.
4. Is it a single monolith or a small set of stable services? → App Service.
5. Are you enterprise regulated with strict isolation needs? → AKS (private cluster) or App Service Isolated v2.

If the answer is mixed, default to Container Apps. It's the easiest to migrate out of (back to AKS if you grow, or to Functions if you shrink).

Migration paths (and how painful each one is)

The least painful path is building for Container Apps from day one. It's effectively 80% of AKS with 20% of the ops burden.

A real migration story: App Service → Container Apps → AKS (and back)

A fintech platform I worked with in 2025 walked the full ladder in 18 months. The journey is instructive because each move was driven by a concrete pain, not by resume-driven architecture.

The lesson: split, don't migrate. Very few orgs need everything on Kubernetes. Keep the regulated, low-churn core on AKS; keep the experimental, high-churn surface on Container Apps or Functions.

What does each platform actually cost at 10, 100, 1000 req/s?

Rough monthly bills, West US 3, Linux, 512 MB average memory, mixed compute/IO workload. These are planning numbers, not commitments.

Functions wins at the bottom, AKS wins at the top, Container Apps is the sweet-spot middle. App Service is a smooth ramp for low-concurrency web apps but loses on raw compute efficiency.

Two traps to avoid. First, the cold-start tax: at 10 req/s on Functions Consumption, every cold start is a revenue hit, budget Flex plan or always-ready instances. Second, the idle-cluster tax: AKS at 10 req/s is paying for nodes you're not using. Scale-to-zero with KEDA or pack multiple services onto the same cluster.

A 90-second decision tree

Post this above your monitor. It has resolved more architecture debates than any whitepaper.

1. Event-triggered, < 10 min runtime, stateless? → Functions.
2. Long-running job, batch, data pipeline? → Container Apps Jobs.
3. HTTP or gRPC service, no k8s experience on team? → Container Apps.
4. Need node-level control, service mesh, strict network policy? → AKS.
5. Legacy monolith, IIS, or Windows stack? → App Service.
6. Everything else, when in doubt? → Container Apps. It's the path of least regret in 2026.

Production checklist: 20 items nobody remembers until outage #1

• Health probe actually checks downstream dependencies, not just /health
• Liveness vs readiness configured, don't bounce pods while they're warming
• Graceful shutdown: SIGTERM handler drains in-flight requests
• Resource requests + limits set; no BestEffort pods in prod
• HPA or KEDA scale metrics match the bottleneck (CPU vs queue depth vs latency)
• Pod Disruption Budgets so node upgrades don't take the app down
• Anti-affinity so all replicas don't land on one node
• Horizontal scaling verified via load test, not assumed
• Image pull secrets + a private registry (ACR with Premium for geo-replication)
• Image scanning in CI (Trivy / Microsoft Defender for Containers)
• Non-root user, read-only root FS, dropped capabilities
• Network policy default-deny, explicit allow rules
• Secrets from Key Vault, not env vars in YAML
• Structured JSON logs → Log Analytics or Grafana Loki
• OpenTelemetry traces, not just metrics, where is the latency?
• SLO defined, error budget dashboard, page-on-burn
• Chaos day scheduled quarterly (kill a pod, a node, a region)
• Backup + restore tested, not just configured
• IaC in git (Bicep / Terraform); no click-ops in prod
• Runbook for every alert, if nobody knows what to do, it's not an alert

Security hardening you can't postpone

Security on container platforms rots quietly. These are the non-negotiables for 2026.

• Workload Identity over client secrets. Federated creds from AKS pods, Container Apps, or Functions straight to Entra ID. Zero stored keys.
• Private Endpoints for every managed service you talk to, Storage, Cosmos, Key Vault, SQL. Close public endpoints in the same PR.
• Defender for Containers on AKS; Defender for App Service on App Service; Defender for Cloud CSPM across everything. The telemetry pays for itself the first time it catches a leaked secret.
• Image provenance. Sign images with Notary v2 + enforce the policy in ACR Tasks or Kubernetes admission controllers.
• SBOMs in CI. Syft + Grype or GHAS Dependency Review. Block PRs that introduce high-severity CVEs.
• Pod Security Admission at restricted in AKS. Privileged workloads must justify themselves with documentation.
• Network policy default-deny, then allow-list. Zero-trust at the pod layer stops most lateral movement.
• Azure Policy + built-in AKS initiative. Enforce these defaults by governance, not hope.

If you can't check 8 of 8 today, pause the next feature and fix the ceiling before the floor.

An observability stack you won't regret

In 2026 the default Azure-native stack has finally become good enough to skip the build-your-own detour.

• Logs. Container logs -> Log Analytics workspace. Structured JSON only. Retention 30 days hot + archive to Storage for compliance.
• Metrics. Managed Prometheus + Azure Monitor. Record both RED (Rate, Errors, Duration) and USE (Utilisation, Saturation, Errors) per service.
• Traces. OpenTelemetry Collector sidecar -> Application Insights. Tail-based sampling at 1% for healthy, 100% for errors.
• Dashboards. Managed Grafana. Template variables per environment. Every service owner curates one dashboard.
• Alerts. Alerts on SLO burn, not raw metrics. If the SLO holds, you sleep.
• On-call. Azure Monitor -> PagerDuty or Incident Manager. Every alert has a runbook link or it gets deleted.

Total cost for a mid-sized system: about $400-900/mo in Log Analytics ingestion, which is cheap compared to the one all-night outage it prevents.

Scaling decisions that bite you at 18 months, not at launch

Most container platform debates focus on day one. Nobody regrets their day-one choice - they regret their day-540 ceiling. Here are the five scaling walls teams hit and what to plan for now.

Wall #1 - the noisy-neighbor ceiling on shared compute

App Service and Container Apps Consumption both use shared underlying infrastructure. At modest load this is invisible. As you approach 500 rps per replica, p99 latency starts to fan out unpredictably because your neighbor is sharing the hypervisor. Teams that grow past this threshold either move to Container Apps Workload Profiles with dedicated capacity, or to AKS. Plan the migration trigger now: what rps or p99 latency number forces the move? Write it on the runbook.

Wall #2 - KEDA scalers you trusted too much

KEDA is fantastic, but every scaler has edge cases. A Kafka scaler that lags the consumer group offset by minutes under heavy load will throttle your scale-out. Test every scaler at 5x expected load, not 1.2x. The pattern that works: combine a KEDA scaler (reactive) with a minimum replica floor sized for normal load (proactive). You pay a little for idle capacity; you sleep through 3 a.m. traffic spikes.

Wall #3 - the region failover that nobody tested

Multi-region readiness isn't a checkbox - it is a muscle. Run a scripted drill quarterly: drain the primary region, confirm DNS failover, confirm data replication lag, confirm the app works end-to-end. Teams that skip this discover, during a real outage, that the secondary region's database firewall never allowed the primary's management subnet, or that a feature flag was only synced to primary.

Wall #4 - cost gradient that reverses

At 10 rps, Functions Consumption is cheapest. At 1,000 rps, AKS on B-series VMs is cheapest. The crossover is around 150-300 rps sustained. Build a quarterly review: pick the three most expensive workloads, model their load in the two alternative platforms, decide whether to migrate. Waiting until cost pain drives the conversation usually means six months of overspend first.

Wall #5 - the platform team bottleneck

AKS is powerful and dangerous. Two AKS clusters and an ops team of four is efficient. Twenty AKS clusters and the same team is a death march. If you can't cap clusters or invest in a platform-as-a-product team with an internal developer portal, Container Apps is the more scalable choice for most enterprises in 2026.

Automation and IaC tooling to use with any of these

Regardless of which compute you pick, automate everything from commit to prod:

• Bicep, Azure-native IaC, terser than ARM, compiles to ARM. Use for Azure-only stacks.
• Terraform + AzureRM provider, if multi-cloud is on the horizon.
• GitHub Actions + azure/login@v2, OIDC federated identity, no secrets.
• Azure Developer CLI (azd), templated deployments; `azd up` works.
• Draft v2, scaffolds Dockerfiles and K8s manifests from source code.
• Radius, Microsoft's open-source application-level abstraction; promising for 2026+.

Open-source tools to add: k9s (terminal UI for K8s), Flux (GitOps), KEDA (standalone scaler), OpenCost (per-namespace cost attribution), kubescape (security posture).