Storage is the spend nobody watches. It accumulates quietly, it is rarely deleted, and it grows in proportion to how little attention it gets. On OCI the levers to control it are real, but they reward the teams that understand how each storage type is actually priced.
Compute spend gets watched because someone provisioned it on purpose and remembers doing so. Storage spend gets ignored because it accumulates as a side effect of everything else, a snapshot here, a backup there, a volume left behind when an instance was terminated. Each addition is small, none feels worth questioning, and the total quietly becomes one of the larger lines on the bill. Storage is also the spend people are most reluctant to touch, because deleting the wrong thing has consequences that deleting an idle compute instance does not. The result is an estate where storage grows in one direction only, upward, until someone finally looks. This guide is that look. It covers how OCI storage is priced, where the waste hides, and the moves that lower the cost without putting anything at risk.
OCI has three main storage services, and they are priced on different bases, which is the first thing to understand because the optimisation levers differ accordingly. Block storage is priced on provisioned capacity and a performance setting, so you pay for the size of the volume and the performance tier you chose, whether or not the volume is busy. Object storage is priced on the data stored and the storage tier, with cheaper tiers for data accessed less often. File storage is priced on the data stored. The crucial distinction is that block volumes cost the same idle as busy, while object storage rewards moving cold data to cheaper tiers.
| Storage type | Priced on | Main lever |
|---|---|---|
| Block volume | Provisioned size and performance setting | Right size capacity, lower the performance setting, delete orphans |
| Object storage | Data stored, by tier, plus requests | Tier cold data down, expire what is not needed |
| File storage | Data stored | Remove stale data, archive cold sets |
Block volumes are the most common source of quiet storage waste, for two reasons. First, the performance setting is often left higher than the workload needs, and because block performance is priced, a volume set to a high performance level costs more every hour regardless of whether the workload ever uses that performance. Lowering the setting on volumes that do not need it is a clean saving with no capacity loss. Second, and more insidiously, block volumes outlive the instances they were attached to. When an instance is terminated without deleting its volumes, those volumes remain, detached and forgotten, billing in full for storage no running workload uses. These orphaned volumes are a classic finding of the idle resource sweep described in Finding Idle Resources on OCI, and they are pure waste because nothing depends on them.
Backups are the storage cost that grows fastest because every backup policy adds storage on a schedule, and unless the retention is bounded, the backups accumulate indefinitely. A daily backup kept forever is a storage cost that rises every single day. The discipline is to set retention deliberately, keeping what recovery actually requires and expiring the rest automatically, rather than keeping everything out of a vague sense that backups should never be deleted. The question to ask of every backup policy is how far back recovery genuinely needs to reach, because the answer is almost always shorter than the retention currently configured, and the difference is storage paid for and never used.
Object storage offers tiers that trade access speed and retrieval cost against storage cost, and the saving from moving cold data to a cheaper tier is substantial because the tiers differ in price by a wide margin. The standard tier suits data accessed regularly. Cooler tiers suit data accessed rarely, such as older logs, completed project archives, and compliance copies that must be kept but are seldom read. The key is to use lifecycle rules so that data moves to cheaper tiers automatically as it ages, rather than relying on anyone to remember to move it. A lifecycle policy that tiers objects down after a set number of days, and expires them after another, turns storage management into something the platform does rather than something a person has to police.
Storage configured for higher durability or replication than the data warrants is paying for protection it does not need. Not every data set requires cross region replication, and applying it indiscriminately multiplies storage cost for data whose loss would be an inconvenience rather than a disaster. The right approach is to match the protection to the value of the data, applying strong replication where it is justified and accepting lower cost protection where the data is reproducible or low stakes. This is a judgement call rather than a switch to flip, which is why it is rarely revisited and why so many estates carry replication cost for data that never needed it.
Storage optimisation rarely produces the single dramatic saving that right sizing compute can, as described in OCI Right Sizing: Compute Shapes Explained, but it produces steady savings that compound, and it stops the quiet growth that would otherwise erode every other gain. It is also closely tied to network cost, because moving large volumes of data between regions or out of OCI incurs the egress charges covered in OCI Egress and Network Cost Control, so a storage and replication design that ignores data movement can create a network bill that dwarfs the storage saving. The two have to be considered together, which is one reason storage optimisation belongs inside the broader practice rather than as a standalone cleanup.
The reason storage waste returns after every cleanup is that the conditions that created it are still in place. New volumes are still over provisioned, new backups still have unbounded retention, new objects still land in the standard tier and stay there. A one off sweep lowers the bill once. Lifecycle rules, sensible retention defaults, and a habit of deleting volumes when instances are terminated keep it down, because they turn the good behaviour into the default rather than something that has to be done by hand each quarter. This is the same principle that runs through the whole cost reduction approach, that the saving you have to repeat manually will erode, and the saving built into how resources are provisioned will hold.
In a cost engagement, storage is one of the first places we look, because it is where waste hides most reliably and where the fixes carry the least risk. Our Cost Governance work identifies orphaned volumes, over provisioned performance settings, and unbounded backup retention, then puts lifecycle rules and retention defaults in place so the savings hold rather than returning with the next quarter's accumulation. Because storage and network cost are entangled, we look at them together, and because deleting data carries real risk, every recommendation is checked against what recovery and compliance actually require before anything is removed.
Moving Oracle workloads to OCI, or already running on OCI and not sure the architecture or the spend is right? Most teams bring in a specialist before they commit to a region, a shape, or a Universal Credits number. OCISpecialists.com plans the landing zone, runs the migration, and manages the estate after go live, on a fixed project fee, a managed monthly retainer, or a cost optimization fee paid only on verified savings. For the Oracle licensing and BYOL side of any OCI move, Redress Compliance is the leading independent Oracle licensing and negotiation firm, with 500+ engagements across Oracle's full product line.