A developer on a team I worked with added a single line to a Terraform module to turn on cross region replication for a logging bucket. It took her about four minutes. She was right to do it, the compliance requirement was real, and nobody reviewing the pull request thought about money because pull requests are not where money gets discussed. That four minute change added roughly 11,000 dollars a year to the bill, and it took us five weeks to work out where the increase had come from.

Nothing about that story is unusual and nothing about it involves waste. It is simply what happens when the act of spending money has been moved from a procurement process into a text editor. If you carry a mental model of IT cost built in the data centre era, cloud will keep surprising you, and the surprises will always arrive about six weeks late. This part is the model that stops that happening.

Provisioned capacity versus consumed capacity

In a data centre you buy capacity in lumps and you buy it ahead of demand. Somebody forecasts eighteen months out, a purchase order goes through, racks arrive, and from that moment the cost is fixed and sunk. Whether the servers run at 12 percent utilisation or 80 percent, the money has gone. The finance treatment reflects this: it is CapEx, depreciated over three to five years, and it appears on the balance sheet as an asset.

Cloud inverts this completely. You do not buy capacity, you rent consumption, metered in units as small as a second and billed as OpEx with no asset to show for it. The practical consequence is that idle stops being free. In a data centre, an instance left running over a weekend costs you nothing incremental, because the hardware was already paid for. In cloud, that same weekend has a price, and it is charged whether or not a single request arrives.

This is what the FinOps Foundation means by its principle to take advantage of the variable cost model. The word take is doing real work there. Variability is not automatically a benefit. It is an option, and an option only pays out if you exercise it. An organisation that lifts and shifts a fleet of always on servers into cloud has adopted the OpEx cost model without adopting any of the elasticity that justifies it, and will end up paying rental rates for a fixed footprint. That is the most expensive possible combination and it is extremely common.

The flip side is the part people underestimate. Because capacity is no longer a constraint you plan around, the natural ceiling on spend disappears. In a data centre, running out of rack space is a hard stop that forces a conversation. In cloud there is no hard stop. There is only a bill that arrives afterwards.

Who actually spends the money?

This is the structural change that matters most, and it has nothing to do with technology. In the data centre model, spending authority sat with a handful of named people. A purchase required a business case, an approval chain, and a signature. The number of humans who could commit the company to an infrastructure cost was small enough to fit in a meeting room.

In cloud, anyone with deploy permissions can commit the company to a recurring cost, and they do it through a mechanism that was deliberately designed to remove friction. That is not a flaw. Removing that friction is most of why cloud made engineering faster. But it means the population of people making spend decisions grew from perhaps five to perhaps five hundred, and not one of those five hundred was given a budget, a price list, or any training in reading one.

Follow the consequences and you arrive at the whole discipline. If spending is decentralised, then accountability has to be decentralised too, which is exactly the FinOps principle that everyone takes ownership for their technology usage. If five hundred people are making cost relevant decisions, a monthly report to one finance business partner is structurally incapable of changing anything, which is why the framework insists that cost data be accessible and timely rather than merely accurate.

The uncomfortable implication for anyone new to this work: you cannot fix cloud cost by getting better at analysis. The analysis was never the bottleneck. The bottleneck is that the person who can act on the finding did not make the finding and may not know it exists.

flowchart LR
  A[Engineer merges a change] --> B[Resource provisioned in minutes]
  B --> C[Meter starts, billed hourly]
  C --> D[Line item appears in billing data]
  D --> E[Aggregated into monthly close]
  E --> F[Finance spots variance]
  F --> G[Investigation traces it back]
  G --> A

The same server at five different prices

Here is a property of cloud pricing with no real equivalent in traditional procurement. Two teams can run byte for byte identical infrastructure, in the same region, in the same account, and pay wildly different amounts, because the price is not attached to the hardware. It is attached to the commercial arrangement you happened to make.

Take an m7i.large in us-east-1. The published On-Demand rate is 0.1008 dollars per hour, which is about 73.58 dollars for a 730 hour month. AWS publishes a maximum discount of up to 72 percent for EC2 Instance Savings Plans, up to 66 percent for the more flexible Compute Savings Plans, and up to 90 percent for Spot capacity that can be interrupted. Same silicon, same performance, four commercial outcomes with roughly a tenfold spread between the top and the bottom.

Treat those percentages as ceilings, not forecasts. Published maximums assume the longest term and the most restrictive commitment, and real blended rates land well short of them. I plan against a one year commitment as a working assumption and treat anything better as upside, because a three year commitment on infrastructure whose shape you cannot predict is a bet, not a saving.

The reason this matters so early in the series is that it forces a decomposition. Your bill is always quantity multiplied by rate. If your spend went up 20 percent, that is not yet a finding. It is a question with two possible answers that lead to entirely different rooms: engineering, if quantity moved, or procurement and leadership, if rate moved. Every cost conversation should begin by separating those two, and most bad cost conversations begin by failing to.

On-Demand rate from the AWS EC2 On-Demand pricing page, July 2026, 730 hour month. Discount ceilings are AWS published maximums across all eligible instance types and terms, not the rate you should expect for this specific instance. Parts 11, 12 and 13 cover rightsizing, commitments and Spot in detail.

Cost is a property of your architecture

In the data centre, architecture and cost were only loosely coupled. A chattier design might need a slightly bigger switch eventually, but the relationship was indirect and slow. In cloud the coupling is direct and immediate, because almost every architectural primitive has a meter attached to it.

Choosing to split a service across availability zones creates inter zone traffic charges. Choosing a chatty synchronous protocol over a batched asynchronous one multiplies request counts on a per request billed service. Choosing to log at debug level in production multiplies ingestion and retention costs on your observability platform, which in my experience is the single most common accidental six figure line item in a mid size estate. None of these are mistakes in the engineering sense. They are trade offs that were made without one of the axes visible.

Once you accept that cost is architectural, the intervention point moves. Reviewing spend after the fact is remediation, and remediation is always more expensive than design, because by then there is running production traffic and a change freeze and someone who does not want to touch it. The cheap moment to influence a cost is in the design review, before anything is deployed.

This is also why FinOps cannot live purely inside a reporting function. A reporting function sees costs after they exist. Influencing architecture requires being in the room before they do, which is a relationship and credibility problem long before it is a data problem.

Data has gravity and a price tag

Movement is the cost dimension that catches out almost everyone coming from on premises, because in a data centre you own the network and moving a terabyte between two racks costs nothing incremental. In cloud, data movement is metered, and the meter is expensive relative to storage.

AWS gives every account 100 GB per month of data transfer out to the internet at no charge, aggregated across services and regions, and then charges 0.09 dollars per GB for the first 10 TB, tapering down through published tiers to 0.05 dollars per GB above 150 TB. Set that against storage: S3 Standard in us-east-1 is 0.023 dollars per GB-month, and S3 Glacier Deep Archive is 0.00099 dollars per GB-month.

Do the comparison slowly, because it reframes a lot of decisions. Sending a gigabyte out to the internet once costs roughly four times what storing that gigabyte costs for an entire month. Against Deep Archive it is about ninety times. Storage is nearly free and motion is not, which is the actual economic meaning of the phrase data gravity. It is not a metaphor about inertia, it is a line item.

The practical consequences follow directly. Compute belongs next to the data it processes rather than the data being shipped to the compute. Analytics that repeatedly pulls the same dataset across a boundary should cache it on the far side. And a multi region or multi cloud design that looks elegant on a whiteboard can carry a transfer bill that dwarfs the compute it was meant to protect. Part 14 covers storage and transfer costs properly.

US East, N. Virginia, July 2026. Tiers are calculated on aggregate monthly transfer out across eligible services. Other regions differ, for example Asia Pacific Singapore starts higher. Cost of 1 TB uses 1024 GB.

Billing granularity and reporting lag

Cloud billing data is simultaneously the most detailed financial dataset most organisations have ever held and one of the hardest to use. The AWS Cost and Usage Report can be delivered at hourly granularity down to individual resources, with something like 125 columns in the CUR 2.0 schema covering cost, usage, rates, product attributes and your own tags. There is no data centre equivalent of that. There is also no data centre equivalent of the problem it creates.

A mid size estate produces tens of millions of line items a month. That is a data engineering workload, not a spreadsheet, and treating it as a spreadsheet is why so many first attempts at cost reporting quietly die after a quarter. The report is not the hard part. Keeping it accurate as the estate changes underneath it is the hard part.

Then there is lag. Usage records take time to land, get revised as credits and commitment allocations are applied, and only settle at month end close. So the data has hourly resolution but is not yet trustworthy at hourly recency, and those two properties get confused constantly. The practical rule I use: yesterday is directional and useful for spotting a spike, and last month is authoritative and the only thing worth putting in front of finance.

Understanding that distinction saves you from the two opposite failures. Reporting unsettled data to finance destroys your credibility the first time a number changes after you presented it. Waiting for settled data before telling an engineer about a spike wastes three weeks of burn. Different audiences, different freshness requirements, same underlying dataset.

Growth changes the question

One last difference, and it is the one that determines whether your cost practice survives a good year. In the data centre model, infrastructure cost was largely decoupled from business volume in the short run, because capacity was already bought. Doubling your customers did not double your infrastructure invoice this month. In cloud it very often does, because consumption tracks demand almost immediately.

This makes total spend a genuinely misleading metric for a growing company. If revenue grew 60 percent and cloud spend grew 45 percent, the bill went up and efficiency improved. A report that shows only the first of those numbers will produce exactly the wrong reaction in the room, and it will produce it every single quarter.

The fix is to express cost against a business denominator: cost per active customer, per order, per gigabyte processed, per model inference. That is unit economics, and it is the only framing in which a cost function can report honestly during growth without appearing to fail. Part 10 covers it in full, but it is worth knowing now, because the tagging and allocation work you are about to do in Part 5 is what makes it possible later.

flowchart TD
  A{The bill moved. What changed} -->|Quantity| B{Was the extra usage wanted}
  A -->|Rate| C{Did a commitment lapse or expire}
  B -->|Yes, demand grew| D[Report unit cost, not total spend]
  B -->|No| E[Engineering owns this, rightsize or schedule]
  C -->|Yes| F[Renew coverage, centrally owned]
  C -->|No| G[Check region, tier or service mix shift]

Separate rate from usage in every report you build

The recommendation from this part is narrow and specific. Whatever cost reporting you build, build it so that quantity and rate are visible as separate numbers, from the first version. Not as an advanced view you add later. In the first version.

The reason is that this one decomposition maps directly onto your organisation. Quantity is engineering, and it is where the decentralised decision making from earlier in this part actually lives. Rate is central, procurement and leadership, and it moves on a different timescale with different people in the room. A report that shows only blended total cost forces every conversation to start with an investigation, and investigations are where cost programmes lose their momentum. A report that shows the split routes the conversation to the right owner immediately.

It costs almost nothing to do at the start and it is painful to retrofit, because retrofitting it means reprocessing history and re educating an audience that has already learned to read your existing report. Do it now while nobody has an opinion about your dashboard yet.

Next in this series is the FinOps Framework in detail, the principles, the personas, and how the Inform, Optimize and Operate phases actually run as a repeating cycle rather than a project plan. It builds directly on the cost model described here. The full sequence lives on the Cloud FinOps guide.

Before the next part, open your cost tool and answer one question about last month: how much of the change was quantity and how much was rate. If your tooling cannot tell you, that is your first piece of work.

References

• FinOps Principles, FinOps Foundation
• Amazon EC2 On-Demand Instance Pricing, AWS
• Compute and EC2 Instance Savings Plans Pricing, AWS
• Amazon S3 Pricing, AWS
• What are AWS Cost and Usage Reports, AWS Documentation

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts