Your Cloud Bill Is Still High After Rightsizing. The Architecture May Be the Problem.
The first wave of cloud cost optimization is usually straightforward. Find oversized instances, idle resources, unused storage, forgotten development environments and poor reservation coverage. Fix them. Costs fall. Then something interesting happens. A few months later, the cloud bill is still higher than expected. Teams have already rightsized.
Resources are being monitored. Budgets and alerts exist. Yet the underlying economics have not improved enough. At that point, the problem may no longer be infrastructure configuration. It may be architecture.
Rightsizing fixes waste. It does not fix design.
Consider an application designed around permanently running infrastructure. The team moves it to the cloud. Then they reduce instance sizes. That helps. But the application may still require constant computation, scale inefficiently, make excessive database calls, move large amounts of data, use expensive middleware, generate unnecessary logs or depend on architectures designed for an on-premises environment.
The resources are correctly sized. The architecture is still expensive.
Cloud cost should eventually become a unit economics question
Many organisations initially measure monthly cloud bills. That is useful but incomplete. The stronger question is: What does it cost to deliver one unit of business value? That unit could be one customer, one transaction, one order, one claim, one API call or one model inference. The FinOps Foundation recommends connecting technology spend to meaningful business units because it allows engineering and business teams to understand whether infrastructure efficiency is actually improving.
A cloud bill rising from ₹1 crore to ₹1.2 crore may look negative. But if transaction volume doubled, the economics may have improved. The reverse is also possible.
Five architectural reasons cloud cost stays high
1. The application never became elastic
One of cloud's strongest advantages is the ability to scale resources with demand. But many migrated applications still behave like data-centre systems: capacity remains provisioned continuously for peak demand. Rightsizing simply creates a smaller permanently running environment. A deeper redesign may be needed to take advantage of elasticity.
2. Data movement is expensive
Application teams often focus on compute costs. But cloud architectures can also accumulate significant spending from data transfer, cross-region traffic, repeated queries, replication and unnecessary movement between services. The solution may require changing where data lives and how services communicate.
3. Managed services are convenient but poorly matched
Managed services can reduce operational work. They are not automatically cheaper. An enterprise may be paying for capabilities it does not need.
The question should not be: Can we replace this with something cheaper? It should be: Does this service create enough operational value to justify its cost?
4. The application performs unnecessary work
Architecture can generate waste even when infrastructure itself is optimized. Examples include redundant processing, repeated API calls, excessive polling, duplicated data pipelines, unnecessary model calls and retry loops. This becomes particularly relevant for AI workloads where token usage, retrieval, repeated agent actions and model selection directly influence cost.
5. The architecture was lifted and shifted permanently
Rehosting may be the correct first migration decision. It becomes a problem when temporary architecture becomes permanent architecture. A business may move quickly to cloud for speed, data centre exit or risk reduction. That does not mean the resulting architecture should remain unchanged forever. At some point, the organisation should reassess whether replatforming or selective refactoring would improve cost, scalability, resilience and operability.
FinOps cannot solve everything alone
FinOps creates visibility, ownership, forecasting, governance and accountability. That is essential. But FinOps can identify that an application is expensive without being able to redesign the application.
At that point: Financial optimization becomes an engineering problem. The FinOps team may show: cost per transaction is rising. Engineering then needs to understand why.
When should architecture enter the conversation?
Architecture deserves review when:
- Cloud cost remains high after obvious waste has been removed.
- Utilisation looks reasonable but unit cost is poor.
- Spend rises faster than business volume.
- Applications cannot scale down.
- Data-transfer costs are unusually high.
- Managed services dominate cost.
- AI workloads create unpredictable consumption.
- Repeated optimisations produce progressively smaller savings.
These are signals that another rightsizing exercise may not be enough.
A practical sequence
- Measure spend by application and business unit.
- Remove clear infrastructure waste.
- Calculate relevant unit economics.
- Identify which architectural components drive cost.
- Estimate the savings versus the cost and risk of changing them.
- Modernize only where the business case is strong.
This last point matters. Do not spend ₹1 crore rebuilding an application to save ₹10 lakh. Cloud optimization should remain an economic decision.
The takeaway
Rightsizing is important. But it has limits. Once obvious infrastructure waste is removed, the next cloud-cost question may no longer be: What can we switch off? It may be: What about the way this application is designed makes every unit of work expensive? That is where cloud cost optimization becomes architecture strategy.
FWC perspective: The objective should not be the lowest possible cloud bill. It should be the most efficient architecture for the required level of performance, reliability and business growth.
