Azure Container Apps: Environments, Revisions, KEDA Scaling, and Managed Ingress

Azure Container Apps is a serverless platform for containerized applications and jobs. It exposes selected Kubernetes-era capabilities—revisions, event-driven scaling, service discovery, ingress, and optional Dapr integration—without giving customers a general Kubernetes API to operate.

Environments, apps, and revisions

Container apps live inside an environment that establishes a networking and observability boundary. A template change creates a revision. Single-revision mode replaces the active revision; multiple-revision mode enables traffic splitting and side-by-side validation. Jobs are separate resources for manual, scheduled, or event-driven work that terminates.

Scaling with KEDA

HTTP demand, CPU or memory, and supported KEDA-based triggers can change replica count. Many workloads can scale to zero, but CPU- or memory-only rules cannot do so because no running replica remains to produce those metrics. Define minimum and maximum replicas deliberately, then protect queues and databases against a sudden burst of parallel consumers.

Security and networking

Managed identities avoid embedding Azure credentials. Secrets can be stored by the platform or referenced through supported integrations; application logs must never print them. Ingress may be external or internal, and environments can integrate with a virtual network. Confirm subnet sizing, DNS, private endpoints, and egress requirements before treating an environment as a drop-in replacement for AKS networking.

Operations and cost

Azure Monitor and Log Analytics provide platform logs and metrics; application-level tracing still requires instrumentation. Revisions simplify rollback, but schema migrations and message consumers must remain compatible during overlap. Consumption and dedicated workload profiles have different cost and isolation characteristics. Container Apps fits teams wanting managed HTTP, event, and job execution; AKS remains appropriate when the Kubernetes API, custom controllers, privileged workloads, or deeper node control are requirements.

Revision scope and release safety

A revision is an immutable snapshot of revision-scoped configuration. Image, command, environment, scale rules, and resource changes can create a new revision, while application-scoped settings affect the app more broadly. In single-revision mode, the platform activates the new revision and moves traffic when it is ready; in multiple-revision mode, operators control active revisions and traffic weights. Neither mode makes an incompatible database migration safe. Use expand-and-contract schema changes, tolerate old and new message formats, and retain the last verified image digest.

Deployment labels and traffic splitting are operational controls, not test substitutes. Send synthetic and real canary traffic, compare latency and error SLOs, then advance weights through a reviewed process. A rollback changes traffic but cannot reverse external side effects. Record revision name, image digest, configuration, traffic weights, migration state, and approval so an incident responder can reconstruct the release.

Scaling is a contract with dependencies

Container Apps supports HTTP scaling and event-driven rules based on KEDA scalers. Authentication for a scale rule should use a managed identity where supported rather than a secret copied into configuration. Define polling interval, cooldown, minimum and maximum replicas, and the scaler’s target with the actual queue or event source. A queue length of one hundred does not necessarily mean one hundred safe workers when each worker opens database connections or calls a rate-limited API.

Scale-to-zero introduces activation latency and removes in-process caches. Set a nonzero minimum where the latency objective requires warm capacity. Jobs have completion, parallelism, replica timeout, and retry semantics that differ from continuously serving apps; make work idempotent and store checkpoints externally. A failed job retry can repeat a side effect just as surely as a retried HTTP request.

Identity, secrets, and network boundaries

System-assigned identities follow the app lifecycle; user-assigned identities are separate resources that can be shared. Grant the selected identity only the data-plane actions required by the application, and keep deployer permissions separate. Secret references prevent a value from appearing directly in an image, but rotation still needs a documented refresh or revision procedure. Audit which revisions can resolve which secret version.

An environment provides service discovery and network configuration for its apps. For virtual-network integration, size the delegated subnet according to the selected environment and workload profiles, and reserve capacity for growth. Confirm DNS resolution, private endpoints, user-defined routes, firewall policy, and outbound dependencies. Internal ingress restricts exposure to the environment’s configured network path; it does not automatically authorize one app to call another.

Production evidence

Collect system logs, console logs, revision and replica status, scale events, request metrics, and distributed traces. Alert on activation failures, replicas stuck at maximum, restart loops, HTTP error budget consumption, queue age, and downstream saturation. Keep diagnostic commands and Azure resource IDs in the runbook, but avoid instructions that require broad Owner access.

Before launch, prove a canary, rollback, scale from zero, maximum-replica protection, managed-identity access, secret rotation, private dependency, and regional recovery assumption. Document current quotas and limitations from Microsoft Learn. Managed infrastructure reduces the platform surface; it does not remove capacity, data, or release engineering.

Configuration should be reproducible through Bicep, ARM, Terraform, or another reviewed declarative path. Capture environment and app settings without exporting secret values, and compare deployed state with source after emergency changes. Assign ownership separately for the environment network, application revision, identities, scale source, and data dependency. During an incident, this prevents a platform team from waiting on an application team that assumes Azure owns the failed component.

Cost tests should include minimum replicas, execution time, dedicated workload-profile capacity where selected, logging ingestion and retention, egress, private networking, and dependent services. Review scale events alongside request or queue SLOs: scaling activity is not success if backlog age or error rate continues to rise. Archive the test results with the release so later tuning can distinguish a configuration regression from a change in workload shape.

Related:

Sources: