Every cloud comparison post follows the same structure: a table of services, a paragraph on pricing, a conclusion that says "it depends on your use case." That conclusion is correct and completely useless, because nobody tells you how to describe your use case in terms that actually discriminate between the platforms.
So let's do that part instead. Four measurable properties. You can collect all of them in an afternoon.
1. Request profile
Instrument or estimate your request distribution over a representative week. What you want is the ratio of peak to median, and the shape of the trough.
steady-state peak/median ≈ 2–3, trough well above zero
spiky peak/median ≈ 10+, trough well above zero
bursty-to-zero long periods with literally no traffic
This determines whether scale-to-zero is worth architecting for. If your trough never approaches zero, scale-to-zero buys you nothing and costs you cold-start latency. If you have genuine idle periods — internal tools, early-stage products, batch-driven systems — it changes the economics substantially, and Cloud Run's model is simpler to reach than assembling the equivalent on the other side.
The common mistake is optimising for a spiky future while running a steady-state present, and paying the complexity cost for two years before the spikes arrive.
2. Data volume and egress direction
Two numbers: projected storage at twelve months, and monthly bytes leaving the provider network.
The second one is the one people miss. Egress is priced very differently from everything else in cloud billing, and it is the mechanism by which a decision becomes irreversible. Things that generate more egress than teams expect:
- Serving media or large payloads directly from object storage without a CDN in front
- Cross-region replication configured during an availability panic and never revisited
- Analytics pipelines that export to a third-party tool on a schedule
- A hybrid setup where one system lives elsewhere and chats constantly with the rest
Measure this before it becomes structural. Once you hold tens of terabytes, the exit cost is real money on top of a multi-month project.
3. Statefulness ratio
Roughly what proportion of your system is stateless request handling versus long-lived state — connections, queues, caches with meaningful contents, and databases you cannot casually restart?
This is a portability metric more than a performance one. The stateless portion moves between providers for approximately the cost of a container build. The stateful portion is where migrations spend their time and where provider-specific behaviour actually bites: failover semantics, replica lag characteristics, backup and restore mechanics, connection pooling behaviour under load.
A system that is 90% stateless is a system whose provider choice is mostly reversible. A system with five stateful services wired to provider-specific managed products is not.
4. Inference intensity
Model calls per user action, and the hosting mode for each.
hosted API → cost decoupled from cloud provider
self-hosted → cost dominated by accelerator availability
hybrid routing → small local model + escalation to hosted
This is the number that has changed most since 2023 and the one most likely to be missing from your estimate.
If you are calling a hosted frontier model, your cloud provider has almost nothing to do with your inference cost. You are paying a per-token rate to a third party; the provider affects egress and latency around the call and nothing else. AI should not influence your cloud choice at all in this case, regardless of what either platform's marketing suggests.
If you self-host open-weights models at scale, the calculus inverts and the binding constraint becomes accelerator availability in your region during a demand spike — not headline per-hour pricing. Evaluate that concretely, with a real quote, before it decides anything.
The hybrid pattern — a small self-hosted model handling high-volume classification, escalating to a hosted model for hard cases — is usually the strongest economic design and is deliberately provider-agnostic.
What the numbers imply
Once you have the four, the mapping is fairly mechanical:
- Large analytical dataset, unpredictable query patterns → the operational simplicity of a serverless warehouse is worth real money and can decide the choice on its own.
- Container-native, many services, small platform team → managed Kubernetes with the least residual node management wins; this is a team-size argument, not a technology argument.
- Enterprise go-to-market, compliance-heavy buyers → ecosystem density and auditor familiarity reduce sales friction more than any technical difference helps you.
- High statefulness, provider-specific managed services → decide carefully now, because you are choosing for longer than you think.
- Heavy self-hosted inference → evaluate accelerator supply concretely on both platforms; treat the rest as secondary.
- Everything else → either works. Pick the one your team knows, and spend the saved deliberation on your actual product.
The part that matters more than the choice
Write down the decision. Three sentences on what you chose, three on the assumptions behind it, three on what would make you revisit. Calendar reminder at twelve months.
I have reviewed a lot of infrastructure that made sense when it was built and stopped making sense eighteen months later, and in essentially every case the failure was not the original decision. It was that no one knew what the decision had assumed, so nobody noticed when the assumptions stopped holding.
Full write-up with the database comparison, GKE/EKS specifics, migration cost breakdown and the multi-cloud question: AWS vs Google Cloud for Startups. If you want another pair of eyes on an architecture decision, we do that too.
Frequently Asked Questions
Can I run this exercise before I have production traffic?
Yes, with estimates. Even rough numbers force the right conversations — particularly the inference intensity one, which is where estimates diverge most from reality. Redo it once you have three months of real traffic; the difference between projection and measurement is itself informative.
How do I measure egress if I do not have monitoring yet?
Both providers expose network egress in billing exports broken down by service. If you are pre-launch, estimate from payload size times expected request volume, and add a large margin for anything serving media directly from object storage.
Does a high statefulness ratio mean I should avoid managed services?
No — managed services are usually worth it. It means you should know which ones have no equivalent elsewhere and record why you accepted the coupling. A proprietary queue is fine. A proprietary queue plus workflow engine plus identity service, all load-bearing, is a one-way door you walked through without noticing.
Should a small team run Kubernetes?
Usually not at first. Kubernetes solves coordination problems that appear with many services and many engineers, and it costs velocity before those problems arrive. Two managed container services and a managed database carry most products a long way past product-market fit.
Is Lambda or Cloud Run the safer bet for portability?
Cloud Run, because the deployment unit is a container and containers move. A Lambda-native architecture with functions wired together through provider-specific event plumbing is meaningfully harder to relocate — though if your system is already event-driven across many AWS services, fighting that grain costs more than it saves.
What is the single highest-value number to get right?
Egress direction and volume. It is the cheapest to measure, the most commonly missed, and the one that determines how long your decision stays reversible.
Top comments (0)