Azure Container Apps

About Azure Container Apps

Azure Container Apps is a managed serverless container platform in Microsoft Azure for running containerized web apps, APIs, background workers, event-driven services, scheduled jobs and AI workloads without operating Kubernetes infrastructure directly. It sits between higher-level application hosting such as Azure App Service and lower-level orchestration such as Azure Kubernetes Service, giving teams container-level deployment, autoscaling, revisions and networking while Microsoft manages the underlying platform.

What is Azure Container Apps used for?

Azure Container Apps is designed for workloads where teams want to deploy containers without taking responsibility for Kubernetes control-plane operations. Microsoft lists APIs, web applications, background processing, event-driven workloads and microservices among common scenarios. Apps can pull images from public or private registries and expose HTTP or TCP ingress.

It is especially useful when containers are already part of the delivery model but the team does not need direct Kubernetes API access. Multiple apps can share an environment, communicate through internal service discovery and use managed revisions and scaling without the team operating cluster upgrades, node pools or ingress controllers.

How does scaling work?

Container Apps uses declarative scale rules and KEDA-based event 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.

Consumption workloads can scale to zero when no replicas are needed. CPU- and memory-based scale rules do not support scale to zero, and configuring a minimum replica count keeps capacity running. Buyers should model idle and active behavior rather than assuming every workload has zero-cost idle time.

Which quotas should production teams check?

Azure Container Apps applies quotas at subscription, region, environment and application scopes. Microsoft says reaching a quota can restrict scaling, cause provisioning timeouts, or block environment and workload-profile creation. Before production launch, teams should inspect their current quota allocations instead of assuming one default applies to every subscription.

Important quota categories include managed environment count by region, maximum Consumption cores per environment, general-purpose and memory-optimized Dedicated profile cores per environment, serverless GPU quotas, dedicated GPU quotas and Dynamic Sessions pool quotas. Microsoft notes that default quota values can depend on factors such as subscription age, subscription type and service use. Quota increases can be requested through Azure Quota Management, with some requests handled directly and others escalated for support review.

How do Consumption, Dedicated and Flex workload profiles differ?

Microsoft currently documents three workload profile types: Consumption, Dedicated and Flex. Consumption uses a serverless model with on-demand scaling and optional scale to zero. Dedicated profiles run in a single-tenant reserved compute pool and are intended for steadier workloads, larger resource needs or specialized hardware.

Flex remains in preview as of September 4, 2026. Microsoft says it combines consumption-style billing with a single-tenant compute pool, planned maintenance windows, dedicated networking and larger replica sizes. Flex requires at least a /25 subnet and apps on Flex cannot scale to zero. Production teams should confirm preview support, regional availability and the lack of scale-to-zero behavior before choosing it.

What is Azure Container Apps Express and what changed in 2026?

Azure Container Apps Express is a preview deployment model aimed at getting HTTP container apps running with fewer environment and networking decisions. Microsoft says Express can provision apps quickly, supports scale from zero and uses production-oriented defaults, but it does not expose the full Container Apps feature set.

Some existing environments can be selected for automatic migration to Express. Microsoft says selected customers receive notice about 25 to 30 days before migration and the move proceeds automatically unless the customer opts out. Jobs, TCP services, MQTT consumers and other non-HTTP long-running workloads are not currently eligible. Express remains preview with no SLA, so teams with formal production change controls should review migration notices carefully and opt out when they need to control timing or rely on unsupported features.

How does pricing work?

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

Apps that scale to zero have no usage charge while no replicas are running. Minimum replicas can incur reduced idle charges. Microsoft currently treats a Consumption replica as active when it is starting, processing requests, using more than 0.01 vCPU cores, or receiving more than 1,000 bytes per second. For TCP-enabled apps, one TCP connection counts as one request for request billing, while jobs do not incur request charges. Express and Sandboxes follow the same consumption-style pay-per-second pricing. Dedicated profiles add management and allocated compute charges, and eligible workloads can use an Azure savings plan for compute.

What are Dynamic Sessions and Container Apps Sandboxes?

Dynamic Sessions provide isolated, short-lived execution environments from prewarmed pools. Microsoft positions them for scenarios such as running untrusted or user-generated code, interactive development tasks and AI workflows that need code execution without placing that code inside the primary application process. Sessions are allocated from a session pool, require Microsoft Entra authentication for the management API and are removed after the configured cooldown period when they are no longer used.

Container Apps Sandboxes are a preview capability for isolated execution with explicit lifecycle control. Microsoft documents sandbox groups and sandboxes as separate resources, with support for start and stop operations, snapshots, persistent state and network controls. Current Microsoft documentation warns that preview sandboxes might not remain compatible with future releases and may need to be recreated. Buyers should treat Sandboxes as an emerging capability rather than a stable replacement for established production isolation patterns.

What networking and deployment controls matter?

Container Apps environments support internal ingress and DNS-based service discovery for private application communication. Microsoft also supports custom virtual networks when teams need user-defined routes, Network Security Groups, Application Gateway integration or communication with resources behind private endpoints.

A revision is an immutable snapshot of a container app version. Single-revision mode supports straightforward production rollouts, while multiple-revision mode can split traffic for blue-green deployments, canary releases and A/B testing.

What should buyers know about specialized hardware?

Microsoft supports Dedicated workload profiles for steadier capacity and specialized hardware, and serverless GPU options are also part of the current Container Apps pricing model. GPU capacity and supported profile types vary by region and quota.

Teams planning AI inference, regulated workloads or hardware-specific deployments should verify the exact profile type, regional availability and quota in the target environment before committing architecture or cost assumptions. A profile being documented by Microsoft does not mean the required capacity is automatically available in every subscription or region.

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

Azure Container Apps is a middle ground for teams that want containers and event-driven scaling without managing Kubernetes. AKS is the better fit when Kubernetes APIs, operators, cluster-level extensions, custom controllers or deeper orchestration control are requirements.

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 Functions on Container Apps for teams that want the Functions programming model on the Container Apps platform.

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 dependent on cluster-level customization may be better suited to AKS.

Scale-to-zero behavior depends on the scaling rule and workload profile. Flex is still preview and cannot scale to zero. Express is also preview and does not support every full Container Apps capability. Dedicated and GPU profiles are region and quota dependent. Sandboxes are preview and Microsoft warns that preview resources might require recreation as the service changes. Costs can increase when workloads stay active, use larger profiles, retain minimum replicas or depend on several paid Azure services around the app.

Who should choose something else?

Choose AKS when Kubernetes itself is part of the application or operating model. 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 naturally function-oriented and event driven.

Azure Container Apps is a strong fit when containers are already part of the software-delivery model, traffic or event volume changes, several services need to communicate and the team wants managed scaling, revisions and ingress without operating Kubernetes infrastructure directly. Teams that require a production SLA for every deployment mode should also be cautious with preview options such as Express, Flex and Sandboxes until their support status changes.