Operations

Cleaning up unused cloud resources: a monthly routine

A repeatable monthly cleanup that finds and removes idle instances, orphaned volumes, stale snapshots, unassigned IPs and forgotten test resources.

Updated September 25, 2026

Cleaning up unused cloud resources: a monthly routine

Cloud cost rarely grows through one big decision. It grows through dozens of small resources that outlived their purpose: the test server from a demo, the volume left behind when a machine was destroyed, the snapshot taken before an upgrade six months ago. Because both Vultr and UpCloud bill hourly for most resources, everything that exists is costing something right now. This is a monthly routine that finds and removes what no longer earns its keep.

Set the rules before the first cleanup

Cleanup without rules becomes a monthly negotiation. Agree three things in advance:

  • A retention period for snapshots that are not part of a defined backup policy.
  • A maximum lifetime for anything tagged as development or test without an owner response.
  • A rule that every resource must have an owner tag, and untagged resources are cleanup candidates by default.

With those agreed, the routine is mechanical and nobody takes deletion personally. The tagging and cost allocation guide covers the owner tag that makes this work.

Step one: instances

List every instance and check three things: is it tagged, is anyone using it and does its size still match its job. Test instances created for a demo or a debugging session are the most common finds. Stop anything doubtful first; if nobody notices within a week, destroy it. On Vultr, instances are listed in the customer portal by region; on UpCloud, the control panel lists Cloud Servers with their plan and storage. Both let you filter and sort by creation date, which surfaces the old ones quickly.

Right-sizing belongs in the same pass. A server running at a fraction of its capacity is not unused, but it is oversized, and both providers make resizing straightforward.

Step two: volumes and storage devices

Block storage bills independently of the instance it was attached to. Look specifically for volumes with no attachment: they are the remains of destroyed servers. On UpCloud, storage devices are listed separately from servers and carry a tier, MaxIOPS, Standard or Archive; a detached MaxIOPS device is paying for performance nobody is using. On Vultr, block storage volumes appear in their own section and show whether they are attached.

Before deleting a detached volume, snapshot it if there is any doubt about its contents, then delete the volume. Delete the snapshot once the retention period passes.

Step three: snapshots and backups

Snapshots are the quietest cost. Each is billed on the space it occupies for as long as it exists. Separate them into two groups: snapshots that belong to a documented backup policy, which stay according to that policy, and ad-hoc snapshots taken before a change, which are deleted once older than the agreed retention period. If you find you have no documented policy, the backup and recovery baseline is the place to build one, and the cleanup then enforces it.

Automated backup features on individual servers add a recurring line. Confirm each enabled backup still protects something that matters.

Step four: IP addresses and networking

Reserved or floating IP addresses that are not assigned to a running server may still be billed because the address is held for you. Release the ones with no purpose. Keep and document the ones held deliberately for failover so the next cleanup does not release them by mistake. Check load balancers as well: a load balancer with no healthy backends is pure cost.

Step five: object storage and everything else

Object storage buckets accumulate logs, build artifacts and old exports. Apply lifecycle rules where the provider supports them so old objects expire automatically. Finally, sweep the rest: managed databases nobody queries, Kubernetes clusters from an experiment, firewall rules referencing servers that no longer exist and API keys whose owners have left.

The monthly checklist

Category Find Action
Instances Untagged, idle or oversized Stop, then destroy or resize
Volumes Detached devices Snapshot if unsure, then delete
Snapshots Ad-hoc copies past retention Delete
IPs and load balancers Unassigned addresses, empty balancers Release or document
Object storage Buckets without lifecycle rules Add expiry rules
Access Keys with no active owner Rotate or revoke

Record what was removed and the estimated saving. After three months the list becomes short, which is the point.

Why it matters more on credit-based accounts

Accounts that start with a balance make waste easy to ignore because the amount due reads zero. The Buy Vultr Account page lists “Vultr $200 Credit Account”, “Vultr $250 Credit Account” and “Vultr $300 Credit Account”, and the Buy UpCloud Account page lists an “UpCloud $500 Credit Account”. Every idle resource shortens how long such a balance lasts and then appears as a real charge the month it runs out. Cleaning up from month one makes the credit go further and keeps the first paid invoice unremarkable. The cost control guide pairs this routine with budgets and alerts, and the UpCloud section of the cloud FAQ answers provider-specific questions.

Questions on this topic

Is it safe to delete a detached volume?

Usually, but check first. A detached volume is most often left over from a destroyed server. If there is any doubt about its contents, take a snapshot, delete the volume, and delete the snapshot once your agreed retention period passes. That keeps a recovery path while stopping the ongoing charge.

How long should I keep ad-hoc snapshots?

Long enough to confirm the change they protected succeeded, and no longer. Many teams settle on a few weeks for snapshots taken before upgrades or migrations. Snapshots that belong to a documented backup policy follow that policy instead. The backup and recovery baseline guide helps define one.

Does cleanup matter if my account still has credit?

Yes. A credit balance hides waste because the amount due shows zero, but every idle resource consumes the balance faster and then becomes a real charge the month it runs out. Cleaning up from the first month stretches a Vultr or UpCloud credit and keeps the first paid invoice predictable.

More from the Blog

All articles