4.1.6.5. Provision and Scale Azure Container Apps

4.1.6.5. Provision and Scale Azure Container Apps

💡 First Principle: Azure Container Instances rents you a container; Azure Container Apps runs an application for you. The platform watches demand and adds or removes copies of your container, called replicas, down to zero when nothing is happening. Sizing a container app is therefore two separate decisions: how big each replica is, which you set, and how many replicas run, which scale rules decide.

Scenario: An order-processing API must be reachable from the internet and absorb lunchtime traffic spikes, and a companion worker drains an Azure Storage queue. Both should cost nothing overnight when there is no work.

What It Is: Azure Container Apps is a serverless platform for containerized applications and microservices. It manages the Kubernetes orchestration for you and uses KEDA (Kubernetes Event-driven Autoscaling) to scale.

The Container Apps Environment

Every container app lives in a Container Apps environment, a secure boundary around one or more apps and jobs. Apps in the same environment share the same virtual network and write logs to the same destination, by default a common Log Analytics workspace. There are two environment types: workload profiles (the default), which supports both the Consumption and Dedicated plans, and Consumption only (legacy). Put apps that must never share compute, such as test and production, in separate environments.

Provisioning a Container App

In the portal, search for Container Apps and select Create > Container App. On the Basics tab you choose the subscription, resource group, container app name, a deployment source of Container image, the region, and the Container Apps environment (a new one is created by default). The next step selects the container image, and Review + create deploys it. The Microsoft.App resource provider must be registered in the subscription.

The same app from the Azure CLI:

az containerapp create \
  --name orders-api \
  --resource-group rg-orders \
  --environment cae-orders \
  --image contosoacr.azurecr.io/orders-api:1.4.2 \
  --ingress external \
  --target-port 8080 \
  --cpu 0.5 --memory 1.0Gi \
  --min-replicas 0 --max-replicas 20 \
  --scale-rule-name http-burst \
  --scale-rule-type http \
  --scale-rule-http-concurrency 50

Ingress exposes the app without a load balancer or public IP resource of your own. External ingress (the portal's Accepting traffic from anywhere) publishes the app at the environment's inbound IP address. Internal ingress (Limited to Container Apps Environment) makes it reachable only from other apps in the same environment, the usual choice for a backend service.

Sizing a Replica (Vertical)

On the Consumption plan, the total CPU and memory of all containers in an app must match one of the published combinations: from 0.25 vCPU with 0.5 GiB up to 4.0 vCPU with 8.0 GiB, in steps of 0.25 vCPU, with memory always twice the vCPU count. Apps in a Consumption only environment are capped at 2 vCPU and 4 GiB. Container Apps doesn't scale vertically on its own; to resize, you change the container's CPU and memory, and because that edits the app's template it creates a new revision.

Scaling Replicas (Horizontal)

Scaling combines limits and rules:

• No rule defined? The default is an HTTP rule scaling between 0 and 10 replicas.
• Several rules? Scaling starts as soon as any one rule's condition is met.
• Scale to zero: No usage charges accrue at zero replicas. After the last event, KEDA waits a 300-second cooldown before scaling to zero. Set the minimum to 1 or more when an instance must always be running.
• Revisions: Adding or editing a scale rule creates a new revision of the app.
• Custom rule authentication: Scale rules can authenticate to the event source with a secret or, for Azure services such as Storage queues, Service Bus, and Event Hubs, with a managed identity.

Visual: What Drives Replica Count

⚠️ Common Pitfall: Deploying a background worker with ingress disabled and no scale rule or minimum replica count. The default HTTP rule never fires, so the app scales to zero and has no way of starting again. Add a custom rule for the worker's event source, or set the minimum replicas to 1 or more.

Key Trade-Offs:

• Minimum replicas 0 vs. 1 or more: Zero costs nothing while idle, but a replica has to start before work resumes. A minimum of 1 or more keeps an instance ready but runs, and can bill, around the clock.
• Container Apps vs. Azure Container Instances: Container Instances is the simplest way to run one container group on demand, but changing its CPU or memory means recreating it. Container Apps adds managed ingress, revisions, and rule-driven scaling for applications whose load changes.

Reflection Question: For a queue-processing worker that must cost nothing while idle, why does the combination of disabled ingress and the default scale rule leave the app stuck at zero replicas, and which scale rule configuration fixes it without paying for an always-on replica?

Theory builds understanding, but hands-on practice builds confidence. Complete these Microsoft Learn labs to reinforce the concepts from this phase with real Azure environments:

Lab 1: Create a Windows Virtual Machine in Azure Focus: Deploy VMs, configure networking, manage disks

Lab 2: Manage Virtual Machines with the Azure CLI Focus: CLI-based VM management, resize, start/stop

Lab 3: Deploy a Website with Azure App Service Focus: Create App Service plans, deploy apps, configure slots

Lab 4: Introduction to Azure Kubernetes Service Focus: Deploy AKS clusters and manage containerized workloads

⚠️ Tip: These labs use free Azure sandbox environments — no personal subscription or credit card required. Complete them after reading the study material but before attempting the practice questions for maximum retention.