Using Azure Container Apps

What Are Azure Container Apps?#

Azure Container Apps is a serverless container hosting platform built on top of an abstracted Kubernetes cluster. It sits between ACI and AKS in the Azure container services spectrum:

ACI (simple, no orchestration)
    ↓
Container Apps (serverless K8s — managed for you)
    ↓
AKS (full Kubernetes control)

You deploy container images, define scaling rules, and Container Apps manages the Kubernetes cluster, ingress, and infrastructure for you.

Container App Environment#

The Container App Environment is an isolated boundary for your Container Apps — similar to an App Service Environment for App Services.

What the environment provides:#

• Shared virtual network (Azure-managed or custom VNet)
• Shared logging and monitoring (Log Analytics workspace)
• Shared Dapr configuration (for microservices)
• Isolation boundary between environments

All apps within the same environment share networking and configuration. Apps in different environments are fully isolated.

You can have multiple Container App Environments, each with its own configuration.

Replicas#

A replica is a single running instance of a Container App. You can run multiple replicas to handle load:

Container App: my-api
├── Replica 1 (running)
├── Replica 2 (running)
└── Replica 3 (running)

Replicas for the same app share the same container image and configuration.

Scale to Zero (Key Difference from App Service)#

Container Apps can scale to zero replicas — no running instances, no cost.

When there is no traffic, Container Apps shuts down all replicas. When a request arrives, a new replica starts. This makes it a true serverless solution.

App Service cannot scale to zero — there is always at least one instance running.

Scaling Rules#

Configure minimum and maximum replica counts, and define scaling triggers:

Example: Min 0, Max 10 replicas with an HTTP rule at 1,000 concurrent requests.

Revisions#

A revision is a versioned snapshot of a Container App deployment. Every time you update the app (image, env vars, scaling), a new revision is created.

Revision modes:#

• Single revision — one active revision at a time (default)
• Multiple revisions — run multiple revisions simultaneously with traffic splitting

Traffic splitting between revisions:#

Revision v1: 90% traffic
Revision v2: 10% traffic (canary test)

This is similar to deployment slots in App Service, but revision-based.

Ingress#

Ingress controls how your Container App is accessed:

Ingress settings:#

• HTTP or TCP transport type
• Target port — the port your container listens on
• IP restrictions — allow or deny specific IPs (ACL)
• Allow or deny insecure (HTTP) connections

When ingress is enabled, the app gets an application URL for external access.

VNet Integration#

By default, the Container App Environment uses an Azure-managed (hidden) VNet. You can bring your own VNet for:

• Private communication with other Azure resources
• Access to on-premises networks via ExpressRoute or VPN gateway
• Integration with peered VNets

Container Apps vs. App Service#

Creating a Container App (Portal Steps)#

1. Go to Azure Portal → Create → Container App
2. Provide a name (e.g. conapp-prod-01)
3. Create or select a Container App Environment
4. On the Container tab:
   • Select image source (Azure Container Registry or quickstart)
   • Choose registry, image, and tag
   • Set workload profile (CPU/memory allocation)
   • Add environment variables if needed
5. Skip Bindings (unless using Dapr)
6. On Ingress tab: configure or leave disabled
7. Review + Create

After deployment — enable ingress:#

1. Go to resource → Ingress
2. Enable, set scope (anywhere / environment / VNet)
3. Set protocol (HTTP/TCP) and target port
4. Configure IP restrictions if needed
5. Click Save — triggers a new revision

Monitoring#

• Go to Revisions and replicas to see active/inactive revisions
• See replica count per revision
• Switch traffic between revisions without redeployment
• Inactive revisions can be reactivated for rollback

Key Exam Takeaways#

• Container Apps = serverless platform on abstracted Kubernetes
• Container App Environment = isolation boundary (shared VNet, logs, Dapr)
• Scale to zero = no traffic → no cost (unlike App Service)
• Replicas = running instances of an app
• Revisions = versioned deployments (like deployment slots)
• Traffic splitting = canary deployments between revisions
• Ingress = how traffic reaches the Container App
• Bring your own VNet to the environment for private connectivity
• Best for microservices; App Service is better for monolithic web apps

Quick Revision Cheat Sheet#

Container Apps = serverless K8s (abstracted)
Environment = isolation boundary (VNet, logs, Dapr)
Replicas = running instances
Scale to zero = true serverless
Revisions = versioned deployments
Traffic split between revisions
Ingress: public / environment-only / VNet-only / disabled
Custom VNet for private access
Best for: microservices
App Service = PaaS + scale units = monolithic apps

Reference Documentation#

• Azure Container Apps overview
• Container App Environments
• Scaling rules in Container Apps
• Ingress in Container Apps
• Revisions and traffic splitting
• Networking in Container Apps
• Container Apps vs AKS vs ACI

Hands-on: Create a Container App with HTTP Ingress#

Goal: Deploy a serverless container app and practice revisions and scale settings.

1. Create a Container Apps environment.
2. Create a container app named az104-containerapp-demo.
3. Use image mcr.microsoft.com/azuredocs/containerapps-helloworld:latest.
4. Enable external ingress.
5. Set target port 80.
6. Create the app.
7. Open the application URL and confirm it loads.
8. Review logs in the associated Log Analytics workspace.
9. Set minimum replicas to 0 and maximum replicas to 3.
10. Create a new revision by changing the image tag or an environment variable.
11. Split traffic between two revisions.
12. Route 100% traffic to the new revision after validation.

Hands-on: Environment-Only Ingress#

1. Create a second container app in the same environment.
2. Set ingress to internal/environment-only.
3. Confirm it does not receive a public internet endpoint.
4. Call it from another app in the same environment.