Learning bite
Budgets, inventory, and cleanup
Treat resource ownership and retirement as part of the lab design.
AWS
Predict before you try
Does a successful local emulator call prove cloud identity and application authorization are correct?
Try it: Practice a retirement review →On this page
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:
| Field | Why it matters |
|---|---|
| Owner and purpose | Someone can decide whether the resource is still needed. |
| Account and Region | Cleanup must reach the same target as creation. |
| Resource ID and creation method | Names alone can be ambiguous; Terraform and manual objects may have different owners. |
| Cost drivers and expiry | Runtime is only one source of cost. |
| Data retention and removal plan | Deletion may be appropriate for fixtures but wrong for retained data. |
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↗.
Prove what you learned
Inspect the result
Retain account/region or the explicit local/design label, the intended path and a denied or missing check.
Explain it in your own words
Explain why your observation supports the stated outcome, and name one thing it does not prove.
Try a small variation
Change one caller, region or proposed dependency on paper and identify which checks must change.
Your evidence should show
- Record the context/revision or label the work as a paper or prepared fixture.
- Compare the prediction with the actual result from “Practice a retirement review”.
- Retain account/region or the explicit local/design label, the intended path and a denied or missing check.
- Explain the transfer challenge and retain the same verification question.
Hint
Name the environment enforcing each identity and permission decision.
Answer guide: compare after predicting
No. Local emulation, real cloud authorization and application outcomes require separate evidence.
Compare this with your actual observation. A paper answer is useful reasoning practice; record execution separately.
Recall DNS, routing and effective identity from Systems Foundations. Revisit the previous lesson.
Save the prediction, result and explanation ↓Your notes and evidence
Record observations, questions, or links to your work. Keep credentials out of your notes.
Back up or restore this path
Progress and notes stay in this browser. A backup contains only this learning path.