Learn how to create a compute instance in your Azure Machine Learning workspace.
Use a compute instance as your fully configured and managed development environment in the cloud. For development and testing, you can also use the instance as a training compute target. A compute instance can run multiple jobs in parallel and has a job queue. As a development environment, a compute instance can't be shared with other users in your workspace.
You can also use a setup script to create the compute instance with your own custom environment.
Compute instances can run jobs securely in a virtual network environment, without requiring enterprises to open up SSH ports. The job executes in a containerized environment and packages your model dependencies in a Docker container.
An Azure Machine Learning workspace. For more information, see Create an Azure Machine Learning workspace. In the storage account, the "Allow storage account key access" option must be enabled for compute instance creation to be successful.
Choose the tab for the environment you're using for other prerequisites.
# Enter details of your AML workspace
subscription_id = "<SUBSCRIPTION_ID>"
resource_group = "<RESOURCE_GROUP>"
workspace = "<AML_WORKSPACE_NAME>"
# get a handle to the workspace
from azure.ai.ml import MLClient
from azure.identity import DefaultAzureCredential
ml_client = MLClient(
DefaultAzureCredential(), subscription_id, resource_group, workspace
)
ml_client is a handler to the workspace that you use to manage other resources and jobs.
If you're not on the compute instance, omit --identity and follow the prompt to open a browser window to authenticate.
Make sure you have the most recent versions of the CLI and the ml extension:
az upgrade
If you have multiple Azure subscriptions, set the active subscription to the one you're using for your workspace. (You can skip this step if you only have access to a single subscription.) Replace <YOUR_SUBSCRIPTION_NAME_OR_ID> with either your subscription name or subscription ID. Also remove the brackets <>.
az account set -s "<YOUR_SUBSCRIPTION_NAME_OR_ID>"
Set the default workspace. If you're using a compute instance, you can keep the following command as is. If you're on any other computer, substitute your resource group and workspace name instead. (You can find these values in Azure Machine Learning studio.)
az configure --defaults group=$CI_RESOURCE_GROUP workspace=$CI_WORKSPACE
No extra prerequisites.
Create
Time estimate: Approximately 5 minutes.
Creating a compute instance is a one time process for your workspace. You can reuse the compute as a development workstation or as a compute target for training. You can have multiple compute instances attached to your workspace.
The dedicated cores per region per VM family quota and total regional quota, which applies to compute instance creation, is unified and shared with Azure Machine Learning training compute cluster quota. Stopping the compute instance doesn't release quota to ensure you are able to restart the compute instance. A quota is a credit limit on Azure resources, not a capacity guarantee, Restarting a compute instance is still dependent on the available capacity of the region. If there is a capacity crunch in the region for the SKU, you may not be able to restart the compute instance. It isn't possible to change the virtual machine size of compute instance once it's created.
# Compute Instances need to have a unique name across the region.
# Here we create a unique name with current datetime
from azure.ai.ml.entities import ComputeInstance, AmlCompute
import datetime
ci_basic_name = "basic-ci" + datetime.datetime.now().strftime("%Y%m%d%H%M")
ci_basic = ComputeInstance(name=ci_basic_name, size="STANDARD_DS3_v2")
ml_client.begin_create_or_update(ci_basic).result()
For more information on the classes, methods, and parameters for creating a compute instance, see the following reference documents:
If you have no compute instances, select Create in the middle of the page.
If you see a list of compute resources, select +New above the list.
Fill out the form:
Field
Description
Compute name
- Name is required and must be between 3 to 24 characters long. - Valid characters are upper and lower case letters, digits, and the - character. - Name must start with a letter - Name needs to be unique across all existing computes within an Azure region. You see an alert if the name you choose isn't unique - If - character is used, then it needs to be followed by at least one letter later in the name
Virtual machine type
Choose CPU or GPU. This type can't be changed after creation
Virtual machine size
Supported virtual machine sizes might be restricted in your region. Check the availability list
Select Review + Create unless you want to configure advanced settings for the compute instance.
Select Next to go to Scheduling if you want to schedule the compute to start or stop on a recurring basis. See enable idle shutdown & add schedule sections.
Select Security if you want to configure security settings such as SSH, virtual network, root access, and managed identity for your compute instance. Use this section to:
Assign the computer to another user. For more about assigning to other users, see Create on behalf of
If you're using an Azure Virtual Network, specify the Resource group, Virtual network, and Subnet to create the compute instance inside an Azure Virtual Network. You can also select No public IP to prevent the creation of a public IP address, which requires a private link workspace. You must also satisfy these network requirements for virtual network setup.
If you're using an Azure Machine Learning managed virtual network, the compute instance is created inside the managed virtual network. You can also select No public IP to prevent the creation of a public IP address. For more information, see managed compute with a managed network.
To avoid getting charged for a compute instance that is switched on but inactive, you can configure when to shut down your compute instance due to inactivity.
A compute instance is considered inactive if the below conditions are met:
No active Jupyter Kernel sessions (which translates to no Notebooks usage via Jupyter, JupyterLab or Interactive notebooks)
No active Jupyter terminal sessions
No active Azure Machine Learning runs or experiments
No VS Code connections; you must close your VS Code connection for your compute instance to be considered inactive. Sessions are autoterminated if VS Code detects no activity for 3 hours.
No custom applications are running on the compute
A compute instance won't be considered idle if any custom application is running. To shutdown a compute with a custom application automatically, a schedule needs to be set up, or the custom application needs to be removed. There are also some basic bounds around inactivity time periods; compute instance must be inactive for a minimum of 15 mins and a maximum of three days. We also don't track VS Code SSH connections to determine activity.
Also, if a compute instance has already been idle for a certain amount of time, if idle shutdown settings are updated to an amount of time shorter than the current idle duration, the idle time clock is reset to 0. For example, if the compute instance has already been idle for 20 minutes, and the shutdown settings are updated to 15 minutes, the idle time clock is reset to 0.
Important
If the compute instance is also configured with a managed identity, the compute instance won't shut down due to inactivity unless the managed identity has contributor access to the Azure Machine Learning workspace. For more information on assigning permissions, see Manage access to Azure Machine Learning workspaces.
The setting can be configured during compute instance creation or for existing compute instances via the following interfaces:
When creating a new compute instance, add the idle_time_before_shutdown_minutes parameter.
# Note that idle_time_before_shutdown has been deprecated.
ComputeInstance(name=ci_basic_name, size="STANDARD_DS3_v2", idle_time_before_shutdown_minutes="30")
You can't change the idle time of an existing compute instance with the Python SDK.
When creating a new compute instance, add idle_time_before_shutdown_minutes to the YAML definition.
# Note that this is just a snippet for the idle shutdown property. Refer to the "Create" Azure CLI section for more information.
# Note that idle_time_before_shutdown has been deprecated.
idle_time_before_shutdown_minutes: 30
You can't change the idle time of an existing compute instance with the CLI.
When creating a new compute instance:
Select Next to advance to Scheduling after completing required settings.
Select Enable idle shutdown to enable or disable.
Specify the shutdown period when enabled.
For an existing compute instance:
In the left navigation bar, select Compute
In the list, select the compute instance you wish to change
Select the Edit pencil in the Schedules section.
You can also change the idle time using:
REST API
Endpoint:
POST https://management.azure.com/subscriptions/{SUB_ID}/resourceGroups/{RG_NAME}/providers/Microsoft.MachineLearningServices/workspaces/{WS_NAME}/computes/{CI_NAME}/updateIdleShutdownSetting?api-version=2021-07-01
Body:
{
"idleTimeBeforeShutdown": "PT30M" // this must be a string in ISO 8601 format
}
ARM Templates: only configurable during new compute instance creation
// Note that this is just a snippet for the idle shutdown property in an ARM template
{
"idleTimeBeforeShutdown":"PT30M" // this must be a string in ISO 8601 format
}
Schedule automatic start and stop
Define multiple schedules for autoshutdown and autostart. For instance, create a schedule to start at 9 AM and stop at 6 PM from Monday-Thursday, and a second schedule to start at 9 AM and stop at 4 PM for Friday. You can create a total of four schedules per compute instance.
Schedules can also be defined for create on behalf of compute instances. You can create a schedule that creates the compute instance in a stopped state. Stopped compute instances are useful when you create a compute instance on behalf of another user.
Prior to a scheduled shutdown, users see a notification alerting them that the Compute Instance is about to shut down. At that point, the user can choose to dismiss the upcoming shutdown event. For example, if they are in the middle of using their Compute Instance.
Select Next to advance to Scheduling after completing required settings.
Select Add schedule to add a new schedule.
Select Start compute instance or Stop compute instance.
Select the Time zone.
Select the Startup time or Shutdown time.
Select the days when this schedule is active.
Select Add schedule again if you want to create another schedule.
Once the compute instance is created, you can view, edit, or add new schedules from the compute instance details section.
Note
Timezone labels don't account for day light savings. For instance, (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna is actually UTC+02:00 during day light savings.
Create a schedule with a Resource Manager template
You can schedule the automatic start and stop of a compute instance by using a Resource Manager template.
In the Resource Manager template, add:
"schedules": "[parameters('schedules')]"
Then use either cron or LogicApps expressions to define the schedule that starts or stops the instance in your parameter file:
For trigger type of Recurrence use the same syntax as logic app, with this recurrence schema.
For trigger type of cron, use standard cron syntax:
// Crontab expression format:
//
// * * * * *
// - - - - -
// | | | | |
// | | | | +----- day of week (0 - 6) (Sunday=0)
// | | | +------- month (1 - 12)
// | | +--------- day of month (1 - 31)
// | +----------- hour (0 - 23)
// +------------- min (0 - 59)
//
// Star (*) in the value field above means all legal values as in
// braces for that column. The value column can have a * or a list
// of elements separated by commas. An element is either a number in
// the ranges shown above or two numbers in the range separated by a
// hyphen (meaning an inclusive range).
Azure Policy support to default a schedule
Use Azure Policy to enforce a shutdown schedule exists for every compute instance in a subscription or default to a schedule if nothing exists.
Following is a sample policy to default a shutdown schedule at 10 PM PST.
To further enhance security, when you create a compute instance on behalf of a data scientist and assign the instance to them, single sign-on (SSO) will be disabled during creation if the compute instance has a setup script or custom app.
The assigned to user needs to enable SSO on compute instance themselves after the compute is assigned to them by updating the SSO setting on the compute instance.
Assigned to user needs to have the following permission/action in their role MachineLearningServices/workspaces/computes/enableSso/action.
Assigned to user does not need compute write (create) permission to enable SSO.
Here are the steps assigned to user needs to take. Please note creator of compute instance is not allowed to enable SSO on that compute instance due to security reasons.
Click on compute in left navigation pane in Azure Machine Learning Studio.
Click on the name of compute instance where you need to enable SSO.
Edit the Single sign-on details section.
Enable single sign-on toggle.
Save. Updating will take some time.
Assign managed identity
You can assign a system- or user-assigned managed identity to a compute instance, to authenticate against other Azure resources such as storage. Using managed identities for authentication helps improve workspace security and management. For example, you can allow users to access training data only when logged in to a compute instance. Or use a common user-assigned managed identity to permit access to a specific storage account.
Important
If the compute instance is also configured for idle shutdown, the compute instance won't shut down due to inactivity unless the managed identity has contributor access to the Azure Machine Learning workspace. For more information on assigning permissions, see Manage access to Azure Machine Learning workspaces.
Select System-assigned or User-assigned under Identity type.
If you selected User-assigned, select subscription and name of the identity.
Once the managed identity is created, grant the managed identity at least Storage Blob Data Reader role on the storage account of the datastore, see Accessing storage services. Then, when you work on the compute instance, the managed identity is used automatically to authenticate against datastores.
Note
The name of the created system managed identity will be in the format /workspace-name/computes/compute-instance-name in your Microsoft Entra ID.
You can also use the managed identity manually to authenticate against other Azure resources. The following example shows how to use it to get an Azure Resource Manager access token:
To use Azure CLI with the managed identity for authentication, specify the identity client ID as the username when logging in:
az login --identity --username $DEFAULT_IDENTITY_CLIENT_ID
Note
You cannot use azcopy when trying to use managed identity. azcopy login --identity will not work.
Enable SSH access
SSH access is disabled by default. SSH access can't be enabled or disabled after creation. Make sure to enable access if you plan to debug interactively with VS Code Remote.
After you have selected Next: Advanced Settings:
Turn on Enable SSH access.
In the SSH public key source, select one of the options from the dropdown:
If you Generate new key pair:
Enter a name for the key in Key pair name.
Select Create.
Select Download private key and create compute. The key is usually downloaded into the Downloads folder.
If you select Use existing public key stored in Azure, search for and select the key in Stored key.
If you select Use existing public key, provide an RSA public key in the single-line format (starting with "ssh-rsa") or the multi-line PEM format. You can generate SSH keys using ssh-keygen on Linux and OS X, or PuTTYGen on Windows.
Set up an SSH key later
Although SSH can't be enabled or disabled after creation, you do have the option to set up an SSH key later on an SSH-enabled compute instance. This allows you to set up the SSH key post-creation. To do this, select to enable SSH on your compute instance, and select to "Set up an SSH key later" as the SSH public key source. After the compute instance is created, you can visit the Details page of your compute instance and select to edit your SSH keys. From there, you are able to add your SSH key.
An example of a common use case for this is when creating a compute instance on behalf of another user (see Create on behalf of) When provisioning a compute instance on behalf of another user, you can enable SSH for the new compute instance owner by selecting Set up an SSH key later. This allows for the new owner of the compute instance to set up their SSH key for their newly owned compute instance once it has been created and assigned to them following the previous steps.
Connect with SSH
After you create a compute with SSH access enabled, use these steps for access.
Find the compute in your workspace resources:
On the left, select Compute.
Use the tabs at the top to select Compute instance or Compute cluster to find your machine.
Select the compute name in the list of resources.
Find the connection string:
For a compute instance, select Connect at the top of the Details section.
For a compute cluster, select Nodes at the top, then select the Connection string in the table for your node.
Copy the connection string.
For Windows, open PowerShell or a command prompt:
Go into the directory or folder where your key is stored
Add the -i flag to the connection string to locate the private key and point to where it is stored:
ssh -i <keyname.pem> azureuser@... (rest of connection string)
The data scientist can start, stop, and restart the compute instance. They can use the compute instance for:
Jupyter
JupyterLab
RStudio
Posit Workbench (formerly RStudio Workbench)
Integrated notebooks
Add custom applications such as RStudio or Posit Workbench
You can set up other applications, such as RStudio, or Posit Workbench (formerly RStudio Workbench), when creating a compute instance. Follow these steps in studio to set up a custom application on your compute instance
RStudio is one of the most popular IDEs among R developers for ML and data science projects. You can easily set up Posit Workbench, which provides access to RStudio along with other development tools, to run on your compute instance, using your own Posit license, and access the rich feature set that Posit Workbench offers
Follow the steps listed above to Add application when creating your compute instance.
Select Posit Workbench (bring your own license) in the Application dropdown and enter your Posit Workbench license key in the License key field. You can get your Posit Workbench license or trial license from posit.
Select Create to add Posit Workbench application to your compute instance.
Important
If using a private link workspace, ensure that the docker image, pkg-containers.githubusercontent.com and ghcr.io are accessible. Also, use a published port in the range 8704-8993. For Posit Workbench (formerly RStudio Workbench), ensure that the license is accessible by providing network access to https://www.wyday.com.
Note
Support for accessing your workspace file store from Posit Workbench is not yet available.
When accessing multiple instances of Posit Workbench, if you see a "400 Bad Request. Request Header Or Cookie Too Large" error, use a new browser or access from a browser in incognito mode.
Setup RStudio (open source)
To use RStudio, set up a custom application as follows:
Follow the previous steps to Add application when creating your compute instance.
Select Custom Application in the Application dropdown list.
Configure the Application name you would like to use.
Set up the application to run on Target port8787 - the docker image for RStudio open source listed below needs to run on this Target port.
Set up the application to be accessed on Published port8787 - you can configure the application to be accessed on a different Published port if you wish.
Point the Docker image to ghcr.io/azure/rocker-rstudio-ml-verse:latest.
Select Create to set up RStudio as a custom application on your compute instance.
Important
If using a private link workspace, ensure that the docker image, pkg-containers.githubusercontent.com and ghcr.io are accessible. Also, use a published port in the range 8704-8993. For Posit Workbench (formerly RStudio Workbench), ensure that the license is accessible by providing network access to https://www.wyday.com.
Setup other custom applications
Set up other custom applications on your compute instance by providing the application on a Docker image.
Follow the previous steps to Add application when creating your compute instance.
Select Custom Application on the Application dropdown.
Configure the Application name, the Target port you wish to run the application on, the Published port you wish to access the application on and the Docker image that contains your application. If your custom image is stored in an Azure Container Registry, assign the Contributor role for users of the application. For information on assigning roles, see Manage access to an Azure Machine Learning workspace.
Optionally, add Environment variables you wish to use for your application.
Use Bind mounts to add access to the files in your default storage account:
Specify /home/azureuser/cloudfiles for Host path.
Specify /home/azureuser/cloudfiles for the Container path.
Select Add to add this mounting. Because the files are mounted, changes you make to them are available in other compute instances and applications.
Select Create to set up the custom application on your compute instance.
Important
If using a private link workspace, ensure that the docker image, pkg-containers.githubusercontent.com and ghcr.io are accessible. Also, use a published port in the range 8704-8993. For Posit Workbench (formerly RStudio Workbench), ensure that the license is accessible by providing network access to https://www.wyday.com.
Accessing custom applications in studio
Access the custom applications that you set up in studio:
On the left, select Compute.
On the Compute instance tab, see your applications under the Applications column.
Note
It might take a few minutes after setting up a custom application until you can access it via the links. The amount of time taken will depend on the size of the image used for your custom application. If you see a 502 error message when trying to access the application, wait for some time for the application to be set up and try again.
If the custom image is pulled from an Azure Container Registry, you'll need a Contributor role for the workspace. For information on assigning roles, see Manage access to an Azure Machine Learning workspace.
Learn how to work with compute targets in Azure Machine Learning. Compute targets allow you to run your machine learning workloads. Explore how and when you can use a compute instance or compute cluster.
Manage data ingestion and preparation, model training and deployment, and machine learning solution monitoring with Python, Azure Machine Learning and MLflow.