The conflict is structural, not procedural
Public procurement is built for a defined scope at a defined price. Cloud consumption is variable by design, and that variability is what makes the business case work.
Azure · Public Sector
Cloud economics in the public sector
Public cloud programmes fail at procurement and governance far more often than at technical migration. This paper examines why and proposes a procurement approach that survives review.
Abstract
Cloud economics in the public sector
Summary
An agency plans a cloud migration carefully, selects sensibly, and then spends four months in a procurement process nobody anticipated because the requirement was written as though buying software.
This paper examines the structural conflict between consumption-based pricing and a procurement model designed for capital purchase, and proposes a way of specifying cloud that a procurement officer can evaluate, a finance officer can budget against, and an elected member can scrutinise — without pretending the cost is fixed.
Key findings
Four things this paper argues
If you read nothing else, read these. The analysis that follows sets out the evidence for each.
Specifying a ceiling with governance beats estimating a total
An estimate presented as a commitment will be exceeded and will become a governance failure. A ceiling with a documented approval path above it will not.
Cost attribution is an accountability problem before it is a technical one
Spend nobody owns is spend nobody reduces. Tagging enforced at creation is the mechanism, and it is trivial before workloads land and a project afterwards.
The questions members ask are answerable, but only by design
Where is the data, who can reach it, how do we know we are not overpaying, what is the exit route. Each is architectural and each is expensive to retrofit.
Analysis
The argument in full
Why the models conflict
A capital procurement asks what you are buying, from whom, for how much, over what period. Every one of those questions has a stable answer for a server and an unstable answer for a cloud estate.
The instinct is to resolve the tension by producing an estimate and treating it as a commitment. This fails in both directions: if consumption comes in under the estimate the agency has over-procured, and if it comes in over, a routine technical outcome becomes a governance incident.
The alternative is to specify the shape of the spend rather than its total — a committed band, a ceiling, and a documented path for approving above it. This is harder to write and considerably easier to defend.
What to put in the requirement
Cost reporting and optimisation reviews should be contractual deliverables rather than goodwill. Exit provisions should cover the extraction format, the timescale and the cost, because that is the question elected members ask most reliably and the one least often answered before contract.
Residency should be specified per workload rather than organization-wide. A blanket statement produces either over-restriction — ruling out services you could have used — or an assurance that turns out not to hold for a specific data type.
- A committed consumption band with a defined ceiling and an approval path above it
- Cost attribution and monthly reporting as contractual deliverables with a named recipient
- Optimisation reviews at defined intervals with expected outcomes stated
- Exit provisions covering data extraction format, timescale and cost
- Knowledge transfer specified with acceptance criteria, not described as a principle
Governance as the enabling condition
The landing zone work — management groups, policy, tagging, network design — costs very little before workloads arrive and is genuinely disruptive to retrofit onto a live estate.
The specific control that carries the most weight is tagging enforced by policy at creation. Untagged resources cannot be attributed, unattributed spend has no owner, and spend with no owner does not reduce. Every agency that has reported a durable reduction in cloud cost to us had done this first.
The second is region restriction enforced by policy rather than stated in a document. A written residency position without a technical control is a statement of intent, and it will be tested.
Framework
Something you can apply without us
Every paper in this series ends with a framework you can run internally. We would rather you used it and reached your own conclusion than took ours on trust.
Framework
Specifying cloud for public procurement
Five elements. Together they produce a requirement that is evaluable, budgetable and defensible.
1
Band
A committed consumption range with a ceiling, rather than a single estimate presented as a total.
2
Attribute
Tagging enforced by policy so every pound is attributable to a workload and a named owner.
3
Report
Cost reporting and optimisation reviews as contractual deliverables with defined cadence.
4
Constrain
Region and service restrictions enforced by policy, matching a per-workload residency position.
5
Exit
Extraction format, timescale, cost and knowledge transfer, with acceptance criteria.
Implications
What this means, depending on your seat
The same argument lands differently across an executive team. These are the three versions worth separating.
References
Where to check this for yourself
Microsoft's own documentation for the product behaviour described above. We would rather you verified the basis than accepted our summary of it.
01
Azure landing zones
02
Azure Policy overview
03
Tag resources, resource groups and subscriptions
04
Azure Cost Management and Billing
05
Data residency in Azure
On these references: each entry names a Microsoft Learn article or documentation area by title, because deep links change while titles are stable. Searching the title on learn.microsoft.com will reach the current version. Where we have cited a figure or a product behaviour, it is Microsoft's statement rather than ours; where we have given a number of our own it is labelled as such in the text.
Recognise the situation?
We will help you write the technical requirement and the governance schedule in language that survives procurement review, before you go to market rather than after a process has stalled.
Discuss this paper Run the related checklist We reply to every message within one business day.
Keep reading
Related papers
The cost of keeping everything
Most agencies have a documented retention schedule and delete nothing. The bill arrives with the next records request.
May 10, 2026 · 13 pages · 14 min readRead
Third-party risk in public supply chains
Public sector organizations work with many suppliers, and each one that reaches your systems extends the attack surface into an organization whose security you do not control.
February 15, 2026 · 13 pages · 14 min readRead