Budgets, inventory, and cleanup

A stopped process and a stopped bill are different things

Cloud services charge for different units: running compute time, stored data, requests, processed traffic, public addresses, and other service-specific usage. Stopping an EC2 instance can stop some instance charges while attached storage and other resources remain. A design that looks small in a diagram can still contain an always-running NAT gateway or load balancer.

A budget alert helps detect spending against a threshold. It is not a universal hard ceiling, and billing data and notifications are not instantaneous. Learn the scope and timing of a control before relying on it to terminate an experiment.

Estimate the complete proposed environment

Use the compute and storage drawing from the preceding lessons. Do not create resources for this exercise. Look up the current pricing for the intended Region and record the assumptions rather than memorizing a price.

For an illustrative estimate, suppose a service has a hypothetical rate of 0.02 currency units per hour and runs for 10 hours. Its runtime component is 0.02 × 10 = 0.20. If it also stores data and sends traffic, those are additional components. This arithmetic example is not an AWS price quote or a claim about a free tier.

Break your estimate into compute hours, storage quantity and retention, request volume, data transfer, and supporting services. Note which values you do not yet know. A cost estimate with visible unknowns is more useful than a precise total built from invented traffic.

Keep an inventory you can reconcile

Create a private resource ledger:

Tags help organize resources, but support varies by service and cost allocation may require activation. An untagged resource is not necessarily unused. Compare the ledger with actual inventory and billing views when you have authorized access.

For a Terraform-managed future lab, review its destroy plan and then check for retained or separately created objects. A snapshot, log group, address, or manual resource may outlive the application. Account-wide deletion scripts based only on a name prefix or tag are too broad for this small exercise.

Practice a retirement review

Take a proposed API VM, its data volume, one snapshot, a load balancer, and a DNS record. For each, decide whether it should be stopped, deleted, retained, or updated at the end of a disposable lab. There is no universal delete-all answer: a retained snapshot may be intentional, but its ownership and cost must remain visible.

If you have no account or created nothing, write “no infrastructure created” as the observation. Do not invent a cleanup log. A claimed saving requires a measured before-and-after comparison with a stated period and workload, not merely changing an instance label.

Local labs consume resources too. Docker images, build cache, VM disks, and database volumes use the 512 GB disk. On the 16 GB host, use one deployment profile at a time and stop idle environments. Inspect usage before removing only the named completed lab objects.

Checkpoint: why is “the VM is stopped” insufficient? Its storage and related services may remain. Why is a budget alert insufficient as a hard spending limit? Its detection and action behavior is not an immediate universal prevention mechanism. Next, use Python to make a bounded read with an explicitly understood identity.

References: AWS Budgets↗, AWS pricing↗, and EC2 lifecycle↗.