The cheapest cloud option is almost never the cheapest cloud option. This isn’t a paradox. It’s the defining economic trap of modern infrastructure decisions, and companies walk into it constantly because they’re comparing the wrong numbers.
Cloud providers have spent years perfecting the art of the attractive entry price. Compute costs are front and center, easy to compare on a spreadsheet, responsive to negotiation. Everything else, the data transfer fees, the support tiers, the proprietary service dependencies, the engineering time required to keep the thing running, gets buried in documentation or revealed gradually through invoices. By the time the full cost is visible, you’re committed.
The Egress Problem Is Structural, Not Accidental
Data egress fees are the clearest example of pricing designed to obscure total cost. Moving data out of a cloud environment to the internet, or to another provider, typically costs money. The rates vary, but the structure is consistent: getting data in is cheap or free, getting it out costs real money at scale.
This isn’t an oversight. It’s deliberate architecture. A provider that prices egress aggressively creates switching costs that don’t appear in any initial comparison. A company running serious data workloads can find that the theoretical savings from a cheaper compute tier evaporate entirely once egress fees are factored in, and that’s before accounting for the engineering work required to actually move.
The European Commission has pushed cloud providers to address this through the Data Act, which came into force in 2024, partly because the egress fee structure was recognized as a competition problem. Regulators naming it doesn’t make it go away, but it confirms what practitioners have known for years: these fees are a feature of the pricing model, not a bug.
Migration Costs Are Real and Systematically Underestimated
Every cloud platform offers services that have no clean equivalent elsewhere. Managed databases, serverless functions, proprietary message queues, ML infrastructure. The deeper an organization builds into these services, the higher the cost of leaving, regardless of what the compute line item says.
This is the real lock-in story, and it’s subtler than vendor contracts. When an engineering team builds on a proprietary queuing service because it integrates cleanly with everything else on the platform, they’re making a rational short-term decision. The long-term cost is an exit price that was never on the original invoice. As salary is the smallest part of what engineers cost, the hidden labor cost of migration, re-architecture, testing, and re-certification dwarfs what shows up in any line-item comparison.
Companies that have gone through major cloud migrations consistently report that the actual cost runs well above initial estimates. The engineering hours alone are substantial, but the opportunity cost, what the team wasn’t building during a multi-quarter migration project, rarely enters the original calculation.
Support Tiers Change the Effective Price Significantly
Base compute pricing assumes you won’t need urgent help. The moment you do, the cost structure changes. Enterprise support contracts at the major providers can run tens of thousands of dollars monthly before you’ve gotten a faster response SLA. For organizations running production workloads, some level of paid support is effectively mandatory, which means the real floor price is considerably higher than the advertised rate.
This applies to reliability guarantees too. As 99.9% uptime sounds impressive until you do the math, the difference between service tiers in practice often comes down to how much downtime you can absorb and whether you’ve priced that risk correctly. A cheaper tier with a weaker SLA isn’t cheaper if your business has real exposure to outages.
The Counterargument
The obvious pushback is that sophisticated buyers know all this, do their homework, and make informed comparisons that account for the full cost. Some do. But the structure of cloud procurement makes it hard even for careful buyers. Pricing pages are not designed for total cost transparency. Egress fees require volume projections to model accurately, and early-stage companies often don’t have those. Proprietary service lock-in only becomes visible after you’ve invested in the platform.
There’s also a reasonable argument that for certain workloads, simpler is better, and the cheapest option on entry-level compute, with minimal service dependencies and predictable usage, genuinely is the cheapest option. This is true. It just describes a narrower set of real-world use cases than most companies assume when they’re making the initial call.
What Honest Cloud Economics Looks Like
The right framework treats cloud infrastructure as a three-year total cost problem, not a monthly invoice problem. Compute rates, egress costs at expected volume, support tier requirements, and a realistic estimate of the engineering time required to manage the platform should all enter the calculation. Exit costs, even as a rough estimate, belong in the model from day one.
Providers that make this analysis difficult are doing so intentionally. That’s worth weighing as part of the decision. The cheapest sticker price, chosen without this work, has a consistent track record of becoming the most expensive option by the time the full bill arrives.
