The vendor comparison is the least useful part of this decision - the parts that actually determine whether you regret it are egress pricing, region coverage, how much of your architecture becomes vendor-specific, and how much of the stack you have signed up to operate.
Most published guidance here is produced by vendors and reaches the conclusion you would expect. That does not make it dishonest, but it does mean the criteria on offer are the ones that favour whoever wrote the page. It is worth assembling your own list first.
Table of contents
- Decide the layer before you decide the vendor
- The four criteria that predict regret
- Hyperscaler or not, stated plainly
- Multi-cloud, and why it usually is not the answer
- A short procedure
- How this fits the rest of the stack
- FAQ
Decide the layer before you decide the vendor
This is the step people skip, and it is the one that dominates everything else. Picking a provider before deciding how much you want to operate is choosing a shop before knowing what you are buying.
- Raw infrastructure. Virtual machines, block storage, networks. You own the OS, patching, runtime, deploys, certificates, and monitoring. Maximum control, and a permanent operational commitment.
- Managed platform. You push code and the provider builds and runs it. You own the application and nothing beneath it. Less control, and dramatically less recurring work.
- Managed services around either. Databases, object storage, queues, caches. Almost always worth taking, even if you run compute yourself. Running your own database to save money is one of the most reliably regretted decisions in this area.
Once the layer is settled, the vendor shortlist usually writes itself, because most providers are clearly stronger at one layer than the others.
The four criteria that predict regret
- Egress pricing. Compute is close to a commodity and the rates cluster. Data leaving the provider’s network varies enormously - by more than an order of magnitude between hyperscalers and smaller providers - and it is the line item that generates surprise bills. Estimate your real monthly transfer and price it at each candidate’s published rate before anything else.
- Regions where your users are. Latency is not fixable in software later, and data residency is not negotiable if a regulation applies to you. This is the criterion most likely to eliminate an otherwise attractive option, so apply it early.
- Depth of managed services you will genuinely use. Not catalogue size. The specific list: a managed database of the type you need, object storage, a load balancer, and somewhere to read logs. A provider missing one of those means you operate that piece.
- Exit cost. How much of your architecture would need rewriting to leave. A container and a Postgres database migrate over a weekend. A system built from a dozen proprietary managed services does not migrate at all in any practical sense.
Pricing per vCPU, which is where most comparisons start, belongs near the bottom of this list. It is the most visible number and the least likely to be the one that hurts.
Hyperscaler or not, stated plainly
The large providers earn their position on breadth, region coverage, compliance certifications, and the depth of the managed-service catalogue. If you need a managed Kubernetes platform, a serious data warehouse, machine learning infrastructure, or a specific compliance attestation, they are frequently the only realistic answer and there is no shame in that.
You pay for that breadth in ways that are easy to underestimate. Identity and access management is genuinely difficult and permission debugging becomes a recurring tax. Egress is expensive. The console has hundreds of products and architectures sprawl because every problem has three official solutions. Cost attribution across a large account is its own discipline requiring its own tooling.
Smaller providers and application platforms win on predictable pricing, lower egress, and far less to learn. They lose on catalogue depth, region count, and the long tail of compliance paperwork that large customers ask for.
Neither is a mistake. The mistake is choosing a hyperscaler by default for a workload that is one web service and a database, and then spending a quarter on IAM policies for a system that could have been deployed in an afternoon.
Multi-cloud, and why it usually is not the answer
Multi-cloud gets proposed as insurance against lock-in and outages. In practice, for teams below a substantial size, it usually delivers neither and costs a great deal.
Running genuinely across two providers means using only the intersection of their features, duplicating operational knowledge, paying egress between them, and doubling the surface area of everything from monitoring to access control. Teams that attempt it without a dedicated platform group generally end up with one real provider and one expensive, half-maintained standby that has never been tested under load.
The realistic version of the same goal is portability rather than parallelism. Keep the application in a container configured by environment variables. Keep data in a standard database with a portable dump format. Avoid proprietary services for anything on the critical path. That gives you the ability to leave in weeks rather than the ability to fail over in seconds, and for most organisations that is the property they actually wanted.
A short procedure
Decide the layer. Estimate monthly egress and price it at each candidate. Eliminate anyone without a region near your users or without whatever residency you require. Check the four managed services you will actually use exist. Then, and only then, compare instance pricing.
And whatever you choose, protect the exit: environment-variable configuration, no state on local disk, a standard database. Those three cost nothing at the start and are the difference between a migration and a rewrite.
How this fits the rest of the stack
The comparison is only as good as the numbers you put in it, and the platform side is short enough to get exactly right in a few minutes. The RunxBuild hosting calculator separates the service, the database, the storage, and the bandwidth so you can set a real figure against a provider estimate. RunxBuild deploys Node, Next.js, Python, Go, Ruby, Java, .NET, and Docker from GitHub with build logs, rollback, and autoscaling, plus managed MySQL and Postgres with backups and private networking.
Useful related references:
- Terraform Helm Provider: Managing Charts as Infrastructure
- Zapier Alternatives: What Changes When Automation Runs on Your Own Infrastructure
- Codex MCP Server: The OpenAI Coding Agent as a Tool Provider, the OAuth Flow, the Tool Surface, and When to Use It
- Services on RunxBuild
FAQ
How do I choose a cloud infrastructure provider?
Decide which layer you want first - raw infrastructure, a managed platform, or managed services around either. Then compare on egress pricing, regions near your users, the depth of the specific managed services you will use, and how much of your architecture would become vendor-specific. Instance pricing comes last.
Why does egress pricing matter so much?
Because compute prices cluster closely between providers while data-transfer rates vary by more than an order of magnitude, and egress is metered on every byte leaving the network. It is the line item that produces surprise bills and the one most often missing from comparisons.
Is a hyperscaler always the safest choice?
It is the right choice for managed Kubernetes, serious data warehousing, machine learning infrastructure, wide region coverage, or specific compliance attestations. For one web service and a database it is a large tool for a small job, and you pay for the breadth in IAM complexity and egress rates.
Should I use multiple cloud providers?
Rarely, below a substantial engineering size. Genuine multi-cloud means using only the intersection of features, duplicating operational knowledge, and paying inter-provider egress. Aim for portability instead: containers, environment-variable configuration, and standard databases, so leaving takes weeks rather than being impossible.
How do I avoid cloud vendor lock-in?
Keep the application in a container that reads configuration from environment variables and holds no state on local disk, and keep data in a standard database with a portable dump format. Use proprietary managed services only where the convenience genuinely justifies the thread it stitches.