Why Cloud Costs Keep Growing: A Diagnostic Framework for Enterprise Technology Leaders
You have run the cost optimisation exercise. You have deployed the cost management tool. You have reviewed the recommendations and actioned some of them. The bill went down briefly and then kept climbing. Three months later, you are having the same conversation again.
This pattern is more common than any vendor will admit, and the reason it keeps repeating is that most cloud cost investigations start in the wrong place. They focus on the bill, which categories are expensive, which services are growing, rather than on the behaviours and structural conditions that are generating the cost. Fix the bill without fixing the behaviour and the bill grows back.
Find where the cost is actually coming from:
Step 1: Establish Whether You Can See What You Are Paying For
Before diagnosing anything else, answer this question: can you attribute cloud cost to specific teams, products, or workloads at the resource level?
If the answer is no, and your cloud spend appears as aggregated account-level numbers without meaningful breakdown, you do not have a cost problem yet. You have a visibility problem, and visibility is the prerequisite for everything else.
The diagnostic here is tagging coverage. Pull a report of your cloud resources and check what percentage have tags applied consistently. In most enterprise environments, the answer is somewhere between poor and catastrophic. Resources provisioned during a hackathon three years ago have no tags. Resources from acquired companies were never tagged in your schema. Resources created through the console by engineers in a hurry have whatever tags they remembered to add.
Without consistent tagging, you cannot answer the question of which team or product is responsible for which cost. Without that attribution, you cannot create accountability. Without accountability, costs accumulate because nobody owns them.
Fix tagging first. Enforce it through policy; most cloud providers allow you to require tags before a resource can be provisioned. Then rebuild your cost views from the tagged data. This alone typically surfaces significant waste by making previously invisible cost attributable to specific owners.
Step 2: Find the Idle and Abandoned Resources
The single largest source of cloud waste in most environments is resources that are running but not doing anything useful. The technical term is idle or underutilised resources. The practical term is paying for nothing.
The diagnostic is utilisation data. For every virtual machine in your environment, pull the average CPU and memory utilisation over the past 30 days. Any instance running at below 10 percent average utilisation is a candidate for investigation. In most enterprise environments, between 20 and 40 percent of instances fall into this category.
The causes are predictable. A developer provisioned an instance for a project that changed scope. A test environment was created for a release and never cleaned up. A proof of concept ran for two weeks, and the engineers moved on without deprovisioning. A production instance was sized for peak load that never materialised.
The fix requires two things: a one-time cleanup of the current inventory and a process that prevents accumulation going forward. The one-time cleanup is straightforward: identify idle resources, contact the owners, and deprovision what is no longer needed. The process fix is harder. It means establishing time-to-live policies for non-production environments, automated alerts when resource utilisation drops below a threshold, and a regular review cycle where teams are responsible for justifying the resources they are running.
Step 3: Audit Your Instance Sizing Against Actual Workloads
Engineers provision conservatively. This is rational; an underpowered instance that causes a production incident is a visible, attributable problem. An oversized instance quietly burning money every month is invisible.
The diagnostic is rightsizing analysis. Compare the provisioned capacity of your instances against their actual peak utilisation over a rolling 30-day period. Most cloud providers surface this through their native cost tools, and third-party platforms like CloudHealth, Spot, and others provide more granular analysis.
The findings in most environments are consistent. The majority of instances are oversized for their actual workloads. Moving from an instance type sized for theoretical peak to one sized for actual peak with a reasonable headroom buffer produces material cost reduction without performance impact.
The important nuance is that rightsizing is not a one-time exercise. Workloads change. An instance that was correctly sized six months ago may be oversized today because the workload changed, or undersized because it grew. Building rightsizing into a continuous operational cadence rather than treating it as a project produces sustained reduction rather than a temporary dip.
Step 4: Examine Your Reserved Capacity and Savings Plan Coverage
On-demand pricing is the most expensive way to run stable workloads. Reserved instances and savings plans offer discounts of 30 to 60 percent for committing to a level of capacity for one or three years. For workloads that run continuously, the economics are straightforward.
The diagnostic is coverage analysis. What percentage of your total compute spend is covered by reservations or savings plans versus running on-demand? For most enterprises, the answer reveals significant on-demand spend on workloads that have been running stably for years and should long since have been covered.
The common reason coverage is lower than it should be is that reservations require commitment, and commitment requires understanding which workloads are stable enough to commit on. In environments without good visibility and attribution, that understanding does not exist. Fix the visibility problem first, and the reservation opportunity becomes clear.
The less common but more expensive reason is stale reservations. Organisations that made reservation commitments and then changed their workload mix find themselves with reservations that no longer match their actual infrastructure profile. The discounts are being applied to workloads that no longer exist while new workloads run on-demand. Regular reservation portfolio reviews against the actual infrastructure profile prevent this accumulation.
Step 5: Investigate Data Transfer and Egress Costs
Data transfer costs are the most consistently underestimated line item in cloud budgets and the most architecturally rooted. Unlike compute costs, where the fix is usually rightsizing or cleanup, high egress costs reflect architectural decisions that are expensive to reverse.
The diagnostic is egress analysis by source and destination. Most cloud billing dashboards break down data transfer costs by region and service. The question to answer is where data is moving, between which systems, and whether that movement was anticipated when the architecture was designed.
Common findings include inter-region data transfer that was never costed in the original architecture, egress fees on data moving from cloud to end users that was assumed to be low volume and turned out not to be, and application architectures where services in different regions call each other in ways that generate cross-region transfer charges on every request.
The fixes range from straightforward to architectural. Consolidating workloads into fewer regions, using CDN for end-user content delivery, and re-examining service communication patterns to reduce cross-region calls all produce egress savings. None of them is quick, but identifying the source of the cost is the prerequisite for making the decision about which fix to apply.
What the Diagnostic Tells You
Working through these five steps tells you whether you have a visibility problem, a cleanup problem, a sizing problem, a reservation coverage problem, or an architecture problem. Usually the answer is some combination of all five, weighted differently depending on how the environment evolved.
The most important insight from this diagnostic is that cloud cost growth is almost never random. It is the cumulative result of specific behaviours: provisioning without deprovisioning, sizing for theoretical peaks, committing to reservations without maintaining them, building architectures without costing the data transfer that repeat until somebody makes them visible and accountable.
At Dygital9, we work with engineering teams building the visibility and governance infrastructure that makes cloud cost manageable at scale. The diagnostic above is the starting point. What you do with the findings depends on which problems you find.
Comments