Clever Cloud instead of AWS, Azure and Vercel
Cloud hosting is where sovereignty gets expensive to talk about and cheap to demonstrate, so let us be concrete: this site and the platform behind our advisory work both run on Clever Cloud, in Paris.
That is not a testimonial. It is the reason we can write about European hosting without it being theoretical.
What it is
A French platform-as-a-service. You push code, it builds and runs it, and it manages the databases. Conceptually closer to Heroku than to AWS — deliberately.
The company is French-owned and French-operated, infrastructure is in EU data centres, and there is no US parent in the corporate structure. Applying the test from the CLOUD Act guide: the corporate nationality is European, which is the question EU regions on US providers cannot answer.
Where it is a clean swap
If what you run is:
- A web application or an HTTP API
- With a managed database behind it
- Some background workers
- Object storage
...then this is a straightforward replacement, and it is often simpler than what you have. A great deal of AWS complexity exists to serve requirements most organisations do not have, and carrying that complexity has a permanent cost in expertise and attention.
The migration for this class of workload is mostly a deployment-pipeline change, not an architectural one.
Where the hyperscalers still win
Breadth. AWS has hundreds of managed services and some of them are genuinely excellent and genuinely irreplaceable if you have built on them.
If your architecture depends on a specific managed queue, a particular data warehouse, a hyperscaler ML platform or an identity product, moving means rebuilding that capability. That may be worth it or it may not, but it is a rebuild and should be costed as one.
The question worth asking honestly: how many of those services do you actually use? Teams frequently discover the answer is three or four, all of which have standard equivalents. Teams also sometimes discover the answer is fifteen, and then the answer is to stay.
| Your situation | Sensible answer |
|---|---|
| Web app plus database plus workers | Clever Cloud; likely simpler than today |
| Static site or frontend on Vercel | Clever Cloud or another EU host; straightforward |
| Deep use of specific AWS managed services | Stay, or move selectively |
| Regulated data with EU residency requirements | Move that system, whatever the effort |
| Kubernetes-based platform with a platform team | Different question — EU IaaS providers, not PaaS |
The comparison that actually matters
Not feature count. Exit cost.
The EU Data Act's cloud-switching provisions, applicable from September 2025, exist because switching costs were the real lock-in — egress charges and friction, not contracts. Ask any provider, including this one:
- What does it cost to get all my data out?
- What format does it come in?
- Could I stand this application up somewhere else from what I hold today?
A provider you can leave is a provider you can safely commit to. That test is independent of jurisdiction, and it is the one most organisations skip.
What moving looks like
Smaller than expected for a standard application, because a PaaS removes work rather than adding it:
- Containerise or confirm your app runs from a standard buildpack.
- Provision the managed database and restore a dump into it.
- Point a staging domain at it and run both in parallel.
- Move DNS with a hard cut-over date.
- Keep the old environment for a defined rollback window, then decommission it deliberately.
The same sequence as any migration. The platform replacement guide applies here too.
The verdict
For standard web and API workloads — which is most workloads — this is a clean, unambiguous European answer, and one of the few on this list with no jurisdictional asterisk attached.
For a deep hyperscaler architecture it is not a like-for-like replacement and does not pretend to be. Decide per system rather than per organisation, which is the same advice as everywhere else in this series.
Frequently asked questions
- What workloads is this genuinely suitable for?
- Web applications, HTTP APIs, background workers, and managed PostgreSQL, MySQL, MongoDB and Redis. That covers the large majority of business systems. If that describes what you run, the migration is mostly a deployment-pipeline change rather than an architectural one.
- Where does it not compete?
- Breadth of managed services. If your architecture depends on a specific hyperscaler service — a particular managed queue, ML platform, data warehouse or identity product — there is no equivalent and you would be rebuilding that capability. Be honest about how many of those you genuinely use versus how many you assume you need.
- Is a smaller provider a reliability risk?
- It is a different risk, not automatically a larger one. Hyperscalers have excellent underlying reliability and enormous blast radius when they fail. A smaller provider has a smaller blast radius and less depth. What actually matters is your own architecture: backups you have restored, a deployment you could repeat elsewhere, and an exit path you have tested.
- How does the cost compare?
- Usually favourably for steady-state workloads, and more predictably — the pricing is simpler and there are no egress charges of the kind the EU Data Act's switching provisions were written to address. Compare on your actual usage rather than list prices, as with any infrastructure decision.