A cloud bill is denominated in dollars and paid from a budget denominated in pesos, which makes the local cost of an unchanged workload move every month. That is not a cloud problem and it is the reason cloud budgets in the region overrun without anyone using more.
Below: the two variables that move independently, which costs are actually controllable, the commitments question under currency risk, and how to make the number predictable.
Cost conversations about the cloud usually start with optimisation — idle resources, oversized instances, storage nobody deleted. Those are real and they are the second problem.
The first is that for an organisation in Colombia or Mexico, the bill has two independent variables, and only one of them is inside the engineering team's control.
Two variables, moving independently
Usage moves with what the business does — more customers, more data, a new environment. Exchange rate moves with things that have nothing to do with the organisation at all.
A month where the local bill rose fifteen per cent can be a month where consumption fell. Without separating the two, the conversation that follows is an engineering investigation into something engineering did not cause.
The separation is trivial to produce and rarely produced: report consumption in dollars, report the local cost, and report the rate used. Three numbers where there is usually one, and it converts an argument into a fact.
What is actually controllable
A useful split is into three groups. Costs that scale directly with usage — compute hours, requests, data processed — which move when the business moves and are the honest cost of doing the work.
Costs that accumulate rather than scale: storage that grows because nothing is ever deleted, snapshots retained indefinitely, logs kept at full fidelity for years. These rise without any business change and they are the largest source of quiet growth.
And costs that are pure waste — environments running outside working hours, resources allocated for a test in 2023, capacity sized for a peak that was estimated rather than measured. This group is the one that responds fastest to attention, and it regenerates unless something structural prevents it.
The commitment question under currency risk
Providers offer meaningful discounts for one- or three-year commitments, and the arithmetic is straightforward in dollars. It is less straightforward when the revenue funding it is in pesos.
A three-year commitment is a three-year currency exposure on a fixed obligation. It can be the right decision — it converts a variable cost into a known one, which has its own value — but it should be made with that stated, not as a purely technical optimisation.
The pragmatic middle most organisations land on is to commit only to the baseline that will exist regardless, and leave everything above it on demand. That captures most of the discount while keeping the exposure proportional to the part of the workload that is genuinely stable.
Where the growth comes from
Almost never from the workload that was migrated. It comes from what accumulated afterwards: environments created for a project and never removed, data retained because nobody was willing to decide it could go, services adopted because they were easy to enable.
That last one deserves particular attention. The property that makes cloud attractive — anyone authorised can create anything in minutes — is the same property that makes cost growth structural rather than occasional.
Which is why the control that works is attribution rather than restriction. When every resource carries an owner and every owner sees their own number monthly, the growth slows without anyone having to approve requests.
Comparing against what it replaced
The comparison that gets made is cloud bill against previous server budget, and it is almost always unfair in both directions. The old figure usually excluded the data centre space, the power, the refresh cycle and the fraction of several people's time; the new one includes everything.
It also compares different things. On premises, capacity was bought for a peak and idle the rest of the time — the cost was paid whether or not it was used. In the cloud the same peak capacity costs money only while it exists, which is a saving that never appears if the environment is left running.
Making the comparison honestly requires assembling the full previous cost once, including the parts that sat in other budget lines. It is worth doing, because the alternative is an annual conversation in which the cloud is assumed to have been more expensive and nobody has the figures to say otherwise.
Making the number predictable
Predictability is usually worth more to a finance team than a lower average, and it is achievable without reducing capability: a committed baseline, an agreed rate assumption for the budget, and a variance report that separates usage from currency.
Budget alerts should be set against the local figure, since that is what runs out, but investigated against the dollar figure, since that is what engineering can act on. Conflating the two produces alerts nobody can respond to.
And the rate assumption belongs in the budget document explicitly. A cloud budget built at one rate and reviewed at another has a variance that is nobody's fault, and saying so in advance is considerably easier than explaining it afterwards.
The optimisation that is worth doing first
Before any architectural work: switch off what is not being used outside working hours, apply a retention rule to logs and snapshots, and delete the environments whose project ended.
These three typically recover a meaningful share of the bill in days, require no design change, and carry almost no risk. They are unglamorous enough that they are frequently skipped in favour of a re-architecture that will take two quarters.
Only after those are done is it worth examining instance sizing, storage tiers and service choices — where the savings are real but require analysis, and where a wrong move affects performance rather than just cost.
Who should own it
Cost management fails when it belongs to finance alone, because finance can see the number and cannot change it, and equally when it belongs to engineering alone, because engineering can change it and is not accountable for the budget.
The arrangement that works gives each team its own attributed number and a monthly review where both are present. It requires the tagging discipline decided at the start — which is why cost attribution belongs in the landing zone rather than being added once the bill becomes a problem.
Retrofitting attribution across an estate that never had it is a project in itself, and the organisations that avoid it are the ones that made a five-minute decision two years earlier.
Where to start
With a bill split three ways — scaling costs, accumulating costs, waste — and a variance report that separates usage from exchange rate. Both are available from what the provider already gives you, and neither requires a cost management tool to produce.
A cloud readiness assessment covers cost attribution alongside architecture and governance, so a cloud plan accounts for what the estate will cost in local currency rather than what the migration quote said.
Frequently asked questions
Why does a cloud bill grow without more usage?
Two reasons: the exchange rate moves against a dollar-denominated bill paid from a peso budget, and costs that accumulate rather than scale — storage, snapshots and logs nobody deletes.
How should cloud cost be reported?
Consumption in dollars, cost in local currency, and the rate used. Three numbers instead of one, which separates an engineering question from a currency one.
Are long-term commitments worth it?
They can be, but a three-year commitment is also a three-year currency exposure. Committing only to the baseline that will exist regardless captures most of the discount with proportional exposure.
What should be optimised first?
Switching off what is unused outside working hours, applying retention to logs and snapshots, and deleting finished projects' environments. Days of work, no design change, almost no risk.
Where does cost growth actually come from?
Rarely the migrated workload — from environments never removed, data nobody decided to delete, and services enabled because enabling them was easy.
Who should own cloud cost?
Neither finance nor engineering alone. Each team gets an attributed number and both attend a monthly review, which requires the tagging decided in the landing zone.
