A cloud proposal lands in front of you.
The estimated infrastructure cost looks lower than what the company currently spends, so the decision seems straightforward: move the product to the cloud and save money.
But I would not approve the business case yet.
The number sitting on the cloud calculator is not necessarily the cost of running the product. It tells us what certain cloud resources may cost under certain assumptions, while the actual business will also pay for networking, storage, backups, monitoring, people, migration, security, support, unused capacity, and many other things.
That is why, as a Product Manager, I would ask a different question:
What will it really cost us to deliver this product over its useful life?
That is where Total Cost of Ownership (TCO) becomes useful.
What is cloud TCO?
Cloud Total Cost of Ownership is the complete cost of running a product or workload in the cloud over a defined period, including infrastructure, software, operations, people, migration, security, support, and other costs required to keep the product working.
The phrase defined period matters.
Comparing ₹50 lakh of today’s on-premises spending with three months of expected cloud spending tells us very little. If the infrastructure decision will affect the product for three years, I want to understand the economics over those three years.
And I don’t want to calculate only what we will spend.
I also want to understand what we receive in return.
That distinction becomes important later.
Why the cloud bill is not the TCO
Let’s start with the obvious costs.
A product running in the cloud may consume computing power to execute the application, storage to keep information, and databases to manage that information. It may also use load balancers, backups, monitoring tools, security services, APIs, managed platforms, and network capacity.
Each service may look relatively inexpensive by itself.
But a production product is not one service.
It is a system.
And the cost of the system is what matters.
This becomes especially important because cloud spending is consumption-based. If usage increases, infrastructure consumption may increase with it. A feature that suddenly becomes popular can therefore increase both customer engagement and infrastructure cost.
That isn’t necessarily bad.
If ₹1 lakh of additional cloud spending creates ₹10 lakh of profitable revenue, I would probably be delighted.
The problem appears when we know the ₹1 lakh increased but cannot explain what business value increased with it.
Companies are still struggling with this
This is not just a theoretical problem.
The FinOps Foundation’s 2025 State of FinOps survey included 861 respondents representing approximately $69 billion in public-cloud spending. Workload optimisation and waste reduction remained the top current priority among practitioners, while cost allocation and accurate forecasting were also major concerns.
That tells me something important as a Product Manager.
Cloud cost management does not end when migration finishes.
In fact, it may become more important because teams can now create and change infrastructure much faster.
McKinsey examined more than $3 billion of cloud spending across organisations and industries and reported finding an additional 10% to 20% of untapped cost-saving potential in most organisations it studied.
So when somebody presents a cloud TCO calculation based entirely on list prices, I would immediately ask what assumptions sit underneath it.
Start with the workload, not the cloud provider
Before calculating cost, I need to understand what we are costing.
Suppose we have an online learning platform.
How many learners use it today?
How many do we expect in three years?
When does traffic peak?
How much video or other data do users consume?
How quickly is stored data growing?
What level of availability do customers expect?
Which environments do engineering teams need?
Without answers to questions like these, a cloud-cost forecast can look precise while being based on very weak assumptions.
A calculation that says:
“Our cloud cost will be ₹80 lakh per year”
isn’t particularly useful by itself.
I want to know:
At what number of customers, transactions, storage volume, traffic level and reliability requirement?
Now we have a model that can be challenged.
Compute is only the beginning
Compute is the processing power used to run applications.
For many teams, this is one of the first cloud costs they estimate. If an application needs a certain number of virtual machines or containers, we can estimate how much those resources will cost.
But there is a trap.
Teams can provision more capacity than the workload actually needs.
This is called overprovisioning.
Imagine booking a 50-seat bus every day because 50 passengers might arrive, even though only 12 usually do.
You are paying for capacity that isn’t creating value.
Cloud gives us mechanisms such as autoscaling that can help capacity adjust as demand changes, while longer-term commitments and different purchasing models may also reduce the effective price of some resources.
But those savings depend on understanding the workload.
Before optimising compute, we therefore need visibility into what the product actually consumes.
Then comes storage—and storage rarely stops growing
Products create data.
Customer records, uploaded files, logs, analytics events, database backups, model outputs, images, videos, documents, and historical information can accumulate over time.
The cost of storing one gigabyte may look tiny.
Multiply that by millions of customers and several years, and the economics change.
The PM question isn’t simply:
How much does storage cost today?
It is:
How quickly is our data growing, how long must we retain it, and how much of it still creates value?
Some information may need fast access.
Older information might be moved to cheaper storage.
Some data must be retained because of legal or regulatory requirements, while other data may no longer need to exist at all.
Data lifecycle therefore becomes part of product economics.
The cost people often discover later: moving data
Storing information in cloud is one thing.
Moving it is another.
Cloud providers may charge for certain types of network traffic, particularly when data leaves specific environments or moves between particular locations or services. These charges are often discussed under terms such as data transfer or data egress.
This matters for products that move large amounts of information.
Video platforms, analytics systems, AI workloads, backup systems, data platforms, and globally distributed applications can all create significant network traffic.
A cloud architecture may therefore look inexpensive when we estimate compute and storage but become much more expensive once we model how information actually moves.
For a Product Manager, the useful question is:
How does a customer action translate into infrastructure consumption?
If watching one hour of video causes storage reads, network transfer, analytics events, logging, and several backend operations, all of those may contribute to the cost of serving that customer.
Now we are getting closer to the true economics of the product.
Don’t forget the people keeping everything alive
Infrastructure does not operate itself.
On-premises environments require people to maintain hardware, networks, operating systems, backups, security, databases, and other infrastructure.
Cloud can remove some of that work because the provider manages parts of the underlying environment.
But cloud doesn’t eliminate operational work.
Teams still need architecture, security, monitoring, cost management, deployment pipelines, incident response, governance, and optimisation.
Those people costs belong in TCO.
There is also another cost that is harder to see:
What could those engineers be doing instead?
Suppose five highly skilled engineers spend a significant portion of their time maintaining infrastructure that does not differentiate the product.
If managed cloud services reduce that effort, the financial benefit isn’t necessarily five fewer employees.
The organisation may instead redirect those engineers toward product capabilities customers actually value.
That is an opportunity cost, and although it can be difficult to quantify perfectly, I would not ignore it.
Migration itself has a cost
A common mistake is comparing:
Current on-prem annual cost
against
Future annual cloud run cost
and concluding that the difference represents savings.
But how did the product get from one environment to the other?
Migration may require application assessment, architecture work, engineering effort, data transfer, testing, security reviews, training, consultants, temporary parallel environments, and sometimes application refactoring.
During part of the migration, the organisation may even pay for both environments simultaneously.
If migration costs ₹2 crore and annual savings are ₹40 lakh, the economics look very different from a proposal that simply says:
“Cloud saves ₹40 lakh per year.”
We need to understand the payback period.
In this simplified example, ignoring other effects, recovering ₹2 crore through ₹40 lakh of annual savings would take roughly five years.
If the organisation expects the architecture to change again in three years, the migration may not make financial sense based on savings alone.
That does not automatically make the migration wrong.
Reliability, speed, growth, or new capabilities may still justify it.
But now we are making the decision with the real trade-off visible.
Reliability also belongs in the cost model
Suppose Option A costs ₹1 crore per year.
Option B costs ₹1.2 crore.
At first glance, Option A wins.
Now suppose Option A produces enough downtime to cause ₹50 lakh in lost revenue, SLA penalties, customer support costs, and churn every year, while Option B dramatically reduces that exposure.
Which option is cheaper?
This is why TCO cannot be separated completely from risk.
Backup systems, disaster recovery, redundancy, additional regions, monitoring, and security controls all cost money.
But failures cost money too.
The correct comparison isn’t:
Resilience vs no resilience
It is:
Cost of resilience vs expected business impact of failure.
A Product Manager should help make that trade-off explicit.
Security and compliance aren’t optional extras
Products handling healthcare, financial, government, enterprise, or personally identifiable information may need additional security and compliance controls.
That can mean encryption, audit logging, identity systems, security monitoring, specialised tooling, certifications, compliance reviews, data-retention controls, and additional operational processes.
These costs don’t disappear because the application moved to cloud.
They may simply change shape.
The same applies to data residency requirements. If information must remain within particular geographical boundaries, that requirement can affect region selection, backups, disaster recovery, architecture, and ultimately cost.
A realistic TCO model therefore needs to reflect the product’s actual regulatory and security environment.
The cost nobody wants to admit: waste
One thing I find particularly interesting about cloud economics is how easy it can be to create resources.
That speed is one of cloud’s greatest advantages.
It can also become a financial problem.
A developer creates a test environment and forgets about it. A storage volume remains after an application is removed. A database is much larger than necessary. Logging retains information nobody uses. Teams provision for a peak that never arrives.
Individually, these decisions may not look serious.
Across hundreds of services and teams, they accumulate.
This helps explain why workload optimisation and waste reduction continue to rank so highly among FinOps practitioners.
It also changes how I think about TCO.
TCO should not assume that the architecture will remain perfectly optimised forever.
We need a process for keeping costs healthy after launch.
That is where FinOps becomes important.
What is FinOps, in simple terms?
FinOps brings engineering, finance, and business teams together so that cloud spending can be understood and connected to the value it creates.
I don’t see FinOps as simply:
“The team that reduces the AWS bill.”
Reducing unnecessary spending matters, but the larger goal is making better decisions about technology economics.
The FinOps Foundation’s 2025 research reflects this broader scope: organisations are focusing not only on optimisation, but also on understanding costs, allocating spending, forecasting, and quantifying value.
That is why Product Managers belong in the conversation.
Finance understands budgets.
Engineering understands infrastructure.
Product should help connect consumption to customers and business outcomes.
I would calculate TCO in layers
If I were building a cloud TCO model for a product, I would not try to create one giant number immediately.
I would build it gradually.
First, I would establish the current-state cost. That includes infrastructure, hardware depreciation or refreshes, licences, facilities where relevant, operations, support, security, backup, disaster recovery, and the people effort required to run the environment.
Then I would calculate the expected cloud run cost. That includes compute, databases, storage, networking, managed services, observability, security tooling, support, backup, disaster recovery, and expected growth.
Next comes migration cost: engineering, testing, data movement, training, consulting, parallel environments, refactoring, and transition risk.
Then I would add the costs that are easier to overlook, including operational complexity, governance, FinOps, unused capacity, commitments, and expected waste.
Finally, I would model the benefits.
Those might include avoided hardware refreshes, reduced licensing costs, faster provisioning, lower operational effort, improved reliability, quicker market expansion, faster releases, or the ability to launch product capabilities that were previously difficult to support.
Only then would I compare the options.
But one TCO number still isn’t enough
Suppose our model predicts:
Cloud TCO over three years: ₹6 crore
On-prem TCO over three years: ₹7 crore
Cloud appears to win.
But what happens if customer growth is twice what we expected?
Or half?
What happens if storage grows much faster than forecast?
What if network traffic doubles?
What if we can negotiate better pricing?
What if migration takes six months longer?
A single forecast hides uncertainty.
I would therefore model at least three scenarios:
Expected case: what we currently believe will happen.
Growth case: what happens if demand increases significantly.
Downside case: what happens if growth is weaker or migration becomes more expensive than expected.
This turns TCO from a static spreadsheet into a decision model.
What I learned while working through cloud TCO
When I first looked at TCO, I thought its purpose was mainly to answer:
“Which option costs less?”
Working through the problem changed that for me.
I now think the better question is:
“Which option creates the best economic outcome for the value we need to deliver?”
Those are not the same thing.
The cheapest infrastructure could slow releases, make scaling difficult, or create reliability problems.
The more expensive architecture could also be wasteful if customers receive no additional value from its capabilities.
So I would not optimise cloud cost in isolation.
I would connect it to the product.
Instead of only tracking:
₹ spent on cloud
I would want metrics such as:
Infrastructure cost per active customer
Cost per transaction
Cost per API request
Cost per workload
Infrastructure cost as a percentage of revenue
Gross margin
For an AI product, I might eventually go even further and measure cost per successful AI task or cost per customer outcome.
That is when cloud economics starts becoming Product Management rather than infrastructure accounting.
So, how do you calculate the true TCO of cloud?
Start with the product and workload rather than the cloud price calculator.
Define the period you are evaluating, then capture the current cost of running the product, expected cloud operating costs, migration and transition costs, people and operational costs, security and compliance requirements, reliability requirements, and realistic allowances for growth and inefficiency.
Then model the value the new environment is expected to create.
Finally, test the assumptions under different scenarios.
The calculation can be summarised as:
True Cloud TCO = Cloud Run Cost + People + Operations + Security + Migration + Transition + Risk + Expected Waste − Avoided Costs
But I would add another line underneath it:
TCO tells us what we spend. Product economics tells us whether that spending creates enough value.
We need both.
Questions I would ask before approving a cloud business case
Before accepting a TCO calculation, I would want to know:
- What period are we modelling?
- What workload assumptions drive the estimate?
- How many customers or transactions are assumed?
- How quickly will compute and storage grow?
- Have network and data-transfer costs been included?
- What software licences change?
- What does migration itself cost?
- Will we operate cloud and on-prem simultaneously during transition?
- What people and operational costs remain after migration?
- What security and compliance costs apply?
- What reliability and disaster-recovery architecture is included?
- How much unused capacity or waste are we realistically assuming?
- What happens if usage doubles?
- What happens if growth is lower than expected?
- Which existing costs disappear after migration?
- What customer or business value do we expect in return?
- How long is the payback period?
If those questions cannot be answered, the TCO may look precise without actually being reliable.
Frequently Asked Questions
What does TCO mean in cloud computing?
Total Cost of Ownership, or TCO, represents the overall cost of operating a workload over a defined period. It can include cloud services, software, networking, people, operations, security, migration, support, and other costs needed to run the product.
Is cloud TCO just the monthly cloud bill?
No. The cloud bill is only part of TCO. Migration, people, security, networking, support, operational processes, tooling, and transition costs can materially affect the overall economics.
Why can cloud costs become unpredictable?
Cloud spending often changes with consumption. Growth in traffic, storage, databases, network usage, logging, AI workloads, or poorly controlled resources can therefore change the bill over time.
What is FinOps?
FinOps is a collaborative practice that helps engineering, finance, and business teams understand technology spending, manage cloud costs, and connect that spending with business value.
What is the difference between TCO and ROI?
TCO focuses primarily on what an option costs over time. Return on Investment (ROI) considers the value or financial return generated relative to the investment. A cloud decision can therefore have a higher TCO but still produce a stronger ROI if it creates substantially greater business value.
The question to remember
When someone tells me:
“Cloud will cost ₹X per month,”
I no longer hear the answer.
I hear the beginning of the analysis.
I want to know what workload that number represents, what assumptions produced it, what has been excluded, how the number changes as the product grows, and what business value we expect in return.
Because the goal isn’t to build the cheapest infrastructure.
It is not even to build the cheapest cloud infrastructure.
The goal is to understand the true economics of delivering the product—and spend where that spending creates value.