Summary
Ten years ago, IT spending was straightforward. You bought servers, paid for licenses, budgeted for maintenance. Capital expenditure, predictable costs, clear depreciation schedules.
Cloud computing changed everything. IT spending became operational expense, variable, and tied directly to usage. The model creates genuine flexibility. You can scale resources up or down based on demand without waiting for procurement cycles or making upfront capital investments.
The flexibility creates new problems. Cloud providers profit from confusion, so they have no incentive to simplify pricing.
FinOps emerged because cloud providers profit from pricing complexity.
AWS has over 200 services with pricing models that change based on region, instance type, commitment level, and usage patterns. Azure’s licensing overlaps with on-premises agreements in ways that even Microsoft licensing specialists struggle to untangle. Google Cloud’s pricing documentation runs to thousands of pages.
Opaque pricing prevents comparison shopping, makes it nearly impossible to predict costs accurately, and discourages customers from switching providers. Vendor lock-in through obfuscation.
FinOps emerged as the pragmatic response. If cloud providers won’t simplify pricing, you need processes and expertise to manage it. The alternative is bill shock: unexpectedly high invoices that destroy your forecasts and consume budget you’d allocated elsewhere.
Bill shock has real mechanisms. A developer spins up EC2 instances for testing, forgets to shut them down, and you’re paying thousands per month for servers running nothing. An auto-scaling policy gets misconfigured and your production environment scales to 10x normal capacity overnight, costing tens of thousands before anyone notices. Cross-region data transfer charges accumulate silently because someone configured replication without understanding the pricing model. A Fortune 500 retailer discovered a £220,000 weekly spike from cross-region replication on untagged resources. Troy Hunt, who runs HaveIBeenPwned, got an unexpected $11,000 Azure bill from bandwidth charges he thought were covered by Cloudflare caching. Quincy Larson received a $7,000 AWS bill from EC2 instances left running for months.
Small configuration mistakes compound over time, invisible until the invoice arrives.
What is FinOps?
FinOps (Financial Operations) brings financial accountability to cloud spending. The practice makes cloud costs visible, allocates them to specific teams or projects, and optimises spending based on actual business value. FinOps aligns cloud spending with business objectives through collaboration between finance, IT, and business teams.
FinOps employs several key strategies:
Cost allocation: Assign cloud costs to departments, projects, or products. Without allocation, cloud spending is an undifferentiated line item that nobody feels responsible for.
Usage monitoring: Track what’s actually being used. Cloud environments accumulate waste: forgotten test instances, orphaned storage, resources provisioned for a project that ended months ago.
Rate optimisation: Understand pricing models and negotiate based on your actual usage. Reserved instances, savings plans, and enterprise agreements all offer discounts, but only if you commit accurately.
Resource optimisation: Right-size instances, eliminate idle resources, architect efficiently. The savings here are real but usually smaller than consultants claim.
Governance: Define policies for who can provision what, with approval workflows and spending limits. Policies prevent individual teams from accidentally spinning up resources that cost thousands per month.
Automation: Automate resource provisioning, scaling, and decommissioning. Automation reduces manual errors and enables faster response to usage changes.
These approaches are sensible. But you’re building elaborate infrastructure to manage problems that cloud providers created deliberately. Paying for tools, hiring specialists, dedicating internal resources to solve problems that wouldn’t exist if cloud pricing were transparent.
Cloud pricing isn’t going to become transparent. So FinOps is necessary.
Why Should CFOs Care?
Your responsibilities include financial planning, risk management, and ensuring the organisation doesn’t waste money. Cloud spending sits at the intersection of all three.
The cloud’s variable cost model offers advantages. You can adapt quickly to market changes without significant upfront investment. You gain competitive advantage by scaling faster than competitors tied to traditional IT infrastructure.
The model also introduces risk. Without proper management, cloud spending escalates quickly. “Bill shock” is common: an unexpectedly high invoice that destroys your quarterly forecast.
The risk compounds because cloud spending often falls outside traditional financial controls. IT teams provision resources directly without procurement involvement. Individual developers can spin up services that cost thousands per month. Nobody notices until the bill arrives.
FinOps addresses the problem through:
Effective cost allocation: Assign costs to departments or projects. Make spending visible. Hold teams accountable.
Resource optimisation: Identify waste in your cloud usage. Eliminate it. Right-size what remains. Most organisations waste 30-40% of cloud spending on resources that provide no value.
Improved forecasting: Monitor actual usage and spending patterns. Predict future costs based on real data rather than guesswork. Traditional IT budgeting assumes fixed costs. Cloud requires continuous forecasting.
Better governance: Create frameworks for who can provision what, with approval requirements and spending limits. Reduce the risk of expensive mistakes or unauthorised usage.
Alignment with business value: Optimise cloud investments to drive actual business outcomes. Faster time-to-market, improved customer experience, operational efficiency. Not just spending less, but spending smarter.
Most FinOps tools and consultants profit from the problem they claim to solve. Tool vendors charge based on your cloud spending (typically 2-5% of total costs). They’re incentivised to keep you spending, not to reduce your bill.
Many FinOps consultants are cloud resellers who earn margins on your consumption. They’ll optimise around the edges while encouraging you to adopt more services.
Independent FinOps expertise exists, but you need to verify the business model. How does the consultant make money? Do they want you to reduce costs, or do they profit when you spend more?
The FinOps Lifecycle
The FinOps lifecycle comprises three stages: Inform, Optimise, and Operate. The stages are sequential but continuous. You start with Inform (understand your spending), move to Optimise (identify improvements), then Operate (implement changes). But you never stop. Cloud usage changes constantly, so you cycle back through Inform to track impact, identify new problems, and adjust.
Think of it as a continuous improvement loop, not a one-time project.
Inform
You can’t manage what you can’t measure. The Inform stage focuses on visibility: gathering data on cloud usage and costs.
Set up dashboards, monitoring tools, and reporting mechanisms that provide real-time insights into your spending.
Key activities include: |
|---|
Data aggregation: Collect data from multiple cloud providers and services. Get a complete view of your cloud landscape. Most organisations use multiple clouds (AWS for some workloads, Azure for others, perhaps Google Cloud or Oracle Cloud for specific needs). Fragmented visibility means hidden spending. Cost attribution: Tag resources to specific departments, projects, or business units. Without tagging, you can’t answer basic questions like “How much does our mobile app cost to run?” or “Which product line is driving our cloud spending?” Budgeting and forecasting: Use collected data to establish budgets that align with financial goals. Cloud spending changes monthly. Your forecasting process needs to match that reality. Stakeholder engagement: Ensure all relevant parties can access the data and understand what it means. Finance, IT, and business units need shared visibility. Otherwise, you get conflicting priorities and finger-pointing when spending exceeds budget. |
The Inform stage never ends. Cloud usage changes continuously. Your visibility needs to match.
Optimise
The Optimise stage takes the data from Inform and identifies opportunities for savings or efficiency gains. Not a one-off activity. An ongoing process requiring regular review and adjustment.
Key activities include: |
|---|
Resource assessment: Evaluate utilisation levels of your cloud resources. Identify underused or idle assets. The typical enterprise has hundreds of resources running that nobody uses: test environments someone forgot to shut down, development instances for projects that shipped months ago, databases backing applications that were decommissioned. Contract review: Analyse existing cloud service contracts. Identify opportunities for better rates. Reserved instances and savings plans offer discounts of 30-70% compared to on-demand pricing, but require accurate commitment forecasting. Get it wrong and you’ve locked yourself into paying for capacity you don’t need. Performance tuning: Adjust configurations, scale resources, implement architectural best practices. The goal: improve performance without inflating costs. Sometimes a smaller instance type runs your workload just fine. Sometimes you need to restructure how you’re using services entirely. Cost-benefit analysis: Weigh the financial implications of different optimisation strategies. Some changes save money but require significant engineering time. Others offer quick wins. Prioritise based on return on effort. |
Here’s what consultants won’t tell you: the biggest savings come from architectural decisions, not from turning off idle VMs. Moving from serverless to containers (or vice versa) can change your costs by an order of magnitude. Restructuring how you use storage or databases can save more than years of “waste elimination.”
Examples of architectural decisions that matter:
Serverless vs containers: Coca-Cola migrated from six EC2 instances (costing $13,000 annually) to AWS Lambda for their vending machine payment system. The migration handled higher request volumes at lower cost because their usage pattern (spiky, event-driven) suited serverless pricing. Conversely, Amazon Prime Video migrated their Video Quality Analysis Service from Lambda to containers on ECS, cutting costs by 90%. Their usage pattern (constant, predictable processing) made containers cheaper than paying per invocation. The decision isn’t about which technology is “better.” It’s about matching architecture to your actual usage pattern. Serverless costs scale linearly with requests. Containers cost a fixed amount whether you’re processing one request or a thousand. At low volumes, serverless is cheaper. Above roughly 60-70 requests per second (depending on configuration), containers become more cost-effective.
Storage architecture: Moving infrequently accessed data from standard storage to cold storage tiers can cut storage costs by 80%. Restructuring how you handle backups, implementing lifecycle policies, or changing database configurations can save millions for large datasets. One manufacturing company reduced cloud storage costs by 40% through a comprehensive audit and tier restructuring.
Multi-region strategy: Running workloads in the cheapest available region (price differences can reach 50% for identical instances in different regions). Restructuring data flows to minimise cross-region transfers, which often cost more than the compute itself.
But architectural changes require actual expertise. They’re harder to automate and sell as a repeatable service. So most FinOps tools focus on the easy stuff: “You have 47 unattached EBS volumes costing $12/month each!”
Operate
The Operate stage puts your optimisation plans into action. Implement changes, monitor their impact, iterate as needed. Continuous improvement, where insights from Inform and Optimise get applied in practice.
Key activities include: |
|---|
Policy implementation: Enforce governance policies that guide cloud usage and spending. Who can provision what? What requires approval? What spending limits apply? Automation: Implement automated workflows for resource provisioning, scaling, and decommissioning. Automation reduces manual errors and enables faster response to usage changes. For example: automatically shut down development environments outside business hours, scale production resources based on actual load, decommission resources when projects end. Performance monitoring: Continuously track performance metrics of your cloud services. Ensure they meet established financial and operational goals. The changes you made in Optimise might have unintended consequences you need to catch early. Feedback loops: Establish mechanisms for collecting feedback from stakeholders. Use it to inform future optimisation efforts. Teams need a way to request exceptions to policies, report issues with automated workflows, or suggest improvements based on their operational experience. |
The Operate stage is where most FinOps initiatives fail. Organisations implement great dashboards and identify massive savings opportunities. Then nothing happens. Nobody has authority to enforce the policies. Nobody has time to implement the optimisations. The feedback loops don’t exist.
Successful FinOps requires executive sponsorship and dedicated resources. Not a side project for your IT team.
Key Metrics CFOs Should Monitor
Data matters, but not all data. Focus on specific metrics that provide actionable insights into your cloud spending. Use these as KPIs to guide your financial decisions and strategies.
Cloud cost per employee: Average cost of cloud services per employee in your organisation. Useful benchmark for assessing efficiency relative to workforce size. A sudden spike indicates problems that need addressing.
Track this metric over time, not as an absolute. Your cloud cost per employee will look different from other organisations based on your business model (SaaS companies will have higher ratios than traditional enterprises). But your trend should be stable or declining as you scale. If it’s increasing while headcount stays flat, you’re accumulating waste or your architecture isn’t scaling efficiently.
Unit cost: Cost of cloud resources per unit of output. Per transaction, per customer, per API call, per whatever metric matters to your business. Shows how efficiently you’re utilising cloud resources to generate business value.
Example: If your unit cost per transaction increases while transaction volume stays flat, you’ve got a problem. Either you’re provisioning more resources than needed, or your architecture isn’t scaling efficiently.
Reserved instance utilisation: If you’re using reserved instances, monitor their utilisation rates. Underutilised reserved instances waste money. You’re paying for resources you’re not using and can’t easily redirect.
What constitutes “good” utilisation depends on your risk tolerance. Above 90% means you’re getting value from your commitment but have little buffer for usage changes. Below 70% means you’ve over-committed and are wasting money. The sweet spot for most organisations sits between 75-85%, balancing cost savings against flexibility.
Most organisations start with on-demand instances, identify stable workloads, then commit to reserved instances for savings. The risk: your usage patterns change, and you’re stuck paying for commitments you no longer need. Monitor this closely. If utilisation drops below 70% for more than two months, you’ve probably over-committed and need to adjust future purchases.
Cost over time: Track cloud costs over specific intervals: daily, weekly, monthly. Identify spending patterns and trends. Spot anomalies or spikes that require immediate attention.
Monthly tracking isn’t enough. Some cost anomalies (someone accidentally provisioning a massive instance) can cost thousands per day. Daily monitoring with alerts catches these problems before they destroy your budget.
Cost by service: Break down costs by specific cloud services. Get a granular view of where money goes. Identify which services are most costly and whether they match business objectives.
You might discover that 60% of your AWS bill comes from data transfer charges, not compute. Or that you’re spending more on monitoring tools than on the infrastructure they monitor. Without the breakdown, you can’t prioritise optimisation efforts.
Cost by department or project: Allocate costs to specific departments or projects. Essential for accountability. Track which parts of your organisation drive cloud costs and whether spending matches strategic goals.
Without this allocation, cloud becomes a shared pool that nobody feels responsible for. With allocation, product managers start asking whether they really need that redundant database backup or whether the analytics pipeline could run less frequently.
Compliance metrics: Compliance with industry regulations and internal policies has financial implications. Potential fines for non-compliance, costs to remediate violations. Monitor compliance metrics to mitigate risk.
Relevant for regulated industries (financial services, healthcare, government). Less relevant for others. Don’t build elaborate compliance monitoring unless you actually need it.
Return on investment (ROI): Calculate ROI of specific cloud services or projects. Assess their financial viability and long-term value.
Cloud ROI is trickier than traditional IT ROI. Traditional IT: you buy a server, depreciate it over five years, calculate TCO. Cloud: you pay per use, costs vary monthly, you can shut down services instantly if they’re not delivering value.
Focus on incremental ROI: “We migrated this workload to cloud and reduced costs by X while improving performance by Y.” Not: “What’s the ROI of our entire cloud infrastructure?”
Anomaly detection: Automated anomaly detection alerts you to sudden changes in cloud spending. Unexpected spikes in usage, configuration changes, potential security incidents. Early detection mitigates financial risk.
Set alerts at multiple thresholds. A 25% week-over-week increase deserves attention. A 100% increase demands immediate investigation. But context matters: if you’re launching a new product or running a major campaign, spikes are expected. The goal is catching unexpected anomalies: someone misconfigures auto-scaling, credentials leak and you’re mining cryptocurrency for attackers, or a test that was supposed to run for an hour keeps running for days.
Daily monitoring catches these problems in hours, not weeks. A misconfigured database running at maximum IOPS can cost thousands per day. Finding it on day one saves thousands. Finding it on day thirty after the monthly invoice arrives saves nothing.
Each metric provides a different lens for viewing cloud spending. Monitor them closely.
Risks and How to Mitigate Them
Managing cloud spending involves significant risks. As a CFO, you need strategies to mitigate them.
Unpredictable costs: The biggest risk in cloud spending is inherent unpredictability. Traditional IT costs are mostly fixed. Cloud costs vary dramatically based on usage, making budgeting and forecasting difficult.
Mitigation: Implement real-time monitoring. Set up alerts when spending exceeds predefined thresholds so you can act immediately.
Use multiple threshold levels: soft alerts at 70% of budget (warning), hard alerts at 90% (urgent attention required), automatic action at 100% (restrict new provisioning, escalate to executives).
Lack of visibility: Without clear visibility into cloud spending, costs spiral out of control. Results from fragmented data or inadequate reporting tools.
Mitigation: Use dashboards that aggregate data from various cloud services. Make information accessible to all relevant stakeholders.
The dashboards need to be actually useful, not just pretty. If your finance team can’t answer basic questions using the dashboard, you haven’t solved the visibility problem.
Resource sprawl: Resource sprawl occurs when cloud resources get provisioned but not adequately managed or decommissioned. Leads to unnecessary costs.
Mitigation: Regular audits of cloud resources identify unused or underutilised assets. Set up automated decommissioning workflows to remove these resources.
Implement mandatory tagging policies. Every resource must have tags indicating: owner, project, cost centre, expiry date. Resources without proper tags get automatically flagged for review or decommissioned.
Vendor lock-in: Depending on a single cloud provider carries risk, especially if their pricing models change or they experience service outages.
Mitigation: Consider a multi-cloud strategy distributing cloud services across multiple providers. Provides a safety net and gives you more leverage in price negotiations.
Multi-cloud introduces its own problems: increased operational burden, multiple sets of tools and skills required, data transfer costs between clouds. Don’t adopt multi-cloud just for theoretical risk mitigation. Adopt it if you have specific workloads that genuinely benefit from different providers’ strengths.
Compliance risks: Failure to comply with industry regulations or internal policies results in financial penalties and legal repercussions.
Mitigation: Implement governance policies aligned with compliance requirements. Regularly review these policies and conduct compliance audits to ensure adherence.
Automated compliance monitoring catches violations before they become audit findings. But automated tools aren’t perfect. They’ll flag false positives and miss nuanced violations. Combine automation with periodic manual review.
Inefficient use of reserved instances: Purchasing reserved instances offers cost savings, but only if utilised efficiently. Underutilised reserved instances waste financial resources.
Mitigation: Monitor utilisation rates of your reserved instances. Adjust your purchasing strategy accordingly. Consider using a mix of reserved and on-demand instances to balance cost and flexibility.
Some cloud providers now offer “savings plans” instead of or alongside reserved instances. More flexible but more complicated. Understand what you’re committing to before you commit.
Lack of stakeholder alignment: Misalignment between finance, IT, and business units leads to inefficient cloud spending. Each department has its own priorities, leading to conflicting objectives.
Mitigation: Establish a FinOps team including representatives from finance, IT, and business units. Give them authority to control spending across departments.
The FinOps team needs actual authority, not just advisory power. Otherwise, you’ll identify problems but can’t fix them because nobody has authority to enforce changes.
Expensive FinOps tools: Many organisations respond to cloud spending problems by buying FinOps tools. The tools themselves cost six figures annually and often create more problems than they solve.
Mitigation: Evaluate whether you actually need a dedicated FinOps tool or whether cloud provider native tools (AWS Cost Explorer, Azure Cost Management, Google Cloud Billing) provide sufficient visibility. Many FinOps tools are expensive wrappers around the same data available from cloud providers.
If you do need a third-party tool, understand the pricing model. Tools that charge a percentage of your cloud spending (common in this market) work against your goal of reducing costs.
🖐 Achieve optimal Azure cost efficiency. Learn more: Microsoft Azure Cloud Cost Optimisation.
What Good FinOps Looks Like
Can you answer basic questions immediately? How much are we spending monthly? Which services cost the most? What’s our month-over-month growth rate? Can we predict next month within 20%? If your team needs three days to pull together answers, your visibility is broken.
Someone needs to own the budget with actual authority to enforce policies, shut down wasteful resources, reject requests that don’t make financial sense. Advisory authority that gets ignored isn’t FinOps.
Without ownership and authority FinOps doesn’t work.
70-80% of resources should be properly tagged with owner, project, cost centre. If you’re at 30% or hearing “we’re working on it,” you can’t allocate costs or hold anyone accountable for waste.
Optimisation should be continuous. Regular identification of waste, architectural improvements, contract renegotiations. Annual fire drills when the bill spikes mean you’re reactive, and last optimisation six months ago means you’re accumulating problems.
Check for independence. Are they using consultants provided by your cloud vendor? Tools that charge based on your spending? Advice from resellers who profit from your consumption? Everyone advising you has a financial interest in you spending more? Conflict problem.
Governance policies need enforcement. Resources require proper tags. Non-production environments shut down outside business hours. Large instance types require approval. Policies that exist only on paper are worthless.
Architectural decisions should get financial review before implementation. Your engineering team commits to serverless or containers or a particular storage strategy, someone should run the numbers first. Architectural decisions often change costs by orders of magnitude, but rarely get financial scrutiny.
Questions to Ask Your FinOps Team
Whether you’re evaluating a consultant or reviewing your internal team, these questions expose problems quickly.
How do you make money from this? For consultants: fixed fee, percentage of spending, or commission on services sold? Percentage or commission means they profit when you spend more. For internal teams: are they using vendor-provided tools or consultants? Same conflict.
What’s our biggest source of waste right now? They should have a specific answer with numbers. “Untagged resources” or “we need better visibility” means they haven’t done the work. Good answer: “£40k/month on development environments running 24/7 that could shut down at night.”
When did you last identify architectural savings? All optimisation being operational (turning things off, right-sizing instances) means they’re missing the big opportunities. Architectural decisions often change costs by orders of magnitude.
Who has authority to enforce policies? “We make recommendations to IT” means nobody. “We present findings to the steering committee” also means nobody. Someone needs actual authority to shut things down or reject requests.
What percentage of our resources are properly tagged? Below 70% and they can’t allocate costs properly. Below 50% and you have no idea which teams or projects waste money.
How much could we save by moving workloads between regions? Tests whether they understand cloud pricing geography. Price differences between regions can hit 50% for identical services. Never looked at this? They’re not thorough.
What conflicts of interest exist in our current setup? Do they admit that using vendor-provided consultants creates conflicts? That percentage-based tool pricing works against you? Denying conflicts exist means they’re either naive or dishonest.
Vague answers, excuses about needing more time, or deflection to other topics all signal problems. Competent teams have specific numbers and explain their work clearly.
Before You Hire Anyone
You’re building elaborate infrastructure to manage problems that cloud providers created deliberately. Cloud pricing could be transparent. Cloud providers choose not to make it transparent because confusion benefits them.
The FinOps industry that emerged to solve this problem often perpetuates it. Tool vendors charge based on your spending. Consultants who are also cloud resellers profit from your consumption. Few participants have genuine incentive to reduce your costs.
Before engaging any FinOps consultant or buying any tool: verify the business model. How do they make money? Do they share your interest in reducing costs, or do they profit when you spend more?
That’s the only question that matters.
Need Help?
Cloud pricing is deliberately confusing. The tools sold to manage it cost six figures and often create more problems than they solve.
We don’t resell cloud services or take commissions from providers. Our business model is simple: companies pay us for expertise when their cloud spending is out of control or they’re being sold something that doesn’t make sense.
We’ve managed cloud cost crises for enterprises spending hundreds of millions annually. The problems are usually structural (wrong architecture, bad contracts, vendor lock-in masquerading as best practice) rather than tactical (idle VMs, unattached volumes).
If your cloud spending doesn’t make sense and everyone selling you solutions has a financial interest in confusion, there’s a form below.