Not the one I started on. Azure in production first, then AWS, with Google Cloud tried along the way. AWS for SMEs and enterprises that plan to grow, Hostinger for an always-on agent box, and AI to carry AWS's complexity.
The short version
| Option | What it's for | Why it isn't my default (or why it is) |
|---|---|---|
| AWS | SMEs and enterprises with specific requirements that expect to grow | It is my default: open-source primitives that compose, and a service for almost every enterprise need. You have to be a pro, and AI now carries much of that. |
| Google Cloud | A client already on it, BigQuery-centred analytics, containers that scale to zero | Nice primitives, but not enterprise-complete. Google builds for Google first. |
| Microsoft Azure | A client all-in on Microsoft, with Entra ID as the directory | Its own concepts instead of real primitives, a bill you can't read, and a black box. |
| Hostinger VPS | One always-on box for agents, scheduled jobs and previews | Not a cloud: shared CPU, restarts, no SLA, no GPUs. For that one job, nothing I've found beats its price. |
| DigitalOcean | Simple VMs and managed databases for small teams | I've never used it, so I have no verdict. People I trust say there's something good there. |
People often assume a consultant recommends a cloud because it's the only one they've used. Not here. This is the order I learned them in, and what each one taught me.
Azure first, and why I left
The cloud I first ran in production was Windows Azure, from 2012, when the cloud was something only startups did. Before that I'd used cloud services only on personal projects. I was a .NET and C# developer, so Azure was the obvious choice, and with nothing to compare it with, I took it as the benchmark.
It was a pain from start to finish:
- Concepts instead of primitives. Rather than expose the real building blocks, Microsoft wrapped them in its own no-code-style abstractions with its own vocabulary. You learn Microsoft's concepts rather than how the system works, which makes it hard to understand and hard to know what you're paying for.
- Prices that moved under us. We ran on Microsoft's cloud SQL database. Microsoft retired the editions we were on and moved everyone to new service tiers, and our bill jumped several times over. There was nothing we could do about it.
- Uptime and slow deploys. Outages we couldn't explain, and deployments that took far longer than they should.
What changed my mind wasn't another cloud. It was open source. As I moved away from .NET and ASP.NET, things started to make sense. Linux and the open-source tools around it are made of small components, each easy to understand and predictable. Because they're predictable, they compose: you build complicated systems by assembling simple parts. The Microsoft stack is the opposite. So I dropped .NET completely, moved to Node.js and full-stack JavaScript, and moved to AWS.
AWS: a breath of fresh air
AWS is, for the most part, open-source building blocks made to run in the cloud: virtual machines, Postgres and MySQL, Redis, Kafka, OpenSearch, containers, an object store, a queue. The same kind of primitives I'd just learned to trust, as services. Everything was easier to understand, and everything composed.
It isn't all rosy:
- IAM. Policies are JSON documents of actions, resources and conditions. Getting them least-privilege by hand was a nightmare.
- Security groups and network ACLs. Two layers of firewall rules that behave differently. They're what melts everybody's head when they first land on AWS.
- Back pressure by hand. Slowing consumers down so a spike doesn't flatten the database means combining SQS, Lambda's maximum concurrency, visibility timeouts and retry counts yourself.
- You have to be a pro. It's not for non-technical people. Someone who isn't a pro drowns, and then gets very angry.
Google Cloud: nice primitives, built for Google
Google sits between Azure and AWS. Like Microsoft, it adds its own concepts on top of the primitives, but unlike Microsoft's, they work. Two I miss on AWS:
- Cloud Run. Give it a container and it scales, down to zero. One instance serves many requests at once, where a classic Lambda environment serves one, so it absorbs traffic with fewer instances.
- Cloud Tasks. A queue with a dial: set a maximum dispatch rate and a maximum number of tasks in flight, and it holds the rest back. On AWS you build that out of SQS settings.
I stopped using it because it doesn't cover everything an enterprise needs. I think that's because Google's biggest client is Google: it builds what it needs first, then opens it to everyone else. AWS builds for its clients. For the companies I work with, that's the difference.
Why AWS is the safe bet for enterprise
SMEs and enterprises have specific requirements: compliance evidence, data residency, private networks, corporate sign-in, auditors, and a system that may need to do something very different in three years. AWS is the most versatile cloud for that. Whatever comes next, there's almost certainly a service for it, so growth doesn't force a migration. For a company that plans to scale, there's no safer bet.
The cost of that bet is the expertise it demands, and that's what AI is changing. A least-privilege IAM policy, a security group that references another, an SQS queue with the right visibility timeout: that's detailed, well-documented work, exactly what agents like Claude Code and Codex are good at. It's now largely the agent's problem, with a human reviewing it. The complexity is still there. Who carries it has changed.
Where AWS isn't the answer: the agent box
My own agents don't run on AWS. They run on a Hostinger VPS, and it's the one place in this catalog where I don't start with AWS.
An agent that works through the night while you sleep needs a machine that's always on, not serverless. On a one- or two-year term, Hostinger's VPS is the best price I've found for that, by a wide margin, and an always-on server with the same RAM on AWS would cost several times as much. It's also easy to start: Hostinger has one-click templates that stand up n8n or an agent like Hermes on a fresh box.
The price has reasons. The CPU is shared and runs on credits, and the box isn't very reliable: it gets restarted more than I'd like. For agents that's survivable, because Claude Code and Codex can resume a session where it stopped. It stops being the right box when you need real dedicated CPUs, GPUs, or more than the largest plan (8 vCPU and 32 GB of RAM). Then the job goes back to AWS.
DigitalOcean
I've never used it, so it gets no verdict in this catalog. Everything here comes from running things in production. I hear there's something good there, mostly simplicity for small teams. If I ever test it properly, it will earn an entry like everything else.