Eighty-two per cent of organisations running containers now run Kubernetes in production, according to the CNCF Annual Survey released in January 2026. That figure is up from 66 per cent in 2023 and is routinely cited as evidence that Kubernetes has won the container orchestration argument. The conclusion most Azure platform teams draw from it is predictable: when in doubt, choose AKS. That conclusion is wrong. The same survey found that cultural change within the development team is now the single biggest barrier to cloud-native success, cited by 47 per cent of respondents, ahead of training at 36 per cent, security at 36 per cent, and complexity at 34 per cent. The platform that wins the market share data is not necessarily the platform that wins the architecture decision.
The default to AKS is costing Azure platform teams in two ways. The first is financial: AKS at Standard tier carries a control plane fee of $0.10 per cluster per hour, always-on node VMs regardless of workload activity, and the engineering overhead of keeping cluster upgrades, node patching, and observability stacks in order. The second cost is harder to quantify but more damaging over time: Kubernetes complexity absorbs senior engineering capacity that most organisations cannot spare. Microsoft’s own Azure Architecture Centre documents a case, Fabrikam’s drone-delivery platform, where a team migrated from AKS to Azure Container Apps after concluding they were paying for Kubernetes capabilities they had never used in production.
This post sets out a decision framework for choosing between Azure Container Apps, Azure Kubernetes Service, and Azure App Service for Containers. The framework treats ACA as the correct default for stateless microservices, event-driven workloads, and API estates with variable traffic, and reserves AKS for workloads that genuinely require Kubernetes API access, custom networking, Windows containers, or persistent block storage. Hexagon’s industrial intelligence platform demonstrates what AKS delivers at its best: a microservices architecture with document processing reduced from two to three days to under one hour, with zero-downtime deployment and strict enterprise security. The framework tells you which side of that line your workload sits on.
The Kubernetes Default Is Costing More Than You Think
The containerisation market is accelerating. In the UK, financial services, public sector, and retail organisations are modernising legacy estates, deploying microservices at pace, and doing so against a backdrop of constrained platform engineering headcount. Azure is the dominant cloud for this cohort, and within Azure the choice between Container Apps and AKS sits at the centre of most container platform decisions in 2026.
Azure offers three tiers of managed container compute that serve different positions on the control-versus-simplicity spectrum. Azure App Service for Containers handles straightforward HTTP web applications with minimal configuration and a 99.99 per cent SLA. Azure Container Apps addresses the microservices middle ground: managed KEDA autoscaling, Dapr service-mesh primitives, revision management, and traffic splitting, without exposing the Kubernetes API. Azure Kubernetes Service provides full cluster control for workloads that need it, including custom CNI, network policies, service mesh configuration, Windows container node pools, and access to GPU VM ranges including NVIDIA H100 and H200.
The business stakes of choosing incorrectly are material in both directions. An organisation that deploys AKS for a stateless API estate pays the Kubernetes operational tax indefinitely: upgrades, patching, security hardening, observability configuration, and incident response for a control plane it has no need to interact with directly. An organisation that deploys ACA for a workload requiring persistent block storage, Windows containers, or custom CNI discovers the constraint and faces a migration six months later.
Gartner recognised Microsoft as a Leader in the 2025 Magic Quadrant for Cloud-Native Application Platforms for the second consecutive year, positioned furthest to the right in Completeness of Vision, and a Leader in Container Management for the third consecutive year. That breadth reflects a genuine platform that covers multiple use cases, but it also complicates the selection decision. Microsoft builds and maintains both ACA and AKS. There is no commercial incentive steering customers toward one over the other; the architectural fit must drive the decision, not vendor positioning and not Kubernetes market share statistics.
How the Container Platform Stack Got Here
Azure Kubernetes Service arrived in 2018 as the managed expression of Kubernetes: Microsoft handles the control plane, customers manage node pools, workloads, and the full Kubernetes API surface. The model worked well for organisations with platform engineering investment, complex workload requirements, and the capacity to absorb Kubernetes operational overhead.
Azure Container Apps launched in preview in 2021 and reached general availability in 2022 with a different architecture. ACA runs on a Microsoft-managed Kubernetes substrate but exposes a higher-level abstraction: container apps, environments, revisions, and ingress, with KEDA and Dapr built in as first-class managed capabilities. The Kubernetes control plane is present but invisible.
The division at launch was relatively clear. ACA suited teams wanting managed microservices without Kubernetes expertise; AKS suited teams with platform engineering investment and complex requirements. That division has narrowed considerably. The ACA Workload Profiles plan, which reached general availability in 2023, introduced dedicated, single-tenant compute pools supporting larger replicas, GPU workloads, and more advanced VNet integration. Serverless GPU instances (NVIDIA A100 and T4) reached general availability in 2025, with regional availability extended at Ignite 2025. ACA Premium Ingress, enabling configurable ingress scaling for high-throughput workloads, also reached general availability at Ignite 2025.
AKS has moved in parallel. AKS Automatic, which moved to a new general availability billing model in October 2025, provides production-ready clusters with Karpenter-based node auto-provisioning, pre-configured Azure Monitor integration, automatic node patching, and enforced Entra ID and RBAC. It represents Microsoft’s most direct response to the Kubernetes operational burden argument. AKS Automatic still exposes the Kubernetes API and still carries AKS production-tier economics, but it reduces much of the traditional node-pool and baseline configuration burden through managed system node pools and node auto-provisioning. The operational overhead is reduced materially, but not eliminated: teams still own Kubernetes-facing workload design, policy, security posture, observability choices, and application operations.
KEDA and Dapr illustrate the difference in operating model clearly. On AKS, both are add-ons you enable, maintain, and upgrade on your own schedule. On ACA, both are managed components updated transparently by Microsoft. For teams building event-driven microservice estates that want KEDA autoscaling and Dapr service-to-service invocation without managing the infrastructure underneath, ACA eliminates an entire operational layer.
The most persistent misconception in enterprise platform teams is that AKS is the “enterprise” choice and ACA suits only lightweight workloads. The Hexagon case study below is a useful corrective: an AI-heavy industrial platform deployed on AKS, not because AKS is inherently more enterprise-ready, but because that specific workload’s stateful database-tier integration, custom security requirements, and zero-downtime microservices genuinely justified it.
Technical Architecture: Where the Decision Lines Are Drawn
The differences between ACA and AKS fall into five areas: the control surface, scaling, networking and security, storage, and GPU and Windows workload support.
The control surface. ACA does not expose the Kubernetes API. There is no kubectl, no Helm, no custom resource definitions, and no support for Kubernetes operators. ACA exposes a high-level model: container apps composed of one or more containers, grouped into environments, deployed via revision through the Azure CLI, Azure Resource Manager, the portal, or standard CI/CD pipelines. For the majority of teams whose Kubernetes usage amounts to deploying workloads and scaling them, ACA provides an equivalent outcome with a substantially smaller configuration surface. AKS exposes the full Kubernetes API. Operators, admission controllers, GitOps tooling such as Argo CD and Flux, and advanced scheduling configurations all require AKS. This is the primary architectural boundary between the two platforms.
Autoscaling. ACA ships KEDA built in and fully managed, supporting HTTP-based scaling, CPU and memory scaling, and the complete KEDA scaler library including Azure Service Bus, Azure Storage Queue, and Kafka. Scale-to-zero is supported for HTTP and event-driven rules; CPU and memory scaling rules cannot scale below one replica. On AKS, KEDA is available as an add-on that teams enable and maintain themselves. Horizontal Pod Autoscaler and Vertical Pod Autoscaler are also available on AKS and are not available on ACA.
Dapr integration. ACA ships Dapr as a managed sidecar. Enabling it per container app activates service-to-service invocation with mTLS, pub/sub messaging via Dapr components, state management, and bindings, without deploying the Dapr control plane yourself. This makes ACA a natural fit for teams building microservice estates that need inter-service communication patterns without a full service mesh. On AKS, Dapr is available as an extension, maintained alongside other add-ons. The capability is equivalent; the operational responsibility differs.
Networking and security. ACA environments can be deployed into an existing virtual network. Workload-profile environments support the widest range of VNet configurations, including private ingress environments for fully private deployments. Consumption-only environments are more constrained in the VNet scenarios they support. AKS provides the full Azure network stack: private clusters with API server endpoints inside a VNet, Azure CNI including the Cilium overlay, network policies for pod-to-pod traffic control, and private endpoints for PaaS service integration. For organisations with compliance requirements demanding granular network-level control, AKS accommodates a wider range of configurations. The Azure Private Endpoints and Private Link enterprise architecture guide covers the private networking patterns applicable to AKS-based deployments in detail.
Both platforms support managed identities and Azure Key Vault integration. ACA supports system-assigned and user-assigned managed identities, with the caveat that some Consumption-only scenarios cannot access managed identity at container startup. AKS uses Microsoft Entra Workload Identity, federated with the cluster OIDC issuer, providing pod-level identity rather than shared node-level identity. Revision management in ACA provides built-in blue/green and canary deployment: traffic splits between active revisions by percentage, with instant rollback by reassigning traffic weight. AKS implements the same patterns via Kubernetes Deployments and optionally a service mesh or ingress controller, requiring more configuration but providing greater granularity.
Storage. ACA is designed for stateless workloads. Persistent storage is supported via Azure Files SMB and NFS mounts, and ephemeral storage is available within the container lifecycle. Persistent block storage, of the kind required for databases, Kafka brokers, or Elasticsearch nodes running in containers, is not supported. Azure Container Storage, Microsoft’s Kubernetes-native persistent volume solution supporting Azure Disk, Azure Elastic SAN, and local NVMe, is AKS-only. This is the single most architecturally significant constraint on ACA. Any workload requiring persistent block storage belongs on AKS.
GPU and Windows. ACA serverless GPU support (A100 and T4) reached general availability in 2025 on Consumption workload profiles. For inference workloads with variable demand and scale-to-zero requirements, ACA’s GPU support now competes seriously with AKS for the right workload shape. AKS supports a broader GPU range including H100 and H200, AKS-managed GPU node pools (driver installation, device plugin configuration, and DCGM metrics, currently in preview), and Windows GPU node pools (preview). For large-scale training, specialised GPU fleets, or Windows-based GPU workloads, AKS is the correct platform. Windows containers represent a clear architectural boundary: ACA supports Linux and AMD64 containers only. AKS supports Windows Server node pools, with Windows Server 2022 currently the practical default for supported Windows container workloads. Windows Server 2019 node pools are no longer supported in AKS as of 1 March 2026, and remaining node images are scheduled for removal from 1 April 2027. Any workload requiring Windows containers belongs on AKS.
Comparing Azure Container Apps and AKS
| Dimension | Azure Container Apps | Azure Kubernetes Service | Azure App Service |
|---|---|---|---|
| Kubernetes API access | None | Full | None |
| Autoscaling | KEDA (managed); HTTP, CPU, memory, event-driven; scale-to-zero for HTTP/events | KEDA add-on (self-managed), HPA, VPA, Karpenter (Automatic) | Built-in HTTP scaling |
| Dapr | Built-in, managed | Extension, self-managed | Not supported |
| Windows containers | Not supported | Supported — Windows Server 2022; Windows Server 2019 no longer supported | Supported |
| Persistent block storage | Not supported | Supported (Azure Container Storage) | Not supported |
| GPU support | A100/T4 (serverless, GA, limited regions) | H100/H200/A100/T4; Windows GPU (preview) | Not supported |
| Service mesh | Dapr mTLS only | Istio add-on, custom | None |
| CRDs / operators | Not supported | Supported | Not supported |
| VNet integration | Supported; Workload Profiles environments preferred | Full: private cluster, custom CNI, network policies | Supported |
| Blue/green deployment | Revision-based traffic splitting | Deployment strategy + ingress controller | Deployment slots |
| Control plane fee | None | ~$72/month Standard; ~$432/month Premium | None |
| Compute cost model | Per vCPU-second and GiB-second; scale-to-zero | Always-on node VMs; Reserved Instances available | Per App Service Plan hour |
| SLA | 99.95% | 99.95% (Standard + Availability Zones) | 99.95–99.99% |
ACA strengths. Operationally lean: KEDA and Dapr as managed capabilities eliminate a significant maintenance surface. Scale-to-zero economics make non-production environments approach zero cost when idle. No control plane fees. Revision management provides a built-in deployment safety mechanism without additional tooling. ACA’s managed OpenTelemetry agent runs at no additional compute cost, and both the Dapr integration and the built-in event-driven scaling make it the natural default for teams adopting event-driven microservice patterns or building agentic AI architectures. Both ACA and AKS integrate with Azure API Management for gateway functionality and traffic management; the Azure API Management enterprise guide covers the backend integration patterns applicable to both.
ACA limitations. The absence of the Kubernetes API is a hard architectural constraint for teams using operators, CRDs, or GitOps tooling that integrates at the Kubernetes API level. Linux and AMD64 only. No persistent block storage rules out stateful containerised workloads entirely. VNet integration is more constrained than AKS, particularly in Consumption-only environments. GPU availability is regionally limited. Replicas on the Consumption plan are capped at 2 vCPU and 4 GiB; workloads requiring larger replicas need a Workload Profiles environment.
AKS strengths. Full Kubernetes API provides access to the entire cloud-native ecosystem. Windows containers, persistent block storage, and a broad GPU range including H100 and H200. Better suited to multi-tenant cluster architectures with namespace-level isolation and granular RBAC. The full AKS production-grade enterprise implementation patterns are documented on this blog.
AKS limitations. Control plane fee at Standard and Premium tiers. Always-on node VMs represent a baseline cost that ACA’s scale-to-zero avoids entirely. Kubernetes operational complexity, including upgrades, node patching, security hardening, and observability configuration, absorbs engineering capacity that many teams underestimate when evaluating total cost of ownership.
Real-World Deployments
Company Name and Industry: The Coca-Cola Company, Consumer Goods
Scale Context: Over one million users across 43 markets, 26 languages, real-time conversational AI interactions at consumer-event scale.
Challenge: Coca-Cola needed to build and deploy a global AI-powered holiday campaign experience within 60 days, requiring a platform capable of handling real-time, multi-language natural-language conversations at unpredictable consumer-driven scale.
Solution Implemented: Azure Container Apps hosted both front-end and back-end services, alongside Azure Functions, Azure AI Foundry, and Azure AI Speech. ACA’s managed autoscaling absorbed the traffic spikes inherent in a global consumer campaign without pre-provisioned capacity.
Measurable Outcomes:
- Delivered globally in 60 days, within a campaign timescale that precluded a conventional infrastructure build.
- Supported simultaneous interactions across 26 languages and 43 markets.
- Engaged over one million users, with built-in load balancing managing scale without manual intervention.
Source: https://www.microsoft.com/en/customers/story/22668-coca-cola-company-azure-ai-and-machine-learning
Company Name and Industry: NFL Combine, Sports Technology
Scale Context: Real-time AI evaluation supporting over 300 elite prospects across live NFL Combine drills, with draft boards and scouting reports updated in real time during broadcast-quality events.
Challenge: The NFL needed to add a real-time natural-language AI assistant to its existing Combine App, providing scouts and coaches with fast, accurate answers during live evaluation sessions with no tolerance for latency or availability issues.
Solution Implemented: Azure Container Apps hosted the back-end AI services alongside Azure OpenAI Service and Azure Cosmos DB. ACA’s managed scaling ensured consistent performance during the event’s compressed, high-demand window without dedicated capacity provisioning.
Measurable Outcomes:
- Real-time, natural-language AI responses during live NFL Combine drills for over 300 prospects.
- Rapid deployment on an event-driven timeline with no manual scaling intervention required during the event.
Source: https://www.microsoft.com/en/customers/story/23954-nfl-combine-azure-ai-foundry
Company Name and Industry: Hexagon, Industrial Intelligence Technology
Scale Context: Enterprise-grade asset lifecycle management platform (HxGN SDx) deployed across global industrial operations, supporting AI-driven document contextualisation at production scale.
Challenge: Hexagon needed to rebuild HxGN SDx as a modern microservices architecture capable of zero-downtime deployment, AI-driven document processing at scale, and strict enterprise security across a global customer base with stateful data-tier integration.
Solution Implemented: Azure Kubernetes Service with Azure SQL Database Hyperscale, Azure OpenAI Service, Azure AI Document Intelligence, and Azure Machine Learning. Security enforced via managed identity, transparent data encryption, cluster-level RBAC, and private endpoints. The AKS microservices architecture supported the stateful database-tier dependencies and advanced security controls the platform required.
Measurable Outcomes:
- Facility onboarding time reduced by more than 90 per cent.
- Document tagging reduced from two to three days to under one hour.
- Zero-downtime deployment achieved at enterprise scale.
Source: https://www.microsoft.com/en/customers/story/24303-hexagon-azure
The contrast between these deployments is itself instructive. Coca-Cola and the NFL Combine represent the ACA archetype: high-demand, stateless, event-driven workloads where managed autoscaling replaces pre-provisioned capacity. Hexagon represents the genuine AKS case: stateful platform with database-tier integration, AI services requiring coordinated deployment, and security controls that benefit from AKS’s full network policy and RBAC model. The decision framework below produces these same outcomes from a set of structured questions.
Cost Analysis and TCO
The cost comparison between ACA and AKS runs on different models, which makes a straightforward comparison harder than it appears.
ACA Consumption billing is per second of active compute: $0.000024 per vCPU-second and $0.000003 per GiB-second at current pay-as-you-go rates. The first 180,000 vCPU-seconds, 360,000 GiB-seconds, and two million requests per subscription per month are free. When minimum replicas are set above zero, ACA switches to a reduced idle rate rather than the full active rate, meaning a warm standby replica costs materially less than an active one. Development and test environments that scale to zero when unused approach zero cost, which represents a meaningful operational saving across a typical multi-environment estate.
AKS costs are additive. The Standard-tier control plane adds $0.10 per cluster per hour, approximately $72 per month, per cluster. The dominant cost is the underlying node VMs: the D4s_v5 (four vCPU, 16 GiB) is confirmed at $0.192 per hour on-demand in East US across multiple current pricing trackers; UK South rates differ and should be verified in the Azure pricing calculator before budgeting. A three-node production pool therefore runs above $400 per month on-demand before discounts, plus the control plane fee. Azure Reserved VM Instances reduce node VM costs by 36 to 72 per cent over one or three-year terms — Microsoft’s published headline range across VM types, with the D4s_v5 in East US running at approximately 38 per cent for a one-year term and 61 per cent for a three-year term based on current tracker data. Azure Savings Plan for Compute offers 11 to 65 per cent, again Microsoft’s published range as of January 2026, with D4s_v5 East US tracking at approximately 31 per cent (one year) and 54 per cent (three years). The FinOps discipline for selecting between these options, including the importance of right-sizing before committing to Reservations, is covered in the FinOps evolution guide.
For an estate of ten to twenty microservices with variable traffic and meaningful overnight and weekend idle periods, ACA Consumption consistently underbids a comparable AKS cluster on raw compute cost. The crossover point shifts as workloads move toward continuous high utilisation: ACA’s per-second billing, without Reserved Instance economics, becomes less competitive against a heavily discounted Reserved AKS node pool for workloads running at sustained capacity.
Hidden costs shift the comparison further in ACA’s favour for many organisations. AKS requires ongoing platform engineering time for cluster upgrades, node patching, security hardening, and observability tuning. That cost does not appear on an Azure invoice but is real. Organisations running a single AKS cluster for a handful of stateless services are rarely recovering that overhead. Organisations with a dedicated platform engineering team amortising AKS operational work across a large estate of genuinely Kubernetes-native workloads are in a different position. Total cost of ownership analysis should include an honest estimate of FTE time before the AKS versus ACA cost comparison is considered complete.
The Decision Framework
The decision between ACA and AKS reduces to a sequence of four concrete questions. Asking them in order takes less than thirty minutes and eliminates weeks of architectural debate.
The first question is whether the workload requires the Kubernetes API: kubectl, Helm chart deployment, custom resource definitions, custom operators, or admission webhooks. If yes, the decision is AKS. The Kubernetes API surface is ACA’s hard boundary, and no other capability of ACA changes that.
The second question is whether the workload requires Windows containers. ACA is Linux and AMD64 only. A Windows container requirement mandates AKS.
The third question is whether the workload requires persistent block storage: data that must survive container restarts and be accessible across replicas, such as a containerised database, Kafka broker, or Elasticsearch cluster. Azure Container Storage is AKS-only. Any workload with this requirement belongs on AKS.
The fourth question is whether the networking requirements fall within ACA’s VNet model. Workload-profile ACA environments support private ingress and internal environments. If custom network policies, a custom CNI configuration, or a private cluster API-server endpoint are required, AKS is the appropriate platform.
If the workload passes all four gates, Azure Container Apps is the correct default. Stateless microservices, HTTP and gRPC APIs with variable traffic, event-driven background processing, AI inferencing with variable demand, and multi-language web applications all fit the ACA model. Azure App Service for Containers occupies a third position in the stack: where the workload is a single HTTP application or REST API that does not require inter-service messaging, Dapr, or event-driven autoscaling, App Service provides maximum simplicity with a 99.99 per cent SLA and no container orchestration overhead.
The anti-pattern to avoid is the reflexive AKS default. The diagnostic question is direct: is the team using kubectl in production, managing operators, configuring network policies, or running stateful containerised data stores? If the answer to each of those is no, the team is sustaining the Kubernetes operational tax for capabilities it is not using.
Implementation Roadmap and Strategic Direction
Phase 1: Foundation (Months 1–3)
Begin with a workload inventory. Map every containerised workload or candidate for containerisation against the four decision questions: Kubernetes API dependency, Windows containers, persistent block storage, and advanced networking requirements. Record a platform assignment for each service. In practice, the majority of workloads in a typical enterprise estate are stateless and event-driven and do not require Kubernetes-native capabilities. The inventory makes that visible before any infrastructure is committed.
Stand up a single ACA environment using Workload Profiles rather than Consumption-only. Workload-profile environments support the widest range of VNet configurations, larger replicas, and GPU workloads if needed later, while running Consumption-billed workloads without cost penalty. Establish Log Analytics, Application Insights, and managed identity integration from the outset. For workloads that genuinely require AKS based on the inventory, deploy a Standard-tier private cluster following production-grade hardening patterns. Establish CI/CD pipelines for both platforms in this phase: GitHub Actions and Azure Pipelines support ACA deployment natively; AKS supports GitOps via Argo CD and Flux as managed add-ons. Keep infrastructure and application deployment pipelines separate as a discipline from day one.
Phase 2: Expansion (Months 4–9)
Migrate suitable workloads to ACA following a consistent pattern: externalise all state to managed Azure services such as Cosmos DB, Azure SQL, or Azure Cache for Redis; remove persistent volume claims or stateful set dependencies; validate KEDA scaler configuration against production traffic patterns; and test revision-based deployment with a 10/90 traffic split before cutting fully to the new revision. The majority of stateless microservice migrations from AKS to ACA require minimal code change. The effort is in infrastructure and pipeline reconfiguration, not application logic.
For the AKS estate, right-size node pools before purchasing Reserved Instances or Savings Plans. Reservations applied to an oversized pool lock in waste permanently; right-sizing first ensures the discount applies to actual required capacity. Spot node pools are appropriate for fault-tolerant batch processing and non-production workloads, provided eviction tolerance is validated in the workload before enabling.
Phase 3: Maturity (Months 10–18)
Enforce managed identity for all workload-to-service connections across both platforms, eliminating connection strings and credentials from application configuration. Apply network segmentation: internal ACA environments for back-end services, private AKS clusters with private endpoints for PaaS dependencies. Enable zone redundancy for ACA environments and multi-availability-zone AKS node pools for workloads with regional HA requirements. For multi-region patterns, neither ACA environments nor AKS clusters replicate across regions automatically; multi-region resilience requires Azure Front Door for traffic distribution and an explicit data replication strategy. The multi-region cloud architecture patterns guide covers the active-active and active-passive patterns applicable to both platforms.
Formalise cost management with tagged resources, budget alerts, and a monthly review of the ACA versus AKS cost allocation. ACA’s per-second billing should track closely with actual usage; significant divergence signals either over-provisioned minimum replicas or workloads that are a better fit for the Dedicated plan.
Looking ahead. Two trends will shape this decision over the next two to three years. The first is AI workloads as a first-class containerisation use case: agentic AI architectures map closely to the ACA model, with Dapr for inter-component communication and KEDA for queue-depth-based scaling. Microsoft cited EY, the London Stock Exchange Group, Chevron, and Paychex as organisations modernising onto ACA specifically for AI workloads at Ignite 2025. ACA Sandboxes, currently in preview, extend this further with fast, ephemeral, suspend-and-resume isolated compute for agentic workloads. The second is the continued evolution of AKS Automatic as a managed Kubernetes tier. If AKS Automatic continues to absorb operational complexity while maintaining full Kubernetes API access, the justification for a self-managed AKS cluster narrows further to very specific requirements: custom CNI, specialised hardware node pools, and multi-tenant cluster architectures that AKS Automatic’s opinionated configuration cannot accommodate.
For most Azure platform teams building greenfield microservices in 2026, Azure Container Apps should be the starting point. The cost and simplicity advantages are most pronounced in organisations running multiple environments across development, staging, and production, where AKS’s always-on node costs and operational overhead compound rapidly. AKS remains the correct choice for workloads that genuinely need the Kubernetes API, stateful containerised data stores, Windows containers, or a specialised GPU estate. The Hexagon deployment illustrates the genuine AKS case. Platform decisions made in 2026 are difficult to reverse in 2028. Choose ACA unless the workload requirements mandate AKS, and revisit the assignment annually as both platforms evolve.
Useful Links
- Azure Container Apps documentation
- Azure Kubernetes Service documentation
- Microsoft Azure Architecture Centre: Choose a Compute Option for Microservices
- Azure Container Apps pricing
- Azure Kubernetes Service pricing
- Azure Container Storage documentation (AKS-only)
- CNCF Annual Survey 2025
- Coca-Cola customer story (Azure Container Apps)
- NFL Combine customer story (Azure Container Apps)
- Hexagon customer story (Azure Kubernetes Service)
