Replica Node-Spread on Consumption vs Dedicated D8 Lab¶

Test the operator claim that the Consumption profile distributes replicas across many underlying nodes while a single Dedicated D8 workload profile may concentrate every replica on one node. This lab uses kernel-context proxies (boot_id, uptime_seconds, boot_time_estimate_ms) because Azure Container Apps does not expose the underlying Microsoft.Compute node id. The highest claim allowed for node placement is [Strongly Suggested].

Lab Metadata¶

flowchart TD
    A[deploy.sh<br/>RG + ACR + diag image + Bicep env + 2 apps] --> B[health-check.sh<br/>env, both profiles, /diag responds 200]
    B --> C[falsify.sh<br/>H3 gate — proxy validity]
    C -->|PASS| D[trigger.sh]
    C -->|FAIL| Z[STOP — proxy invalid, do not publish H1/H2]
    D --> E[Consumption profile<br/>app-consumption<br/>scale 1 → 3 → 10 → 30]
    D --> F[Dedicated D8 profile<br/>app-dedicated-d8<br/>scale 1 → 3 → 10]
    E --> G[At each step:<br/>scale.sh + sample.sh /diag]
    F --> G
    G --> H[Top step ×3 repeats]
    H --> I[evidence/*.jsonl<br/>boot_id, uptime, boot_time_estimate per sample]
    I --> J[analyze.py<br/>cluster by boot_id and boot_time_estimate]
    J --> K[evidence/analysis-summary.md]
    K --> L[H1 verdict — Consumption multi-cluster?<br/>H2 verdict — Dedicated D8 single-cluster?]

1. Question¶

Does an Azure Container Apps environment, configured with one Consumption profile and one Dedicated D8 profile, produce a multi-cluster kernel-context distribution for replicas running on the Consumption profile and a single-cluster kernel-context distribution for replicas running on the Dedicated D8 profile, when both apps are scaled to their per-profile target replica count using identical resource requests and the same container image?

The question is framed as three pre-registered hypotheses (Section 3) so the lab is falsifiable from observation alone, not from interpretation. The evidence ceiling is capped at [Strongly Suggested] because Container Apps does not expose the underlying Microsoft.Compute node id; the lab uses kernel-context proxies that distinguish microVMs but cannot directly identify physical hosts.

2. Setup¶

Region selection¶

Pick a region that supports both Container Apps workload profiles and the Dedicated D8 SKU. Verified options: koreacentral, eastus, westeurope. Cross-check the current matrix in Workload profiles in Azure Container Apps before deploying.

Required environment variables¶

export RG="rg-aca-rns-lab"
export LOCATION="koreacentral"
export SUBSCRIPTION_ID="<subscription-id>"

az account set --subscription "$SUBSCRIPTION_ID"
az extension add --name containerapp --upgrade

Deploy the lab¶

cd labs/replica-node-spread
./deploy.sh
./health-check.sh

Build the diag image¶

deploy.sh builds the image automatically. To rebuild without redeploying the environment:

ACR_NAME="$(az acr list --resource-group "$RG" --query '[0].name' --output tsv)"
az acr build --registry "$ACR_NAME" --image "rns-lab/diag:latest" ./diag

3. Hypothesis¶

Three pre-registered hypotheses. H3 is a methodology gate: H1 and H2 are scientifically meaningless if the proxy is invalid, so the lab refuses to publish H1 / H2 verdicts until H3 has independently passed.

H1 — Consumption profile produces multi-cluster kernel-context distribution¶

On a Container Apps environment's Consumption profile, scaling a single app to N replicas (N >= 10) produces samples whose boot_id and boot_time_estimate_ms cluster into more than one group, consistent with placement across multiple underlying kernel contexts (and therefore, by inference, multiple underlying physical or virtual hosts).

H2 — Dedicated D8 profile produces single-cluster kernel-context distribution¶

On the same environment's Dedicated D8 profile (one D8 node, 8 vCPU / 32 GiB), scaling a single app to N replicas (N <= node capacity) produces samples whose boot_id and boot_time_estimate_ms cluster into exactly one group, consistent with placement on a single underlying kernel context (and therefore, by inference, a single underlying host).

H3 — Kernel-context proxy is valid¶

The kernel-context signal triple (boot_id, uptime_seconds, boot_time_estimate_ms) is a deterministic per-replica reading: within one replica, boot_id is stable across samples, uptime_seconds increases monotonically with wall-clock time, and boot_id is a non-trivial UUID rather than an empty or zero-sentinel value.

Pre-registered analysis plan¶

To prevent post-hoc reframing once data is in hand, the lab commits to these decisions before the first H1 / H2 measurement:

1. Primary metric for H1: boot_time_clusters >= 2 at Consumption top scale (N=30), with all three top-scale repeats agreeing on a cluster count >= 2. This is the H1 confirmation signal.
2. Primary metric for H2: boot_time_clusters == 1 at Dedicated D8 top scale (N=10), with all three top-scale repeats agreeing on a cluster count of exactly 1. This is the H2 confirmation signal.
3. Primary metric for H3 (gating): all four sub-checks (replica-consistent, boot-consistent, uptime-monotonic, boot-nontrivial) PASS on a single pinned replica with minReplicas=maxReplicas=1 and 5 samples 10s apart. Any sub-check failure aborts the lab; trigger.sh will not run.
4. Boot-time cluster threshold: two boot_time_estimate_ms values are inferred to be on distinct kernel contexts when their gap exceeds 5,000 ms. This is wide enough to absorb cross-host clock skew between samples in the same run and tight enough that two replicas on the same host (which share boot_time exactly) never appear as distinct.
5. Stopping rule: complete the full sample sweep for both profiles. No early stop on partial data, regardless of how the early steps trend. The top-scale ×3 repeats are required to compute the concurrence rollup.
6. What this lab does NOT measure:
   1. Per-replica Microsoft.Compute virtual-machine identity. The Azure Container Apps management plane does not expose this on either profile. Any claim about "different physical nodes" remains [Strongly Suggested], never [Observed].
   2. Dedicated D8 placement at scale beyond a single node. The lab uses one D8 profile with one node; multi-node Dedicated profiles (D8 × 3, for example) may exhibit different behavior and are out of scope.
   3. Long-term stability of placement. Each measurement is point-in-time; a re-run minutes later may produce a different cluster count if the scheduler shuffles replicas.

4. Prediction¶

If the platform delivers the strict "Consumption distributes across many nodes, Dedicated D8 concentrates on one node" interpretation many operators assume, then:

• H3 PASSes — the proxy is deterministic per replica.
• H1 PASSes — Consumption at N=30 shows boot_time_clusters >> 1 (likely close to N or in the same order of magnitude), and all three top-scale repeats agree on a count >= 2.
• H2 PASSes — Dedicated D8 at N=10 shows boot_time_clusters == 1 across all three top-scale repeats.

If the platform's behavior differs:

• H3 FAILing aborts the lab immediately — no H1 / H2 verdict is published.
• H1 partially confirming (some repeats >= 2, others == 1) is reported as inconsistent and the verdict is downgraded from [Strongly Suggested] to [Inferred] at most.
• H2 FAILing (cluster count >= 2 at Dedicated D8 top scale) is the most operationally significant outcome: it would mean that even a single Dedicated D8 profile distributes replicas across more than one kernel context, contradicting the operator mental model that "one D8 profile == one shared host."

5. Experiment¶

Phase 1 — H3 falsification gate (~3 minutes)¶

./falsify.sh

H3 must PASS before Phase 2. The lab's trigger.sh invokes ./falsify.sh automatically (unless SKIP_FALSIFY=1 is set, which is reserved for debugging only — H1 / H2 results are not publishable when H3 was skipped).

Phase 2 — Consumption scale sweep (~25 minutes)¶

./trigger.sh

The orchestrator walks app-consumption through scale targets 1 → 3 → 10 → 30, with three repeats at N=30. At each step it:

1. Calls ./scale.sh app-consumption <N> to set minReplicas=maxReplicas=N and waits for the running count to stabilize.
2. Pauses 20 s to let any in-flight scale activity settle.
3. Calls ./sample.sh to issue K HTTP GETs against https://<fqdn>/diag and append one JSON line per response to evidence/consumption-scale-<N>-run-<R>.jsonl. Sample sizes per step: N=1 → 6, N=3 → 30, N=10 → 80, N=30 → 240 (8× oversample).

Phase 3 — Dedicated D8 scale sweep (~10 minutes)¶

trigger.sh then walks app-dedicated-d8 through scale targets 1 → 3 → 10, with three repeats at N=10. Same per-step protocol as Phase 2. Sample sizes: N=1 → 6, N=3 → 30, N=10 → 80.

Phase 4 — Scale back to 1¶

trigger.sh automatically issues ./scale.sh app-consumption 1 and ./scale.sh app-dedicated-d8 1 at the end of Phase 3 to stop charging unused replicas while you run analysis. This is not a teardown — the apps remain provisioned for further runs.

6. Execution¶

Run Phase 1 as a hard gate before any sampling. trigger.sh enforces this by invoking ./falsify.sh first and aborting if H3 does not PASS. Once H3 PASSes, the master orchestrator runs Phase 2 then Phase 3 sequentially within a single invocation:

source /tmp/rns-lab.env   # exports SUBSCRIPTION_ID, RG, LOCATION, BASE_NAME, EXPIRY_HOURS
./trigger.sh

Capture stdout to a log file if you want a transcript of the run:

./trigger.sh 2>&1 | tee evidence/trigger-run-$(date -u +%Y%m%d-%H%M%S).log

Total wall-clock budget: ~40 minutes for the H3 gate + both scale sweeps + scale-back. Each top-scale repeat (N=30 for Consumption, N=10 for Dedicated) adds ~3 minutes of sampling. The slowest single step is the first Consumption scale-up to N=30 (~80 s of scale-up followed by ~3 minutes of sampling).

7. Observation¶

After trigger.sh completes, run the analysis:

python3 ./analyze.py
cat evidence/analysis-summary.md

Record the exact numbers in the Observed Evidence subsection of Section 12.

8. Measurement¶

The lab's primary metrics, derived directly from the pre-registered analysis plan:

• [Measured] H3 verdict: replica-consistent, boot-consistent, uptime-monotonic, boot-nontrivial (per falsify.sh).
• [Measured] unique_boot_ids per (profile, scale, run).
• [Measured] boot_time_clusters per (profile, scale, run), with cluster gap threshold = 5,000 ms.
• [Measured] Top-scale concurrence: whether all three repeats at N=30 (Consumption) and N=10 (Dedicated D8) agree on the same cluster count.
• [Measured] hit_ratio = unique_replicas / scale_target — sanity check for sampling coverage. A hit_ratio < 0.7 weakens any verdict at that scale because under-sampling could mask a multi-host distribution.
• [Strongly Suggested] H1 verdict tying multi-cluster boot_time to multi-node placement on Consumption.
• [Strongly Suggested] H2 verdict tying single-cluster boot_time to single-node placement on Dedicated D8.

The [Strongly Suggested] ceiling is permanent for both H1 and H2 under the current Container Apps management-plane surface, because per-replica Microsoft.Compute identity is not exposed.

9. Analysis¶

Combine the measurements with the pre-registered analysis plan:

• H3 evaluation: PASS / FAIL is binary per falsify.sh. A FAIL aborts the lab; no H1 / H2 analysis is published.
• H1 evaluation: If boot_time_clusters >= 2 at Consumption N=30 across all three repeats, H1 is [Strongly Suggested] confirmed. If only some repeats meet the threshold, H1 is [Inferred] confirmed — the platform is multi-cluster on Consumption, but with measurable variance across runs.
• H2 evaluation: If boot_time_clusters == 1 at Dedicated D8 N=10 across all three repeats, H2 is [Strongly Suggested] confirmed. If any repeat shows >= 2, H2 is falsified for this configuration — Dedicated D8 distributed replicas across more than one kernel context, contradicting the operator mental model.
• Cross-profile comparison: Compute the ratio consumption_clusters_at_top / dedicated_clusters_at_top. A ratio >> 1 (e.g. 27 / 1) is [Strongly Suggested] evidence that profile choice is a placement choice, not a billing-only choice.
• Hit-ratio sanity: If any top-scale run has hit_ratio < 0.7, downgrade that run's verdict by one evidence level (e.g. [Strongly Suggested] → [Inferred]). Under-sampling at top scale is the most common confounder.

10. Conclusion¶

State the conclusion in three buckets, one per evidence level, citing only the pre-registered measurements:

• Confirmed (or falsified) hypotheses: H1 verdict with Consumption top-scale cluster counts. H2 verdict with Dedicated D8 top-scale cluster counts. H3 verdict (must be PASS).
• Confirmed secondary effects: Cross-profile cluster-count ratio at top scale. Hit-ratio sanity per run.
• Open / not measurable: Per-replica Microsoft.Compute virtual-machine id (always [Not Proven] for this lab regardless of result). Multi-node Dedicated profile behavior (out of scope).

Conclusions are point-in-time. A re-run minutes later may produce different cluster counts on Consumption if the scheduler shuffles replicas across hosts. The lab's verdict applies to the specific reproduction window recorded in Section 12's Observed Evidence subsection.

11. Falsification¶

The lab is built to be falsifiable in three complementary directions:

1. H3 gate: falsify.sh runs before any H1 / H2 sampling. If the kernel-context proxy is non-deterministic (boot_id varies within a single replica, or uptime is non-monotonic, or boot_id is the zero-sentinel), the lab aborts with a clear error — H1 / H2 results would be scientifically meaningless. This is the most aggressive falsification path because it kills the entire experiment if the methodology is unsound.
2. Top-scale ×3 repeats: Each top-scale step runs three times. The analysis script computes a concurrence flag — all three repeats must agree on the same boot_time_clusters count for a [Strongly Suggested] verdict. A single discrepant repeat downgrades the verdict to [Inferred].
3. Cross-profile expectation flip: The lab is designed so that H1 and H2 predict opposite outcomes on the two profiles using the same measurement code. A confound (e.g. broken sampling, scheduler shuffling mid-sample) would have to produce the expected pattern on both profiles to defeat falsification. Producing multi-cluster on Consumption and single-cluster on Dedicated D8 from a confounded measurement is implausible.

11b. Phase B Falsification Gates¶

The 2026-06-24 evidence-pack overlay adds a Phase B verifier under labs/replica-node-spread/. Unlike the live-Azure Phase A workflow (falsify.sh + trigger.sh + analyze.py), the rewritten labs/replica-node-spread/verify.sh is a pure file processor: it reads only the committed canonical cohort under labs/replica-node-spread/evidence/ (15 canonical files — 2 summary + 2 H3 anchor + 6 Consumption scale + 5 Dedicated D8 scale, anchored on h3-20260614-143432) and emits four derived gate JSONs. Each sub-gate evaluates a Strong path AND a Fallback path; the sub-gate passes if either is true. The four gates encode the Oracle Lab 19 strategy consult's four anti-pattern blocks (deterministic-spread claims, cross-profile pooling, scale mixing, summary-first reasoning) plus the "raw JSONL wins over summary on conflict" rule. All 16 sub-gates pass on the 2026-06-14 cohort.

The four gates together block the four Oracle-directive anti-patterns: deterministic-spread claims are blocked by Gate 12 sub-gate (a)'s claim-string refusal of the word Observed for placement; cross-profile pooling is blocked by Gate 12 sub-gate (b)'s requirement that Consumption and Dedicated D8 are tabulated as separate profiles; scale mixing is blocked by Gate 11 sub-gate (a)'s one-to-one {profile, scale, run} cell decomposition; summary-first reasoning is blocked by Gate 11 sub-gate (c) and Gate 12 sub-gate (e), both of which recompute cluster counts directly from raw JSONL and require bit-exact reconciliation against analysis-summary.json — if the summary is wrong, the recompute is authoritative.

Gate 12 sub-gate (d) is the counterexample-surfacing gate: it requires both consumption_30_co_location_detected (3 Consumption-30 runs with 27 < 30 boot_time clusters) AND dedicated_3_co_location_detected (Dedicated-D8 scale-3 with 1 < 3 boot_time clusters) to be true. These counterexamples are not anomalies to suppress; they are direct empirical evidence that the lab's headline claim is the narrower "observed node-spread behavior under this test matrix" rather than the over-strong "Consumption deterministically spreads one replica per node" (which the 27/30 partial co-location falsifies) or "Dedicated D8 only co-locates at top scale" (which the Dedicated-3 full co-location falsifies). The point of surfacing them is that they fit the operator-narrative — Consumption distributes across many kernel contexts when capacity permits but may co-locate when convenient; Dedicated D8 co-locates all replicas on its single node by design — and the gates require them present rather than omitted.

Together with Gate 10 (cohort integrity) and Gate 13 (packaging), the four-gate suite proves: (1) the evidence pack is internally consistent and uncontaminated; (2) the test matrix is one-to-one without cross-cell contamination; (3) the headline claim stays within the [Strongly Suggested] evidence ceiling and surfaces all known counterexamples; and (4) a reader can re-verify every claim from the committed files alone without re-deploying to Azure. The gates do NOT prove cross-replica node distinctness directly — that requires the kernel-context proxy (boot_id, boot_time_estimate_ms), and the proxy is itself capped at [Strongly Suggested] because Container Apps does not expose per-replica Microsoft.Compute virtual-machine identity on either profile. The full per-file provenance and honest-disclosure notes are in labs/replica-node-spread/evidence/README.md.

12. Evidence¶

Required CLI evidence (always collected)¶

Observed Evidence (Live Azure Reproduction)¶

Reproduction window: 2026-06-14 (UTC). H3 gate: h3-20260614-143432 (PASS). Consumption scale sweep: 2026-06-14T14:38–14:46Z. Dedicated D8 scale sweep: 2026-06-14T14:46–15:00Z. All scale steps recorded their start and stable-count times in /tmp/trigger.log; raw timestamps are in each evidence/*.jsonl file's client_sample_at field.

Region / RG: koreacentral / rg-aca-rns-lab-202606141423. Subscription: <subscription-id>. Environment: cae-rnslab-khefip. Both apps share image rnslabacr<hex>.azurecr.io/rns-lab/diag:latest, both use 0.25 vCPU / 0.5 GiB resource requests, both expose /diag over HTTPS external ingress.

Subject apps: app-consumption (workload profile: Consumption, max replicas 30, FQDN app-consumption.purplebush-69d6d99a.koreacentral.azurecontainerapps.io), app-dedicated-d8 (workload profile: Dedicated D8, max replicas 10, FQDN app-dedicated-d8.purplebush-69d6d99a.koreacentral.azurecontainerapps.io).

Portal captures (2026-06-14 reproduction)¶

The five captures specified during this reproduction are committed under docs/assets/troubleshooting/replica-node-spread/.

[Observed] C1 — Resource group Overview. Both subject apps, the Container Apps environment, the ACR, the Log Analytics workspace, and the user-assigned managed identity are all listed under the single resource group rg-aca-rns-lab-202606141423. This eliminates the "deployment split across multiple resource groups" confounder.

[Observed] C2 — Container Apps environment Workload profiles tab. Both Consumption and Dedicated D8 profiles are provisioned on the same environment cae-rnslab-khefip. Both subject apps are bound to this one environment; the only differentiator between them is the per-app workloadProfileName value set in infra/main.bicep.

[Observed] C3 — app-consumption Active revisions tab at N=30. The single active revision row shows the running replica count = 30 under the Consumption profile.

[Observed] C4 — app-dedicated-d8 Active revisions tab at N=10. The single active revision row shows the running replica count = 10 under the Dedicated D8 profile. (D8's practical replica ceiling within the 600 s scale window is ~10; see the D8 capacity ceiling bullet above.)

[Observed] C5 — app-consumption Overview Essentials. The Essentials section shows Environment type: Workload profiles for the parent environment, which is the prerequisite for the per-app workloadProfileName: Consumption binding declared in infra/main.bicep. The app-level binding itself is captured by the Bicep template (committed) plus the az containerapp show --query "properties.workloadProfileName" CLI evidence, not by this blade.

Caveat 1 on H1. A multi-cluster verdict on Consumption is consistent with multi-node placement; it is not a proof that Container Apps' scheduler always distributes replicas across many nodes. The scheduler may co-locate replicas on the same node when load permits (for example, at very low N where one host has enough headroom). The H1 confirmation signal at N=30 does not guarantee the same pattern at N=3.

Caveat 2 on H2. A single-cluster verdict on Dedicated D8 at N=10 is consistent with single-node placement on a single-node D8 profile; it is not a proof that Container Apps cannot place D8 replicas on multiple nodes in any configuration. A multi-node Dedicated profile (e.g. D8 × 3) would have to be tested separately; this lab does not cover that case.

Caveat 3 on point-in-time scope. Both H1 and H2 verdicts are point-in-time for the reproduction window. A re-run minutes later may produce different cluster counts on Consumption if the scheduler shuffles replicas; Dedicated D8 is more stable in practice because the node binding is fixed for the profile's lifetime, but neither verdict is a long-term guarantee.

Mapping to Container Apps Non-Guarantee Claims¶

This lab tests three distinct claims about Container Apps replica placement. Each claim has a different evidence ceiling, and the ceilings are independent of how cleanly any single reproduction passes. Even with a perfect multi-cluster signal on Consumption and a perfect single-cluster signal on Dedicated D8, the lab cannot prove physical-host distribution because the underlying signal is not exposed by the platform.

Why this matters for incident response. When a customer escalates a "we expected fault isolation across nodes" or "we expected concentration on one node" case on Container Apps, support engineers should anchor the response in the profile choice, not in placement assumptions. The permanent [Strongly Suggested] cap on Claims 2 and 3 means there is no internal Container Apps signal that can prove per-replica node placement at the moment of incident; the Container Apps management plane does not expose that visibility, and that limit is a known platform property rather than a defect. Customers whose RTO genuinely requires per-replica node-identity visibility have options beyond Container Apps — for example, AKS surfaces per-node identity via kubernetes.io/hostname and zone labels — but that is an architectural choice driven by the visibility requirement, not the only available path.

13. Solution¶

Pick the profile that matches the placement property your workload actually needs. The lab's results justify the following operator guidance:

This lab does not test multi-node Dedicated profiles. Operators planning a multi-node Dedicated deployment should run a follow-up experiment that varies the number of D-series nodes in the profile and re-measures the cluster count at top scale.

14. Prevention¶

• Treat "Consumption distributes" and "Dedicated D8 concentrates" as [Strongly Suggested] defaults, not [Observed] guarantees. Document the evidence ceiling in your service description, post-incident reviews, and customer-facing SLAs.
• Pick the profile by required placement property at design time, not by per-replica cost optimization at deploy time. Switching profiles requires re-deploying the app and may surface differences in scaling behavior, cold-start time, and probe timing.
• Re-run this lab once per quarter (or whenever the team onboards a new region) so the team retains hands-on familiarity with kernel-context proxy reasoning. A platform behavior change (e.g. a new Hyper-V isolation model) would surface as a changed H3 verdict or a changed top-scale cluster count.
• Capture the D8 capacity ceiling for your specific resource shape. The lab's ~10 provisionable ceiling is specific to 0.25 vCPU / 0.5 GiB replicas on a single D8 node in koreacentral. Larger replicas, smaller replicas, or other regions will have different empirical ceilings.

15. Takeaway¶

Profile choice on Container Apps is a placement property choice, not just a billing choice. Consumption gives you [Strongly Suggested] multi-host distribution at the price of per-replica billing and microVM cold-start overhead. A single-node Dedicated profile gives you [Strongly Suggested] single-host concentration at the price of shared blast radius across all replicas in that profile. The platform does not expose the underlying Microsoft.Compute node identity on either profile, so the highest evidence ceiling for either claim is [Strongly Suggested] — anchor your runbook, SLO, and customer documentation in that ceiling, not in the operator mental model of "Consumption = many nodes, Dedicated = one node."

16. Support Takeaway¶

When a customer escalates a Container Apps "we expected per-replica fault isolation" or "we expected single-host concentration" case:

1. Read the workload profile binding first. az containerapp show --resource-group "$RG" --name "$APP_NAME" --query "properties.workloadProfileName" is the single source of truth for placement intent. Mismatched expectations almost always trace back to a profile choice that does not match the customer's mental model of placement.
2. Set the evidence-ceiling expectation explicitly. Tell the customer that Container Apps does not expose per-replica Microsoft.Compute node identity on any profile, that this is a known platform property (not a defect), and that the strongest empirical evidence available is the kernel-context proxy this lab uses. Customers who require per-replica node-identity visibility for their RTO should evaluate AKS — surface that option early.
3. Re-frame the question in profile terms. "Are my replicas across nodes?" on Consumption is [Strongly Suggested] yes at scale; on a single-node Dedicated profile is [Strongly Suggested] no; on a multi-node Dedicated profile is untested by this lab and requires its own reproduction.
4. Reference Microsoft Learn's exact wording on each profile's isolation model in the case notes so the customer's mental model is reset before further investigation. Cite Plans for Consumption isolation and Workload profiles for Dedicated profile node binding.

Clean Up¶

./cleanup.sh

Related Playbook¶

• Workload Profile Mismatch
• Replica Load Imbalance

See Also¶

• Plans and Workload Profiles
• Consumption Plan
• Workload Profiles
• Replica Load Imbalance Lab
• Zone Redundancy Is Best-Effort Lab
• Workload Profile Mismatch Lab

Sources¶

• Plans in Azure Container Apps
• Workload profiles in Azure Container Apps
• Scale an app in Azure Container Apps
• Containers in Azure Container Apps
• Environment variables in Azure Container Apps
• Billing in Azure Container Apps