Teams starting a new project often spend a week comparing the three largest cloud platforms and come away with a spreadsheet that says, in effect, “they can all do it”. That is a fair conclusion. Compute, object storage, managed databases, container orchestration, serverless functions, queues and identity all exist on AWS, Azure and Google Cloud, and any of them will run a normal web application without trouble.
The differences that actually change a decision are rarely feature lists. They are the things that make a team faster on one platform than another.
Start with the skills already in the room
The single strongest predictor of how a project goes is whether the people building it have used the platform before. An engineer who has written IAM policies for years will be productive on AWS in a morning and frustrated on a platform where the equivalent concepts have different names and boundaries. That familiarity is worth more than any individual service advantage.
If the team is split, weigh the person who will carry the on-call pager most heavily. Operational familiarity matters more at 3am than it does during design.
Follow the existing stack
-
Microsoft-centric organisations
If identity already runs through Microsoft tooling and the estate is largely Windows and .NET, Azure removes a category of integration work rather than adding one.
-
Data and analytics-led teams
Teams whose centre of gravity is analytics or machine learning often find Google Cloud’s data tooling the most natural fit, because the pipeline from storage to query to model training is the platform’s strongest seam.
-
Breadth and ecosystem
AWS has the widest service catalogue and by far the largest body of third-party tooling, tutorials and hiring pool. For an unusual requirement, it is the most likely to have a managed answer already.
Compare the things you will touch daily
Rather than comparing catalogues, compare the handful of surfaces the team will use constantly. Those are where friction accumulates.
| What to test | Why it matters |
|---|---|
| Console and CLI ergonomics | You will use them every day; awkward defaults compound. |
| Identity and permissions model | Least-privilege is either natural or a constant fight. |
| Infrastructure-as-code support | Check provider maturity in the tool you actually use. |
| Managed service depth | Only for the two or three services you genuinely need. |
| Region availability | Latency to your users and any data-residency obligation. |
| Billing visibility | How quickly you can attribute spend to a team or project. |
Run a one-day spike, not a three-week evaluation
The fastest way to settle the question is to build the same small thing twice: a container behind a load balancer, talking to a managed database, deployed from your existing pipeline. A day on each platform tells you more than a month of reading, because it surfaces the specific places where your stack and the platform disagree.
- Pick one representative slice of the real system, not a hello-world.
- Deploy it with the same infrastructure-as-code tool you plan to use in production.
- Wire up logging and one alert, so you see the observability story too.
- Note every point where you had to search for an answer.
- Tear it down and compare the notes, not the feature pages.
What lock-in actually looks like
Lock-in is rarely about compute. A virtual machine running Linux is portable almost everywhere. It is the managed services around it that bind you: the proprietary queue, the serverless runtime, the data warehouse. If portability genuinely matters, keep the boundary at containers and standard protocols, and accept that you are trading some convenience for it.
Most teams are better served by using the managed services fully, moving faster, and accepting a migration cost they will probably never pay.
A practical decision order
- Does a regulation or contract force a region or provider? If so, that decides it.
- Does the team already know one platform well? Default to it.
- Does your existing identity or data stack pull in one direction? Follow it.
- Otherwise, run the one-day spike and pick the one that annoyed you least.
The honest summary
For a greenfield project with no constraints and no existing preference, all three will work. Choose the one your team can operate confidently, get the first version shipped, and revisit the question when you have real traffic and real bills to reason about. A decision made on evidence from your own workload beats one made on a comparison chart.
