The cloud question, asked properly
"Should we be on AWS / Azure / GCP / Hetzner / OVH" is a question that gets asked at a level too abstract to answer. The right question is: "given our workload's compute / storage / network / managed-services profile, latency requirements, compliance constraints, and team capability, which platform produces the lowest total cost over the 3-year horizon".The answer for most teams in 2026 is "two of those, depending on the workload". Below is the framing.
AWS — the broad default
Strengths: the broadest service catalog, the deepest documentation, the strongest ecosystem of third-party integrations. The default for most engineering teams who haven't been forced to specialise.Trade-offs: cost. Egress charges in particular are the part that surprises new customers. Vendor lock-in via managed services (Aurora, Lambda, DynamoDB) is real and accumulates.
Use when: broad workload mix, team comfort matters, willingness to invest in cost optimisation work, no specific reason to be elsewhere.
Azure — the enterprise default
Strengths: Microsoft enterprise integration (Active Directory, Office 365, Power Platform), strong .NET tooling, regional / sovereign cloud offerings in markets AWS doesn't serve directly.Trade-offs: some services lag AWS equivalents in maturity. Documentation and community resources can be thinner.
Use when: enterprise customer with Microsoft footprint, regional compliance requirements that Azure addresses better than competitors, .NET-heavy stack.
GCP — the data + ML default
Strengths: BigQuery, Vertex AI, Spanner, Pub/Sub. Where the data and ML stories are state-of-the-art. Networking is excellent (Google's backbone).Trade-offs: smaller third-party ecosystem. Some services are best-in-class, others are notably thinner. Sales / enterprise relationship can lag AWS / Azure.
Use when: data-heavy workload, ML platform requirements, teams that already know the GCP idioms.
Hetzner — the cost play
Strengths: dramatic cost difference. Dedicated servers and cloud instances at a fraction of hyperscaler pricing. Strong in EU (mostly Germany, Finland).Trade-offs: much smaller managed service catalog. You build more yourself. EU-centric — multi-region globally is harder. Customer support story is "good enough", not enterprise-grade.
Use when: cost is the binding constraint, the workload doesn't need a wide managed-service catalog, the team is competent enough to manage more themselves.
OVH — the EU sovereign play
Strengths: EU-headquartered, strong sovereignty story, GDPR-friendly defaults, expanding service catalog. Pricing is competitive.Trade-offs: documentation and community are thinner than hyperscalers. Service maturity varies. The 2021 Strasbourg fire incident is sometimes cited (recovery story has been documented since).
Use when: EU sovereignty matters, customer requires non-US infrastructure provider, cost matters but Hetzner's catalog is too thin.
The decision matrix
- Generalist workload, hyperscaler default → AWS, unless reason to choose otherwise
- Microsoft-heavy enterprise → Azure
- Data / ML platform requirements → GCP, with AWS as the "respectable default" alternative
- Cost-driven, EU acceptable → Hetzner for compute, hyperscaler for managed pieces
- EU sovereignty mandated → OVH or Scaleway
- Highly regulated industries with regional sovereignty rules → may force Azure or a sovereign-cloud variant
The multi-cloud reality (and the over-claim)
"Multi-cloud" is often the stated strategy. In practice, most "multi-cloud" deployments are: workload primarily on cloud A, disaster recovery on cloud B, occasional service borrowed from cloud C. True multi-cloud (workload runs identically on multiple clouds) is engineering work — abstracting away each cloud's idioms, accepting the lowest-common-denominator feature set, paying integration cost on every change. Worth it for some workloads, expensive for most.The cost-optimisation conversation
Whatever cloud you pick, plan for cost optimisation. The patterns:- Reserved / savings plans for steady workloads (usually 30-50 % savings vs on-demand)
- Right-sizing reviews quarterly (instances are almost always over-provisioned)
- Egress audits — egress is the silent cost killer
- Tagging discipline — without it, cost attribution is impossible
- Cost anomaly alerting — set thresholds; budgets that surprise you are the budgets that derail.
One pattern we'd warn about
Building cloud-agnostic infrastructure code "just in case we move clouds". The "just in case" rarely happens, and the cost of agnosticism is paid every day. Pick a cloud, commit, accept the lock-in for what it gives you.One pattern that always pays off
Pricing-aware architecture. Knowing the cost of egress, the cost of storage tiering, the cost of cross-AZ traffic — and designing accordingly. The 10 % of architects who think about cost during design save the company multiples over time.What's your stack? And — for the EU folks — has anyone successfully migrated production workloads to Hetzner from a hyperscaler in 2026?
