Lesson 2 — The three platforms compared
Every comparison of these platforms dates quickly, because all three ship features continuously and copy each other within months. So this lesson covers what is stable: the shape they share, the axes on which they actually differ, and the criterion that should decide.
They all provide the same seven things
Whatever the branding, each platform gives you:
| Capability | What it does |
|---|---|
| Managed notebooks | A development environment with data access and no local setup |
| Training jobs | Submit a container and a dataset, get a model, machine shuts down after |
| Automated model search | Try many algorithms and configurations for you |
| Model registry | Versioned models with stages and lineage |
| Endpoints | Deploy a model behind an API, with autoscaling and traffic splitting |
| Pipelines | Chain steps into a repeatable, schedulable workflow |
| Monitoring | Drift detection and data quality checks on live traffic |
That list is the MLOps course rendered as configuration. It is the substantive reason to use a platform at all.
Two features worth calling out because they change how you work:
Managed training jobs are the most underrated. You submit a job, it provisions hardware, runs, writes the model to storage and shuts the machine down. No forgotten instance running all weekend, which is the single most common source of unexpected GPU bills.
Automated model search is genuinely useful as a baseline. Point it at a tabular dataset and it will produce something reasonable in an hour, which tells you what an easy solution scores before you invest in a hard one. It will not beat a competent practitioner who understands the domain, and beating it should be your bar rather than your goal.
Where they genuinely differ
AWS SageMaker is the broadest and the least coherent. It has been built up over years, which means there are usually three ways to do anything and the documentation covers all three. Enormous capability, a steep and irregular learning curve, and the strongest option if your data is already in AWS — which for a large share of organisations it is.
Azure Machine Learning is the most conventional in its engineering, and it integrates with the Microsoft identity, governance and compliance stack in ways that matter a great deal in enterprises already committed to it. If your organisation runs on Microsoft, the path of least resistance here is genuine rather than merely convenient.
Google Vertex AI is the most consistent to use, with the fewest overlapping ways to accomplish something, and it is strongest where BigQuery is your data platform — training directly from warehouse tables removes a whole category of pipeline work. Google also tends to expose research-derived capability earlier.
| SageMaker | Azure ML | Vertex AI | |
|---|---|---|---|
| Breadth | Highest | High | High |
| Coherence | Lowest | Good | Highest |
| Learning curve | Steepest | Moderate | Gentlest |
| Enterprise governance | Good | Strongest | Good |
| Data platform synergy | S3, Redshift | Fabric, Synapse | BigQuery, strongest |
| Best when | Already on AWS | Already on Microsoft | Already on Google, or using BigQuery |
The criterion that should actually decide
Use the platform where your data already is.
Not a compromise — the correct answer for most organisations, for reasons that outweigh every feature comparison:
Moving data is slow and expensive. Terabytes take real time, and providers charge for data leaving their network. Egress fees are the cost line people forget until it appears.
Cross-cloud architectures cost operational effort permanently. Two identity systems, two networking models, two billing structures, two sets of people who know them.
The feature differences are small relative to the migration cost. Anything genuinely valuable on one platform appears on the others within a year or two.
Reasons that do override this: a hard data residency requirement that only one provider satisfies in your region, a capability that genuinely exists nowhere else, or a contractual arrangement that changes the economics materially.
Hosted model gateways
Distinct from the platforms and increasingly the more important product: AWS Bedrock, Azure AI Foundry and Google's model APIs give you several foundation model families through one interface, inside your cloud account, with your existing identity and networking controls.
Why this matters practically:
- Your data stays within your cloud boundary rather than going to a separate vendor, which resolves a large share of procurement objections
- Switching between model families is a configuration change rather than an integration project
- Billing, access control and audit logging work the way the rest of your infrastructure does
In a market where the leading model changes every few months, the ability to switch cheaply is worth more than being on whichever model currently leads. This is the strongest argument for a gateway over calling a model vendor directly.
Do not forget the alternatives
The three major platforms are not the only options, and for some situations they are not the best.
Specialist GPU providers rent accelerators considerably cheaper than the major clouds, with less around them. Excellent for training, less suited to production serving with compliance requirements.
Model hosting platforms in the mould of Hugging Face's inference offerings deploy open models with far less ceremony than a full platform, and their model hubs are where most open models are distributed regardless.
Your own servers. For steady high-volume inference, owned hardware is frequently cheaper than any cloud equivalent, and the crossover arrives sooner than cloud pricing pages imply. Worth calculating rather than assuming.
Nothing at all. A model in a container on one virtual machine, behind a load balancer, is a complete production deployment for a great many use cases and needs none of this lesson.
Start from where your data lives. Then adopt the smallest piece of the platform that solves your immediate problem — usually managed training jobs, or an endpoint. Resist adopting the whole platform in one go: the learning cost is real, and most of the surface will not apply to you.
In three sentences
All three platforms provide the same seven capabilities — managed notebooks, training jobs, automated model search, a registry, endpoints, pipelines and monitoring — which is the MLOps course rendered as configuration, with managed training jobs being the most underrated because they shut the machine down and prevent the most common source of surprise GPU bills. They differ in coherence and in which data platform they pair with rather than in what is possible: SageMaker is broadest and least tidy, Azure ML fits Microsoft-committed enterprises, Vertex AI is the most consistent and strongest alongside BigQuery. The criterion that should decide is where your data already lives, because moving data is slow and expensive while feature gaps close within a year or two, and hosted model gateways deserve separate attention since switching model families cheaply is worth more than being on whichever model currently leads.
Next — Lesson 3: controlling cost →