Azure Container Apps vs AKS: Rozhodovací matice pro rok 2026
Azure Container Apps vs AKS: Rozhodovací matice pro rok 2026
Otázka „Container Apps nebo AKS?" mi za poslední rok přišla v různých variantách od pěti zákazníků. Odpověď není „AKS, protože je víc enterprise" ani „Container Apps, protože je jednodušší". Záleží na třech věcech: počet workloadů, typ workloadů a zralost týmu.
V tomhle článku rozeberu rozhodovací matici, kterou používám se zákazníky, a tři reálné scénáře, kde rozhodnutí padlo různě.
TL;DR rozhodovací matice
| Kritérium | Container Apps | AKS |
|---|---|---|
| Počet workloadů v cluster | 1–5 | 5+ |
| Operations zralost týmu | Začátečník až střední | Pokročilý |
| Potřeba StatefulSet/CRD/operator | Ne | Ano |
| Service mesh (Istio/Linkerd) | Built-in (limited) | Plný |
| Event-driven scaling (KEDA) | Built-in | Self-managed KEDA install |
| Fix měsíční náklady | Žádné (per second) | ~400 EUR (3 nodes min) |
| Networking complexity | Nízká | Vysoká |
| Multi-tenancy | Per app environment | Per namespace + NetworkPolicy |
| GitOps (Flux/Argo) | Externí (omezené) | Native |
| Compliance/Audit | Sdílený control plane | Plná kontrola |
Scénář 1: Startup s 2 microservices → Container Apps
V CostSentry.AI jsme začínali s API gateway a background worker. Dvě služby, jeden tým, nula Kubernetes zkušeností. Rozhodnutí bylo přímočaré: 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 }
}
}
}Klíčové vlastnosti, které nás v Container Apps drží:
- Scale to zero: noční hodiny stojí 0 EUR (development), produkce má
minReplicas: 1 - Key Vault integrace přes Managed Identity: žádné connection stringy v env vars
- Built-in HTTPS s vlastním FQDN: žádný ingress controller k řešení
- Revisions a traffic splitting: blue-green nasazení v jednom YAML
Měsíční Azure faktura za celý CostSentry stack: ~85 EUR. Na AKS by samotný cluster stál 5× tolik.
Scénář 2: Christie's platform tým, 30+ microservices → AKS
V Christie's je jiná realita. Třicet microservices, deset týmů, polovina používá Helm, druhá kustomize, někteří mají vlastní operátory pro deployment přes Argo CD. Container Apps by tu fungoval jen jako zlomek funkčnosti, kterou tým potřebuje.
Klíčové faktory, které rozhodly pro AKS:
| Faktor | Důvod |
|---|---|
| Service mesh (Istio) | mTLS mezi službami, traffic policies |
| Argo CD GitOps | Standardizovaná deployment pipeline napříč týmy |
| StatefulSets pro Kafka | Persistentní storage per replika |
| Custom Operators | Auto-rotace credentials, custom backup CRDs |
| Multi-tenancy | Namespace-per-team s NetworkPolicies |
| HPA + KEDA + VPA | Granulární scaling napříč workloady |
Cost overhead se ztrácí na 30 workloadech – produkce běží na 9 D8s_v5 node, ~3 600 EUR/měsíc, ale to vychází na ~120 EUR per workload. V Container Apps by 30 workloadů stálo násobně víc.
Scénář 3: Nespresso s 9 J2C aplikacemi → AKS s rezervou
Devět aplikací migrujících z on-prem do Azure. Tým má Kubernetes zkušenosti z předchozí firmy, používá Terraform, mají GitOps zavedený. Container Apps zvažovaný nebyl – tým chtěl plnou kontrolu nad networking a service mesh.
Proč AKS zvítězil i přes nižší počet workloadů:
- Předem investovali do Kubernetes know-how – nebyla žádná learning curve cena
- Plánujeme růst na 25+ aplikací do roku 2027 – AKS scaluje lineárně
- Compliance vyžaduje audit Kubernetes API serveru – Container Apps to neposkytuje
- Cilium NetworkPolicy pro mTLS a identity-aware ACLs (viz článek z března 2026)
Edge cases, kde rozhodnutí není jednoznačné
Event-driven worker s nepravidelným loadem: Container Apps + KEDA na Azure Service Bus queue. Žádná infra k údržbě, platí se jen za zpracované zprávy. Pokud worker běží míň než 4 hodiny denně, je Container Apps 3–5× levnější.
Batch processing 1× denně: Container Apps Jobs (GA od poloviny 2024). Pro periodické úlohy lepší než Kubernetes CronJob na AKS, protože nevyžaduje běžící cluster.
Frontend SPA s API backendem: Container Apps pro API + Azure Static Web Apps pro SPA. Žádný důvod sahat po AKS.
Cost porovnání reálných workloadů
Z mé praxe – stejný workload (REST API, 4 vCPU, 8 GB RAM, 8 hodin denně skutečného trafficu):
| Setup | Měsíční náklad | Komentář |
|---|---|---|
| Container Apps (Consumption, scale to zero) | ~25 EUR | Pouze za skutečný compute |
| Container Apps (Consumption, always-on) | ~115 EUR | minReplicas: 1, full month |
| Container Apps (Dedicated D4 profile) | ~280 EUR | Reserved capacity, no cold start |
| AKS (3× D4s_v5 + load balancer) | ~430 EUR | Cluster fix bez ohledu na využití |
| AKS (3× D4s_v5 Reserved 3Y) | ~210 EUR | S RI 50 % sleva |
Pro jednu aplikaci je AKS dvojnásobně dražší. Pro pět aplikací sdílejících cluster je AKS levnější.
Migration path Container Apps → AKS
Pokud Container Apps přerostete, migrace je v 90 % případů přímočará:
- Container image – beze změny, stejný image v ACR
- Bicep Container Apps definice → Kubernetes manifests:
# Z 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 } } } }] } - Secrets: Container Apps secrets → AKS Secret Store CSI driver pointing na Key Vault
- Dapr: pokud používáte, nainstalujte Dapr na AKS přes Helm (10 minut)
Typicky 2–3 sprinty na aplikaci, hlavní time-sink je integrační testování.
Závěr
Container Apps je v roce 2026 zralá platforma, která pokrývá ~70 % typických cloud-native workloadů bez Kubernetes overhead. AKS zůstává volbou pro enterprise prostředí s 5+ workloady, custom operators a potřebou plné Kubernetes API. Migrace mezi nimi není drahá – kontejnery zůstávají, mění se pouze deployment vrstva.
Pravidlo, které opakuji zákazníkům: začněte na Container Apps, dokud máte ≤ 5 workloadů. Přejděte na AKS, až vám platform overhead Container Apps začne vadit, ne když ho začnete tušit.
Potřebujete pomoct s rozhodnutím Container Apps vs AKS pro váš konkrétní stack? Podívejte se na naše služby cloudové architektury nebo se ozvěte pro architecture review.
O autorovi

Martin Rylko
Senior Cloud Architect & DevOps Engineer
Více než 14 let v IT – od on-premises datacenter a Hyper-V clusteringu po cloudovou infrastrukturu v Microsoft Azure. Specializuji se na Landing Zones, IaC automatizaci, Kubernetes a bezpečnostní compliance.
Nejcastejsi dotazy
Kdy zvolit Container Apps a kdy AKS?▾
Kolik stojí Container Apps oproti AKS?▾
Mohu na Container Apps běžet stateful workloady?▾
Lze migrovat z Container Apps na AKS bez přepisu aplikace?▾
Mohlo by vás zajímat
AKS Breaking Changes: Co se ruší v březnu 2026 a jak migrovat
Windows Server 2019, Azure Linux 2.0 a kubelet certificate rotation – tři AKS retirements s deadline v březnu 2026. Praktický migrační návod s CLI příkazy a Bicep šablonami.
ČístAKS Cilium NetworkPolicy: Migrace z Calico bez výpadku produkce
Praktický playbook migrace AKS clusteru z Calico Network Policy engine na Azure CNI Powered by Cilium. Zero-downtime postup, eBPF benefity a typické pasti při rolloutu.
ČístKubernetes AKS: Produkční checklist pro architekty
Kubernetes AKS produkční checklist pro architekty. Azure CNI síťování, Workload Identity, RBAC, autoscaling, monitoring a DR strategie.
Číst