An Azure machine learning service for building and deploying models.
The strongest next test is to create a temporary Azure Machine Learning workspace in another region and provision a small CPU Compute Instance there, because a Compute Instance cannot be placed in a region different from its workspace and available quota does not guarantee North Central US capacity.^1^
Is this likely a capacity issue?
It is plausible, but the current evidence does not prove it:
- Compute Instance creation normally takes approximately five minutes, so more than two hours is abnormal.
- Azure explicitly defines quota as a credit limit, not a capacity guarantee. Allocation can still fail when the selected region lacks capacity for a SKU.^1^
- Trying several VM families reduces the likelihood of a single-SKU shortage, but it does not eliminate a regional allocation or Azure ML backend issue.
- The public Azure status page does not show a widespread Azure Machine Learning incident specific to North Central US. That page covers widespread incidents; subscription- or region-specific events may appear only in Service Health.^2^
Since you already checked family quota, providers, locks, public networking, diagnostics, Service Health, and multiple SKUs, do not repeat those checks.
Run these remaining discriminating tests
- Check the separate Azure ML total-compute limit In Azure portal → Quotas, filter for Azure Machine Learning in North Central US and inspect both:
- Dedicated cores for the relevant VM family.
- Total compute limit per region.
- Check the workspace’s default storage prerequisite Open the workspace in the Azure portal, locate its default storage account, and go to: Storage account → Configuration → Allow storage account key access This setting must be enabled for Compute Instance creation. Also inspect the storage account’s Activity Log at the original creation time for denied key or storage operations.^1^ This is still relevant even with public network access enabled; public access and storage-account key access are separate settings.
- Perform a region-isolation test A Compute Instance must be in its workspace’s region; unlike a compute cluster, it cannot be created in a different region from that workspace.^4^ Therefore:
- Create a temporary workspace in another region available to the Azure for Students subscription.
- Keep the workspace configuration standard—no VNet, private endpoints, setup scripts, or custom applications.
- Create a small supported CPU Compute Instance.
- Interpret the result:
- Succeeds: strongly isolates the issue to North Central US allocation or the original workspace.
- Also hangs: points toward a subscription-level policy/backend issue or a shared workspace dependency rather than one regional SKU.
Escalate the stuck operation
If the storage prerequisite and total-compute limit are valid and the cross-region test succeeds, this needs Microsoft to inspect backend provisioning traces.
- Open Resource group → Activity log.
- Select the accepted Compute Instance creation operation.
- Open JSON and save:
- Correlation ID
- Operation ID
- Timestamp in UTC
- Workspace and Compute Instance resource IDs
- Requested SKU and region
- Capture the Compute Instance resource’s current provisioning state.
- Open an Azure support request under Azure Machine Learning → Compute Instance → Start, Stop or Restart Compute Instance and include the above data plus the list of SKUs already tested.
A comparable accepted case required backend investigation/retry after quota had already been ruled out; its guidance likewise recommends supplying the correlation ID when the Activity Log contains no actionable error.^5^
After collecting the operation details, delete the unusable stuck instance before further retries to avoid leaving an orphaned resource or possible charges.
References