Azure Machine Learning Computes should be in a virtual network policy not compliant.

Eric Yong Sze Guan 0 Reputation points
2026-07-22T08:01:37.3733333+00:00

Recently I have seen some compute instances not compliant to the policy of "Azure Machine Learning Computes should be in a virtual network" which puzzled me.

These compute instances are created in a workspace with a Managed Virtual Network. They are not supposed to fail the compliance of this specific policy. What went wrong?

Thank you.

Azure Machine Learning

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. kagiyama yutaka 4,345 Reputation points
    2026-07-22T08:51:05.0633333+00:00

    I think the policy checks whether the compute is configured with a virtual network and subnet, and the workspace’s managed‑vnet is not part of that evaluation. You can open the compute’s JSON to confirm the network settings, and creating the compute with a subnet usually clears the audit.

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-07-22T08:02:25.9433333+00:00

    The likely cause is that the built-in policy "Azure Machine Learning Computes should be in a virtual network" audits whether compute clusters and compute instances are configured in a virtual network, while managed virtual network has its own behavior and limitations.

    Supported facts to check:

    1. Managed virtual network is different from deploying computes into a custom virtual network. When using Azure Machine Learning managed virtual network, compute resources can only be created inside the managed virtual network and can't be deployed inside a custom virtual network.
    2. Existing managed compute resources aren’t migrated automatically when managed virtual network is enabled. If the workspace existed before managed virtual network was enabled, there is no supported migration path for existing managed compute resources. Existing compute clusters, compute instances, and managed online endpoints must be deleted and recreated after enabling the managed virtual network.
    3. Policy compliance can reflect how the resource was created or evaluated, not just current workspace intent. If the noncompliant compute instances were created before managed virtual network was enabled, they can remain noncompliant until they are recreated.
    4. Custom policy controls can also affect managed virtual network behavior. Microsoft recommends ensuring that Microsoft-managed private endpoints created for the managed virtual network are allowlisted in custom policy. Also make sure there are no scope locks on Azure Machine Learning resources or the resource group, because internal operations related to managed virtual network can be blocked.

    So the most likely explanation is:

    • the compute instances were created before managed virtual network isolation was enabled, or
    • policy/custom policy evaluation is not recognizing the managed-network-related resources correctly until the computes are recreated.

    A practical validation path is:

    1. Check whether the affected compute instances were created before managed virtual network was enabled on the workspace.
    2. If yes, delete and recreate those compute instances. Warning: this is destructive for the compute resource and should be planned carefully.
    3. Review whether any custom Azure Policy is blocking or not allowlisting the Microsoft-managed private endpoints required by the managed virtual network.
    4. Check for scope locks on the workspace resources or resource group.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.