Why does cloud spending keep climbing even when finance teams swear they finally have it under control? Ask anyone who has run a FinOps practice and you will hear the same story: the dashboard looks great in month one, then a new product launch, a re-architecture, or a reorg quietly breaks everything. FinOps is not a project with an end date. It is a way of running the business, and that is precisely why it is so hard.
The framework itself is well documented. The FinOps Foundation defines FinOps as an operational framework and cultural practice that maximizes business value from cloud and creates financial accountability through collaboration between engineering, finance, and business teams. The public definition of FinOps is worth reading in full, because the phrase “cultural practice” is where most challenges hide. Tools do not fix culture. People do, slowly, with a lot of arguing about tags. (AWS Well-Architected Framework)
Below are the challenges that show up again and again, why they persist, and what actually helps in practice.
The allocation problem: shared costs that refuse to split cleanly
The single most common frustration is cost allocation. Cloud bills do not arrive sorted by team, product, or customer. They arrive sorted by service and account. A shared Kubernetes platform, a central logging pipeline, networking egress, support plans, and committed-use discounts all serve many consumers at once.
Teams try to solve this with tagging, and tagging works until it doesn’t. Someone spins up a cluster without the right labels. A vendor’s managed service does not support the tag you need. A shared database hosts workloads from three departments. Suddenly 30 percent of the bill is “unallocated,” and showback reports lose credibility the moment someone asks who owns that chunk.
What actually works in practice:
- Start with a small number of mandatory tags (cost center, product, environment) and enforce them at provisioning time through policy, not through reminders.
- Accept that some costs will always be shared, and publish a written allocation rule for them (for example, split shared platform cost by each team’s compute share).
- Report the unallocated percentage openly every month. It is a health metric, not a failure to hide.
The mistake people make is chasing 100 percent allocation. Ninety percent with a transparent rule beats ninety-nine percent with a rule nobody trusts.
Tagging discipline decays faster than you think
Tags are the plumbing of FinOps, and plumbing leaks. New engineers do not know the convention. Contractors use their own naming. Infrastructure-as-code templates drift from the standard. Within two quarters, a clean taxonomy becomes a museum exhibit.
The fix is not more governance documents. It is making the correct path the easiest path. Pre-built modules that inject tags automatically, a short list of allowed values, and a monthly report that names the top offenders by team all do more than a 40-page standard. If you want a deeper look at how organizations handle this operational grind, the cloud section on 9481.org covers related infrastructure topics in plain language. (Cloud computing)
Commitment discounts: savings today, stranded spend tomorrow
Reserved capacity and savings plans offer real discounts in exchange for a one- or three-year promise. The challenge is that the promise is a bet on your future architecture. AWS documents how Savings Plans work and the flexibility they offer across instance families, but no discount model protects you from deciding six months later to move a workload to a different provider or a managed service.
Over-commitment is a quiet killer. The bill shows savings, so nobody complains, while a portion of the commitment covers capacity you no longer use. Under-commitment is the opposite problem: you leave money on the table and the finance team notices.
A workable middle ground:
| Approach | Strength | Risk |
|---|---|---|
| Cover baseline with 1-year commitments | Fast payback, low lock-in | Less discount than 3-year |
| Cover only steady-state workloads | Protects flexibility | Requires accurate baselines |
| Central commitment pool | Shared across teams | Needs clear internal charging |
| No commitments at all | Maximum agility | Highest unit cost |
Most mature teams commit to a conservative baseline and revisit quarterly, rather than optimizing for the maximum headline discount.
Unit economics: the number everyone wants and nobody can build
Executives do not want to know what cloud costs. They want to know what a customer costs to serve, or what a transaction costs to process. That is unit economics, and it is genuinely difficult. Cost data lives in billing systems. Business metrics live in product analytics. Customer identifiers rarely map cleanly to cloud resources.
The practical route is to pick one metric, not ten. Choose something like cost per active user for a single product, define the numerator and denominator in writing, and accept that the first version will be approximate. Precision comes later. Teams that wait for perfect data never ship a unit metric at all.
Kubernetes and containers blur the picture
Containerized workloads break the mental model of “one resource, one owner.” A cluster is shared. Pods come and go. Cluster overhead, idle capacity, and the control plane all need a home. Open-source projects such as OpenCost exist specifically to attribute Kubernetes costs to namespaces and workloads, which tells you how large the gap was.
Even with good tooling, someone must decide how to treat idle capacity. Charge it to the platform team? Spread it across tenants? Leave it unallocated? Each choice changes behavior. The teams that get this right treat idle capacity as a visible line item with an owner, because invisible waste never gets fixed.
Forecast accuracy and the budget conversation
Cloud spend is variable, which makes it feel unpredictable to finance teams trained on fixed budgets. Forecasts built by extrapolating last month’s bill break the moment a workload scales or a migration completes.
Better practice is to forecast from drivers rather than history: expected customer growth, planned launches, known migrations. Then show a range, not a single number. A forecast with a stated confidence band survives contact with reality far better than a precise figure that misses by 40 percent.
Waste is real, but the percentages are noisy
Everyone quotes a waste percentage, and the numbers vary wildly depending on who ran the survey and what they counted. Treat any single figure with suspicion, especially when the survey sponsor sells optimization software. What matters is your own number, measured consistently month over month. Idle non-production environments, oversized instances, orphaned storage volumes, and forgotten load balancers are the usual suspects, and they are findable without a vendor.
The organizational challenge: nobody owns the bill
Here is the uncomfortable truth. Engineering is rewarded for shipping. Finance is rewarded for predictability. Procurement is rewarded for discounts. Nobody’s bonus depends on cloud efficiency, so it becomes everyone’s side project.
FinOps succeeds when accountability is explicit. That might mean a named owner for each product’s cloud cost, a monthly review where engineers see their own numbers, or a lightweight incentive tied to efficiency targets. Without that, the practice depends on one enthusiastic person who eventually changes jobs.
Tooling sprawl and dashboard fatigue
A familiar pattern: the team buys a cost visibility tool, then a second one for Kubernetes, then a spreadsheet to reconcile them. Three sources of truth, none trusted.
Consolidation matters more than features. One primary source for cost data, one agreed definition of each metric, and one monthly report beats five dashboards nobody opens. If a tool cannot answer “who owns this cost and is it going up or down,” it is decoration.
Regulatory constraints limit the easy wins
The simplest optimization is often “move it to a cheaper region.” Data protection rules can make that impossible. The official GDPR text sets conditions on transferring personal data outside the EU, and similar rules exist in many jurisdictions. Residency requirements therefore become a hard boundary on optimization, and FinOps teams need to know which workloads are legally pinned before promising savings. For current developments in this space, the news coverage on 9481.org tracks regulatory and industry shifts that affect cloud operations.
Sustainability reporting adds a new axis
Carbon reporting is arriving on the same desk as cost reporting, and the methodologies are still maturing. The Software Carbon Intensity specification from the Green Software Foundation offers a standardized way to score software emissions, but cloud provider data remains coarse. Teams are being asked to optimize for cost and carbon simultaneously, often with estimates rather than measurements. Expect this to be a growing challenge rather than a solved one.
Culture is the hardest part
Every challenge above has a technical component and a human one. The human one is harder. Engineers resist cost conversations because they feel like blame. Finance resists variable budgets because they feel like chaos. The bridge is language: talk about efficiency and reliability together, celebrate teams that cut waste without cutting performance, and make cost data visible where engineers already work rather than in a separate portal they never visit. If you want more practical write-ups on running these operational programs, the blog on 9481.org has related material.
Conclusion
FinOps challenges are not really about tools. They are about shared costs that resist clean splitting, commitments that trade flexibility for savings, unit metrics that require two organizations to agree on definitions, and a cultural gap between the people who spend the money and the people who account for it. The teams that make progress are rarely the ones with the most sophisticated dashboards. They are the ones with a short list of enforced tags, a written rule for shared costs, one unit metric they actually trust, a conservative commitment strategy, and a monthly rhythm where engineers see their own numbers and know they will be asked about them. Start with allocation and tagging. Everything else gets easier once people believe the numbers.
What is the biggest FinOps challenge for most organizations?
Cost allocation. Shared platforms, networking, support contracts, and commitment discounts serve many teams at once, so a meaningful share of the bill cannot be attributed cleanly. Until there is a written rule for splitting shared costs, showback and chargeback reports lose credibility and the whole practice stalls.
Why does tagging fail even when standards exist?
Because standards are documents and provisioning is action. Tags decay when the correct path requires extra effort, when new people are not onboarded to the convention, and when nothing reports on compliance. Enforcement at provisioning time through policy and pre-built templates works far better than periodic reminders to tag properly.
Are commitment discounts worth the lock-in?
Usually yes for steady-state workloads, with caution. A one-year commitment on a well-understood baseline captures most of the available savings with limited risk. The danger is committing to the maximum discount based on today’s architecture, then stranding spend when workloads move to managed services or another provider.
How do you measure cloud cost per customer?
Pick one product and one metric, define the numerator and denominator in writing, and accept an approximate first version. Cost data and business metrics live in different systems, so perfect mapping is rare. A rough but consistent unit metric that ships beats a precise one that never does.
How should teams handle Kubernetes cost allocation?
Attribute what can be attributed through namespace and workload labels, then make a deliberate decision about idle capacity and cluster overhead. Charge it to the platform team or spread it across tenants, but never leave it invisible. Open-source tooling can help with the attribution mechanics, but the policy decision is yours.
How often should a FinOps practice be reviewed?
Monthly for cost review and anomaly checks, quarterly for commitments and forecasts, and annually for the tagging taxonomy and allocation rules. The quarterly cadence matters most for commitments, because that is where savings and stranded spend both accumulate quietly.
