6. Integrations

Azure ML is a hub by design: it owns almost no data and runs almost no application. Nearly everything useful is a connection to something else.

[Image Prompt: 2D minimalistic hub-and-spoke diagram with an Azure Machine Learning workspace at the centre connected by labelled edges to Blob Storage and ADLS Gen2, Key Vault, Azure Container Registry, Azure Databricks, Microsoft Fabric and Synapse, Event Grid, Azure Monitor and Application Insights, API Management, Microsoft Entra ID, Azure AI Foundry, and a private endpoint into a virtual network, flat design, clean vector art style, white background]

The two glue mechanisms that recur

Before the list, the two patterns that explain most of it:

1. Managed identity, everywhere. Azure ML's preferred way to reach anything is a token, not a secret. The workspace has one identity, each compute has one, each online deployment has one. The recurring task is granting the right identity the right data-plane role on the right resource — and the recurring bug is granting it to the wrong one of those four. Use a single user-assigned managed identity across compute and deployments and this collapses to one grant per resource. See Deployment.

2. Datastores and connections. A datastore is a saved, named pointer to a storage service with its auth attached. A connection (workspace-level) is the same idea generalised to non-storage services — a Git repo, a container registry, an API key for a third party. Both exist so credentials live in one governed place instead of scattered through notebooks.

Storage — Blob and ADLS Gen2

The one integration you cannot avoid. Every workspace has a workspaceblobstore datastore on its default storage account, and virtually every real project adds datastores pointing at the data lake.

• ADLS Gen2 (hierarchical namespace on) is the right target for anything analytical: real directories, and POSIX ACLs on top of RBAC, so you can grant a training identity read on /curated/fraud/ without granting it the container.
• Identity-based access beats credential-based. Set shared_access_key_enabled = false on the storage account and grant Storage Blob Data Reader to the compute's identity. No key exists to leak.
• Mount vs. download. Job inputs can be ro_mount (streamed via a FUSE layer) or download (copied to local disk first). Mount wins for large data you read once; download wins for many small files read repeatedly, because per-file mount overhead is real.
• A data asset is a pointer, not a snapshot. Version 3 of an asset over a mutable prefix means something different tomorrow. Write to date-partitioned paths if you need genuine immutability.

Key Vault

The workspace's Key Vault holds datastore credentials and any secret a job needs. Two things worth knowing:

• Use RBAC authorization on the vault, not access policies — access policies are the legacy model and don't compose with the rest of your governance.
• Purge protection is a one-way door. Turn it on in prod knowing you have permanently reserved that vault name. See the rollback table in Deployment.
• A job reads secrets as its own identity. Granting yourself Key Vault Secrets User does not help the job.

Azure Container Registry

Every custom environment becomes an image, and images live in the workspace's ACR. Consequences people trip over:

• ACR is often created lazily — it appears in the resource group the first time an image is built, which is why your carefully-planned resource group grows a resource by itself.
• Premium SKU is required for private endpoints. If the workspace is network-isolated, Basic won't do.
• The identity running the job needs AcrPull; the build process needs push. If you bring your own ACR, grant both.
• ACR storage is a real, ignorable-until-it-isn't cost. Environments accumulate. Set a retention policy on untagged manifests.

Azure Databricks

The most common two-platform pairing on Azure, and it works because both speak MLflow.

• Feature engineering in Databricks, registry and serving in Azure ML. Log the model to MLflow in Databricks, then register it into an Azure ML workspace or registry and deploy it to a managed online endpoint. One tracking API, two runtimes.
• The reverse — attaching Databricks as an Azure ML compute target — exists but has historically been the more awkward direction. ⚠️ Verify current support for Databricks as a linked compute before designing around it.
• The honest warning: two platforms means two sets of clusters, two quota conversations, and two bills. Justify it with a data-gravity argument, not an org-chart one.

Microsoft Fabric and Synapse

Where the data usually already is.

• Fabric OneLake can be reached from Azure ML as a datastore, keeping one copy of the data rather than exporting to a second lake. ⚠️ This integration has moved quickly — verify current support.
• Synapse Spark pools can be attached as an Azure ML compute target for Spark jobs, and Azure ML also offers serverless Spark that needs no attached pool. Prefer serverless unless you already own a pool.
• Direction of travel matters: Azure ML consumes from these, it does not become your warehouse.

Azure AI Foundry

The relationship is closer than it looks, and stating it precisely saves confusion:

• Foundry hubs run on this resource provider. A hub is Microsoft.MachineLearningServices/workspaces with kind = Hub. That is why Azure ML workspaces and Foundry hubs appear in the same ARM queries.
• Model direction: a model you train and register in Azure ML can be deployed and consumed as part of a Foundry application. Conversely, Azure ML's model catalogue surfaces the same foundation models Foundry does.
• Pick by task, not by portal. Training loop → Azure ML. Prompt, retrieval, agent → Foundry. If a workflow needs both — fine-tune a small model, then serve it inside an agentic app — the model registry is the seam. See Azure AI Foundry.

Azure Monitor and Application Insights

Two distinct telemetry paths, and conflating them is why people think endpoint monitoring is broken.

• Application Insights receives online endpoint request telemetry — latency, failures, dependency calls, and anything your scoring script logs. This is where you debug a 424.
• Azure Monitor metrics and diagnostic settings on the workspace resource carry platform-level signals: job counts and states, quota utilisation, compute node counts. Route these to Log Analytics with a diagnostic setting; nothing is retained long-term by default.
• Model data collection is a third, separate switch on a deployment that writes request and response payloads to storage for later drift analysis. It is not on by default and it has privacy implications. See Production.

Azure Event Grid

The event-driven MLOps hook. The workspace publishes events — RunCompleted, ModelRegistered, RunStatusChanged, DatasetDriftDetected and similar — that you can route to a Function, a Logic App, or a webhook. ⚠️ Verify the current event type list against Azure docs.

The two patterns worth building:

• Model registered → trigger the evaluation and deployment pipeline. This is what turns "someone remembers to deploy" into a system.
• Job failed → page someone. Training failures are silent by default; a failed nightly retrain that nobody notices for a week is a classic.

The inverse trigger — new data lands in Blob Storage → Event Grid → start a training pipeline — is how retraining becomes reactive rather than scheduled.

API Management

Put APIM in front of online endpoints when you have more than one consumer.

What it buys: a stable, versioned public URL that survives the endpoint being recreated; rate limiting and quotas per consumer (Azure ML has none of its own); subscription keys for callers who cannot do Entra ID, with APIM holding the real credential; request/response logging in one place; and the ability to fan a single logical API across endpoints in two regions.

What it costs: another hop of latency, another thing to deploy, and a tier decision of its own. Not worth it for one internal caller; close to mandatory when the model is a product.

Azure Kubernetes Service

Two very different relationships, and they are easy to confuse:

1. AKS as an Azure ML compute target — install the Azure ML extension on your AKS (or Arc-enabled Kubernetes) cluster, attach it to the workspace, and run training jobs and Kubernetes online endpoints on it. Same az ml API, your infrastructure. Choose it for on-prem, edge, tight cost control, or a hard requirement that inference runs in a cluster you own.
2. AKS as an alternative to Azure ML serving — skip endpoints entirely and deploy your own container. Cheaper and more flexible; you own the scoring contract, autoscaling, auth, and the rollout mechanism.

Rule of thumb: if you would otherwise build blue/green traffic splitting yourself, use a managed online endpoint. If you already have a mature Kubernetes deployment story, option 2 is not a downgrade. See Azure Kubernetes Service.

Networking — Private Link and the managed VNet

Not an integration so much as the thing that makes every other integration harder, so it belongs here.

Locking down the workspace with a private endpoint is one line. Making the whole system private means: a private endpoint on the workspace, on the storage account (both blob and file sub-resources), on Key Vault, on ACR (Premium), and on any data source a job reads; plus a managed VNet for the compute; plus private DNS zones so all those names resolve inside the VNet.

The classic half-finished job: workspace private, storage account public. The front door is locked and the filing cabinet is on the pavement.

And the AllowOnlyApprovedOutbound consequence worth planning for: pip install from PyPI fails until you add an FQDN rule, and the managed firewall doing that filtering is a billed resource with a meaningful hourly rate. Budget it before you promise the security team full isolation. See Virtual Network.

Microsoft Entra ID

Underneath everything. Users authenticate to the studio with Entra ID; jobs and deployments authenticate to Azure with managed identities; endpoint callers can use Entra ID tokens instead of keys.

The one Azure ML-specific thing to remember: aad_token auth on an online endpoint is the production choice, and the caller needs the endpoint's scoring permission granted explicitly — being Owner of the subscription does not include it. See Architecture and Microsoft Entra ID.

Source control and CI/CD

• GitHub Actions or Azure DevOps with workload identity federation — no secrets. Two pipelines: infrastructure (Terraform) and artifacts (az ml YAML). See Deployment and GitHub Actions.
• Compute instances can be linked to a Git repo, which is a convenience, not a strategy. Code that only exists on a compute instance is code that will be lost when someone deletes it.

---

Next: Production →

← Back to the Azure Machine Learning overview · ← Previous: Deployment