What is the best way to compare compute unit pricing across clouds?

I'm an integration lead at a mid-market CPG company running a direct-to-consumer stack, and I've spec'd the backend compute for our order management API (Shopify to NetSuite) and all the middleware glue that sits between them.

Your list is good, but you're thinking like an infra architect. For a CRO project where cost predictability is key, you need to compare like a procurement manager. Here's my method:

1. **Normalize to a real workload benchmark, not specs.** Forget trying to equate vCPUs. I run a simple, consistent load test (like a sustained API calculation) on the smallest viable instance for each provider. I record the time to completion and multiply by the instance's hourly cost. AWS's m6i.large, Azure's D4s v3, and GCP's n2-standard-2 are my starting points. The performance-per-dollar spread is usually 15-20% between them on identical-looking specs.

2. **Commit to a term and use their calculator, but input actual traffic.** The reserved instance/savings plan/committed use discount is where the real pricing is. For a 1-year commit, I've seen costs drop 35-40%. Don't use the calculator defaults. Input your expected CPU utilization from your current logs; if your CRO backend is spiky, a 40% average use is aggressive. For a steady background job, you can push to 70%.

3. **Price the complete unit, not the VM.** You noted load balancers. Add in: egress bandwidth costs (first 100GB is often free, then ~$0.09/GB), managed database read replicas if needed ($0.10+/hr each), and any specific OS licensing (Windows SQL Server can double a VM cost). For our API, the VM cost was 60% of the total monthly bill.

4. **Treat "burstable" as a hard no for production.** Use them for dev, but budget for the 100% CPU baseline cost. We got burned with a t3.medium for a staging environment that ran load tests; the credit bill was higher than a comparable m5.large would have been. The surprise invoice is the hidden cost.

For a new CRO backend where I need predictable latency and cost, I'd go with Google Cloud's n2d VMs on a 1-year committed use discount. You get AMD Epyc cores at a lower per-core cost, and their sustained use discount applies automatically without needing a reserved instance reservation. If your workload is highly variable with unpredictable peaks or you're already heavily invested in AWS services for everything else, tell us which one and we can narrow it down.

Benchmarking with a real workload is the only sane approach. Your load test method is solid, but you need to bake in variability.

> The performance-per-dollar spread is usually 15-20% between them on identical-looking specs.

That's the floor. I've seen it hit 40% on memory-intensive operations, especially when comparing Intel to AMD instances. Your NetSuite middleware is likely more RAM-sensitive than CPU-bound. Don't just test a calculation, test a batch JSON transform with a 500MB payload.

On the commitment point: always model the break-even. A 35% discount on a 1-year commit is worthless if your architecture changes in 8 months and you're stuck with the wrong instance family. I run the calculator with three scenarios: projected growth, flat, and a scenario where we shift half the workload to serverless.

Agreed on breaking it down by operation type. The 40% delta on RAM-intensive tasks? Absolutely. Spot the same thing running session replay processing.

Your three-scenario model for commitments is key. I'd add a fourth: model for sudden traffic spikes from a winning experiment. If you commit to steady-state capacity, a big win can become a cost nightmare overnight.

Spot on about the load balancer costs. That's such a hidden line item, especially for a CRO project where you might spin up new environments frequently. I got stung because Azure's standard load balancer isn't included, while AWS's ALB and GCP's external HTTP(S) LB are pure usage-based. My comparison sheet has a separate column for "baseline network egress" and "essential services overhead" because of that.

Your point on burstable instances is also critical for development/staging tiers. My caveat: don't just model the credits, watch the baseline performance. A t3.medium's baseline is like 20% of a CPU core, which can make integration tests crawl. I ended up using standard instances for CI/CD runners and only using burstable for idle staging environments.

One thing I'd add to your list: **sustained use discounts vs. committed use.** GCP applies automatic discounts just for running an instance most of the month, no commitment. For workloads with steady but unpredictable growth, that can be simpler than guessing your 1-year commit. But for a known, stable baseline, AWS/Azure commitments usually beat it.

You've nailed the hidden cost of the ancillary services, which is where most spreadsheet comparisons fall apart. I'd push back on one thing though.

> simpler than guessing your 1-year commit

I find GCP's sustained-use discount often lulls teams into a false sense of simplicity. It's great if you run a single VM nonstop, but once you start autoscaling, or have separate dev/staging/prod VMs, the discount application gets opaque and you're back to guessing anyway. You're still playing the prediction game, you just aren't locking yourself into a contract. For a CRO project with potential greenfield rewrites in 9 months, that's probably fine. For anything meant to last, the opacity is its own cost.

Also, that baseline performance on burstable instances is a killer. Calling it 20% of a core is generous when the credits run out and your CI pipeline is held hostage. It's a tax on developer productivity disguised as a discount.

The "essential services overhead" column is a lifesaver. I'd argue it should include the tax for logging and monitoring, which is where they really get you. On AWS you're paying per gigabyte for VPC Flow Logs, on GCP it's per-sample for Cloud Monitoring, and Azure's diagnostic settings bloat your storage account. It's never zero, and the pricing models are deliberately incommensurate.

Your note on burstable baseline performance is the whole trap. People see the low idle rate and think "dev environment savings," but forget that a `docker build` or a test suite run isn't idle. That 20% baseline turns a ten-minute job into an hour, which blows any savings and annoys your developers into demanding more expensive instances anyway.