Machine learning in the cloud: how to compare platforms

On 18 May 2021, Google recorded in its official release notes that AI Platform (Unified) was becoming Vertex AI. Names, interfaces and catalogues have continued to change, but the problem addressed by cloud machine-learning platforms remains: coordinating data, code, compute, models and deployments without every team building all the infrastructure.

A managed service replaces part of the operational work; it does not choose a sound target, validate data or guarantee production results. The durable capability is to read a platform as a chain of responsibilities and compare the whole chain through the same experiment. A feature list or hourly price reveals neither traceability, total cost nor exit difficulty.

The model is a small piece of the system

Before training, teams must locate and version data, prepare a reproducible environment and run experiments. Afterwards they register the artefact, deploy it for batch or online inference, observe behaviour and decide when to update or retire it. Google Cloud’s MLOps guide also lists data validation, testing, configuration, metadata, monitoring and resource management around model code.

Vertex AI combines AutoML and custom training, a registry, deployment and tools for AI applications. Azure Machine Learning organises jobs, versioned assets, pipelines, models and endpoints in workspaces. Amazon SageMaker AI provides environments and services for building, training and deployment; AWS documents that the former Amazon SageMaker product adopted the SageMaker AI name on 3 December 2024.

All three families cover much of the journey with different vocabularies and boundaries. Two buttons labelled “deploy” do not imply the same identity, network, format, scaling, startup time or bill. The comparison unit is the system a team must operate, not one isolated feature.

Managed does not mean fully delegated

A provider may operate datacentres, hardware and service layers. The customer still decides which data to upload, who has access, which permissions to grant, how to configure networks and encryption and how to use each prediction. Azure’s shared-responsibility model explicitly leaves data, identities and configuration under customer responsibility across cloud models.

Machine learning adds another layer. The provider is not accountable for a poor target variable, biased labels, leakage between training and test data or a metric hiding consequential errors. Nor does it decide whether human review is required. An explainability or fairness service supplies instruments; the team must define groups, thresholds, consequences and actions.

The pilot’s first table should have two columns: “provider operates” and “our team demonstrates.” Each service moves the boundary but does not remove the second column. If a task lacks an owner, the word “managed” has merely concealed a gap.

AutoML does not remove decisions

Depending on product and data type, AutoML automates parts of preparation, algorithm selection or hyperparameter tuning. It can build a baseline quickly. It cannot determine whether a label represents the outcome that matters, future data resemble history or the test set correctly separated patients, customers or time periods.

A valid result preserves task definition, data provenance and version, code, environment, parameters, the training-test split, metric and cost of each error. If an interface produces a score while making those elements hard to reconstruct, it has reduced visibility rather than risk.

Custom training offers more control and permits open frameworks, but adds container images, libraries, drivers and configuration. Saving a final file does not make a model reproducible. The full path must be rebuildable, including who approved its promotion to production.

Six questions before choosing

1. Where may data live and travel? Map regions, networks, identities and sources before selecting a service. Moving large datasets or opening cross-cloud access can outweigh a training-speed difference. Residency, encryption and audit requirements are verified in the specific configuration.

2. What is traced? Every version should link data, code, environment, parameters, metrics, evaluation and approval. A visual interface is secondary if it cannot reconstruct why a version reached production or restore its predecessor.

3. How is inference served? An overnight calculation calls for batch inference; an interactive application needs an endpoint with measured latency and availability. Keeping an accelerator running for sporadic load differs from starting it on demand.

4. How is deterioration detected? CPU and memory are insufficient. Teams must observe input changes, quality when labels arrive, errors by segment and active versions. An alert needs an owner and action: abstain, roll back, review or retrain.

5. What enables exit? Before adopting a proprietary capability, export a test model, run it outside the service where possible and list dependencies on data, registry, pipeline, endpoint and identity. Perfect portability is rare; exit cost can still be measured.

6. Who will operate it? An individual notebook, a regulated team and hundreds of production models require different controls. Compare onboarding, environment separation, approval, quotas, support and incident response as well.

The bill follows the architecture

Cost accumulates across storage, preparation, CPU or accelerator hours, hyperparameter searches, active endpoints, requests, logging, monitoring and transfer. Google publishes Vertex AI pricing, Microsoft Azure Machine Learning pricing and AWS SageMaker AI pricing. They support scenario calculations, not a universal winner.

The test reproduces a small but real workload and labels every resource. It measures preparation time, training, utilisation, intermediate storage, latency, idle cost, observability and transfer. The team then projects counters under low, expected and high usage. Credits and discounts are reported separately so they cannot hide the unpromoted cost.

Human cost belongs in the calculation too: time spent on permissions, integration, debugging, deployment and on-call work. A cheaper compute hour may cost more when additional components require maintenance; a more integrated platform may deepen dependency. Both effects are measured rather than assumed.

A comparable, reversible pilot

Fix the same dataset, test split, reference code, reasonably equivalent region and acceptance threshold. In each platform, complete a minimum journey: prepare, train, register, deploy, monitor, restore its predecessor and retire. Score model quality, effort, traceability, security, latency, cost and reversibility.

Keep infrastructure as code, the container, data schema, export format and a list of proprietary services. Perform a restoration too: build the environment from scratch and prove another operator can find the model, its data and approval. A theoretical exit that nobody has exercised is not a plan.

Finally, document omissions and the deciding constraint. One team may accept more manual work because it already masters one cloud’s identity and networking; another may prioritise proximity to data or a required region. These are system conditions, not universal provider qualities.

The cloud can operate infrastructure and offer AutoML, pipelines, registries and endpoints. The team retains responsibility for task definition, data validation, error measurement, access control, production monitoring and exit preparation. Once that boundary is written, Vertex AI, Azure Machine Learning and SageMaker AI stop being incomparable catalogues and become options that can be tested through the same trial.

The final deliverable is not merely a chosen provider. It is a decision record containing workloads, assumptions, measurements, responsibilities and signals that will trigger reconsideration. A future migration can then begin from evidence rather than institutional memory.