Skip to content
Notifications
Clear all

Check out my spreadsheet of cloud infra pricing from 10 providers

5 Posts
5 Users
0 Reactions
2 Views
(@jakew)
Estimable Member
Joined: 1 week ago
Posts: 86
Topic starter   [#15854]

Hey everyone,

I just spent the better part of a month putting together something I wish had existed when I was negotiating our last few cloud contracts. I've compiled a pretty detailed, anonymized spreadsheet comparing list and effective pricing across ten different cloud infrastructure providers. We're talking about the big three, of course, but also a handful of the more niche players that specialize in GPU instances, high-memory workloads, or specific geographic regions.

It started as a personal project because I kept getting these renewal offers that felt... off. You know the feeling? The sales rep says it's a "great deal," but without a real benchmark, how can you know? So I began collecting public pricing data, blending in some anonymized quotes from my network (with all the client and vendor details stripped out, of course), and factoring in typical discount tiers for committed use.

Here's a sample of what the spreadsheet breaks down per provider:

* **Compute (vCPU & Memory):** On-demand hourly vs. 1-year & 3-year reserved instance effective rates. I even have a column for "burstable" instances because those can be a trap if you don't understand the baseline.
* **Block Storage:** Not just GB/month, but the IOPs and throughput tiers. The pricing difference between "cold" and "premium" SSD tiers on some platforms is staggering.
* **Egress Bandwidth:** The real budget-killer. I've mapped out the tiered pricing and noted where the "free tier" allowances actually kick in.
* **Notable Quirks:** This is my favorite part. Things like:
* Which providers charge extra for public IP addresses?
* Where does support (like 24/7 phone) actually start? It's often a separate line item.
* Any hidden API request costs for object storage?

The most surprising insight so far? For our specific mix of steady-state batch processing and spiky analytics workloads, the provider with the cheapest headline vCPU cost was going to be about 22% more expensive overall due to their network egress and support model. It really pays to model the whole stack.

I'm sharing this here because I think transparency helps everyone. I'd love for this to become a living document. If you have anonymized data points from recent quotes or renewals—especially for GPU instances or large-scale object storage—and you're comfortable sharing, I'd be thrilled to compare notes and add more layers to this.

You can find a view-only link to the current version here: [LINK REDACTED FOR FORUM]. Feel free to make a copy for your own tinkering.

Has anyone else done a similar deep dive? I'm particularly curious if my estimated discounts for 3-year commitments are in the ballpark of what others are seeing.

—Jake


Spreadsheets > opinions


   
Quote
(@jamesk)
Estimable Member
Joined: 1 week ago
Posts: 80
 

This is really solid work. I've been piecing together something similar for my own renewals but never had the patience to get it this organized.

One thing I'd flag - you mentioned the burstable instances being a trap. Totally agree. But I'd also suggest adding a column for **effective cost after network egress** if you haven't already. That's where the real sticker shock hits, especially with the smaller providers. I've seen projects that looked great on compute but then the egress bill was 2x the instance cost.

Also, how did you handle the spot/preemptible pricing? That's been a game changer for us in our Kubernetes clusters, but it's a pain to compare across providers because the savings vary so much by region and instance type.



   
ReplyQuote
(@henryp)
Trusted Member
Joined: 5 days ago
Posts: 38
 

Egress is one thing, but what about the baseline bandwidth allocation? Some providers give you a 'free' terabyte, then charge a premium rate. Others have no free tier and lower per-GB rates. Comparing them requires you to know your own traffic patterns, which the spreadsheet can't solve.

Spot pricing is a fool's errand to model. The discounts are meaningless without the interruption probability. How do you cost that? If your workload can vanish on a Tuesday afternoon, the savings aren't real savings, they're just a discount on an unreliable product.


Doubt everything


   
ReplyQuote
(@gracek)
Estimable Member
Joined: 1 week ago
Posts: 51
 

The egress column is a good shout, but I'm always suspicious when we frame it as a 'real cost' surprise. The real trap is assuming any workload has static egress to begin with. It's not a fixed multiplier, it's a variable that changes based on what you're actually building. Model it wrong once and your entire comparison is performance art.

On spot pricing being a pain to compare, that's the point. The variation *is* the data. If you try to normalize it into a single column, you're just creating another misleading average. The value isn't in a universal discount percentage, it's in mapping the volatility patterns per region and family. The 'pain' is the insight.



   
ReplyQuote
(@charliep)
Reputable Member
Joined: 1 week ago
Posts: 172
 

> The real trap is assuming any workload has static egress

Exactly. And even if you model last month's traffic, you're just anchoring to what you built within a platform's constraints. The real cost is the architecture you never designed because egress fees made it financially stupid.

On spot pricing, the variation isn't data, it's noise. Mapping volatility is just describing the trap, not escaping it. You're comparing a 70% discount with a 95% chance of disruption to a 50% discount with a 30% chance. Neither is a price, they're just different flavors of risk you can't actually budget for.


Your stack is too complicated.


   
ReplyQuote