Azure Machine Learning

Azure Machine Learning is the platform you use to build models rather than consume them: tracked training jobs on compute you don't administer, versioned data and environments, a model registry, reproducible pipelines, and managed endpoints that serve the result. If Azure AI Foundry is the workspace around somebody else's model, Azure ML is the factory where yours gets made.

Names. The service has kept its name, but two things around it changed. Azure Machine Learning Studio (classic) — the old drag-and-drop product with .ilearner files — was retired on 31 August 2024 and is unrelated to today's studio at ml.azure.com; if a tutorial mentions "Studio (classic)", close it. And the v1 SDK/CLI (azureml-core, az ml v1) has been superseded by v2 (azure-ai-ml, az ml v2, YAML-first). Every command and snippet in this topic is v2. The resource provider — Microsoft.MachineLearningServices — is also what Azure AI Foundry's hub-based architecture is built on, which is the single biggest source of confusion between the two products.

What it is and where it fits

Strip away the studio and Azure ML is a workspace resource plus a set of asset types. You create one workspace; inside it you create compute (a dev box, an autoscaling cluster, or nothing at all if you use serverless), data assets, environments (a Docker image plus dependencies), jobs (a command run on compute, tracked), models (a registered, versioned artifact), components and pipelines (jobs composed of steps), and endpoints (online for real-time, batch for bulk). The studio, the notebooks, the designer, and the MLflow UI are views over those objects.

The problem it solves is the one that shows up the day a notebook works. The model trained fine on someone's laptop. What is hard is: which data version produced it, which package versions were installed, which run had the metric you quoted in the deck, who is allowed to see the training data, how you get a GPU for six hours without owning a GPU for a year, how you serve it behind an authenticated HTTPS endpoint with health probes, and how you shift 10% of traffic to the new one and back again. Azure ML is Microsoft's answer to that list, and — importantly — its tracking layer is MLflow, not a proprietary API, so the lock-in is thinner than it looks.

The one distinction to fix before anything else: Azure ML vs. Azure AI Foundry. Azure ML is for training and operating your own models — datasets, compute clusters, experiments, registries, MLOps. Foundry is for consuming foundation models — deployments, prompts, agents, evaluations. They overlap because Foundry's classic hub architecture is an Azure ML workspace with kind = Hub, and because Azure ML's model catalogue can also serve foundation models. The rule that holds: if you are writing a training loop or a feature pipeline, you are in Azure ML; if you are writing a prompt, you are in Foundry. See Azure AI Foundry.

The rest of the neighbourhood, one line each:

• Azure Databricks — the other serious training platform on Azure, Spark-first, notebook-first, with its own workspace and its own bill. Teams often run both: Databricks for feature engineering at scale, Azure ML for the registry and the endpoints. They interoperate through MLflow, which both speak.
• Azure AI Services (formerly Cognitive Services) — prebuilt task APIs. If a good-enough model already exists behind an endpoint, training your own is a choice you should have to justify.
• Azure Container Apps / AKS — where a hand-rolled inference container lives when you don't want the Azure ML endpoint abstraction. Cheaper and more flexible; you own the scoring contract, the scaling, and the auth.
• Azure Synapse / Microsoft Fabric — where the data usually is. Azure ML consumes it, rarely stores it.

The honest summary: Azure ML is the right default when the model is yours and the process has to be repeatable, and the wrong tool when you have one script, one dataset, and no second run planned.

Key facts at a glance

Category	AI / ML — training, experiment tracking, model registry, and managed inference
Resource provider	Microsoft.MachineLearningServices/workspaces. Child resources include /computes, /onlineEndpoints, /onlineEndpoints/deployments, /batchEndpoints, /datastores, /connections. Cross-workspace asset sharing uses Microsoft.MachineLearningServices/registries
Scope	Regional resource in a resource group. The workspace has a kind — Default (this topic), Hub and Project (Foundry classic), FeatureStore (managed feature store)
Dependent resources	A Storage account (mandatory — default datastore), plus Key Vault, Application Insights, and a Container Registry. Key Vault, App Insights and ACR can be omitted or created lazily on newer API versions; ACR appears the first time something needs an image built ⚠️ verify which are optional against current Azure docs
SKU / tier axis	The workspace sku is a red herring — Basic is effectively the only value since the Enterprise tier was retired, and it changes nothing you care about. The axis that actually matters is compute: compute instance vs. compute cluster vs. serverless vs. Kubernetes; VM family and size; dedicated vs. Spot (low-priority); and for serving, the instance type and count on each managed online deployment. A second axis is network isolation mode — public, AllowInternetOutbound, or AllowOnlyApprovedOutbound, the last of which provisions a managed firewall you pay for
Unit of billing	The workspace itself is free. You pay for compute-hours (training and serving), the storage account, ACR, Application Insights ingestion, any managed-VNet firewall, and public IP / egress. Managed online deployments bill per instance-hour whether or not a single request arrives
Capacity unit	vCPU quota per VM family, per subscription, per region, counted separately for dedicated and low-priority. Managed online endpoints have their own separate quota, also per-subscription-per-region. There are additional caps on endpoints per workspace and deployments per endpoint ⚠️ quotas vary by subscription type and region — verify before designing
SLA posture	An availability SLA applies to managed online endpoints; training jobs on Spot/low-priority compute are preemptible and carry no such guarantee. Preview features (and there are always several here) have no SLA ⚠️ verify current SLA terms
Usual companions	Blob Storage / ADLS Gen2, Key Vault, Container Registry, Application Insights, Microsoft Entra ID managed identity, Azure DevOps or GitHub Actions, Private Link, Azure Databricks, Event Grid
Primary alternative	Azure Databricks (Spark-native training), a self-managed stack on AKS with MLflow and KServe, or Azure AI Foundry if the model isn't yours to train
AWS analogue	Amazon SageMaker AI. The analogy is unusually good — workspace ≈ domain, training job ≈ training job, model registry ≈ model registry, managed online endpoint ≈ endpoint with production variants including the traffic split. It breaks on: Azure ML's mandatory dependent resources, MLflow as the native tracking API rather than an add-on, and Azure ML registries, which have no clean SageMaker equivalent

When to use it

• You are training or fine-tuning your own models and need runs to be reproducible six months later.
• You need burst compute you don't want to own. A cluster that scales to zero and back up to sixteen GPU nodes for an afternoon is the single most compelling reason to be here.
• You need an audit trail. Which data version, which code commit, which environment, which metrics, which person, which approval — all of it is a first-class object rather than a convention.
• You need real-time inference with blue/green. Managed online endpoints give you traffic splitting across deployments, which makes model rollout an operational dial rather than a redeploy.
• You are doing MLOps across environments. Registries let a model trained in the dev workspace be promoted to staging and prod workspaces as the same versioned artifact, not a re-upload.
• You have data-governance constraints. Private endpoints, managed VNet, customer-managed keys, and identity-based datastore access are the reason regulated teams pick this over a VM with a GPU.

When not to use it

• One-off analysis. A notebook on a Compute Instance is a fine place to start, but if you never intend a second run, the workspace, the ACR, the Key Vault, and the storage account are overhead.
• You only want to call a foundation model. That is Azure AI Foundry. Building an Azure ML workspace to call gpt-4.1 is a long way round.
• You already live in Databricks. Two training platforms is two sets of clusters, quotas, and bills. Use Azure ML for the registry and the endpoints if you want, but don't duplicate the compute story.
• Ultra-low-latency, high-QPS inference on a tiny model. The managed endpoint adds a hop and a scoring-script layer. A container on AKS or Container Apps with the model in-process will beat it.
• You need the cheapest possible always-on inference. A managed online deployment bills per instance-hour with no scale-to-zero; a Container App that scales to zero will be cheaper for spiky, latency-tolerant traffic. (Batch endpoints, which spin a cluster up per job, are the in-family answer.)
• Your organisation cannot grant regional vCPU quota. Nothing about this platform works if the GPU family you need is at zero quota in your region — check first, not after the design review.

What this topic covers

Sub-topic	What it covers
What & Why	The problem it kills, where it sits against Foundry, Databricks, and SageMaker, the v1→v2 break, and honest anti-patterns
Core Concepts	Workspace, datastore, data asset, environment, job, component, pipeline, model, registry, endpoint, deployment — plus the compute taxonomy that is the SKU axis
Architecture	What actually happens when you submit a job and when you score a request, control plane vs. data plane and the roles on each side, quota mechanics, and the failure modes
Getting Started	One workspace, one cluster, one tracked job, one registered model — portal, az ml CLI, and minimal Terraform — with teardown and the soft-delete trap
Deployment	A parameterised Terraform module with azurerm + azapi, remote state, an Ansible playbook, the Bicep equivalent, OIDC CI/CD, three environments, blue/green rollback, and drift
Integrations	Storage and ADLS Gen2, Key Vault, ACR, Databricks, Synapse and Fabric, Event Grid, Monitor, API Management, Foundry, and the two glue mechanisms that recur
Production	Security, cost (where the money actually goes), scaling and quota scopes, observability including data drift, and reliability across regions
Interview Questions	Three tiers with answer keys, from "what is a workspace" to "someone bumped the endpoint traffic by hand at 2 a.m."
Glossary & Cheatsheet	Every term in one line, the commands you will actually type, the resource ID shapes, and the limits worth knowing

Three ideas worth carrying into every other page

A model is an artifact, an endpoint is an address, and a deployment is the thing in between. Your application calls an endpoint by a stable name. Behind it sit one or more deployments, each pinning a specific model version, environment, scoring script, instance type and instance count. Traffic is split across deployments by percentage. This three-level indirection is the most valuable thing Azure ML gives you operationally — and the most commonly collapsed, by teams that run one deployment called default and redeploy in place. Name deployments blue and green, keep two alive, and rollback becomes a traffic percentage instead of an incident.

Almost everything you pay for is compute you forgot about. The workspace is free. The bill is a Compute Instance somebody left running over a long weekend, a cluster with min_instances = 1, and an online deployment serving zero requests at three instances. Idle-shutdown on instances, min_instances = 0 on clusters, and a hard look at endpoint instance counts recover most of a first-month surprise.

The control plane and the data plane are different services with different roles. ARM at management.azure.com creates the workspace, the compute, and the endpoints. A separate regional data-plane endpoint (<region>.api.azureml.ms, discovered from the workspace) runs jobs, registers models, and reads assets — and scoring happens at a third address entirely, <endpoint>.<region>.inference.ml.azure.com. Contributor on the workspace does not by itself make your training job able to read the storage account, and Owner does not make you able to invoke an endpoint with a token. This split accounts for most "works in the studio, 403s from the pipeline" tickets.

Resource groups, subscriptions, ARM, Entra ID, RBAC inheritance, regions and zones are explained once in Foundations rather than repeated here.

Reading paths

New to Azure ML — What & Why → Core Concepts → Getting Started. Run one job, register one model, delete the resource group, then come back for Architecture.

Coming from SageMaker — start with the compute taxonomy and the asset model in Core Concepts; the pieces map well but the mandatory dependent resources and the registry have no equivalent you already know. Then Architecture for the identity model, which is where the analogy fails hardest.

Coming from Databricks or plain MLflow — read the MLflow section of Core Concepts first: the workspace is an MLflow tracking server, and most of your existing code works unchanged once you set the tracking URI.

Need to ship this quarter — Deployment then Production. Getting Started is deliberately throwaway.

Chasing a cost surprise — the cost section of Production, then the compute table in Core Concepts. It is a Compute Instance or an idle online deployment roughly nine times out of ten.

Interview or DP-100 prep — Core Concepts, Architecture, Interview Questions. Compute types, endpoint traffic splitting, and the control-plane/data-plane split come up almost every time.

---

Next: What & Why →

← Back to the article