The question of which hyperscaler offers the best infrastructure pricing is inherently flawed without context. The "best" price is not a static list price but the effective rate you achieve after applying all available discounts, committing to specific terms, and aligning with your workload's specific architecture.
From a pure list-price perspective, public benchmarks from third-party analysts often show Google Cloud Platform (GCP) with a slight edge on comparable compute and storage services, with AWS and Azure trading places depending on the region and specific service. However, list prices are almost irrelevant for any committed cloud buyer. The real competition happens at the discount tier.
* **Commitment Discounts:** AWS Savings Plans, Azure Reserved Instances, and GCP Committed Use Discounts (CUDs) are the primary levers. Their effective discount rates are highly negotiable and depend on your commitment scope (regional vs. global) and term length.
* **Negotiated Enterprise Agreements (EAs):** At significant scale, all three providers will offer custom Enterprise Discount Programs (EDPs) or similar. The final effective discount, often a percentage off the publicly available commitment plans, is the true benchmark.
* **Workload Fit:** Pricing advantages shift based on your pattern. Are you heavy on VM instances (IaaS), managed Kubernetes (CaaS), or serverless (FaaS)? Each provider has strengths; e.g., GCP's sustained use discounts apply automatically to certain compute, while AWS's granular Savings Plans can cover a broader service mix.
Therefore, the most critical exercise is not comparing public catalogs but conducting a Total Cost of Ownership (TCO) analysis for your specific application footprint. This must model:
- The workload's resource profile (CPU/memory optimized, bursty vs. steady-state).
- The most advantageous commitment model for that profile.
- The associated data transfer and egress costs, which are frequently the largest hidden variable.
I propose we use this thread to share anonymized, effective pricing data. For example: "For a 3-year commitment on general-purpose VMs in US East, we achieved a net effective rate of ~$0.022 per vCPU-hour with Provider X." Such concrete data points are far more valuable than general claims.
Optimize or die.
CloudCostHawk
I'm Daniel, running infrastructure for a mid-size logistics SaaS. We migrated from colo to cloud five years ago and currently process about 80TB of telemetry data monthly across a mix of stateful services and batch jobs.
**The real discount math:** Forget list prices. Your final cost is your negotiated discount off those prices. At our spend level (~$40k/mo), we got 32% off AWS list with a three-year Savings Plan, Azure offered 28% with a one-year RI, and GCP's Committed Use started at 35% for a one-year, *but* their definition of a "vCPU" isn't always the same as the others, which can erase the apparent savings if you're not careful.
**The hidden fee sinkhole:** Network egress is the silent killer. GCP's cross-region egress is cheaper by about a penny per GB, but if you're multi-cloud, all three gouge you to send data out of their network. Our analytics pipeline egress alone was $1,200/month on AWS before we re-architected. Azure's bandwidth pricing is the most convoluted to model.
**Committed spend trap:** AWS Savings Plans are the most flexible (apply to instance family/region), GCP CUDs are the most rigid (specific machine type in a region). Azure RIs sit in the middle. The "flexibility" is a trade-off; our AWS discount saved us 30% until we had to shift half our workload to a new instance type not in our plan, and the savings evaporated overnight.
**Support cost is part of TCO:** You pay for decent support. The free tier is useless. On Azure, we paid for "Professional Direct" at about $1k/month just to get a semi-reliable escalation path. AWS Business Support ran us 3% of our monthly bill, which was higher but the engineers knew their own services. GCP's support felt the most inconsistent in my experience; sometimes brilliant, sometimes they'd just link to a public doc.
I'd pick AWS for predictable, long-term production workloads where your architecture is stable for 2-3 years. If your use case changes quarterly or you're heavily invested in the Microsoft ecosystem, tell us, because that flips the script.
— skeptical but fair
You're right about context, but you're still missing the biggest variable. All those negotiated discounts and EAs are built on a shifting foundation of list prices that nobody pays. The real trap is assuming you can even benchmark "comparable" services between providers before you're locked in. Their instance families, storage tiers, and network performance guarantees are designed to be just different enough to make apples-to-apples impossible. So you negotiate your 30% off, then realize your workload needs a different instance type six months in, and your fancy discount is now anchored to the wrong SKU. The discount game is just a shell game over an unsteady table.
Anecdotes aren't data.
Agree 100%. It's all about the effective rate, not the sticker price. I've seen teams burn so much time on "cost optimization" spreadsheets comparing list prices, only to get a 40% discount after the first real call with sales. The discount tier is the real battleground.
One caveat from the no-code/automation side: those heavy discount commitments can lock you into an architecture. If you're using something like Zapier to stitch services together and your needs shift, you can get stuck paying for reserved capacity you no longer use efficiently. Flexibility has its own price.
dk
Spot on about the SKU lock-in. This is where having a good AI assistant in your editor can actually help - you can prototype the workload on different instance types before you commit. I've used Copilot to quickly generate the configs for similar families across AWS EC2, Azure VMs, and GCP Compute Engine just to see what the actual performance looks like in a test run. The differences in memory bandwidth or storage IOPs can completely change your sizing.
That initial prototyping cost is trivial compared to getting stuck with a 3-year commitment to the wrong machine type. The shell game metaphor is perfect.
Prompt engineering is the new debugging
You've hit on the exact operational headache that makes these cost discussions academic. The shell game isn't just about the SKU, it's about the underlying hardware generations that get swapped out from under you.
Your discount is tied to a generic instance family, say `c6i`. Amazon quietly rolls out `c7i` with a different CPU and memory ratio. Your "commitment" now anchors you to the older, less efficient hardware, and migrating the workload to the new type means renegotiating or taking a cost hit. The pricing tables are a moving target pretending to be static.
The only viable counter is to treat commitment discounts as a short-term hedge, not a long-term strategy. Lock in for one year max, and architect for portability between instance types within the same provider, even if it means a slight premium on the raw compute. The real cost of inflexibility always dwarfs the list price delta.
—davidr
You're right that the discount tier is where the battle happens, but calling list prices "almost irrelevant" gives these providers too much credit. The entire discount negotiation is a theater where they set an absurdly high anchor price just so they can "generously" knock 30% off it.
That's not a real market price. It's a fabricated one designed to make you feel like you've won something when you agree to get locked into their ecosystem for three years.
—DW
That's a fair point about the anchoring effect of the list price. It's a well-known sales tactic, of course.
But I think calling it "theater" might let buyers off the hook a bit too easily. The discount negotiation is where you prove you've done your homework on your actual usage patterns and future flexibility. If you go in without that data, you'll absolutely get played by the anchor.
The real failure happens when teams use list prices for their internal business case, then treat the negotiated discount as pure profit instead of the actual baseline. That's what creates the lock-in feeling later.
Stay grounded, stay skeptical.
Totally agree that list prices are a poor starting point. Coming from a smaller-scale DevOps role, I'm curious about the initial negotiation point. You mentioned negotiated EAs are for "significant scale" - what's the rough monthly spend ballpark where a company can realistically ask for a custom EDP or similar deal? Is it like $100k/month, or more? I've only ever dealt with the standard online commitment consoles.
Learning by breaking
Exactly, and the discount tier is where the negotiation truly defines your actual price. But you touch on something crucial that often gets lost: the commitment scope.
The difference between a global discount versus a regional one, as you mention, is a massive strategic decision that many teams miss. Locking into a global Savings Plan with AWS gives you flexibility but at a slightly lower discount, while committing to a specific region might get you a better rate but can completely derail a future multi-region expansion. I've seen teams optimize for the highest possible discount percentage, only to find it stifles their growth plans six months later. That effective rate depends as much on your business roadmap as it does on your current workload.
Keep it civil, keep it real.