Why do boot volumes become a cost problem?
On OCI, compute and its boot volume are separate resources. The instance runs the workload; the boot volume holds the operating system and bills as Block Volume storage. When you terminate the instance, OCI lets you keep the boot volume, and a great deal of automation does exactly that by default so it can re attach later. The result is that every short lived environment, every failed deployment, and every decommissioned server can leave a boot volume behind, each billing per GB month plus its performance units forever.
The buyer takeaway is that this is pure waste with no production dependency, which makes it one of the safest line items to remove. The only work is confirming that a detached volume is genuinely unwanted before deleting it.
What does an orphaned boot volume actually cost?
Block Volume bills on capacity and performance. The capacity rate is indicative at about 0.0255 dollars per GB month, and the performance setting adds volume performance units on top. A default boot volume is 50 GB but is often expanded well beyond that. One forgotten 100 GB boot volume is small; a thousand of them across years of test environments is a five figure annual line that nobody planned to pay.
| Orphaned volumes | Average size | Indicative monthly cost |
|---|---|---|
| 50 | 100 GB | about 128 dollars |
| 500 | 100 GB | about 1,275 dollars |
| 1,000 | 150 GB | about 3,825 dollars |
Figures are indicative of capacity cost only and exclude performance units and backups, which push the real number higher. Verified against anonymized billing data.
How do I run the cleanup safely?
Work in four passes. First, list every boot volume with no attached instance; these are the orphan candidates. Second, confirm ownership through tags and recent activity so you do not delete a volume someone intends to re attach, then terminate the genuinely unwanted ones. Third, right size what remains: lower the performance tier on boot volumes that do not need fast input output, since most do not once the instance is up. Fourth, review boot volume backups and expire anything beyond your retention policy.
How do I stop it coming back?
Hygiene is a policy problem, not a one time sweep. Set termination automation to delete the boot volume when the instance is genuinely disposable, and keep it only where re attachment is the deliberate intent. Apply a backup lifecycle policy so snapshots expire on schedule. Tag every volume with an owner and an environment so the next audit can tell a deliberate keep from an accidental orphan in seconds rather than guessing.
The decision you can make this week
Run a report of detached boot volumes across your tenancy and sort by size. Confirm and remove the clear orphans, drop the performance tier on boot volumes that do not need it, and set a backup expiry policy. Then fix the termination automation so future instances clean up after themselves. The first sweep usually pays for itself immediately, and the policy change keeps the savings.
Frequently asked questions
Recover the storage spend hiding in old volumes
Our buyer side review finds orphaned boot volumes, stale backups, and over provisioned performance tiers across your OCI tenancy and recovers the spend safely. We take zero provider commissions, and we guarantee results: we reduce your cloud spend or we reimburse our service fee.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.