Start from constraints, not features
Feature comparison tables are close to useless for this decision, because every major provider can run a web application and a database. What separates them is a small number of constraints, and most projects only have two or three that matter.
Work through the hard requirements first. They usually eliminate most of the field before you have compared anything.
The constraints that actually decide it
- Data residency. If data must stay in a jurisdiction, that rules out most options immediately.
- Outbound email. If you need port 25, only a few providers permit it at all.
- Managed services. If you need a hosted foundation model, a serverless data warehouse or managed Kubernetes, the developer clouds are out.
- Existing ecosystem. If the organisation runs on Microsoft identity, Azure removes friction the others reintroduce.
- Egress volume. If the workload serves a lot of data, egress pricing may outweigh every other cost.
- Budget shape. Predictable flat monthly pricing and consumption billing suit different kinds of project.
Then ask what your time is worth
The clearest split in the market is between platforms that hand you a server and platforms that hand you a managed service. Hetzner will cost a fraction of AWS for the same raw compute, and the difference is that you run everything yourself.
For a solo developer whose time is not billed, that trade is often worth taking. For a small team shipping a product, the managed service usually wins even at several times the infrastructure cost.
Do not over-plan for scale you do not have
A great deal of cloud architecture is chosen for a scale the project never reaches. Multi-region deployment, elaborate autoscaling and service meshes all carry real ongoing complexity.
Choose for the scale you have plus one order of magnitude. Beyond that you will know more than you do now, and rebuilding with real traffic data is a better outcome than guessing today.
Lock-in is real but often overstated
Managed services are where lock-in lives. Plain virtual machines and object storage are broadly portable; a serverless data warehouse or a proprietary event system is not.
That is not a reason to avoid managed services, which are frequently worth it. It is a reason to know which parts of the stack would be expensive to move, and to make that choice deliberately.
Multiple accounts are normal
Nothing requires a single provider. Running application servers on a developer cloud, sending email through a dedicated service, and keeping one hyperscaler account for a managed service you cannot get elsewhere is a perfectly ordinary arrangement.
Separate accounts also isolate environments and make cost attribution obvious, which is worth something on its own.
Related cloud accounts
This guide applies across providers. The cloud account catalogue lists every platform with its configurations and prices, and the comparison table puts them side by side.
Further reading
- OVHcloud Accounts: What You Get and How to Choose a Configuration
- Taking Full Ownership of a Cloud Account After Handover
- DigitalOcean vs Hetzner: Which Cloud Account Should You Buy?
- European Cloud Providers and Data Residency
Frequently asked questions
No. AWS has the broadest catalogue, but breadth is only an advantage if you use it. For a plain application server, a developer cloud is usually cheaper and simpler.
Often, yes. Using the right platform per component is common and generally sensible, provided you are not duplicating the same workload across two clouds for no reason.
Enough to know which components would be hard to move, not enough to avoid managed services that genuinely save time.
