Skip to content
← Platform engineering

Learning bite

Cost inventory and teardown

Account for all resources in an experiment and verify cleanup without assuming a budget stops spending.

Documentation reviewed2026-10-01 · 3 min read
On this page

A lab ends when its resources are accounted for

A resource inventory names what exists, why it exists, who owns it and what should happen at the end of the exercise. Cost control begins with that inventory. A stopped application can leave storage, addresses, logs or networking resources behind.

Cost follows resources, not lesson completion

A cloud cluster experiment can include control-plane charges, compute, disks, snapshots, registries, public IPs, NAT, load balancers, logs, and network transfer. Do not price only the worker nodes. Use the selected region, service mode, and current provider pricing to prepare an estimate; record the assumptions behind the estimate rather than assuming a free tier or fixed monthly total.

Assign an owner and removal date to the experiment. Budget alerts provide feedback; they are not generally an automatic hard spending cap. Define the human or implemented automation that responds to them.

Optimize after observing

Measure idle and active resource demand, then examine oversized requests, always-on optional services, excess retention, and resources left after a session. On the local 16 GB host, stopping optional profiles can be more useful than adding an autoscaler. Do not recommend spot/preemptible capacity for a workload without considering interruption and data recovery.

Keep recurring synthetic-user checks local. Cloud profiles must not copy their CronJobs, monitor runners, or fault jobs.

Plan cleanup as a dependency sequence

No prices are assumed in this exercise. Fill the unit prices from the chosen provider and region only when planning an actual run.

Resource classEstimate driverEnd-of-session question
Cluster and worker computeMode, size and hoursWas the intended cluster removed or merely scaled down?
Load balancer and networkingHours, processed/transferred dataDid controller-created resources disappear?
Disks and snapshotsAllocated storage and retentionWhich data must be retained deliberately?
Logs and image registryIngestion, storage and retentionIs cleanup policy configured and observed?
State backendStorage and access requirementsIs it retained until cleanup is verified?

Draw arrows where one resource can create another. A Kubernetes LoadBalancer Service can cause a cloud load balancer to exist through a controller. Removing the cluster before its controllers can finish cleanup may leave resources to investigate manually. Follow the provider's deletion sequence and inspect the resulting inventory.

For the 16 GB local host, the comparable habit is simpler: stop the active profile when finished, retain only needed volumes and measure disk usage before pulling another large stack. Local storage exhaustion is still an operating problem even without a cloud bill.

Try it

Create an inventory before a cloud experiment and update it from actual provisioned identifiers afterward. For each resource, record dependency, retention decision, and deletion check. Include the state backend separately so removing the application does not erase the information needed to finish cleanup.

Review a destroy plan before execution. After cleanup, check the provider inventory for retained disks, snapshots, addresses, load balancers, log storage, and registries. A successful Terraform command only reports on resources it manages; it cannot prove an entire account has no remaining charges.

Checkpoint and revision

Show what you intend to retain and why. Report the observed costs and cleanup results, including the time period they cover. A scheduled reminder or a budget threshold is not evidence that resources were removed.

Compare your reasoning

A budget alert tells you about spending; it is not generally a hard cap. A successful destroy covers the resources known to that configuration, not every resource in an account. The output of this exercise is an inventory and cleanup decision, not a claimed cost saving.

Sources

AWS Budgets↗, Google Cloud budgets↗, EKS deletion↗, GKE deletion↗.

Your notes and evidence

Record observations, questions, or links to your work. Keep credentials out of your notes.

Loading saved progress…

Back up or restore this path

Progress and notes stay in this browser. A backup contains only this learning path.