Forty percent sounds like a marketing number until you see where the waste actually hides. This is the playbook that finds it, in the order that works, and the practice that stops it coming back.
The forty percent figure is the one that gets the meeting, and it is also the one people quietly disbelieve. It sounds like the kind of number a vendor invents to win attention. In our experience across hundreds of Oracle Cloud Infrastructure estates, it is closer to a reliable average for any estate that has never been through a structured optimisation pass. The reason is not that anyone was careless. It is that cloud spend grows through a hundred small, rational decisions that nobody ever revisits, and the savings sit there untouched simply because no one has gone looking with the right method.
This article is that method. It walks through the levers that find the savings, in the sequence that compounds, and then the governance that keeps the run rate down once you have lowered it. If you read only one thing from our complete FinOps guide first, this is the practical companion that turns the theory into a number on the invoice.
It helps to know that the savings are rarely one big thing. They are the sum of several medium things, which is exactly why estates miss them. A team chasing a single dramatic cut gives up when no single resource is obviously wasteful. The discipline is to add up the levers, each modest on its own, until the total reaches a number that changes the budget conversation.
| Lever | Typical share of the saving | Effort to capture |
|---|---|---|
| Right sizing compute and database | Largest single contributor | Medium |
| Eliminating idle and orphaned resources | Significant quick win | Low |
| Scheduling non production environments | Steady recurring saving | Low |
| Storage tiering | Grows with data volume | Low to medium |
| Commitment matched to demand | Large on stable workloads | Medium |
| Licensing model correction | Large for Oracle software | Medium to high |
No single row gets you to forty percent. Together, on an unoptimised estate, they routinely do. The order in the table is roughly the order of attack, because the early rows fund the attention the later ones need.
You cannot cut what you cannot see, and the first mistake teams make is reaching for a fix before they understand the bill. Start by breaking the spend down by service, by compartment and by team, so that the largest lines are obvious and the surprises surface early. Most estates discover at this stage that a handful of resources drive the majority of the cost, which is good news, because it means the work has a focus. The detail of how to stand up that view is covered in Building an OCI Cost Dashboard, and the tagging that makes spend attributable is in Tagging Strategy for OCI Cost Allocation.
Before anything clever, harvest the obvious. Estates accumulate resources that run and cost money while doing nothing useful, the test instance from a closed project, the block volume attached to a machine that was deleted, the environment nobody owns. Finding and removing these is the fastest return in the whole exercise, and it builds the credibility that funds the rest of the work. The systematic approach is in Finding Idle Resources on OCI.
Scheduling is the second quick win. Development, test and staging environments rarely need to run overnight or at weekends, yet most run every hour of the year. Shutting them outside working hours can cut their cost by well over half with no effect on delivery, because nobody is using them when they are off.
The single largest lever is paying for capacity that workloads never use. Compute shapes get chosen to match the old on premises server, databases get provisioned for a peak that arrives twice a year, and headroom gets layered on headroom out of caution. Right sizing means measuring what each workload actually consumes over a representative period and matching the shape to that with a sensible margin, not to a worst case that almost never happens. The mechanics of OCI shapes and how they map to real demand are in OCI Right Sizing: Compute Shapes Explained.
Right sizing is iterative, not a single event. You reduce, you watch, and you reduce again, leaving margin for genuine peaks. Done with discipline it is the lever that contributes the most to the forty percent, because over provisioning is the most common form of waste in any cloud estate.
Two lines are routinely ignored until they are large. Storage grows because data accumulates on high performance tiers when most of it is cold and belongs somewhere cheaper, a pattern addressed in OCI Storage Cost Optimization. Network egress, the cost of data leaving OCI, is invisible until the first bill and can be material for chatty architectures, which is why it deserves deliberate attention. Neither line is glamorous and both reward a few hours of work.
OCI rewards commitment, and an estate paying on demand rates for capacity it runs continuously is leaving money on the table. The skill is committing to the stable baseline of demand while leaving the variable portion flexible, so you capture the discount without locking into capacity you will not use. The mechanics are set out in Universal Credits vs Pay As You Go on OCI, and the negotiation that sets the number is in OCI Commitment Negotiation Basics. Commitment comes after right sizing on purpose, because committing before you have right sized just locks in the waste.
For Oracle workloads, licensing can dominate the economics, and the choice between Bring Your Own License and included licensing changes the arithmetic substantially. An estate on the wrong licensing model can be paying far more than necessary no matter how well sized the infrastructure is. This is a distinct workstream and it is exactly where independent licensing expertise earns its place, as explored in BYOL on OCI: Licensing Cost Savings.
Following the sequence is what reaches forty percent. Skipping to commitment or licensing before right sizing locks in waste, and skipping governance at the end means the savings drift away within two quarters.
Cutting the bill once is satisfying and temporary. An estate optimised in March drifts straight back to waste by September as new resources are provisioned and old ones linger, unless governance prevents it. Budgets and quotas cap spend before it runs away, as covered in OCI Cost Governance with Budgets and Quotas, and chargeback puts the cost in front of the people who incur it, as in Showback and Chargeback on OCI. The standing rhythm that ties it together is the FinOps practice described in FinOps Operating Model for OCI, and the surprise it prevents is the one in Avoiding OCI Bill Shock.
Numbers make the case better than adjectives. Take an estate running at one hundred thousand dollars a month that has never been optimised. Right sizing the compute and database fleet from measured utilisation typically removes a fifth of the bill on its own, because the gap between provisioned and consumed capacity is usually that wide. Eliminating idle and orphaned resources and scheduling the non production environments adds several points more, because these costs are pure waste with no offsetting benefit. Tiering cold storage and controlling egress trims another few points on the quiet lines. Matching commitment to the now smaller, well understood baseline lowers the rate on what remains. Correcting the licensing model, where it applies, can move the number again. Add those together and forty percent is not optimistic, it is arithmetic, and the only reason most estates have not captured it is that nobody has worked through the levers in order.
The first objection is that the estate is already lean because the team is careful. Care is real and waste is still there, because waste in the cloud is structural, not a sign of sloppiness. Provisioning is fast and deprovisioning is slow, and that asymmetry produces drift in even the most disciplined teams. The second objection is that optimisation will hurt performance. Done properly it does the opposite, because right sizing leaves margin for genuine peaks while removing the headroom that was never used, and a well sized workload is easier to reason about than an over provisioned one. The third objection is that the work is not worth the disruption, which only holds if the saving is small, and on an unoptimised estate it rarely is.
It is worth being honest about the boundaries of the claim. Forty percent is what a first structured pass tends to find on an estate that has never had one. An estate that has already been optimised will not yield another forty percent, because the waste has already been removed, and chasing that number on a lean estate leads to cutting into capacity that workloads genuinely need. The figure is a description of how much waste accumulates in the absence of a practice, not a promise that any estate can always be cut by that much. The durable goal is not a single dramatic cut but a low run rate that stays low, which is why the governance step matters as much as the cutting.
Internal teams can run this, but it competes for attention with delivery, and the specialised levers reward deep expertise. We run cost optimisation on a fee paid only on verified savings, which aligns our interest exactly with lowering your run rate. If we find no savings there is no fee, and if we find substantial savings the fee is a fraction of a benefit you would not otherwise have captured. It is the rare engagement where the provider's incentive and the client's interest point the same way, which is why our OCI Cost Optimization practice is structured around it. The work starts with an assessment that measures where the spend actually goes, because every saving above begins from seeing the truth of the bill.
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.