Azure Container Apps icon

Serverless containers

Azure Container Apps

Kubernetes-powered containers without Kubernetes operations: bring any container, get HTTPS ingress, KEDA event-driven scale (including to zero), traffic-split revisions, Dapr, jobs and GPUs — with the cluster fully managed for you.

How it works

Apps live in an environment — a secure boundary sharing a VNet, logging and Dapr configuration. Each app runs revisions (immutable snapshots) with traffic-splitting between them.

flowchart TB
    subgraph ENV[Container Apps environment · VNet]
        ING[Managed ingress
HTTPS · TCP · traffic split]
        subgraph AppA[App: storefront-api]
            R1[Revision v2 · 90%]
            R2[Revision v3 · 10% canary]
        end
        AppB[App: order-worker
scales 0→N on queue length]
        AppC[Job: nightly-report
scheduled / event-driven]
        DAPR[Dapr sidecars
pub-sub · state · service invocation]
    end
    U[Clients / APIM] --> ING
    ING --> R1
    ING --> R2
    SB[(Service Bus)] -->|KEDA scaler| AppB
    AppA <-.-> DAPR
    AppB <-.-> DAPR
Environment = shared boundary; apps scale independently; KEDA watches event sources; revisions enable canary/blue-green.

Core capabilities

KEDA autoscaling

Scale on HTTP concurrency, CPU/memory, or 60+ event sources (Service Bus, Event Hubs, Kafka, Cosmos DB…). Scale to zero when idle; pay only while running.

Revisions & traffic split

Every deploy creates an immutable revision. Split traffic (90/10 canary), test by label URL, roll back instantly.

Dapr integration

Managed Dapr sidecars for service discovery/invocation (mTLS), pub/sub over Service Bus, state stores, bindings and resiliency policies — microservice plumbing without SDK lock-in.

Jobs

Finite-run containers: manual, scheduled (cron) or event-driven (queue-triggered batch). Perfect for CI runners, batch ETL, per-message processors.

Dynamic sessions

On-demand, sandboxed code-interpreter sessions (Hyper-V isolated) at scale — the standard way to safely run LLM-generated Python for agents.

Serverless GPUs

GPU workload profiles that scale to zero — inference for open-source models without owning a GPU cluster.

Workload profiles

Mix consumption and dedicated (memory-optimized/GPU) compute in one environment.

Functions & landing zone

Host Azure Functions images natively; use the ACA landing zone accelerator for enterprise setups.

Container Apps vs AKS vs App Service

QuestionPick
Microservices/event-driven containers, no cluster ops wantedContainer Apps
Need raw Kubernetes API, custom operators/CRDs, service mesh controlAKS
Classic web app/API from code, minimal container interestApp Service
Single event-driven function, minimal footprintFunctions (Flex)

Detailed use cases

Use case

Microservice backends behind APIM

Each bounded context = one container app. APIM fronts the environment; Dapr handles service-to-service auth and pub/sub; revisions give safe canaries per service.

Use case

Queue-drained workers

KEDA scales workers 0→100 based on Service Bus queue depth, then back to zero. Cost tracks the backlog exactly.

Use case

Agent code execution

Dynamic sessions give each AI agent an isolated Python sandbox for code interpretation — thousands of parallel sessions, sub-second allocation, no jailbreak blast radius.

Use case

Self-hosted model inference

Serve Llama/Mistral/embedding models on serverless GPUs; scale to zero overnight; front with APIM AI Gateway for token policies.

Use case

Event-driven batch jobs

Event-driven jobs pick one message per execution for heavyweight processing (video transcode, report render) with clean retry semantics.

Use case

Lift containerized apps off VMs

Any Linux container runs as-is: get TLS, scale, zero-downtime deploys and log streaming without writing Kubernetes manifests.

Best practices