Azure Container Apps

About Azure Container Apps

Azure Container Apps is a managed serverless container platform in Microsoft Azure for running containerized APIs, web applications, background workers, event-driven services and scheduled jobs without managing Kubernetes clusters directly. It sits between higher-level platforms such as Azure App Service and lower-level orchestration such as Azure Kubernetes Service.

What is Azure Container Apps used for?

Azure Container Apps is designed for containerized workloads where teams want application-level control without operating Kubernetes infrastructure. Microsoft lists API endpoints, background processing, event-driven processing and microservices among common scenarios. The platform can run containers from public or private registries and expose applications through HTTP or TCP ingress.

It is useful when an application already fits a container deployment model but does not require direct Kubernetes control-plane access. Teams can deploy several container apps into a shared environment, use internal service discovery, and avoid managing cluster upgrades, node pools and ingress controllers themselves.

How does scaling work?

Container Apps uses declarative scale rules and KEDA for horizontal scaling. Microsoft documents scaling based on HTTP traffic, TCP connections, CPU, memory and supported event sources such as Azure Service Bus, Azure Event Hubs, Apache Kafka and Redis.

Many Consumption workloads can scale to zero. Microsoft notes that applications using CPU or memory scaling rules cannot scale to zero. Setting a minimum replica count keeps capacity running and can result in idle charges rather than a true zero-cost idle state.

What are revisions and traffic splitting?

A revision is an immutable snapshot of a container app version. Container Apps supports single-revision mode for straightforward production rollouts and multiple-revision mode when teams need more control. Multiple revisions can split traffic between versions for blue-green releases, A/B tests and gradual rollouts.

This helps teams deploy safely without building Kubernetes rollout tooling. Application state should still be externalized, and teams should test database migrations, background consumers and long-running connections when more than one revision is active.

How do workload profiles work?

Microsoft currently documents Consumption, Dedicated and Flex workload profile types. Consumption uses a serverless model. Dedicated profiles provide fixed profile instances with options such as general purpose, memory optimized and selected GPU configurations. Flex has different networking and scaling characteristics and currently does not scale to zero.

Profile and hardware availability varies by Azure region, so buyers should confirm supported workload profile types for the target location before standardizing an architecture.

How does pricing work?

Pricing was checked on August 26, 2026. Microsoft currently prices the Consumption plan by per-second vCPU and memory allocation plus requests. The published monthly free grant includes 180,000 vCPU-seconds, 360,000 GiB-seconds and 2 million requests per subscription.

Applications that scale to zero have no usage charge while no replicas are running. Minimum replicas can incur idle charges. Dedicated and specialized profiles use different capacity models. Microsoft also offers Azure savings plan for compute for eligible workloads, so steady workloads should compare consumption flexibility with commitment-based savings.

How does Container Apps compare with AKS, App Service and Functions?

Azure Container Apps is a middle ground for teams that want to deploy containers without managing Kubernetes. AKS is the better fit when Kubernetes APIs, cluster-level extensibility, operators or deeper orchestration control are required.

App Service is often simpler for conventional web apps and APIs. Azure Functions is better when the workload is naturally expressed as functions with triggers and bindings. Microsoft also supports Azure Functions on Container Apps for teams that want the Functions programming model on the Container Apps platform.

What networking and security considerations matter?

Container Apps environments can use internal ingress and DNS-based service discovery for private application communication. Microsoft also supports custom virtual networks for requirements such as user-defined routes, Network Security Groups, Application Gateway integration and private endpoint connectivity.

Teams still need to manage application secrets, identities, container image access, network exposure, software dependencies, monitoring and application-level security. The managed platform reduces infrastructure administration but does not remove workload security responsibilities.

What are the main limitations?

Container Apps intentionally hides many Kubernetes details. That reduces operational work but means teams cannot assume every Kubernetes feature or extension is available. Workloads that depend on cluster-level customization may be better suited to AKS.

Scale-to-zero behavior depends on the scaling rule and workload profile. Specialized profiles and GPUs are region dependent. Costs can rise when workloads stay active, use large profiles, keep minimum replicas or rely on several paid Azure services around the app.

Who should choose something else?

Choose AKS when Kubernetes itself is a requirement. Choose App Service when the workload is mainly a conventional website or API and container orchestration adds little value. Choose Azure Functions when the workload is best expressed as event-driven functions.

Azure Container Apps makes the most sense when containers are already part of the delivery model, traffic or event volume changes, several services need to communicate, and the team wants managed scaling and revision controls without operating a Kubernetes control plane.