Cloud Pricing Is Designed to Be Impossible to Compare

The three major cloud providers publish millions of individual prices. AWS alone lists over 1.6 million distinct SKUs across its services. Google Cloud and Azure are not far behind. None of this transparency is accidental, and none of it makes comparison easier. The complexity is the point.

Understanding why requires looking past the listed rates and into the structural choices that govern how cloud computing is actually sold and consumed. This is not a story about hidden fees, exactly. It is a story about how legitimate pricing decisions, stacked on top of one another, produce a system that is functionally unnavigable for any customer trying to make a rational purchase.

The Unit Problem

Compare anything and you need a common unit. Cloud providers ensure no common unit exists.

AWS prices compute in terms of instance types (c6i.xlarge, m5.2xlarge, r6g.large) defined by combinations of vCPUs, memory, network performance, and processor generation. Azure sells similar resources under different families with different naming conventions. Google Cloud uses a similar but not identical taxonomy. When AWS says a c6i.xlarge costs a certain amount per hour, that instance type does not exist on Azure or Google Cloud. The closest equivalent might be an Azure D4s v5 or a Google Cloud n2-standard-4, but the underlying hardware, the hypervisor, the network performance guarantees, and the burst behavior all differ in ways that matter for real workloads.

This means price comparison requires benchmark parity, which requires running actual workloads on each cloud, which requires accounts on each cloud, expertise on each cloud, and weeks of engineering time. Most companies do not have this. So they don’t compare.

Egress as a Moat

The most consequential pricing decision in cloud computing is egress fees, and it is rarely discussed as the strategic weapon it actually is.

Moving data into a cloud is free. Moving it out costs money, and the fees are not trivial. AWS charges for outbound data transfer at rates that vary by destination and volume tier. A company with several petabytes of data in AWS S3 faces an extraction bill that can easily run into millions of dollars before they’ve even thought about re-ingesting that data somewhere else. The same logic applies to Azure and Google Cloud.

This is not incidental. Egress pricing converts a commodity infrastructure decision into a long-term structural commitment. Once your data is in, leaving becomes a capital expenditure, not an operating one. The lock-in is so severe that the European Union’s Cloud Services Regulation, which took effect in 2024, specifically targeted egress fees, requiring providers to allow customers to switch or port data to competitors without excessive charges. The fact that regulation was required tells you everything about how voluntary change was going.

A company evaluating cloud providers based on compute rates is like evaluating a mortgage based only on the monthly payment and ignoring the prepayment penalty. The headline number is real. The exit cost is what actually governs your options.

Commitment Discounts Make Comparison Worse

AWS Reserved Instances, Azure Reserved VM Instances, and Google Cloud Committed Use Discounts all offer significant savings, commonly 30 to 60 percent, in exchange for one or three-year commitments. This is a reasonable trade. The problem is that commitment discounts interact with the unit problem in ways that make comparison nearly impossible.

When you commit to a Reserved Instance, you’re committing to a specific instance family, region, and sometimes a specific instance size. AWS has partially addressed this with Convertible Reserved Instances, which allow you to exchange for a different instance type, but at a lower discount. The flexibility costs money. The rigidity saves money. Neither option maps cleanly onto a competitor’s equivalent.

Meanwhile, the on-demand prices that appear on comparison sites and in press coverage are the rates almost nobody actually pays for significant workloads. They’re list prices, the equivalent of MSRP for a car. The real prices are negotiated, reserved, or covered by Savings Plans, a newer AWS construct that offers flexibility across instance families but requires predicting spend patterns a year or three in advance.

You cannot compare clouds using the listed prices because the listed prices are not what large customers pay. You cannot compare using real prices because real prices require signed commitments that differ by provider. The comparison problem is structural, not solvable by a spreadsheet.

The Services Entanglement

Even if you somehow normalized compute pricing, modern cloud bills are not primarily compute costs. They are an accumulation of dozens of adjacent services, each priced differently, each with its own discount structure.

A typical production application running on AWS might generate costs across EC2, RDS, ElastiCache, S3, CloudFront, Lambda, API Gateway, and Route 53, plus data transfer between each of those services. AWS charges for inter-region transfer differently from intra-region transfer, differently again from transfer to the internet. CloudFront has its own origin-fetch pricing on top of its distribution pricing. RDS charges for storage, IOPS, and instance type separately, and Multi-AZ deployments cost roughly double.

Azure and Google Cloud have equivalent complexity with different structures. Azure Blob Storage pricing differs from AWS S3 pricing in its tier thresholds and retrieval fees. Google Cloud BigQuery is priced on queries processed rather than instance hours, which makes it genuinely incomparable to any equivalent AWS or Azure analytics service.

This services entanglement matters because migrating between clouds is not just moving virtual machines. It is re-architecting integrations, retraining teams, and accepting that services which feel equivalent often behave differently under load. An application built heavily on AWS Lambda and API Gateway cannot be transplanted to Azure Functions and API Management with confidence that the cost model will be similar. The services are different products that happen to serve similar purposes.

Enterprise Agreements and the Private Market

For large enterprise customers, the publicly listed prices become almost fictional. AWS Enterprise Discount Program agreements, Azure Enterprise Agreements, and Google Cloud Enterprise contracts are negotiated privately and subject to NDA. Discounts of 20, 30, even 50 percent off list are available to customers with sufficient spend or strategic value to the provider.

This creates a two-tier market. Startups and mid-market companies pay something closer to list. Large enterprises pay negotiated rates that are invisible to everyone else. The implication is that a startup comparing public prices against a competitor that has an enterprise agreement is not comparing the same cost structure at all. Cloud costs as a competitive input are not standardized. Two companies running nearly identical workloads can have dramatically different unit economics based solely on their negotiating leverage.

This has downstream consequences for startup benchmarking and competitive analysis. Your runway number is almost certainly wrong in part because infrastructure cost modeling tends to use public prices as a baseline, which overstates actual costs for large players and understates the advantage they hold.

Why Simplification Would Cost Them

Cloud providers are not unaware of pricing complexity. They employ product managers, economists, and pricing specialists whose job is to think carefully about how services are priced. The complexity is not an oversight.

Simpler, more comparable pricing would accelerate commoditization. If AWS compute were priced in a way that made direct comparison with Google Cloud trivial, the price would be the product. Margins would compress. The hyperscalers would compete the way airlines compete on economy fares, which is to say badly, for everyone involved except the customer.

Instead, complexity sustains differentiation. A company that has spent years training its engineers on AWS tooling, building automation around CloudFormation, integrating with IAM, and tuning RDS parameter groups has made capital investments that are not easily transferable. The pricing system reinforces this. Each new service with its own pricing model is another strand in the web.

This is not unique to cloud. Complexity as competitive strategy appears in telecommunications, financial services, and health insurance. But cloud is notable because it markets itself on transparency, on the idea that you pay for what you use and can see exactly what that is. The pricing pages are public. The calculators are free. The opacity is structural, not rhetorical.

What This Means

For engineering and finance teams trying to control cloud spend, a few things follow from this analysis.

Public price comparisons are not starting points, they’re noise. Any serious evaluation needs to account for the workloads you actually run, the commitment structure you can sustain, and the exit costs you would face after migration. The total cost of ownership calculation includes the engineering time to migrate, the re-training, and the architectural changes, not just the monthly bill delta.

Egress pricing deserves more weight than it typically gets in vendor selection. The upfront compute rates are competitive. The lock-in mechanism is egress, and the cost of switching after significant data accumulation can dwarf any savings from a lower hourly rate.

For startups in particular, the negotiating leverage question matters more than the list price. Growing into better rates is possible, but the path requires volume commitments that carry their own risk. Understanding that your larger competitors likely pay substantially less for the same infrastructure is a useful corrective to naive cost benchmarking.

The cloud pricing system rewards customers who can afford to model it rigorously and punishes those who can’t. That asymmetry is not a bug. It is a feature of a market where the sellers have thought much harder about pricing than the buyers have.