Skip to content

Cost And Lifecycle

Committed design, not implemented

A disposable lab is only useful when likely cost, lifetime, ownership, and cleanup are reviewable before deployment.

Cost estimation will be a separate operation exposed by -CostEstimate. It will read the same schema-validated YAML as planning and deployment; it will not be an automatic side effect hidden inside deployment.

The operation will produce the same versioned result in:

  • a concise console view;
  • JSON for automation;
  • Markdown for pull requests and run records;
  • a self-contained HTML report for people reviewing the lab.

The estimate will identify region, currency, SKU, quantity, expected runtime, price timestamp, price source, one-time and recurring categories, licensing assumptions, and omissions. The report must distinguish priced, estimated, unknown, and excluded items.

The committed model includes an expected lab budget, warning thresholds, tags for owner and expiry, and an optional Azure budget resource where the account and scope support it.

Azure Cost Management budgets generate alerts; they do not stop resources or cap spending by themselves. Cost data and budget evaluation can also be delayed. Any automated reaction to an alert is a separate workflow with its own identity, approval, and failure risks.

Stopping or deallocating compute can reduce part of the bill, but the lab may continue to pay for disks, snapshots, public IPs, Bastion, storage, backup, logs, Fabric capacity, network services, licenses, or reservations. A shutdown plan must list what stops, what keeps running, and what keeps costing money.

Every discovered resource needs an ownership class before deletion:

Ownership class Teardown behavior
owned Eligible when teardown intent and approval include it
adopted Eligible only within its separately approved adoption scope
reused Never deleted by this run
external Never deleted by this run
Unknown or ambiguous Stop and request review

Teardown will first show the resource, ownership evidence, dependencies, expected data loss, and action. Confirmation follows the summary. No confirmation mode may broaden deletion beyond resources already proven eligible.

Control Intended evidence
Time to live Expiry, owner, policy, and overdue status
Shutdown Requested schedule, actual state, and residual costs
Resume State reconciliation and dependency validation
Teardown preview Delete, retain, conflict, and unknown resources
Cleanup proof Azure requery showing what was removed and what remains

Interrupted deployment or teardown must remain resumable. The run record will distinguish completed, pending, failed, drifted, retained, and unknown actions.