Topic 6.5 — Technology Cost Management & Cloud FinOps

In health and care, the running cost of technology is public money spent every hour whether anyone is watching or not, so managing that cost — especially in the cloud — is an operational discipline of stewardship, not an annual finance exercise.

Why this matters in health and care#

For most of the history of NHS technology, the money was spent once. You bought a server, a storage array or a licence, capitalized it, and it sat in a rack depreciating quietly for five years. The cost was visible, bounded and largely fixed. Cloud computing broke that model. Now the meter runs continuously, the bill changes daily, thousands of small decisions by engineers move real money, and the invoice arrives a month after the spending is already done. A misconfigured job left running over a bank-holiday weekend, a test environment nobody switched off, a storage bucket that quietly grows — each is public money leaking in real time.

This matters in health and care for three reasons beyond ordinary thrift. First, it is public money held in trust: every pound spent on idle compute or a duplicated software licence is a pound not spent on care, and you are accountable for it to auditors, to your board and ultimately to the public (see Topic 6.4 — Governance & Assurance). Second, the money follows peculiar rules. NHS budgets split hard between capital and revenue, and the shift from buying assets to renting services quietly converts one into the other — a technical decision with a budgetary consequence that can blindside a finance director. Third, unmanaged cost is a safety and continuity risk in disguise: teams that fear a surprise bill under-provision resilience, delay patches, or cannot afford to run the environments a safe service needs.

The failure mode is distinctive and common. Organizations move to the cloud expecting savings, celebrate the migration, and then eighteen months later discover the bill is larger than the data centre it replaced — and no one can say why. The problem is rarely the technology. It is that no one owns the running cost as a live discipline: engineers optimize for delivery speed, finance sees a single opaque invoice, and the feedback loop between a design decision and its cost never closes. This topic is about closing that loop.

Core concepts#

Cloud computing delivers computing resources — servers, storage, databases, networking — as an on-demand, metered service rather than as owned equipment. Its defining commercial feature is elasticity: you can acquire and release capacity in minutes and pay only for what you consume. That same elasticity is why cost management is hard. The technical architecture of cloud and legacy is covered in Topic 4.0 (see Topic 4.0 — Technical Architecture, Cloud & Legacy); this topic owns what happens to the cost once that architecture is running.

The central accounting shift is from capital expenditure (capex) — money spent to acquire a fixed asset that is then depreciated over years — to operating expense (opex), an ongoing cost of running a service. Buying a server is capex; renting the equivalent cloud capacity is opex. In the NHS this is not a neutral bookkeeping detail: capital and revenue are separately allocated, separately controlled, and rarely fungible, so moving spend from capex to opex can relieve one pressure while creating another. The up-front appraisal of these choices — the Five Case Model, capital versus revenue basics — belongs to financial management and business cases (see Topic 6.0 — Financial Management & Business Cases); this topic picks up where the business case ends and the meter starts.

FinOps — a contraction of "cloud financial operations" — is the operating discipline that brings engineering, finance and business teams together to manage cloud cost as a shared, data-driven responsibility. Promoted by the FinOps Foundation (part of the Linux Foundation), it is usually described as a lifecycle with three iterative phases: Inform (give everyone visibility of what is being spent and why, through allocation and reporting), Optimize (act on that visibility to eliminate waste and buy more cheaply), and Operate (embed cost awareness into everyday ways of working and governance). FinOps is deliberately not just cost-cutting; its goal is to maximize the business value of every pound of cloud spend, which sometimes means spending more because the return justifies it.

Two allocation mechanisms make cost visible. Showback reports to each team or service what its technology consumption costs, for transparency and behaviour change, without moving money. Chargeback goes further and actually recovers the cost from the consuming unit's budget — a form of internal cost allocation that assigns shared-service costs to the cost centre that consumes them. Both depend on tagging: labelling every cloud resource with metadata (service, team, environment, patient-facing or not) so that an undifferentiated invoice can be split into meaningful lines.

Three more ideas run through the topic. Total cost of ownership (TCO) is the full direct and indirect cost of a technology over its whole life — not just the licence or the compute, but the people, integration, support, exit and decommissioning around it. Software asset management (SAM) is the discipline of tracking and optimizing the software an organization owns and rents, increasingly dominated by software-as-a-service (SaaS) subscriptions and per-user software licences that renew silently. And unit economics expresses cost as a rate against something the organization cares about — cost per patient, per appointment, per referral, per API call — so that a rising bill can be judged against rising value rather than in a vacuum. Autoscaling, the automatic adjustment of capacity to match load, and the broader financial-management practices of ITIL sit alongside these as the operational levers.

Best practices#

1. Make cost visible before you try to cut it — Inform first. You cannot manage what no one can see, and the default cloud invoice is a single opaque number arriving a month late. Establish near-real-time cost visibility broken down by service, team, environment and, where you can, by clinical service, so that the people making design decisions can see the cost of those decisions within days, not quarters. Visibility alone changes behaviour: teams that can see their own spend routinely find waste no central finance report would ever have caught.

2. Tag everything, and treat untagged spend as a defect. Cost allocation is only as good as the metadata underneath it; an untagged resource is money you cannot attribute, question or reclaim. Agree a mandatory tagging standard — owner, service, environment, cost centre, data classification — enforce it through automated policy so non-compliant resources are flagged or blocked at creation, and report the proportion of spend that is properly allocated as a headline metric. In a health context, tagging whether a workload is patient-facing or clinical-critical also lets you protect the right things when you optimize the rest.

3. Choose showback or chargeback deliberately, and match it to your accountability. Showback builds cost awareness gently and is the right starting point for most organizations; chargeback creates real budgetary consequence but needs mature allocation and the political will to defend the numbers. Decide which behaviour you are trying to create — awareness, or genuine financial ownership — and be honest that premature chargeback with shaky data will generate disputes that discredit the whole effort. Whichever you choose, the aim is a closed loop where a team's decisions visibly affect a budget it recognizes as its own.

4. Eliminate waste relentlessly: rightsize, schedule and delete. A large share of cloud spend in most estates is pure waste — over-provisioned instances, oversized databases, orphaned storage, and non-production environments running twenty-four hours a day for a nine-to-five team. Rightsize resources to observed load rather than guessed peak, schedule development and test environments to switch off overnight and at weekends, and put a lifecycle on storage and snapshots so nothing accumulates forever. This is the fastest, lowest-risk saving available and it recurs every month once automated.

5. Buy committed capacity for your predictable baseline. Cloud providers discount heavily — often substantially — in exchange for a one- or three-year commitment through reserved instances, savings plans or committed-use agreements, and the steady baseline of a health service (the core electronic patient record, the always-on integration engine) is exactly the predictable load these instruments reward. Analyse your stable usage, commit to it to capture the discount, and keep on-demand or autoscaled capacity for the variable peak on top. Review commitments regularly so you do not lock in capacity you have since re-architected away, and coordinate purchases with procurement and commercial colleagues (see Topic 6.3 — Procurement & Commercial).

6. Manage SaaS and licence sprawl as deliberately as cloud compute. The cloud bill is visible; the twenty SaaS subscriptions bought on departmental cards, the per-seat licences assigned to leavers, and the overlapping tools that do the same job are not — yet together they often rival the infrastructure spend. Maintain a live register of software subscriptions and entitlements, reconcile licences against actual named users and usage, cancel or downgrade what is unused, and consolidate duplicated tools. Software asset management here is both a cost discipline and a security one, because unknown SaaS is also unmanaged data flow (see Topic 1.7 — Information Governance, Data Protection & Cyber Security).

7. Judge cost by unit economics, not by the size of the bill. A rising bill is not automatically bad and a falling one is not automatically good; what matters is cost relative to value delivered. Define unit-cost metrics that make sense clinically and operationally — cost per patient monitored, per appointment booked, per referral processed, per thousand API calls — and track them over time so you can tell efficiency from mere growth and defend spend that is genuinely earning its keep (see Topic 6.2 — Benefits Realization & Value Management, and Topic 10.1 — KPIs). Unit economics is also how you connect running cost back to the health-economic case for the service (see Topic 6.1 — Health Economics).

8. Think in total cost of ownership across the whole estate, including exit. The sticker price of a platform is a fraction of its lifetime cost; integration, data migration, support staff, training, egress charges and the eventual cost of leaving all belong in the picture. Assess options on total cost of ownership over a realistic life, be especially wary of data-egress fees and proprietary services that raise the cost of exit, and remember that lock-in is a future cost even when it looks free today (procurement owns the contractual side of lock-in — see Topic 6.3 — Procurement & Commercial). A TCO view also stops the organization congratulating itself on a cheap platform that is quietly expensive to run.

9. Embed cost into engineering and governance so it operates continuously. FinOps fails when it is a quarterly clean-up campaign and succeeds when cost is a standing consideration in design reviews, architecture decisions and delivery pipelines (see Topic 3.6 — DevOps & Engineering Excellence). Give teams cost budgets and anomaly alerts, put estimated cost impact into significant architecture decisions, and set automated alerts and hard spending guardrails so a runaway job is caught in hours, not on next month's invoice. The goal of the Operate phase is that cost-consciousness becomes ordinary engineering hygiene rather than an external audit.

10. Balance cost against clinical value and sustainability, not cost alone. The cheapest option is not always the right one: an aggressive saving that removes resilience, delays a patch, or degrades a patient-facing service trades money for risk in the wrong direction. Weigh cost decisions explicitly against clinical value and against carbon, since compute you eliminate as waste is also emissions you avoid — cost and sustainability optimization frequently point the same way (see Topic 8.5 — Sustainability & Net Zero). Make the trade-offs visible and owned rather than letting cost pressure silently erode safety.

Questions to discuss with your team#

1. Who actually owns the running cost of our technology — and does that owner have both the visibility and the authority to change it? This matters because unowned cost is the cost that grows unchecked: engineers optimize for delivery, finance sees one invoice, and no one is accountable for the gap between them. Debate whether cost ownership sits with a central finance team that cannot influence engineering decisions, or with engineers who cannot see the bill, or ideally with a joint capability that spans both. Probe whether the owner can actually act — can they switch off an idle environment, block an untagged resource, or refuse a design that is needlessly expensive — or whether they can only report after the money is spent. Consider the health-specific tension: cost owners must never be able to compromise clinical safety or continuity in the name of saving, so where are those guardrails. A good, honest answer names a specific accountable owner or forum, confirms it has near-real-time visibility and real decision rights, and admits candidly where today the answer is "the bill just arrives and we pay it".

2. How much of our cloud and software spend is genuinely delivering value, and how would we know? Most organizations cannot answer this, because they track the total bill but not the value it buys, so every cost looks equally justified or equally suspect. Discuss whether you have unit-cost metrics that connect spend to something clinical or operational — cost per patient, per appointment, per API call — or whether you only have an undifferentiated number that goes up. Surface the trade-off between cost-cutting and value: the aim is not the smallest bill but the best return, which sometimes means spending more on a service that clearly earns it. Consider how much of your spend is measurable waste — idle environments, over-provisioned instances, licences for leavers — versus genuinely productive load, and be honest about how confident you are in that split. A good answer distinguishes waste from value with evidence, has at least a few real unit-economic metrics, and resists the reflex that a smaller bill is automatically a better one.

3. When we moved (or move) spend from capital to operating expenditure, who understood the budgetary and long-term consequences? The capex-to-opex shift is often treated as a purely technical migration, but it changes which budget the money comes from, converts a one-off cost into a permanent recurring one, and can quietly commit the organization to a rising liability for years. Debate whether your finance and digital teams jointly modelled this before committing — did anyone map the multi-year opex trajectory, the exit costs, and the effect on the capital-versus-revenue balance the NHS controls so tightly. Consider the honesty trap: cloud migrations are frequently sold on savings that assume disciplined cost management which then never materializes, so was your business case predicated on a FinOps capability you actually built. Explore what happens when the recurring bill grows faster than the budget that funds it, and who is accountable when it does. A good answer shows finance and digital reasoning together about the whole lifecycle, not a technical team optimizing for migration speed while finance discovers the consequences later (see Topic 6.0 — Financial Management & Business Cases).

4. How confident are we that a runaway cost would be caught in hours rather than on next month's invoice? The defining hazard of metered cloud is latency between a mistake and its discovery: a misconfigured job, an accidental over-provision, or a test environment left running can burn public money silently for weeks before a monthly bill reveals it. Discuss whether you have anomaly alerts and hard spending guardrails wired to the people who can act, or whether your only detection mechanism is the invoice arriving a month in arrears. Probe the balance between guardrails that genuinely stop waste and controls so aggressive they throttle a legitimate clinical workload at the wrong moment — the alert that cries wolf is soon ignored, and the guardrail that blocks a safe service is worse than the spend it prevents. Consider who receives an anomaly alert at 2am and whether they have both the authority and the confidence to act on it without fearing they will break something patient-facing. A good answer describes a tested detection-and-response loop measured in hours, names who owns it, and is honest about how many past surprises were only found when the bill landed.

5. How much software are we paying for that we cannot see — and who would notice if a subscription renewed for a tool no one uses? The cloud compute bill is at least visible; the sprawl of SaaS subscriptions bought on departmental cards, per-seat licences still assigned to leavers, and overlapping tools doing the same job is not, yet together these often rival the infrastructure spend. Discuss whether you hold a live register of software entitlements reconciled against actual named users, or whether renewals pass through silently because no single person owns the whole picture. Surface the security dimension as well as the cost one: unknown SaaS is also unmanaged data flow, so shadow software is both money leaking and an information-governance gap (see Topic 1.7 — Information Governance, Data Protection & Cyber Security). Consider the organizational reason this happens — devolved budgets and easy card payments make it frictionless to acquire software and nearly impossible to retire it — and what would have to change for someone to be accountable for the total. A good answer admits how much of the estate's software spend is genuinely mapped, distinguishes deliberate tools from accreted sprawl, and can point to a reconciliation that actually cancelled something.

6. When cost pressure and clinical safety pull in opposite directions, how do we make sure safety wins — and can we prove it did? Every optimization lever in this topic — rightsizing, switching things off, deferring spend, buying the cheapest option — can, applied carelessly, remove resilience, delay a patch, or degrade a patient-facing service, trading money for risk in exactly the wrong direction. Debate whether your cost decisions carry an explicit safety check, so that a workload tagged clinical-critical is reviewed separately before any change touches it, or whether cost targets are allowed to erode safety quietly and invisibly. Consider the sustainability angle that usually aligns rather than conflicts: compute eliminated as waste is also carbon avoided, so cost and net-zero optimization frequently point the same way (see Topic 8.5 — Sustainability & Net Zero) — but be honest about the cases where they diverge and something has to give. Explore who holds the line when a savings target and a resilience requirement collide, and whether that trade-off is made visibly and owned or made silently under budget pressure. A good answer shows safety and continuity treated as constraints that cost may not override, with a real mechanism to enforce it, not merely a stated value that bends when the invoice grows.

In practice: a health & care example#

Northmarsh Integrated Care System moved its analytics platform, several patient-facing services and a large data lake to the public cloud over two years, funded by a business case that promised a modest saving against the ageing data centre it replaced. The migration was delivered on time and celebrated. Eighteen months later the monthly cloud invoice was running at nearly double the business-case figure, growing every quarter, and when the finance director asked the digital team to explain the increase, no one could break the number down. The invoice was a single line from the provider, and nothing underneath it was tagged.

The board commissioned a small FinOps initiative rather than a blanket cost-cutting order. Its first job was Inform: the team stood up a cost-visibility tool, mandated a tagging standard, and spent six weeks retro-tagging resources and reconciling them against the services that owned them. The picture that emerged was familiar. The data-science team's development and test environments — large, expensive instances — ran continuously, including nights and weekends when no one used them. The migrated data lake had been lifted and shifted onto premium storage with no lifecycle policy, so five years of superseded snapshots were accumulating at full price. Three separate teams were paying for overlapping SaaS analytics tools bought on different budgets. And a batch job misconfigured during migration had been re-processing the same dataset nightly for months.

The Optimize phase was deliberately staged by risk. Non-production environments were scheduled to switch off outside working hours, saving a large recurring sum with no clinical impact whatsoever. Storage was tiered and given a lifecycle so old snapshots aged out automatically. The steady baseline load of the always-on patient-facing services was analysed and covered with a three-year committed-use discount, negotiated with procurement colleagues. The duplicated SaaS tools were consolidated to one. Crucially, before any change touched a patient-facing or clinical-critical workload, its tag flagged it for a separate, cautious review — cost was never allowed to override safety or resilience.

Then came Operate, which mattered most. Each service team was given a monthly showback report and a cost budget, anomaly alerts were wired to flag any sudden jump within hours, and a lightweight cost check was added to the architecture-review checklist so new designs carried an estimated running cost. Within two quarters the bill had fallen back below the original data-centre baseline and, more importantly, it had stopped being a mystery — every pound was attributable to a service, and the ICS could now report cost per active user of its analytics platform and defend it as value. The saving was real, but the durable win was the closed loop: decisions now had visible, owned financial consequences.

Sector lenses#

Startup#

For a digital-health startup, cloud cost is survival maths: it is often the single largest infrastructure line, and burn rate directly determines runway. The founding advantage is that FinOps discipline can be built in from the first commit — tagging from day one, cost dashboards every engineer sees, and unit economics (cost to serve one patient or one customer) tracked as a core business metric that investors will scrutinize. The risk is over-optimizing too early, spending scarce engineering time shaving pennies off a bill that is still tiny, or locking into long commitments before the architecture has stabilized. The discipline that scales is cultural: treat cost as a product metric, not a finance afterthought, so that when the startup wins an NHS contract its cost-to-serve is already known and defensible.

Small business#

An established small provider — a GP practice, a community pharmacy, a care home, a single-site clinic or a small health-tech supplier — pays the same metered cloud and SaaS bills as a large trust but has no dedicated FinOps or IT capability to manage them, so the practical priority is a handful of high-leverage habits rather than a full discipline. The realistic wins are eliminating obvious waste (switching off what is not used, deleting old storage), keeping a simple list of every subscription and licence with its renewal date so nothing renews unnoticed, and being wary of long commitments or lock-in that a small organization cannot easily unwind. Cost visibility usually means a monthly look at the provider console rather than a real-time dashboard, and much of the estate may be SaaS chosen for someone else to run, which shifts the discipline from tuning infrastructure to managing subscriptions and reading contracts. The unavoidable tension is that the same information-governance and continuity duties apply as to a big organization, but with tight cash and thin staffing the temptation to defer a patch or drop resilience to save money is real — so even here, a clear rule that safety is not traded for cost matters, ideally supported by shared or framework buying so the small provider is not negotiating cloud and licence prices alone (see Topic 4.1 — Platforms & Shared Services).

Enterprise#

A large NHS trust or ICS runs a sprawling estate — legacy data centres, multiple cloud accounts, hundreds of SaaS subscriptions bought across dozens of budgets — and its challenge is coordination and allocation at scale. The realistic goal is a central FinOps capability that gives federated teams visibility and guardrails without becoming a bottleneck: a common tagging standard, showback to every service, committed-use purchasing negotiated centrally, and cost embedded in architecture governance. The hardest problem is usually organizational, not technical — getting engineering and finance, who speak different languages and report to different directors, to share one view of the truth. At this scale the biggest wins come from a few estate-wide disciplines applied consistently (tagging, waste elimination, committed-use, SaaS rationalization) rather than heroic optimization of any single service, and cost work must be explicitly bounded so it never erodes clinical safety or continuity.

Government#

A national body — NHS England, a devolved health department, a shared-services organization — shapes the cost environment every provider operates in. Its leverage is aggregation: negotiating national cloud and licensing agreements so individual trusts are not each bargaining from a weak position, publishing FinOps and TCO guidance so good practice is the default, and building shared platforms whose unit cost falls as more organizations use them (see Topic 4.1 — Platforms & Shared Services). Government also owns the capital-versus-revenue rules that make the capex-to-opex shift so consequential, and it can ease or worsen that friction through how it allocates and flexes budgets. Its accountability is to Parliament and the public for value for money across the whole system, so it carries a duty to make cost transparent and comparable between organizations, and to ensure cost pressure does not quietly widen inequities in the services patients receive.

Common failure modes#

• The mystery invoice. A single opaque bill arrives monthly, no one can break it down, and by the time it is questioned the money is long spent. Fix it with tagging and near-real-time visibility before anything else.
• Lift-and-shift then act surprised. Migrating servers to the cloud unchanged, keeping them running at full size around the clock, and expecting cloud economics to appear by magic. Cloud saves money only when you use its elasticity — rightsize, schedule and scale.
• Cost-cutting instead of cost management. A one-off panic cull that saves money for a quarter, damages resilience, and quietly grows back because nothing changed the underlying behaviour. FinOps is a continuous loop, not a campaign.
• Optimizing away safety. Switching off redundancy, delaying patches, or under-provisioning a clinical service to hit a cost target. Cost decisions must be explicitly weighed against clinical value and never override it.
• SaaS in the shadows. Dozens of subscriptions on departmental cards, licences still assigned to people who left, and three tools doing one job — invisible because they are not on the cloud bill. Keep a live software register and reconcile it.
• Premature chargeback. Recovering costs from teams using immature, disputed allocation data, generating arguments that discredit the whole effort. Start with showback; earn the data quality before you move money.
• Committing blind. Buying three-year reservations for capacity you re-architect away six months later, or never buying commitments for a stable baseline and paying full on-demand rates forever. Match commitment to genuinely predictable load and review it.

Maturity model#

Checklist#

• Cloud and technology spend is visible near-real-time, broken down by service and team, to the people who make design decisions.
• A mandatory tagging standard is enforced automatically, and the proportion of properly allocated spend is a tracked metric.
• Showback (or, where mature, chargeback) gives each service a recognizable view of what its technology consumes.
• Non-production environments are scheduled off outside working hours; resources are rightsized to observed load; storage has a lifecycle.
• The predictable baseline is covered by committed-use or reserved-capacity discounts, reviewed regularly.
• A live software-asset register reconciles SaaS subscriptions and licences against actual users and usage.
• Unit-cost metrics (cost per patient, appointment, referral, API call) are defined and tracked against value.
• Options are appraised on total cost of ownership over a realistic life, including egress and exit costs.
• Cost impact is a standing item in architecture reviews, and automated guardrails and anomaly alerts catch runaway spend within hours.
• Cost decisions affecting patient-facing or clinical-critical workloads are reviewed separately and never override safety, resilience or sustainability.
• Finance and digital jointly model the capex-to-opex trajectory, including the multi-year recurring liability, before major commitments.

Key sources#

• FinOps Foundation — FinOps Framework (Inform / Optimise / Operate lifecycle, principles, capabilities and personas) — the recognised body of knowledge for cloud financial operations.
• HM Treasury — The Green Book (appraisal and evaluation) and public-spending rules on the distinction between capital and revenue (resource) expenditure.
• NHS England — cloud, technology and digital-spend guidance, including cloud adoption and the treatment of capital and revenue in NHS digital investment.
• Cloud providers' well-architected cost-optimisation guidance — AWS Well-Architected Cost Optimization Pillar, Microsoft Azure Well-Architected Framework (Cost Optimization), Google Cloud Architecture Framework (Cost optimization).
• AXELOS / PeopleCert — ITIL 4, IT financial management practice (budgeting, accounting and charging for IT services).
• Technology Business Management (TBM) Council — TBM taxonomy and standards for costing and managing technology spend transparently.

References#

1. Cloud computing — Wikipedia — https://en.wikipedia.org/wiki/Cloud_computing
2. Capital expenditure — Wikipedia — https://en.wikipedia.org/wiki/Capital_expenditure
3. Operating expense — Wikipedia — https://en.wikipedia.org/wiki/Operating_expense
4. Cost allocation — Wikipedia — https://en.wikipedia.org/wiki/Cost_allocation
5. Cost centre — Wikipedia — https://en.wikipedia.org/wiki/Cost_centre_(business)
6. Total cost of ownership — Wikipedia — https://en.wikipedia.org/wiki/Total_cost_of_ownership
7. Software asset management — Wikipedia — https://en.wikipedia.org/wiki/Software_asset_management
8. Software as a service — Wikipedia — https://en.wikipedia.org/wiki/Software_as_a_service
9. Software license — Wikipedia — https://en.wikipedia.org/wiki/Software_license
10. Autoscaling — Wikipedia — https://en.wikipedia.org/wiki/Autoscaling
11. ITIL — Wikipedia — https://en.wikipedia.org/wiki/ITIL
12. Unit cost — Wikipedia — https://en.wikipedia.org/wiki/Unit_cost
13. FinOps Foundation — FinOps Framework — FinOps Foundation (Linux Foundation) — https://www.finops.org/framework/
14. HM Treasury — The Green Book: appraisal and evaluation in central government — GOV.UK — https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-government
15. NHS England — Cloud and technology guidance — NHS England — https://www.england.nhs.uk/
16. Amazon Web Services — Well-Architected Framework: Cost Optimization Pillar — AWS — https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html
17. Microsoft — Azure Well-Architected Framework: Cost Optimization — Microsoft Learn — https://learn.microsoft.com/en-us/azure/well-architected/cost-optimization/
18. Technology Business Management Council — TBM Framework and taxonomy — TBM Council — https://www.tbmcouncil.org/