Lab: size an ACI group and scale a Container App

Outcome

Create a deliberately small Azure Container Instance group, verify its requested allocation and endpoint, then configure a Container App with bounded HTTP scaling. You will break an image deployment safely and correct it. This lab teaches the distinction: ACI allocates resources to a container group; Container Apps scales replicas of a revision.

Before you begin

Use a training subscription. Container Apps environments and running replicas can incur charges; delete the resource group at the end. Ensure the containerapp extension is installed:

az extension add --name containerapp --upgrade
az group create --name rg-azlearn-containers --location <azure-region>

Do: allocate an ACI group

Create an internet-reachable training container with explicit CPU and memory. Pick a DNS label unique in the selected region.

az container create \
  --resource-group rg-azlearn-containers \
  --name aci-hello \
  --image mcr.microsoft.com/azuredocs/aci-helloworld \
  --cpu 1 --memory 1.5 --os-type Linux \
  --ports 80 --dns-name-label <unique-dns-label>
az container show --resource-group rg-azlearn-containers --name aci-hello \
  --query '{state:instanceView.state,cpu:containers[0].resources.requests.cpu,memory:containers[0].resources.requests.memoryInGb,fqdn:ipAddress.fqdn}' -o json

Open the FQDN and record the response. ACI sums container resource requests into the group allocation; leave a buffer because service infrastructure also consumes a small amount of that allocation. Do not infer Container Apps autoscaling from this fixed ACI request.

Do: bound Container Apps HTTP scaling

Create an environment and a Container App with ingress, scale-to-zero allowed, a maximum of three replicas, and an intentionally low HTTP concurrency threshold for a visible training exercise.

az containerapp env create --name cae-azlearn --resource-group rg-azlearn-containers --location <azure-region>
az containerapp create \
  --name ca-hello --resource-group rg-azlearn-containers --environment cae-azlearn \
  --image mcr.microsoft.com/azuredocs/containerapps-helloworld:latest \
  --ingress external --target-port 80 \
  --min-replicas 0 --max-replicas 3 \
  --scale-rule-name training-http --scale-rule-type http --scale-rule-http-concurrency 5
az containerapp show --name ca-hello --resource-group rg-azlearn-containers \
  --query '{fqdn:properties.configuration.ingress.fqdn,scale:properties.template.scale,revision:properties.latestRevisionName}' -o json

Generate a short burst only against this training endpoint, then inspect replica count and logs in the portal’s Revisions and replicas view. HTTP scale measurements are evaluated over short intervals; do not expect an instantaneous or permanent replica count. Record the configured minimum/maximum, rule threshold, observed replica count, and the time window.

Verify

You should now understand:

  • --cpu and --memory request ACI group capacity; they do not add replicas.
  • Container Apps scaling is constrained by min-replicas and max-replicas; the HTTP rule is a trigger, not a promise of a fixed count.
  • A minimum of zero allows scale-to-zero; choose a nonzero minimum only when cold-start/availability requirements justify its ongoing cost.

Break and fix

  1. Create a second, disposable ACI with --image doesnotexist.invalid/training:nope. Inspect instanceView.events to distinguish image-pull failure from a capacity or networking problem. Delete that failed group after recording the event.
  2. On a training branch/configuration, set Container App max-replicas to 1, generate the same load, and explain why the app cannot exceed the configured ceiling. Restore 3.
  3. If you remove ingress while keeping a zero minimum and no custom event rule, the app has no HTTP path to wake it. Do not apply that to a live workload; explain the failure from the scale configuration, then retain ingress or set an appropriate trigger/minimum.

Scenario practice

  1. Configure: A single short-lived batch command needs 2 CPU and 4 GB but no autoscaling. Choose ACI or Container Apps and justify the allocation/trigger model.
  2. Diagnose: A Container App remains at one replica under traffic. Which evidence do you inspect first: current revision, ingress target port, HTTP rule, ceiling, or request pattern?
  3. Distinguish: A workload must avoid cold starts versus a workload must minimize idle cost. Contrast min-replicas: 1 and min-replicas: 0 without treating either as universally correct.

Clean up

az group delete --name rg-azlearn-containers --yes --no-wait

Sources and re-audit

Re-audit when CLI flags, scale-rule defaults, quotas, or billing conditions change.

Azure Container Instances · Azure Container Apps · Workload · All labs