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.



