Azure Container Apps

Azure Container Apps (ACA) is a fully managed serverless container hosting service built on top of Kubernetes and KEDA (Kubernetes Event-Driven Autoscaling). Unlike AKS, you do not manage the control plane, node pools, or Kubernetes manifests directly. Instead, you deploy containers using a simple CLI or YAML definition, and Azure handles all the orchestration. ACA is ideal for microservices, API backends, event-driven workers, and background processing jobs that need to scale dynamically, including scale-to-zero.

A Container Apps Environment is the isolated boundary within which one or more Container Apps run. All apps in an environment share the same virtual network and Log Analytics workspace. Environments are scoped to a region and a resource group. You can deploy multiple environments for isolation between teams or stages (production vs. staging). An environment can optionally be VNet-injected into your own virtual network to allow private communication between Container Apps and other Azure services without going through the public internet.

To deploy a Container App, you specify the container image (from Azure Container Registry or any public registry), the number of replicas, and environment variables. The app is publicly accessible via an auto-generated HTTPS URL if you enable external ingress. Ingress configuration includes the target port, traffic split for blue-green deployments, and whether to allow HTTP or HTTPS only. ACA pulls the image at deployment time; the environment must have pull permissions on the registry.

Container Apps scales using KEDA scalers that trigger based on external metrics. Built-in KEDA scalers include: HTTP traffic (concurrent requests per replica), Azure Service Bus queue depth (messages waiting), Azure Storage Queue, Cron (time-based), and CPU/Memory. When the scaler metric falls to zero and minReplicas is set to 0, Container Apps scale to zero — incurring no compute cost until new requests arrive. Scale-to-zero is excellent for event-driven workers that have sporadic workloads.

Dapr (Distributed Application Runtime) is a portable, event-driven runtime that simplifies building microservices. Container Apps has native Dapr integration — you enable it per app with a single flag. Dapr provides building blocks for: service invocation (with retry and mTLS), pub/sub messaging (abstracting Service Bus, Event Hubs), state management (abstracting Redis, Cosmos DB), and output bindings. With Dapr, microservices communicate through the Dapr sidecar without knowing the underlying infrastructure details.

Every deployment to a Container App creates a new revision. In multiple-revision mode, you can split traffic between revisions for blue-green or canary deployments. For example, send 10% of traffic to a new revision and 90% to the current stable revision. Monitor error rates and latency on the new revision before increasing its traffic weight to 100%. Old revisions can be deactivated but are retained in history, allowing instant rollback by shifting traffic weight back.

Container Apps supports two ways to inject configuration: environment variables (for non-sensitive config like feature flags or API URLs) and secrets (for sensitive values like connection strings). Secrets are stored at the Container App level and referenced by environment variables or Dapr components. For the most secure setup, reference secrets from Azure Key Vault using a managed identity, so the secret value is fetched at runtime and never stored in the Container App's configuration plane.

Container Apps Jobs extend the platform to support run-to-completion workloads — containers that start, do work, and exit. Jobs support three trigger types: Manual (triggered via API or CLI), Scheduled (cron expression), and Event-driven (KEDA scaler triggers each execution). Jobs are billed only for actual execution time and are ideal for batch processing, report generation, database migrations, and ML inference pipelines that run periodically or in response to events.

Container Apps sends system logs (platform events like revision creation and scaling) and console logs (your application's stdout/stderr) to the Log Analytics workspace attached to the environment. Query logs with KQL: ContainerAppConsoleLogs_CL | where ContainerAppName_s == 'myapi' | project TimeGenerated, Log_s. Built-in Azure Monitor metrics include replica count, request count, request latency, and CPU/memory utilisation per replica — all available in the Azure portal without any additional configuration.

Choosing the right Azure container platform: Container Apps is best for microservices, event-driven workers, and APIs where you want Kubernetes benefits without managing the cluster — especially when scale-to-zero is valuable. AKS is best when you need full Kubernetes control, custom operators, or specific node configurations (GPU, high memory). App Service is best for traditional web applications and APIs where the developer team prefers a simple PaaS model without container management overhead. All three support containers; the distinction is management complexity versus control.

Container Apps supports two ingress modes: External (publicly reachable via a load-balanced HTTPS endpoint with automatic TLS) and Internal (only reachable from within the same Container Apps environment or from VNet-peered resources). Internal ingress is used for backend services that should never be exposed to the internet. Apps can call each other using the auto-generated internal DNS name http://myapi within the same environment, enabling simple service-to-service communication without deploying an API gateway.

Test your understanding of Microsoft Azure Fundamentals (AZ-900) concepts from this lesson.

In this lesson you learned: Azure Container Apps provides serverless container hosting built on Kubernetes and KEDA without cluster management, KEDA scalers enable scale-to-zero based on queue depth, HTTP traffic, or cron schedules, and Dapr integration simplifies microservice-to-microservice communication and state management. Next up we connect everything into a complete end-to-end developer workflow.