Skip to content

Min Replicas Cost Surprise Lab

Lab Metadata

Field Value
Difficulty Beginner
Duration 20-30 min
Tier Inline guide only
Category Cost and Quota

1. Question

Does min replicas cost surprise reproduce when the documented trigger condition is present, and does applying the documented resolution fully restore service?

2. Setup

3. Hypothesis

4. Prediction

If the trigger condition is present, the failure symptom will appear. Correcting the configuration will resolve the failure within one revision deployment cycle.

5. Experiment

6. Execution

Run the commands in the Experiment section sequentially in a shell with the Azure CLI authenticated. Capture all terminal output for the Observation section.

7. Observation

8. Measurement

Evidence What confirms the hypothesis
az containerapp show --query "properties.template.scale" [Observed] The app clearly switches between minReplicas=1 and minReplicas=0.
az monitor metrics list --metric Replicas [Measured] The average replica count remains above zero in the first phase and drops toward zero in the second phase.
az containerapp revision list [Correlated] The active revision no longer needs to hold a warm replica after the minReplicas=0 phase.

9. Analysis

The observations confirm that the failure is isolated to the trigger condition identified in the hypothesis. Metric and log data collected during the experiment support the causal chain described. No confounding factors were introduced between the failure run and the corrected run.

10. Conclusion

The hypothesis is confirmed. The trigger condition directly causes the observed failure, and removing or correcting it restores expected behaviour. The root cause is not platform-level instability but a misconfiguration or missing resource.

11. Falsification

To falsify: revert only the corrective change and confirm the failure re-appears. Then re-apply the fix and confirm recovery. This rules out coincidental platform recovery and proves the fix is the controlling variable.

12. Evidence

Evidence What confirms the hypothesis
az containerapp show --query "properties.template.scale" [Observed] The app clearly switches between minReplicas=1 and minReplicas=0.
az monitor metrics list --metric Replicas [Measured] The average replica count remains above zero in the first phase and drops toward zero in the second phase.
az containerapp revision list [Correlated] The active revision no longer needs to hold a warm replica after the minReplicas=0 phase.

Observed Evidence (Live Azure Test — 2026-04-29)

[Observed] az containerapp update --min-replicas 5 succeeded; subsequent az containerapp show --query "properties.template.scale.minReplicas" returned 5.

[Observed] az containerapp update --min-replicas 0 succeeded; subsequent query returned 0.

[Correlated] az containerapp replica list after idle period with minReplicas=5 showed 5 running replicas; same command after minReplicas=0 and idle period showed 0 replicas.

[Inferred] The cost difference between minReplicas=5 and minReplicas=0 on the Consumption plan is purely the idle compute for 5 permanently-warm replicas — no traffic required to accumulate charges.

Environment: koreacentral, Consumption plan.

13. Solution

Apply the corrective configuration change described in the Runbook section. Validate that the container app reaches a healthy running state and that the original symptom no longer appears in logs or metrics.

14. Prevention

Add the configuration requirement to your infrastructure-as-code templates and pre-deployment checklists. Enable Azure Policy or Advisor recommendations to detect the misconfiguration before it reaches production.

15. Takeaway

Min Replicas Cost Surprise is a reproducible, configuration-driven failure. The fix is deterministic and low-risk. Operationally, the key lesson is to validate the affected configuration dimension during initial setup rather than at incident time.

16. Support Takeaway

When escalating or handing off: confirm the trigger condition is present before applying the fix. Collect logs from the failing revision before deletion. Document the before-and-after configuration in the incident record.

Expected Evidence

Observed Evidence (Live Azure Test — 2026-05-01)

Environment: rg-aca-lab-test6 / cae-lab6, koreacentral, Consumption plan. App: ca-min-replicas (0.5 vCPU / 1 Gi, minReplicas=5, maxReplicas=10).

[Observed] With zero traffic, az containerapp replica list returned 5 replicas running — all idle, each consuming 0.5 vCPU / 1 Gi.

[Measured] Idle cost at minReplicas=5: 5 × 0.5 vCPU × $0.000024/vCPU-s × 2,592,000 s/month ≈ $155.52/month (vCPU alone, pre-free-tier).

[Observed] After fix: az containerapp show --query "properties.template.scale.minReplicas" returned 1 — setting applied immediately.

[Observed] Post-fix scale verified: az containerapp show --query "properties.template.scale" returned {"minReplicas": 1, "maxReplicas": 10}.

[Inferred] Idle replicas run continuously regardless of traffic. Consumption plan charges per vCPU-second and memory-GiB-second for active replicas. minReplicas=5 with no traffic wastes 4 replicas worth of compute 24/7. Setting minReplicas=0 eliminates idle cost entirely but introduces cold start latency.

Fix: Set --min-replicas 1 for user-facing apps to balance cost and cold start. Set --min-replicas 0 only for background jobs where latency is acceptable.

Clean Up

Choose the final state that matches the intended production behavior.

az containerapp show \
    --name "$APP_NAME" \
    --resource-group "$RG" \
    --query "properties.template.scale" \
    --output json
Command Why it is used
az containerapp show --query "properties.template.scale" Confirms the app was left in the desired post-lab state.

See Also

Sources