1. What and Why

The problem, stated honestly

A model that works once is not an achievement. A model you can rebuild is.

Here is the failure mode Azure Machine Learning exists to prevent, and it is depressingly consistent across companies. Someone trains a good model in a notebook. Six weeks later the business asks for it in production. Nobody can say which snapshot of the data was used, because the CSV was on a laptop and has since been overwritten. Nobody can rebuild the environment, because pip install today resolves different versions than it did in March. The metric quoted in the deck exists in a screenshot and nowhere else. The GPU that trained it was a VM someone spun up personally and has been billing quietly ever since. And the "deployment plan" is a Flask app in a container with no auth, no health probe, and no way to roll back.

Every one of those is a record-keeping and infrastructure problem, not a data-science problem. That is the whole thesis of the platform: the modelling is your job; the reproducibility, the compute lifecycle, and the serving contract are the platform's.

[Image Prompt: 2D minimalistic diagram of Azure Machine Learning sitting between upstream inputs — raw data in a storage account, training code in a git repository, and a container environment definition — and downstream outputs — a versioned registered model, a real-time scoring endpoint, and batch prediction files written back to storage, with the workspace as a labelled box in the middle, flat design, clean vector art style, white background]

What Azure ML actually gives you

Four things, and it is worth being precise because the studio's surface area hides how few load-bearing ideas there are.

1. Tracked execution. You do not "run a script"; you submit a job. The platform records the code snapshot, the environment, the input data assets, the compute target, the parameters, the metrics, the logs, and the output artifacts, and stamps it with an identity and a timestamp. The tracking API is MLflow — the open-source one — so mlflow.log_metric() in your training script works without an Azure-specific import. That choice matters more than it sounds: it means the instrumentation in your code is portable, and only the tracking URI is Azure-specific.

2. Compute you rent by the minute. A compute cluster scales from zero nodes to a configured maximum, runs your job, and scales back to zero. You get GPU access without owning a GPU, and — via Spot / low-priority nodes — at a steep discount in exchange for the job being killable. This is the single strongest economic argument for the service, and it is undermined entirely by leaving min_instances above zero.

3. Versioned assets with lineage. Data assets, environments, components, and models are all versioned, immutable-by-convention objects with URIs like azureml:my-model:7. A job records which versions it consumed and which it produced, so "what produced this model" is a query rather than an archaeology project.

4. Serving as infrastructure. A managed online endpoint is an HTTPS address with TLS, Entra ID or key auth, health probes, autoscaling, and — crucially — traffic splitting across deployments. You can run blue at 90% and green at 10%, watch the metrics, and move the dial. Nobody redeploys to roll back.

Where it sits, and where the mental models transfer

If you know SageMaker, the transfer rate is unusually high. Training jobs are training jobs. Processing jobs are command jobs. The model registry is the model registry. A SageMaker endpoint with production variants and a traffic split is an Azure ML online endpoint with deployments and a traffic split — same idea, same operational value.

Where it breaks, and these are worth knowing before you assume:

• Azure ML workspaces drag dependent resources behind them. A storage account is mandatory; Key Vault, Application Insights, and a container registry are conventional and sometimes required depending on what you do. SageMaker has no equivalent "you must also own these four resources" requirement. This is the number-one surprise for AWS engineers, and it changes how you write the Terraform. ⚠️ Which of the four are strictly required has moved across API versions — verify against current Azure docs.
• MLflow is native here, not bolted on. The workspace is an MLflow tracking server. On AWS you typically run MLflow yourself or use the managed add-on.
• Azure ML registries have no clean SageMaker analogue. A registry is a separate ARM resource that holds models, environments, and components shared across workspaces and regions — the mechanism for promoting an artifact from dev to prod without rebuilding it.
• Quota is per VM family, per subscription, per region, and split dedicated/low-priority. AWS service quotas are per instance type too, but Azure's are more granular, vary more by subscription type, and are more likely to be zero for GPU families until you ask.

If you know Databricks, the split is: Databricks owns the data and the Spark cluster; Azure ML owns the registry and the endpoints. Both speak MLflow, so a model logged in Databricks can be registered into an Azure ML workspace or registry and served from there. Running both is common and defensible. Running both for training is usually a reorg artifact, not a design.

The v1 → v2 break, and why old tutorials mislead you

Azure ML has two generations of API, and the internet is still mostly full of the first one.

	v1 (legacy)	v2 (current)
Python SDK	azureml-core, azureml-sdk	azure-ai-ml (MLClient)
CLI	az ml v1 extension	az ml v2 extension, YAML-first
Central abstraction	Experiment, Run, Estimator, Dataset	Job, Component, Data, Environment, Model, Endpoint
Serving	ACI / AKS webservice	Managed online endpoints, batch endpoints
Tracking	Run.log()	MLflow
IaC fit	poor	good — YAML specs are diffable and CI-friendly

Two practical consequences. First, if a snippet imports azureml.core, it is v1 — it may still run, but you are learning a dead dialect. Second, ACI-based deployment (AciWebservice) is legacy; managed online endpoints replaced it, and the old path should not appear in new work. ⚠️ Check current deprecation status of the v1 SDK and ACI-based webservices before relying on either.

Separately and confusingly: Azure Machine Learning Studio (classic) — the drag-and-drop product from the 2015 era — was retired on 31 August 2024. It shares almost nothing with today's studio at ml.azure.com beyond the word "studio". If a search result mentions experiments made of connected boxes and .ilearner files, it is about a dead product.

The shape of a real project

Nothing on this page is abstract, so here is the arc a working team actually follows, with a pointer to where each step is covered.

1. Land the data in Blob Storage or ADLS Gen2, and register it as a data asset so the version is pinned. → Core Concepts
2. Define an environment — a base image plus a conda or pip specification — and register it. Now "it worked on my machine" has a version number.
3. Write a training script that reads its inputs from arguments and logs metrics with MLflow.
4. Submit it as a job to a compute cluster. Iterate. The runs accumulate in an experiment. → Getting Started
5. Register the winning model, with its metrics and lineage attached.
6. Promote it to a registry so staging and prod workspaces can consume the identical artifact.
7. Deploy it behind a managed online endpoint as green, at 0% traffic, and shift the dial. → Deployment
8. Monitor latency, error rate, and — the ML-specific one — data drift between the training distribution and what production is actually sending. → Production

Steps 1–5 are what people mean by "doing ML". Steps 6–8 are where projects die, and they are the reason you are paying for a platform rather than a GPU VM.

Anti-patterns worth naming

• The workspace as a shared laptop. A Compute Instance per person, everyone running notebooks interactively, nothing submitted as a job. You get the bill of a platform and the reproducibility of a laptop. Compute Instances are for authoring; clusters and serverless are for running.
• min_instances = 1 "so it's warm". You have converted a rented cluster back into an owned VM. If cold-start on training genuinely hurts, that is a serverless-compute conversation, not a floor.
• One deployment named default. Redeploying in place throws away the entire reason online endpoints have a traffic split. Two deployments, blue and green, cost more and are worth it.
• Pinning nothing. azureml:my-env@latest and azureml:my-data@latest in a production pipeline means your reproducible platform now reproduces whatever happened most recently.
• Building the workspace by hand in the portal, then writing the Terraform afterwards. The dependent resources (storage, Key Vault, ACR, App Insights) get auto-created with generated names, and importing that mess costs more than starting again. → Deployment
• Ignoring quota until the design review. A GPU family at zero quota in your chosen region is not a configuration problem; it is a two-week support ticket. Check before you promise a date.
• Using Azure ML because there's an LLM in the plan. If the work is prompts, retrieval, and agents, you want Azure AI Foundry. The hub-based Foundry architecture runs on this resource provider, which is why the two keep getting confused — but they are different jobs.

---

Next: Core Concepts →

← Back to the Azure Machine Learning overview