Azure Container Apps Guide: Architecture, Scaling, and Best Practices

Containers have become the standard way to package and deploy applications. They provide consistency across environments, efficient resource utilization, and simplified dependency management. But running containers in production introduces a familiar dilemma: do you adopt Kubernetes or stick with a simpler platform?

Kubernetes is powerful. It provides fine-grained control over scheduling, networking, and scaling. But that power comes with significant operational complexity. Managing the control plane, configuring networking, securing the cluster, and keeping everything up to date requires specialized expertise. For many teams, this complexity outweighs the benefits.

On the other end of the spectrum, fully managed platforms like Azure App Service abstract away the infrastructure entirely. You deploy your code, and the platform handles the rest. But these platforms have limitations—they're not container-first, and they don't provide the same level of control over the container runtime.

Azure Container Apps sits in the middle. It's a serverless container platform that runs microservices and containerized applications on Azure. It provides built-in autoscaling, including scale to zero, and supports multiple programming languages and frameworks. Container Apps integrates with Azure Kubernetes Service for advanced networking and monitoring.

Azure Container Apps provides a managed environment for running containerized applications while abstracting much of the underlying Kubernetes infrastructure. You still work with containers, revisions, scaling, networking, identities, and application configuration. But Azure manages the underlying platform—the Kubernetes control plane, node management, and infrastructure updates.

Common uses of Azure Container Apps include:

• Deploying API endpoints
• Hosting background processing jobs
• Handling event-driven processing
• Running microservices

Applications built on Container Apps can dynamically scale based on HTTP traffic, event-driven processing, CPU or memory load, or any KEDA-supported scaler. This flexibility makes it suitable for everything from simple APIs to complex event-driven microservices.

What Is Azure Container Apps?

Azure Container Apps is a serverless platform that allows you to maintain less infrastructure and save costs while running containerized applications. Instead of worrying about server configuration, container orchestration, and deployment details, Container Apps provides all the up-to-date server resources required to keep your applications stable and secure.

Core purpose

Azure Container Apps is designed for teams that want to run containerized applications without managing Kubernetes. It provides:

• Container-first application model – Deploy containers from any registry, public or private, including Docker Hub and Azure Container Registry
• Serverless characteristics – Automatic scaling, including scale to zero, with pay-per-use pricing
• Microservice support – Built-in service discovery, internal networking, and traffic splitting
• Event-driven workloads – Scale based on queues, event streams, and other triggers
• HTTP applications and APIs – Built-in ingress with HTTPS and TLS termination
• Background jobs – Run batch processing, scheduled tasks, and event-driven jobs

What Azure Container Apps is NOT

To understand Container Apps, it's equally important to understand what it is not:

• It is not simply Azure Container Instances – Container Apps provides a higher-level application platform with revisions, scaling, and lifecycle management
• It is not equivalent to Azure App Service – App Service is a PaaS platform for web applications; Container Apps is a container-first platform
• It is not a replacement for every AKS workload – Workloads requiring direct Kubernetes API access, custom scheduling, or specialized Kubernetes extensions are better suited for AKS
• It is not a traditional VM-based container platform – It abstracts the underlying infrastructure entirely

Level of abstraction

Container Apps provides a higher level of abstraction than AKS but lower than App Service. You work with container images, environment variables, secrets, and scaling rules. You don't work with nodes, pods, or the Kubernetes API directly. This abstraction reduces operational complexity while maintaining the flexibility of a container-based platform.

Azure Container Apps at a Glance

Capability	Purpose
Container deployment	Run containerized applications from any registry
Revisions	Version and manage application deployments with immutable snapshots
Autoscaling	Scale applications based on HTTP, events, CPU, memory, or custom metrics
Ingress	Expose applications through HTTPS/TCP with built-in TLS termination
Internal communication	Connect services within an environment with built-in DNS-based service discovery
Jobs	Run batch, scheduled, or event-driven workloads with finite duration
Secrets	Manage application secrets directly in your application
Managed identity	Authenticate to Azure services without embedded credentials
Dapr integration	Support distributed application patterns where appropriate
Networking	Integrate applications with virtual networks
ACR integration	Pull private container images with managed identity
Monitoring	Integrate with Azure Monitor and Log Analytics
Traffic splitting	Support gradual rollout and blue/green or canary-style deployment

Azure Container Apps Architecture

Hierarchy and major components

Azure Subscription
  └── Resource Group
        └── Container Apps Environment
              └── Container App
                    └── Revision
                          └── Replica (container instance)

Each layer explained

Container Apps Environment – The secure boundary and networking container for all container apps and jobs. An environment provides:

• A dedicated network boundary
• Shared logging and monitoring infrastructure
• Internal service discovery
• Security and compliance boundaries

Container App – A logical application that contains one or more revisions. Each container app represents a single deployable unit with its own:

• Container image and configuration
• Ingress settings
• Scaling rules
• Secrets

Revision – An immutable snapshot of the container app's configuration, including the container image, environment variables, secrets, and scaling rules. Every time you make a change to a container app, a new revision is created.

Replica – A running instance of a revision. When a revision scales, the platform creates new replicas as needed. Replicas are the actual running containers.

Container – The running container instance within a replica. A container app can run one or more containers per replica.

Conceptual architecture diagram

Internet / Client
        ↓
   Ingress (HTTPS/TCP)
        ↓
Container App (my-api)
        ↓
    Revision (v1.0.0)
        ↓
    Replicas (3 instances)
        ↓
Azure Services (Database, Storage, etc.)

Multi-service architecture

Multiple container apps can communicate within the same environment using internal ingress and service discovery:

Container Apps Environment
    ├── Container App: api-gateway (public ingress)
    ├── Container App: orders-service (internal only)
    ├── Container App: payments-service (internal only)
    └── Container App: inventory-service (internal only)

Internal services discover each other through built-in DNS-based service discovery, using the container app name as the hostname.

Container Apps Environment

The Container Apps Environment is the most important architectural boundary in Azure Container Apps.

What an environment provides

• Network boundary – All container apps in an environment share the same virtual network configuration
• Shared logging – Logs from all container apps flow to the same Log Analytics workspace
• Security boundary – Managed identities, secrets, and access controls are scoped to the environment
• Internal service discovery – Container apps can communicate using built-in DNS resolution

Workload profiles (v2)

As of January 2026, Workload Profiles (v2) has become the default environment type, replacing the legacy Consumption-only (v1) model. Any new Azure Container Apps environment should be a Workload Profiles (v2) environment.

Workload Profiles v2 environments provide:

• Multiple profile types – Consumption (auto-scale, scale-to-zero) and Dedicated (reserved compute)
• Enhanced networking – Firewall support, native private endpoints, and optimized IP address allocation
• GPU support – Native GPU workload profiles for AI/ML workloads
• Flexible architecture – Mix consumption and dedicated profiles within the same environment

Choosing environment architecture

When to put multiple services in one environment:

• Services need to communicate internally
• You want to share networking configuration
• You want to share logging and monitoring
• You want to reduce operational overhead

When to separate into different environments:

• Different security requirements
• Different networking requirements
• Different compliance boundaries
• Different cost centers or teams

Trade-offs:

• Isolation – Separate environments provide stronger failure isolation
• Governance – Separate environments enable different policies and controls
• Networking – One environment simplifies internal communication
• Cost – One environment reduces management overhead
• Failure domains – A failure in one environment doesn't affect another

Container Apps and Containers

The relationship

Container image → The packaged application and its dependencies, stored in a container registry.

Container App → The logical application that references a container image.

Revision → A specific version of the container app with a specific image tag and configuration.

Replica → A running instance of a revision.

Image sources

Azure Container Apps can pull images from:

• Azure Container Registry (ACR)
• Docker Hub
• Any other container registry (public or private)

Image naming and versioning

Use meaningful image tags for production:

• Semantic versioning: myapp:v1.2.3
• Git commit SHA: myapp:a1b2c3d
• Date-based: myapp:2024-01-15-1200

Do not use latest in production. The latest tag is mutable and provides no versioning guarantees. Using latest makes it impossible to determine which version is actually deployed or to roll back reliably.

Image pull authentication

For private registries, Container Apps authenticates using:

• Managed identity (recommended)
• Registry credentials (username/password)

Recommendation: Use managed identity for ACR authentication. Grant the container app's managed identity the AcrPull role on the registry.

Deployment Options

Deployment methods

Azure Container Apps supports multiple deployment approaches:

• Azure Portal – Quick testing and prototyping
• Azure CLI – Scripted deployments and automation
• Infrastructure as Code – Bicep, ARM templates, or Terraform for production
• GitHub Actions – CI/CD from GitHub repositories
• Azure DevOps – Enterprise CI/CD pipelines

Typical developer workflow

Source Code
    ↓ (git push)
Build container image (Docker build)
    ↓ (docker push)
Azure Container Registry
    ↓ (az containerapp update / GitHub Actions)
Container App
    ↓
New Revision
    ↓ (traffic shift)
Application updated

Infrastructure as Code

For production deployments, use Infrastructure as Code:

• Bicep – Azure-native declarative language
• ARM templates – Azure Resource Manager templates
• Terraform – HashiCorp's declarative IaC tool

IaC provides version control, repeatability, and auditability for your Container Apps infrastructure.

Revisions and Application Lifecycle

Revisions are central to how Azure Container Apps manages application deployments.

What is a revision?

A revision is an immutable snapshot of your container app. Each revision includes:

• The container image and tag
• Environment variables
• Secrets (references, not the actual values)
• Scaling rules
• Ingress configuration
• Resource limits

Revision modes

Azure Container Apps supports two revision modes:

Single revision mode – The default for new container apps. Only one revision is active at a time. When you deploy a change, the old revision is automatically deactivated, and the new revision becomes active. This mode provides zero-downtime deployment with automatic traffic switching.

Multiple revision mode – Allows multiple revisions to be active simultaneously. Traffic can be split between active revisions based on percentage weights. This mode enables:

• Blue/green deployments
• Canary releases
• A/B testing
• Gradual rollouts

Traffic splitting

When multiple revision mode is enabled, you can split incoming traffic between active revisions. Traffic splitting is based on the weight (percentage) of traffic that is routed to each revision. The combined weight of all traffic split rules must equal 100%.

Labels – You can assign labels to revisions and route traffic based on labels instead of revision names. Labels provide stable URLs that don't change when the revision name changes.

Practical deployment flow with multiple revisions

Revision 1 (current production, 100% traffic)
    ↓
Deploy Revision 2 (new version, 0% traffic initially)
    ↓
Send 5% traffic to Revision 2 (canary)
    ↓
Observe metrics and logs
    ↓
Increase traffic to Revision 2 (20%, 50%, 100%)
    ↓
Move 100% traffic to Revision 2
    ↓
Deactivate Revision 1

Blue/green deployments

Blue/green deployments are supported through multiple revision mode and traffic splitting. The "blue" revision is the current production version. The "green" revision is the new version. Traffic is switched from blue to green in a single step (or gradually) by adjusting traffic weights.

Rollback

Rolling back is simple with revisions. If a new revision causes issues, you can:

1. Adjust traffic weights to send 100% traffic back to the previous revision
2. Or deactivate the problematic revision and reactivate the previous one

Since revisions are immutable, you can always revert to a known-good version.

Scaling and Autoscaling

Azure Container Apps manages automatic horizontal scaling through a set of declarative scaling rules.

How scaling works

When a container app revision scales, the platform creates new instances of the revision as needed. These instances are called replicas. The scaling behavior is powered by KEDA (Kubernetes Event-driven Autoscaling).

Scaling limits

Scaling Limit	Default	Minimum	Maximum
Minimum replicas per revision	0	0	Up to 1,000
Maximum replicas per revision	10	1	Up to 1,000

Minimum replicas – Set to 0 for scale-to-zero (you're not charged when scaled to zero). Set to 1 or higher to avoid cold starts for latency-sensitive applications.

Maximum replicas – Prevents over-scaling and controls costs.

HTTP-based scaling

HTTP scaling adjusts replica count based on concurrent HTTP requests. The platform calculates concurrent requests by dividing the number of requests received in the past 15 seconds by 15.

HTTP scale properties:

• concurrentRequests – When the number of HTTP requests exceeds this value per replica, the app adds another replica. Default is 10 concurrent requests per replica.

When to use HTTP scaling – APIs, web applications, and any HTTP-based service.

Event-driven scaling

Event-driven scaling enables your container apps to respond to external signals beyond HTTP traffic. Azure Container Apps integrates with KEDA to provide scaling based on message queues, event streams, and other Azure services.

Supported scalers include:

• Azure Service Bus (queues and topics)
• Azure Event Hubs
• Azure Storage Queues
• Apache Kafka
• Redis
• CPU and memory load
• Any KEDA-supported scaler

Important: When using non-HTTP event scale rules, set the container app's activeRevisionsMode property to single.

Scale-to-zero

Most applications can scale to zero. When scaled to zero:

• No replicas are running
• No compute costs are incurred
• The app resumes when a request arrives or an event triggers it

Considerations for scale-to-zero:

• Cold start latency – The first request after scaling to zero may have higher latency
• Not suitable for all workloads – Some applications need to be always ready

Scaling best practices

• Use minimum replicas for latency-sensitive applications
• Use maximum replicas to control costs and protect downstream systems
• Test scaling behavior with realistic load patterns
• Monitor replica count and scaling events
• Set appropriate concurrentRequests values for HTTP scaling

Event-Driven Scaling

Container Apps is designed to support event-driven architectures through KEDA-based scaling.

Event-driven architecture example

Event Source (Service Bus queue)
    ↓ (messages accumulate)
KEDA scale trigger detects queue depth
    ↓ (scale out)
Container App replicas process messages
    ↓ (scale in)
Messages processed, replicas scale down

Common event sources

Azure Service Bus – Scale based on queue length or topic subscription message count. Use for order processing, workflow coordination, and reliable business messaging.

Azure Event Hubs – Scale based on events per partition or total events. Use for high-volume telemetry and event streaming.

Azure Storage Queues – Scale based on queue message count. Use for simple background processing.

Apache Kafka – Scale based on lag per consumer group. Use for Kafka-based event streaming.

Event-driven jobs

Event-driven jobs use scaling rules to trigger execution based on events. Unlike apps, jobs run for a finite duration and then stop. For more details on jobs, see the Container Apps Jobs section below.

When to use event-driven scaling

Use event-driven scaling when:

• Workloads are triggered by messages or events
• Traffic patterns are unpredictable
• You want to scale to zero during idle periods
• You're building event-driven microservices

Container Apps Jobs

Azure Container Apps jobs enable you to run containerized tasks that run for a finite duration and then stop. You can use jobs for data processing, machine learning, or any scenario where on-demand processing is required.

Apps vs. jobs

There are two types of compute resources in Azure Container Apps: apps and jobs.

Aspect	Apps	Jobs
Runtime	Run continuously	Run for finite duration, then stop
Restart behavior	Automatically restart on failure	Stop when finished
HTTP ingress	✅ Yes	❌ No
Scaling	Scale based on HTTP, events, CPU, memory	Scale based on events (event-driven jobs)
Scheduling	Not applicable	Schedule or on-demand
Best for	APIs, web apps, background services	Batch processing, scheduled tasks, one-off jobs

Example scenarios

Scenario	Compute Resource	Notes
HTTP server serving web content and API requests	App	Configure an HTTP scale rule
Process that generates financial reports nightly	Job	Use the Schedule job type with a cron expression
Continuously running service processing Service Bus messages	App	Configure a custom scale rule
Job processing a single message batch from a queue and stopping	Job	Use the Event job type with a custom scale rule
Background task triggered on-demand	Job	Use the Manual job type

Job trigger types

Manual jobs – Triggered on-demand via the Azure portal, CLI, or API. Each execution runs once and stops.

Scheduled jobs – Triggered on a schedule using a cron expression. Use for nightly reports, daily data processing, or weekly maintenance tasks.

Event-driven jobs – Triggered based on events from KEDA-supported scalers. Use for processing messages from queues or event streams.

Job configuration

Key job configuration parameters:

• Replica timeout – Maximum duration for a job execution
• Replica retry limit – Number of retry attempts on failure
• Parallelism – Number of replicas to run in parallel
• Replica completion count – Number of successful replicas required to mark the job as complete

Jobs and environments

Container apps and jobs run in the same environment, allowing them to share capabilities such as networking and logging.

Networking

Networking architecture

Azure Container Apps provides flexible networking options.

Public ingress – Expose applications to the internet with HTTPS/TCP ingress. Azure manages the TLS certificates and load balancing.

Internal ingress – Expose applications only within the virtual network. Use for internal APIs, microservices, and services that shouldn't be publicly accessible.

Environment networking – By default, Container Apps environments use an automatically generated managed VNet. Alternatively, you can provide an existing VNet when creating an environment.

Virtual network integration

To use a VNet with Container Apps, the VNet must have a dedicated subnet:

• Workload profiles (v2) environment: Subnet with CIDR range of /27 or larger
• Legacy Consumption-only environment: Subnet with CIDR range of /23 or larger

When to use a custom VNet:

• User-defined routes (UDR)
• Integration with Application Gateway
• Network Security Groups (NSG)
• Communication with resources behind private endpoints

Private endpoints

Container Apps environments in Workload Profiles v2 support native private endpoints. This enables:

• Private access to your container apps
• Network isolation from the public internet
• Compliance with enterprise security policies

DNS and service discovery

Container Apps provides built-in DNS-based service discovery for internal services. Container apps within the same environment can communicate using the container app name as the hostname.

Enterprise network patterns

Pattern: Private application with dependent services

Container Apps Environment (internal ingress)
    ├── Container App: internal-api (internal only)
    ├── Container App: worker (internal only)
    │
    ├── Azure SQL Database (private endpoint)
    ├── Azure Storage Account (private endpoint)
    └── Azure Service Bus (private endpoint)

All traffic stays within the virtual network, with no public exposure.

Security

Azure Container Apps provides multiple layers of security.

Authentication and authorization

Microsoft Entra ID – Authenticate users and applications using Microsoft Entra ID.

Azure RBAC – Control who can create, modify, and delete Container Apps resources.

Managed identities – Eliminate the need to store credentials in your code or configuration by providing an automatically managed identity in Microsoft Entra ID.

Managed identity types

Azure Container Apps supports two types of managed identities:

System-assigned identity – Created and managed automatically with your container app's lifecycle. The identity is tied to the container app and deleted when the app is deleted.

User-assigned identity – Created independently and assigned to one or more container apps. Useful for sharing an identity across multiple apps.

Managed identity usage pattern

Container App
    ↓ (managed identity)
Microsoft Entra ID
    ↓ (RBAC)
Azure Resource (Key Vault / Storage / Service Bus / Database)

This pattern eliminates the need to store connection strings, access keys, or other credentials in your container app configuration.

Secrets

Azure Container Apps provides built-in secret management. Secrets can be:

• Container Apps secrets – Stored securely within the container app
• Azure Key Vault references – Reference secrets stored in Azure Key Vault

Secret access – Secrets are exposed to your container app as environment variables or mounted files. They are never exposed in the Azure portal or API responses.

Key Vault integration

Use Azure Key Vault for centralized secret management:

• Store connection strings, API keys, and certificates
• Reference Key Vault secrets from Container Apps
• Use managed identity for secure access to Key Vault

Container image security

• Use trusted registries (ACR is recommended)
• Scan images for vulnerabilities before deployment
• Use managed identity for ACR authentication
• Avoid using latest tags in production

Security best practices

• Use managed identities instead of connection strings
• Store secrets in Key Vault, not in environment variables
• Apply least-privilege RBAC
• Use private networking for sensitive workloads
• Enable HTTPS for all ingress
• Scan container images for vulnerabilities
• Regularly rotate secrets

Managed Identity

Managed identity is the recommended approach for authenticating Container Apps to Azure resources.

System-assigned vs. user-assigned

System-assigned managed identity:

• Created automatically when enabled
• Tied to the container app lifecycle
• Simpler to use for single-app scenarios
• Cannot be shared across multiple apps

User-assigned managed identity:

• Created independently as a separate Azure resource
• Can be shared across multiple container apps
• Better for multi-app scenarios with shared access requirements
• More complex to set up initially

When to use each

Scenario	Recommended Identity Type
Single container app accessing Azure resources	System-assigned
Multiple container apps sharing the same identity	User-assigned
CI/CD pipeline accessing Azure resources	User-assigned or service principal
Simple development scenarios	System-assigned

RBAC assignment

After creating a managed identity, assign RBAC roles to grant access to Azure resources:

Role	Grants access to
AcrPull	Pull images from Azure Container Registry
Key Vault Secrets User	Read secrets from Azure Key Vault
Storage Blob Data Contributor	Read/write blobs in Storage
Service Bus Data Sender	Send messages to Service Bus
Service Bus Data Receiver	Receive messages from Service Bus

Realistic architecture example

Container App: order-api
    ↓ (system-assigned managed identity)
Key Vault Secrets User → Azure Key Vault (connection strings)
AcrPull → Azure Container Registry (pull images)
Service Bus Data Sender → Azure Service Bus (send order events)
Storage Blob Data Contributor → Azure Storage (write order logs)

The application code uses DefaultAzureCredential to acquire tokens and access these resources without any credentials stored in the application.

Azure Container Registry Integration

Azure Container Apps integrates seamlessly with Azure Container Registry (ACR).

Integration

Container Apps can pull images from ACR using:

• Managed identity – The container app's managed identity is granted AcrPull on the registry
• Registry credentials – Username and password stored as secrets

Recommendation: Use managed identity. It's more secure and eliminates credential management.

Workflow

Developer / CI
    ↓ (docker build + push)
Azure Container Registry
    ↓ (pull with managed identity)
Container App
    ↓ (new revision)
Application updated

Image pull authentication

When you deploy a container app referencing an ACR image, the platform uses the container app's managed identity to authenticate to ACR. No credentials are stored in the container app configuration.

CI/CD integration

ACR and Container Apps are commonly integrated in CI/CD pipelines:

1. Build container image
2. Push to ACR
3. Update Container App to reference the new image
4. Container App pulls the image using managed identity

This provides a secure, credential-free deployment pipeline.

Observability and Monitoring

Azure Monitor metrics

Azure Monitor collects metric data from your container app at regular intervals to help you gain insights into performance and health.

Key metrics:

• CPU Usage Percentage
• Memory Working Set Bytes
• Replica Count
• Total Replica Restart Count
• Network utilization

What developers should monitor

• Application logs
• Error rates
• Request latency (for HTTP apps)
• Replica count (scaling behavior)
• Container restarts

What architects should monitor

• Environment-level metrics
• Resource utilization across all apps
• Cost and usage trends
• Scaling behavior and capacity
• Security events and access logs

Logging

Azure Container Apps provides built-in logging capabilities:

• Application logs – Logs from your container application
• System logs – Platform-level logs
• Container logs – Container runtime logs

Logs are sent to the Log Analytics workspace associated with the environment.

Application Insights

For deeper application performance monitoring, integrate Application Insights:

• Request rates, response times, and failure rates
• Dependency tracking
• Distributed tracing
• Performance anomaly detection

Monitoring checklist

• Set up alerts for high error rates
• Monitor replica count and scaling events
• Track CPU and memory usage
• Review application logs regularly
• Set up dashboards for key metrics
• Configure alerts for service health
• Monitor cost and usage

Dapr and Microservices

Azure Container Apps provides APIs powered by Distributed Application Runtime (Dapr) that help you write and implement simple, portable, resilient, and secured microservices. Dapr works together with Azure Container Apps as an abstraction layer to provide a low-maintenance and scalable platform.

What Dapr provides

Azure Container Apps offers a selection of fully managed Dapr APIs, components, and features, catered specifically to microservice scenarios:

• Service invocation – Securely call other services with automatic retries and circuit breakers
• Pub/sub – Publish and subscribe to messages between services
• State management – Manage state with pluggable state stores
• Bindings – Connect to external systems with input/output bindings
• Secrets – Access secrets from secret stores

How Dapr works with Container Apps

Dapr is enabled at the container app level by configuring a set of Dapr arguments. A Dapr sidecar runs alongside your container app, exposing Dapr APIs via HTTP on port 3500 and gRPC on port 50001.

Architecture:

Container App (your code)
    │ (HTTP/gRPC)
    ▼
Dapr Sidecar (managed by Container Apps)
    │ (Dapr components)
    ▼
External services (Azure Service Bus, Redis, etc.)

Dapr components

Dapr components are shared across multiple container apps. Components include:

• State stores (Redis, Cosmos DB)
• Pub/sub brokers (Service Bus, Event Hubs)
• Secret stores (Key Vault)
• Bindings (Storage, Service Bus)

When to use Dapr

Use Dapr when:

• You're building microservices with multiple services
• You need service-to-service communication with resilience
• You need pub/sub for event-driven architectures
• You want to simplify distributed application patterns

When direct Azure service integration may be simpler:

• Single service with one or two dependencies
• Simple HTTP API with database
• Team is not familiar with Dapr

Dapr and Container Apps benefits

• Fully managed – no infrastructure to operate
• Integrated with Container Apps revisions and scaling
• Dapr versions include Azure-specific customizations for enhanced security
• Works with multiple programming languages

Azure Container Apps for Microservices

Azure Container Apps is an excellent platform for microservices architectures.

Microservices architecture example

API Gateway (public ingress)
     ↓
 ┌───────────────┬───────────────┬───────────────┐
 ↓               ↓               ↓               ↓
Orders          Payments        Users           Notifications
Service         Service         Service         Service
(internal)      (internal)      (internal)      (internal)
 ↓               ↓               ↓               ↓
 └───────────────┴───────────────┴───────────────┘
                     │
                     ▼
              Service Bus (events)

Service boundaries

Each microservice is deployed as a separate container app:

• Independent scaling based on workload
• Independent deployment with revisions
• Independent failure isolation
• Own data store (database per service)

Internal communication

Services communicate using:

• HTTP – Synchronous calls using internal ingress and service discovery
• Dapr – Service invocation with resilience
• Service Bus – Asynchronous event-driven communication

Independent deployments

Each service has its own revision lifecycle:

• Deploy a new revision for Service A without affecting Service B
• Roll back Service A independently
• Canary deployments per service

Independent scaling

Each service scales independently:

• Orders Service scales based on HTTP traffic
• Payments Service scales based on queue depth
• Notifications Service can scale to zero when idle

Failure isolation

Failures are contained within each service:

• One service failing doesn't affect others
• Circuit breakers prevent cascading failures
• Retries and timeouts protect downstream services

Azure Container Apps for AI Workloads

Azure Container Apps is increasingly used for AI workloads, especially with the introduction of GPU support and serverless AI primitives.

AI use cases on Container Apps

AI inference APIs – Deploy AI models as scalable HTTP APIs. Container Apps provides:

• Automatic scaling based on request volume
• Scale-to-zero during idle periods
• Integration with Azure AI services

LLM application APIs – Host APIs that interact with LLMs (Azure OpenAI, etc.). Container Apps provides the application layer while Azure OpenAI handles the model inference.

RAG (Retrieval-Augmented Generation) APIs – Build RAG APIs that combine vector search with LLM generation.

AI agents – Host AI agent services that process tasks, call tools, and interact with users.

Background AI workers – Process AI workloads asynchronously:

• Document processing
• Embedding generation
• Batch inference
• Data preprocessing

Event-driven AI pipelines – Trigger AI processing based on events from Service Bus, Event Grid, or Event Hubs.

GPU support

Workload Profiles v2 environments support GPU workload profiles with NVIDIA T4 and A100 accelerators. This enables:

• Model inference with GPU acceleration
• Batch processing of AI workloads
• Real-time AI applications

When to use GPU profiles: Workloads requiring GPU acceleration, such as large language model inference, computer vision, or deep learning inference.

Example AI architecture

Frontend (web/mobile)
    ↓
AI API Container App (CPU, HTTP scaling)
    ↓
 ┌──────────────┬───────────────┐
 ↓              ↓               ↓
Azure OpenAI   Azure AI        Cosmos DB
                Search
                (vector)
                ↓
Blob Storage (documents)

Container Apps vs. AKS for AI

Aspect	Container Apps	AKS
GPU support	Yes (Workload Profiles v2)	Yes
Model serving	Built-in scaling, simpler operations	Full control, custom serving frameworks
Operational complexity	Low	High
Kubernetes API access	No	Yes
Best for	Application layer, API hosting, event-driven AI	Specialized model serving, custom Kubernetes operators

When Container Apps is appropriate

Container Apps is ideal for the application and orchestration layer of AI systems:

• Hosting AI APIs
• Orchestrating AI workflows
• Processing events
• Managing application logic

Model inference and complex AI processing can be handled by Azure OpenAI, Azure AI Services, or specialized model hosting.

When AKS may be more appropriate

AKS may be better for:

• Specialized model serving frameworks (Triton, vLLM)
• Custom Kubernetes operators for AI
• Fine-grained control over GPU scheduling
• Multi-model serving with complex routing

Azure Container Apps vs. Azure App Service

Aspect	Azure Container Apps	Azure App Service
Container-first	Yes (OCI containers)	Limited (Docker support, but platform-first)
Application model	Container images	Code or containers
Scaling	KEDA-based, scale-to-zero	HTTP-based, fixed minimum instances
Scale-to-zero	✅ Yes	❌ No
Revisions	✅ Immutable revisions with traffic splitting	Deployment slots
Microservices	✅ Built-in service discovery	Requires custom configuration
Networking	VNet integration, private endpoints	VNet integration
Developer experience	Container-focused	Code-first
Operational complexity	Low	Lower
Best-fit workloads	Containerized microservices, event-driven workloads	Web applications, APIs, code-first deployments

When to choose Container Apps instead of App Service

• You want to run containerized applications with a container-first experience
• You need scale-to-zero to minimize costs
• You're building microservices with internal service discovery
• You need event-driven scaling (KEDA)
• You want immutable revisions with traffic splitting

Azure Container Apps vs. Azure Kubernetes Service

Aspect	Azure Container Apps	AKS
Abstraction level	High (serverless container platform)	Low (Kubernetes control)
Kubernetes API access	❌ No	✅ Full
Operational responsibility	Low (platform manages infrastructure)	High (you manage cluster operations)
Networking	Managed, VNet integration	Full control (CNI, network policies)
Scaling	KEDA-based (built-in)	HPA + Cluster Autoscaler
Deployment complexity	Low	High
Microservices	✅ Built-in	✅ Full support
GPU workloads	✅ Yes (Workload Profiles v2)	✅ Yes
Custom Kubernetes features	❌ No	✅ Yes (custom resources, operators, service mesh)
Platform extensibility	Limited	High
Developer productivity	High (less infrastructure to manage)	Lower (more infrastructure to manage)
Cost	Pay-per-use, scale-to-zero	Pay for nodes, even if underutilized

Decision framework

Choose Container Apps when:

• You want managed container execution without managing Kubernetes
• You do not need direct Kubernetes API access
• You want simpler operations
• You need autoscaling and revisions
• You're deploying APIs, microservices, workers, or event-driven workloads
• You want scale-to-zero to minimize costs

Choose AKS when:

• You need Kubernetes APIs
• You need advanced cluster-level control
• You need specialized scheduling
• You need extensive Kubernetes ecosystem integration
• You need advanced networking or platform customization
• You have workloads requiring capabilities beyond Container Apps

Azure Container Apps vs. Azure Container Instances

Aspect	Azure Container Apps	Azure Container Instances
Application lifecycle	Full lifecycle (revisions, scaling, updates)	Simple container execution
Scaling	Automatic (KEDA-based)	Manual
Scale-to-zero	✅ Yes	❌ No (always running)
Revisions	✅ Yes	❌ No
Networking	VNet integration, service discovery	Basic networking
Microservices	✅ Built-in service discovery	❌ No
Operational model	Application platform	Container runtime
Best-fit workloads	Production microservices, APIs, event-driven workloads	Simple containers, burst workloads, testing

Common Architecture Patterns

Pattern 1: Simple containerized API

Client
    ↓ (HTTPS)
Container App (public ingress)
    ↓
Azure SQL Database

When to use: Single API or web application. Simple, low operational overhead.

Benefits: Easy to deploy, automatic scaling, built-in HTTPS.

Risks: Limited to a single service.

Pattern 2: Microservices platform

API Gateway (public ingress)
    ↓
 ┌───────────────┬───────────────┐
 ↓               ↓               ↓
Orders          Payments        Users
Service         Service         Service
(internal)      (internal)      (internal)
 ↓               ↓               ↓
 └───────────────┴───────────────┘
                     │
                     ▼
              Service Bus (events)

When to use: Multiple services with independent scaling and deployment.

Benefits: Independent scaling, independent deployments, failure isolation, team autonomy.

Risks: More complex to manage, requires service discovery and communication patterns.

Pattern 3: Event-driven worker

Event Source (Service Bus queue)
    ↓ (scaling based on queue depth)
Container App Worker
    ↓
Storage / Database

When to use: Processing messages from queues, event streams, or event hubs.

Benefits: Scale-to-zero during idle periods, automatic scaling based on workload.

Risks: Cold start latency, requires idempotent processing.

Pattern 4: Private enterprise application

Internal network
    ↓
Container Apps Environment (internal ingress)
    ├── Container App: internal-api (private)
    ├── Container App: worker (private)
    │
    ├── Azure SQL (private endpoint)
    └── Azure Storage (private endpoint)

When to use: Enterprise applications requiring network isolation and private access to Azure resources.

Benefits: No public exposure, private connectivity to Azure services, compliance.

Risks: Requires VNet configuration, more complex networking.

Pattern 5: AI application

Client
    ↓
AI API Container App (CPU, HTTP scaling)
    ↓
 ┌──────────────┬───────────────┐
 ↓              ↓               ↓
Azure OpenAI   Azure AI        Cosmos DB
                Search

When to use: AI applications requiring integration with Azure AI services.

Benefits: Serverless scaling, integration with AI services, simple deployment.

Risks: GPU workloads may require AKS for specialized model serving.

High Availability and Reliability

Reliability design principles

The purpose of the Reliability pillar is to provide continued functionality by building enough resilience and the ability to recover fast from failures.

Multiple replicas

For ingress-exposed applications, use at least three replicas to help ensure availability. This provides redundancy if a replica fails.

Why three? With two replicas, losing one means losing 50% capacity. With three, losing one means losing only 33% capacity, and you still have two running.

Availability zones

Use availability zones as part of your resiliency strategy to increase availability when you deploy to a single region. Many Azure regions provide availability zones.

Best practice: Spread replicas across availability zones for zone-level failure protection.

Multi-region deployments

For critical workloads, deploy Container Apps environments across multiple regions and use Azure Front Door or Azure Traffic Manager for traffic management.

Health probes

Container Apps supports health probes for your containers:

• Liveness probes – Indicate whether the container is running
• Readiness probes – Indicate whether the container is ready to serve traffic

Configure probes to ensure the platform can detect and recover from failures.

What Container Apps manages vs. what you manage

Container Apps manages:

• Kubernetes infrastructure
• Node management and patching
• Control plane availability
• Platform-level scaling

You remain responsible for:

• Application design (stateless, resilient)
• Health probes
• Replica count (minimum/maximum)
• Application-level retries
• External state management
• Disaster recovery planning

Performance Considerations

Container startup time

Image size affects startup time. Keep images small:

• Use minimal base images (Alpine, Distroless)
• Remove unnecessary dependencies
• Use multi-stage builds

Cold starts

When scaling from zero, the first request may experience higher latency. Mitigations:

• Set minReplicas to 1 or higher for latency-sensitive applications
• Keep images small to reduce startup time
• Use warm-up endpoints

Replica scaling

Scaling adds replicas when needed. Considerations:

• Scaling up adds replicas based on the scale rule
• Scaling down removes replicas based on the scale rule
• There's a cooldown period between scaling events

Concurrency

HTTP scaling is based on concurrent requests per replica. Configure concurrentRequests appropriately:

• Too low → unnecessary scaling
• Too high → overloaded replicas

Resource allocation

Allocate appropriate CPU and memory to containers:

• Under-allocated → performance issues
• Over-allocated → wasted capacity

Network latency

• Place Container Apps and dependent Azure services in the same region
• Use private networking for lower latency
• Use Azure Front Door for global distribution

Database connection management

• Use connection pooling
• Reuse connections
• Set appropriate connection limits
• Monitor database connection counts

Cost Considerations

Main cost drivers

Compute consumption – Based on the number and size of replicas running. You're not charged when scaled to zero.

Replica count – More replicas = higher cost. Set appropriate minimum and maximum values.

Minimum replicas – Setting minReplicas to 1 or higher means at least one replica runs continuously.

Resource allocation – Larger CPU and memory allocations cost more.

Environment architecture – Workload Profiles environments allow mixing consumption and dedicated profiles.

Logging – Log Analytics storage and ingestion costs.

Supporting Azure services – Service Bus, Event Hubs, Storage, etc., have their own costs.

Network traffic – Data transfer costs for egress.

Architecture choices affecting cost

Choice	Cost Impact
Scale-to-zero (minReplicas=0)	✅ Cost savings during idle periods
Minimum replicas=1	❌ Always-running cost
Consumption profile	Pay-per-use (lower for variable workloads)
Dedicated profile	Reserved compute (lower for steady workloads)
Large image sizes	❌ Higher storage and transfer costs
Unnecessary logging	❌ Higher Log Analytics costs

Cost optimization recommendations

• Use scale-to-zero for development and test environments
• Set appropriate maxReplicas to prevent runaway costs
• Right-size container resources (CPU and memory)
• Use Consumption profiles for variable workloads
• Use Dedicated profiles for steady, predictable workloads
• Clean up old revisions and inactive environments

Production Best Practices

Deployment

• Use immutable image versions (no latest)
• Use Infrastructure as Code for production
• Separate development, staging, and production environments
• Use managed identity for ACR authentication

Scaling

• Set appropriate minReplicas for latency-sensitive applications
• Set appropriate maxReplicas to control costs and protect downstream systems
• Test scaling behavior with realistic load patterns
• Use event-driven scaling for queue-based workloads

Security

• Use managed identities instead of connection strings
• Store secrets in Key Vault
• Apply least-privilege RBAC
• Use private networking for sensitive workloads
• Enable HTTPS for all ingress
• Scan container images for vulnerabilities

Observability

• Monitor key metrics (CPU, memory, replica count, errors)
• Set up alerts for critical conditions
• Use structured logging
• Add correlation IDs for request tracing

Reliability

• Use at least three replicas for production workloads
• Configure health probes (liveness and readiness)
• Design applications to be stateless
• Externalize persistent state (Azure SQL, Storage, etc.)
• Test failure scenarios

Operations

• Use revisions for controlled deployments
• Use traffic splitting for canary and blue/green deployments
• Test upgrades in staging before production
• Document dependencies and failure modes
• Regularly review cost and usage

Common Mistakes

Treating Container Apps as a VM

Container Apps is a container platform, not a VM. Containers are ephemeral. Don't store state in the container filesystem. Use external state stores for persistent data.

Treating Container Apps as full Kubernetes

Container Apps abstracts Kubernetes. You don't have direct access to the Kubernetes API, custom resources, or operators. If you need those, use AKS.

Using one environment for unrelated applications

One environment shares networking and logging. Separate environments provide better isolation, governance, and failure domains.

Storing secrets inside images

Secrets in images are exposed to anyone with image access. Use environment variables, secrets, or Key Vault instead.

Using long-lived credentials

Use managed identities instead of connection strings and access keys. Managed identities are automatically rotated.

Deploying latest in production

The latest tag is mutable and provides no versioning guarantees. Use immutable tags (semantic version or Git SHA) for production.

Ignoring cold starts

Scale-to-zero causes cold starts. Set minReplicas to 1 or higher for latency-sensitive applications.

Setting minimum replicas too low for latency-sensitive services

If your service needs to respond quickly, scale-to-zero may cause unacceptable latency. Set minReplicas appropriately.

Setting maximum replicas without considering downstream limits

Scaling can overwhelm downstream systems (databases, APIs). Set appropriate maxReplicas and monitor downstream capacity.

Ignoring database connection scaling

Each replica creates database connections. Ensure your database can handle the maximum number of connections.

Putting state inside the container filesystem

Container filesystems are ephemeral. Use Azure SQL, Storage, or Cosmos DB for persistent state.

Using public ingress for internal services unnecessarily

Use internal ingress for services that shouldn't be publicly accessible.

Failing to monitor revisions

Monitor revision health, traffic distribution, and rollback if issues occur.

Choosing Container Apps when advanced Kubernetes control is required

If you need Kubernetes APIs, custom resources, or operators, choose AKS.

Choosing AKS when Container Apps would be sufficient

If you don't need Kubernetes control, Container Apps provides a simpler, more cost-effective platform.

Ignoring image vulnerabilities

Scan images before deployment. Block deployments with critical or high-severity vulnerabilities.

Troubleshooting

Container fails to start

• Symptom: Revision shows unhealthy or container crashes
• Likely causes: Application error, missing dependencies, incorrect entrypoint
• Diagnose: Check container logs in the Azure portal; use az containerapp logs show
• Fix: Fix application code; verify Dockerfile; test locally

Image pull failure

• Symptom: Revision shows ImagePullBackOff or similar
• Likely causes: Image doesn't exist, incorrect tag, ACR authentication failure
• Diagnose: Check image name and tag; verify ACR exists; check managed identity permissions
• Fix: Push the image; correct the tag; grant AcrPull role to managed identity

ACR authentication failure

• Symptom: denied: requested access to the resource is denied
• Likely causes: Managed identity doesn't have AcrPull role; registry is private
• Diagnose: Check managed identity permissions; verify registry is accessible
• Fix: Assign AcrPull role to the container app's managed identity

Revision becomes unhealthy

• Symptom: Revision status is Unhealthy
• Likely causes: Health probe failures; application errors; resource constraints
• Diagnose: Check liveness and readiness probe configuration; review container logs
• Fix: Fix probe endpoints; increase timeouts; allocate more resources

HTTP requests fail (404/403/5xx)

• Symptom: Clients receive errors
• Likely causes: Incorrect routing; authentication issues; application errors
• Diagnose: Check ingress configuration; review application logs; test locally
• Fix: Correct routing rules; fix authentication; fix application code

Container App cannot reach another service

• Symptom: Service discovery fails; connection timeouts
• Likely causes: Incorrect service name; networking issues; service not running
• Diagnose: Verify service name (container app name); check DNS resolution; verify service is running
• Fix: Use correct service name; ensure services are in the same environment

Managed identity authorization failure

• Symptom: Application cannot access Azure resources
• Likely causes: Missing RBAC role; incorrect identity configuration
• Diagnose: Verify RBAC role assignment; check managed identity is enabled
• Fix: Assign appropriate RBAC role; enable managed identity

Key Vault access failure

• Symptom: Secrets not retrieved from Key Vault
• Likely causes: Missing Key Vault Secrets User role; incorrect secret reference
• Diagnose: Check RBAC role; verify secret name and version; check Key Vault access policy
• Fix: Assign Key Vault Secrets User role; correct secret reference

Scaling does not behave as expected

• Symptom: Application doesn't scale or scales too much
• Likely causes: Incorrect scale rules; metric not triggering; limits too low/high
• Diagnose: Check scale rule configuration; monitor metrics; review scaling events
• Fix: Adjust scale rules; set appropriate limits

Scale-to-zero causes unexpected latency

• Symptom: First request takes a long time
• Likely causes: Cold start (image pull, container startup)
• Diagnose: Check image size; review startup time; verify scale-to-zero is enabled
• Fix: Set minReplicas to 1; optimize image size; use warm-up endpoints

Practical Learning Path

For developers

1. Understand containers – Docker basics, images, container runtimes
2. Create a Container Apps environment – Azure portal or Azure CLI
3. Deploy a simple containerized API – Container image, ingress, HTTPS
4. Configure ingress – Public vs. internal, HTTPS, routing
5. Deploy revisions – Single vs. multiple revision mode, traffic splitting
6. Configure autoscaling – HTTP scaling, scale-to-zero
7. Integrate ACR – Push images, managed identity authentication
8. Use managed identity – Access Azure resources without credentials
9. Connect to Azure services – SQL, Storage, Service Bus

For architects

10. Build a microservice architecture – Multiple services, internal communication
11. Implement CI/CD – GitHub Actions, Azure DevOps
12. Add monitoring – Metrics, logs, alerts, Application Insights
13. Configure private networking – VNet integration, private endpoints
14. Design production architectures – High availability, multi-region
15. Evaluate Container Apps vs. AKS and App Service – Decision framework

For AI engineers

16. Deploy an AI API – Inference API with Azure OpenAI
17. Build a RAG application – Container Apps, Azure AI Search, Azure OpenAI
18. Implement event-driven AI – Service Bus, Container Apps workers

Interview and Architecture Questions

What is Azure Container Apps?

Azure Container Apps is a serverless container platform that runs microservices and containerized applications on Azure. It provides built-in autoscaling, including scale to zero, and supports multiple programming languages and frameworks.

How is Container Apps different from AKS?

Container Apps abstracts the underlying Kubernetes infrastructure. You don't have direct access to the Kubernetes API. AKS provides full Kubernetes control. Container Apps is simpler to operate; AKS provides more flexibility.

How is Container Apps different from App Service?

Container Apps is container-first—you deploy container images. App Service is code-first—you deploy code (or containers) to a platform. Container Apps provides scale-to-zero; App Service does not. Container Apps is better for microservices; App Service is better for web applications.

What is a Container Apps Environment?

A Container Apps Environment is the secure boundary and networking container for all container apps and jobs. It provides a dedicated network boundary, shared logging, and internal service discovery.

What is a revision?

A revision is an immutable snapshot of your container app's configuration, including the container image, environment variables, secrets, and scaling rules. Each deployment creates a new revision.

How does autoscaling work?

Azure Container Apps uses KEDA (Kubernetes Event-driven Autoscaling) for scaling. Scaling is based on HTTP traffic, events (queues, event streams), CPU, memory, or custom metrics.

What is scale-to-zero?

Scale-to-zero means your container app can scale down to zero replicas when there's no traffic. You're not charged when scaled to zero.

How does Container Apps integrate with ACR?

Container Apps uses managed identity to authenticate to ACR. The container app's managed identity is granted AcrPull on the registry.

How does managed identity work?

Managed identity provides an automatically managed identity in Microsoft Entra ID. The container app uses this identity to authenticate to Azure resources without storing credentials.

How would you secure Container Apps?

Use managed identities instead of credentials, store secrets in Key Vault, apply least-privilege RBAC, use private networking, enable HTTPS, and scan container images.

How would you design a production microservices architecture?

Use multiple container apps (one per service), internal ingress for service-to-service communication, multiple revisions for deployment, traffic splitting for canary deployments, and separate scaling per service.

When would you choose Container Apps instead of AKS?

Choose Container Apps when you want managed container execution without managing Kubernetes, don't need direct Kubernetes API access, want simpler operations, and need autoscaling and revisions.

How would you troubleshoot a failed revision?

Check revision status (Unhealthy), review container logs, verify health probe configuration, check image pull status, and review revision events.

How would you design an event-driven worker?

Use a container app with event-driven scaling based on a queue (Service Bus, Storage Queue). Set scale rules to scale based on queue depth. Configure minReplicas=0 for scale-to-zero.

How would you deploy an AI API using Container Apps?

Use a container app with the AI model or API wrapper. Configure HTTP scaling based on request volume. Use managed identity to access Azure AI services. For GPU workloads, use Workload Profiles v2 with GPU support.

Key Takeaways

Azure Container Apps is a serverless container platform that runs microservices and containerized applications on Azure. It provides built-in autoscaling, including scale to zero, and supports multiple programming languages and frameworks.

It sits between fully managed platforms and Kubernetes – higher abstraction than AKS, lower than App Service. It's container-first with serverless characteristics.

Container Apps Environments are the secure boundary and networking container for all container apps and jobs. Workload Profiles v2 is the default environment type as of January 2026.

Revisions enable controlled deployments – immutable snapshots of your container app. Multiple revision mode supports canary, blue/green, and A/B testing.

Scaling is powered by KEDA – scale based on HTTP traffic, events (Service Bus, Event Hubs, Storage Queues), CPU, memory, or custom metrics.

Networking supports VNet integration with dedicated subnets, private endpoints, and internal ingress.

Managed identity is the recommended security model – eliminates credentials from code and configuration. Store secrets in Key Vault.

ACR integration uses managed identity – no credentials needed for image pulls.

Container Apps is ideal for microservices and event-driven workloads – built-in service discovery, independent scaling, and event-driven scaling.

AI workloads are supported – GPU profiles with NVIDIA T4 and A100, event-driven AI pipelines, and integration with Azure AI services.

Choose Container Apps when you want managed container execution without Kubernetes complexity. Choose AKS when you need Kubernetes APIs, custom resources, or advanced networking.

Production best practices include: use immutable image versions, set appropriate minReplicas and maxReplicas, use managed identities, configure health probes, monitor metrics and logs, and use revisions for controlled deployments.