Cloud Resource Lifecycle: From Launch to Clean Deletion
Most cost problems are lifecycle problems: a stage that was skipped, or a deletion that did not delete everything.
Resource lifecycle management is governing a cloud resource through its whole existence: why it was created, who owns it, how it runs, when it is reviewed, and how it is retired. Each stage has its own cost risk, and most of the waste found in cleanup campaigns traces back to a stage that had no owner or no rule.
Stage 1: provision with an exit in mind
The cheapest time to decide how a resource ends is when it is created. At provisioning:
- Record an owner and purpose in tags, and an expiry date for anything temporary: feature environments, load tests, demos.
- Create it through infrastructure-as-code where possible, so its existence is reviewed and its removal is a code change.
- Choose deletion behaviour for attached storage deliberately, because the defaults differ.
Stage 2: operate with the right power state
A running resource should be running because someone needs it now. Environments used only in working hours can follow a start/stop schedule; see cloud scheduling best practices. Stopping is not free: disks, IP addresses, and managed networking bill while compute is stopped, as described in infrastructure idle costs.
Stage 3: review and optimize
Usage drifts after launch. Periodic review asks three questions: is it still used, is it the right size, and is it on the right pricing model? The answers lead to rightsizing, a schedule, or a commitment for steady baseline capacity. Review works best on a cadence tied to something that already happens, such as a sprint or a monthly cost review, with the owner doing the review rather than a central team guessing.
Stage 4: retire completely
Deleting a VM does not necessarily delete what it used. Provider defaults:
| Provider | What happens to disks when the VM is deleted |
|---|---|
| AWS EC2 | A root volume attached at launch is deleted on termination; data volumes attached after launch, or at launch via the console, are preserved and keep billing |
| Google Cloud | Each disk’s autoDelete property decides; set it to false to keep a disk, true to delete it with the instance |
| Azure | In the portal the OS disk defaults to Delete with VM; with the CLI and PowerShell the default is to detach the OS disk, and detached resources continue to incur charges |
After the compute is gone, check for the rest: snapshots and images made from it, public IPs, load balancers, DNS records, and security groups. Snapshots need their own policy. EBS snapshots are incremental, so deleting one may not reduce storage cost if other snapshots reference the same data. AWS Recycle Bin can retain deleted snapshots for a retention period so accidental deletions are recoverable, at the cost of keeping them billed until the period expires.
Keeping the stages connected
- Every temporary resource carries an expiry, and something checks it.
- Every resource has an owner who is still in the organization.
- Every deletion is preceded by a check of what depends on it.
Where ZopNight fits
ZopNight supports the operate and review stages with schedules, overrides that expire automatically, and recommendations across idle, rightsizing, schedule, and orphan categories. For retirement, orphan recommendations surface leftovers such as unattached volumes and snapshots, and the remediation workflow runs delete steps behind an admin-approval gate, with a blast radius view of what a delete would affect. Ownership detection shows who created and last changed a resource.
Related: cloud sprawl and cloud inventory.
Questions we get a lot.
If yours isn't here, email us and we'll answer directly.
Why do I still pay for storage after terminating an EC2 instance?
Data volumes attached after launch, and data volumes attached at launch through the console, are preserved on termination by default. They keep billing until you delete them.
Does deleting an Azure VM delete its disks?
It depends on the delete options. The portal defaults the OS disk to Delete with VM, while VMs created with the CLI or PowerShell detach the OS disk by default. Detached disks continue to incur charges.