Protección de soluciones de MLOps con seguridad de red de Azure

DevOps de aprendizaje automático (MLOps), resaltado por primera vez en Deuda técnica oculta en los sistemas de aprendizaje automático en 2015, está creciendo rápidamente. Se espera que el mercado de MLOps alcance los 4 mil millones de USD en 2025. Mientras tanto, trabajar para proteger las soluciones de MLOps es cada vez más importante.

En este artículo, se describe cómo proteger las soluciones de MLOps mediante funcionalidades de seguridad de red de Azure, como Azure Virtual Network, el emparejamiento de red, Azure Private Link y Azure DNS. También se presenta cómo usar:

• Azure Pipelines para acceder a los recursos de la red virtual
• Las configuraciones necesarias de Azure Container Registry y las instancias y clústeres de proceso de Azure Machine Learning de una red virtual.

Por último, este artículo describe los costos de usar los servicios de seguridad de red.

Architecture

Descargue un archivo Visio de esta arquitectura.

Flujo de datos

El diagrama de arquitectura muestra una solución de MLOps de muestra.

• La red virtual llamada AML VNET ayuda a proteger área de trabajo de Azure Machine Learning y sus recursos asociados.

• El host de salto, Azure Bastion y los agentes autohospedados se encuentran en otra red virtual llamada BASTION VNET. Esta disposición simula tener otra solución que requiere acceso a los recursos de la red virtual de Azure Machine Learning.

• Con la compatibilidad con el emparejamiento de redes virtuales y las zonas DNS privadas, Azure Pipelines puede ejecutarse en agentes autohospedados y desencadenar las canalizaciones de Azure Machine Learning publicadas en el área de trabajo de Azure Machine Learning para entrenar, evaluar y registrar los modelos de aprendizaje automático.

• Por último, el modelo se implementa en puntos de conexión en línea o puntos de conexión por lotes compatibles con el proceso de Azure Machine Learning o los clústeres de Azure Kubernetes Service.

Componentes

La solución de ejemplo de MLOps consta de estos componentes:

• Almacenamiento de datos: Azure Blob Storage para el almacenamiento de datos.
• Entrenamiento, validación y registro del modelo: área de trabajo de Azure Machine Learning
• Implementación de modelos: Puntos de conexión de Azure Machine Learning y Azure Kubernetes Service
• Supervisión de modelos: Azure Monitor para Application Insights
• Canalizaciones de MLOps: Azure DevOps y Azure Pipelines

En este escenario de ejemplo también se usan los siguientes servicios para ayudar a proteger la solución de MLOps:

• Azure Key Vault
• Azure Policy
• Virtual Network

Detalles del escenario

MLOps es un conjunto de prácticas en la intersección entre Machine Learning, DevOps e ingeniería de datos que pretende implementar y mantener modelos de aprendizaje automático en producción de forma fiable y eficaz.

En el diagrama siguiente se muestra un modelo de proceso de MLOps simplificado. Este modelo ofrece una solución que automatiza la preparación de datos, el entrenamiento de modelos, la evaluación de modelos, el registro de modelos, la implementación de modelos y la supervisión.

Al implementar una solución de MLOps, es posible que desee ayudar a proteger estos recursos:

• Canalizaciones de DevOps
• Datos de entrenamiento de aprendizaje automático
• Canalizaciones de Machine Learning
• Modelos de Machine Learning

Para ayudar a proteger los recursos, tenga en cuenta estos métodos:

• Autenticación y autorización

  • Use entidades de servicio o identidades administradas en lugar de la autenticación interactiva.
  • Use el control de acceso basado en roles para definir el ámbito del acceso de un usuario a los recursos.

• Seguridad de las redes

  • Use Virtual Network para aislar completamente o parcialmente el entorno de la red pública de Internet para reducir la superficie expuesta a ataques y la posibilidad de filtración de datos.
    • En el área de trabajo de Azure Machine Learning, si sigue usando la CLI de Azure Machine Learning v1 y el SDK de Python de Azure Machine Learning v1 (por ejemplo, la API v1), agregar un punto de conexión privado al área de trabajo proporciona aislamiento de red para todo excepto las operaciones crear, leer, actualizar y eliminar (CRUD) en el área de trabajo o los recursos de proceso.
    • Para aprovechar las ventajas de las nuevas características del área de trabajo de Azure Machine Learning, utilizar la CLI de Azure Machine Learning v2 y el SDK de Python de Azure Machine Learning v2 (por ejemplo, la API v2), en la que habilitar un punto de conexión privado en el área de trabajo no proporciona el mismo nivel de aislamiento de red. Sin embargo, la red virtual seguirá protegiendo los datos de entrenamiento y los modelos de Machine Learning. Se recomienda evaluar la API v2 antes de adoptarla en las soluciones empresariales. Para obtener más información, consulte ¿Cuál es la nueva plataforma API en Azure Resource Manager?.

• Cifrado de datos

  • Cifre los datos de entrenamiento en tránsito y en reposo mediante claves de acceso administradas por la plataforma o administradas por el cliente.

• Directiva y supervisión

  • Use Azure Policy y Microsoft Defender for Cloud para aplicar directivas.
  • Use Azure Monitor para recopilar y agregar datos (como métricas y registros) de varios orígenes en una plataforma de datos común para el análisis, la visualización y las alertas.

El área de trabajo de Azure Machine Learning es el recurso de nivel superior para Azure Machine Learning y el componente principal de una solución de MLOps. El área de trabajo proporciona un lugar centralizado para trabajar con todos los artefactos que cree al usar Azure Machine Learning.

Al crear una nueva área de trabajo, se crean automáticamente los recursos siguientes de Azure que el área de trabajo utiliza:

• Azure Application Insights
• Azure Container Registry
• Azure Key Vault
• Cuenta de Azure Storage

Posibles casos de uso

Esta solución se adapta a escenarios en los que un cliente usa una solución de MLOps para implementar y mantener modelos de Machine Learning en un entorno más protegido. Los clientes pueden proceder de diversos sectores, como la fabricación, las telecomunicaciones, el comercio minorista, la atención sanitaria, etc. Por ejemplo:

• Un operador de telecomunicaciones protege las imágenes, los datos y los modelos de Machine Learning de un cliente en su sistema de supervisión de vídeo para tiendas minoristas.

• Un fabricante de motores necesita una solución más segura para ayudar a proteger los datos y los modelos de Machine Learning de sus fábricas y productos para su sistema, que utiliza Computer Vision para detectar defectos en las piezas.

Las soluciones de MLOps para estos escenarios y otros pueden usar áreas de trabajo de Azure Machine Learning, Azure Blob Storage, Azure Kubernetes Service, Container Registry y otros servicios de Azure.

Puede usar todo o parte de este ejemplo para cualquier escenario similar que tenga un entorno de MLOps que se implemente en Azure y use las funcionalidades de seguridad de Azure para ayudara a proteger los recursos pertinentes. El cliente original de esta solución está en el sector de las telecomunicaciones.

Consideraciones

Estas consideraciones implementan los pilares del Azure Well-Architected Framework, que es un conjunto de principios rectores que mejoran la calidad de una carga de trabajo cuando se aplica. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.

Seguridad

La seguridad proporciona más garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para obtener más información, consulte Lista de comprobación de revisión de diseño para seguridad.

Considere cómo ayudar a proteger la solución de MLOps comenzando con el diseño de la arquitectura. Es posible que los entornos de desarrollo no necesiten una seguridad significativa, pero es importante en los entornos de ensayo y producción.

Optimización de costos

La optimización de costes trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la optimización de costes.

La configuración de Virtual Network es gratuita, pero hay cargos por los demás servicios que pueda requerir su escenario, como los vínculos privados, las zonas DNS y el emparejamiento de red virtual. En la tabla siguiente se describen los cargos por esos servicios y otros que podrían ser necesarios.

Excelencia operativa

La excelencia operativa abarca los procesos de las operaciones que implementan una aplicación y la mantienen en ejecución en producción. Para obtener más información, consulte la Lista de comprobación de revisión de diseño para la excelencia operativa.

Para simplificar la integración continua y la entrega continua (CI/CD), el procedimiento recomendado es usar herramientas y servicios para la infraestructura como código (IaC), como Terraform o plantillas de Azure Resource Manager, Azure DevOps y Azure Pipelines.

Implementación de este escenario

En las secciones siguientes, se describe cómo implementar, acceder y ayudar a proteger los recursos en este escenario de ejemplo.

Virtual Network

El primer paso para ayudar a proteger el entorno de MLOps es ayudar a proteger el área de trabajo de Azure Machine Learning y sus recursos asociados. Un método eficaz de protección consiste en utilizar Virtual Network. Virtual Network es el bloque de creación básico de una red privada en Azure. Virtual Network permite que muchos tipos de recursos de Azure se comuniquen entre sí, con Internet y con redes del entorno local de forma más segura.

Colocar el área de trabajo de Azure Machine Learning y sus recursos asociados en una red virtual garantiza que los componentes se puedan comunicar entre sí sin exponerlos a la red pública de Internet. Al hacerlo, se reduce su superficie expuesta a ataques y se ayuda a evitar la filtración de datos.

El siguiente fragmento de código de Terraform muestra cómo crear un clúster de proceso para Azure Machine Learning, asociarlo a un área de trabajo y colocarlo en una subred de una red virtual.

resource "azurerm_machine_learning_compute_cluster" "compute_cluster" {
  name                          = "my_compute_cluster"
  location                      = "eastasia"
  vm_priority                   = "LowPriority"
  vm_size                       = "Standard_NC6s_v3"
  machine_learning_workspace_id = azurerm_machine_learning_workspace.my_workspace.id
  subnet_resource_id            = azurerm_subnet.compute_subnet.id
  ssh_public_access_enabled     = false
  scale_settings {
    min_node_count                       = 0
    max_node_count                       = 3
    scale_down_nodes_after_idle_duration = "PT30S"
  }
  identity {
    type = "SystemAssigned"
  }
}

Private Link y punto de conexión privado de Azure

Private Link permite el acceso mediante un punto de conexión privado de la red virtual a las opciones de plataforma como servicio (PaaS) de Azure, como un área de trabajo de Azure Machine Learning y Azure Storage, y a los servicios propiedad del cliente y propiedad de los asociados hospedados en Azure. Un punto de conexión privado es una interfaz de red que se conecta solo a recursos específicos, lo que ayuda a protegerse frente a la filtración de datos.

En este escenario de ejemplo, hay cuatro puntos de conexión privados que están vinculados a opciones de PaaS de Azure y que se administran mediante una subred de la red virtual de Azure Machine Learning, como se muestra en el diagrama de arquitectura. Por lo tanto, estos servicios solo son accesibles para los recursos de la misma red virtual, la red virtual de Azure Machine Learning. Estos servicios son:

• Área de trabajo de Azure Machine Learning
• Azure Blob Storage
• Azure Container Registry
• Azure Key Vault

El siguiente fragmento de código de Terraform muestra cómo usar un punto de conexión privado para vincularlo a un área de trabajo de Azure Machine Learning, que está más protegida por la red virtual como resultado. El fragmento de código también muestra el uso de una zona DNS privado, que se describe en Zonas de DNS privado de Azure.

resource "azurerm_machine_learning_workspace" "aml_ws" {
  name                    = "my_aml_workspace"
  friendly_name           = "my_aml_workspace"
  location                = "eastasia"
  resource_group_name     = "my_resource_group"
  application_insights_id = azurerm_application_insights.my_ai.id
  key_vault_id            = azurerm_key_vault.my_kv.id
  storage_account_id      = azurerm_storage_account.my_sa.id
  container_registry_id   = azurerm_container_registry.my_acr_aml.id

  identity {
    type = "SystemAssigned"
  }
}

# Configure private DNS zones

resource "azurerm_private_dns_zone" "ws_zone_api" {
  name                = "privatelink.api.azureml.ms"
  resource_group_name = var.RESOURCE_GROUP
}

resource "azurerm_private_dns_zone" "ws_zone_notebooks" {
  name                = "privatelink.notebooks.azure.net"
  resource_group_name = var.RESOURCE_GROUP
}

# Link DNS zones to the virtual network

resource "azurerm_private_dns_zone_virtual_network_link" "ws_zone_api_link" {
  name                  = "ws_zone_link_api"
  resource_group_name   = "my_resource_group"
  private_dns_zone_name = azurerm_private_dns_zone.ws_zone_api.name
  virtual_network_id    = azurerm_virtual_network.aml_vnet.id
}

resource "azurerm_private_dns_zone_virtual_network_link" "ws_zone_notebooks_link" {
  name                  = "ws_zone_link_notebooks"
  resource_group_name   = "my_resource_group"
  private_dns_zone_name = azurerm_private_dns_zone.ws_zone_notebooks.name
  virtual_network_id    = azurerm_virtual_network.aml_vnet.id
}

# Configure private endpoints

resource "azurerm_private_endpoint" "ws_pe" {
  name                = "my_aml_ws_pe"
  location            = "eastasia"
  resource_group_name = "my_resource_group"
  subnet_id           = azurerm_subnet.my_subnet.id

  private_service_connection {
    name                           = "my_aml_ws_psc"
    private_connection_resource_id = azurerm_machine_learning_workspace.aml_ws.id
    subresource_names              = ["amlworkspace"]
    is_manual_connection           = false
  }

  private_dns_zone_group {
    name                 = "private-dns-zone-group-ws"
    private_dns_zone_ids = [azurerm_private_dns_zone.ws_zone_api.id, azurerm_private_dns_zone.ws_zone_notebooks.id]
  }

  # Add the private link after configuring the workspace
  depends_on = [azurerm_machine_learning_compute_instance.compute_instance, azurerm_machine_learning_compute_cluster.compute_cluster]
}

El código anterior para azurerm_machine_learning_workspace usará la plataforma de API v2 de manera predeterminada. Si todavía desea usar la API v1 o tiene una directiva de empresa que prohíba el envío de comunicaciones mediante redes públicas, puede habilitar el parámetro v1_legacy_mode_enabled, como se muestra en el siguiente fragmento de código. Cuando se habilita, este parámetro desactiva la API v2 para el área de trabajo.

resource "azurerm_machine_learning_workspace" "aml_ws" {
  ...
  public_network_access_enabled = false
  v1_legacy_mode_enabled  = true
}

Zonas DNS privadas de Azure

Azure DNS proporciona un servicio DNS confiable y más seguro para administrar y resolver los nombres de dominio en una red virtual sin necesidad de agregar una solución DNS personalizada. Al utilizar zonas DNS privadas, puede usar nombres de dominio personalizados en lugar de los nombres proporcionados por Azure. La resolución de DNS en una zona DNS privada solo funciona desde redes virtuales vinculadas a ella.

Esta solución de ejemplo usa puntos de conexión privados para el área de trabajo de Azure Machine Learning y para sus recursos asociados, como Azure Storage, Azure Key Vault o Container Registry. Por lo tanto, debe definir la configuración de DNS para resolver las direcciones IP de los puntos de conexión privados del nombre de dominio completo (FQDN) de la cadena de conexión.

Puede vincular una zona DNS privada a una red virtual para resolver dominios específicos.

El fragmento de código de Terraform en Private Link y el punto de conexión privado de Azure crea dos zonas DNS privadas mediante los nombres de zona que se recomiendan en la configuración de zona DNS de los servicios de Azure:

• privatelink.api.azureml.ms
• privatelink.notebooks.azure.net

Emparejamiento de redes virtuales

El emparejamiento de red virtual permite el acceso de la máquina virtual (VM) de host de salto o de las máquinas virtuales de agente autohospedado de la red virtual de Azure Bastion a los recursos de la red virtual de Azure Machine Learning. Con fines de conectividad, las dos redes virtuales funcionan como una. El tráfico entre máquinas virtuales y recursos de Azure Machine Learning en redes virtuales emparejadas usa la infraestructura troncal de Azure. El tráfico entre las redes virtuales se enruta a través de la red privada de Azure.

El siguiente fragmento de código de Terraform configura el emparejamiento de red virtual entre la red virtual de Azure Machine Learning y la red virtual de Azure Bastion.

# Virtual network peering for AML VNET and BASTION VNET
resource "azurerm_virtual_network_peering" "vp_amlvnet_basvnet" {
  name                      = "vp_amlvnet_basvnet"
  resource_group_name       = "my_resource_group"
  virtual_network_name      = azurerm_virtual_network.amlvnet.name
  remote_virtual_network_id = azurerm_virtual_network.basvnet.id
  allow_virtual_network_access = true
  allow_forwarded_traffic      = true
}

resource "azurerm_virtual_network_peering" "vp_basvnet_amlvnet" {
  name                      = "vp_basvnet_amlvnet"
  resource_group_name       = "my_resource_group"
  virtual_network_name      = azurerm_virtual_network.basvnet.name
  remote_virtual_network_id = azurerm_virtual_network.amlvnet.id
  allow_virtual_network_access = true
  allow_forwarded_traffic      = true
}

Acceso a los recursos de la red virtual

Para acceder al área de trabajo de Azure Machine Learning en una red virtual, como la red virtual de Azure Machine Learning en este escenario, use uno de los métodos siguientes:

• Azure VPN Gateway
• Azure ExpressRoute
• Azure Bastion y la máquina virtual del host de salto

Para más información, consulte Conexión al área de trabajo.

Ejecución de Azure Pipelines que acceden a los recursos de la red virtual

Azure Pipelines crea y prueba automáticamente proyectos de código para ponerlos a disposición de otros. Azure Pipelines combina la integración continua y la entrega continua para probar y compilar el código y enviarlo a cualquier destino.

Agentes hospedados en Azure frente a agentes autohospedados

La solución de MLOps de este escenario de ejemplo consta de dos canalizaciones, que pueden desencadenar canalizaciones de Azure Machine Learning y acceder a los recursos asociados. Dado que el área de trabajo de Azure Machine Learning y su recurso asociado están en una red virtual, este escenario debe proporcionar una manera de que un agente de Azure Pipelines acceda a ellos. Un agente es una infraestructura informática con software de agente instalado que ejecuta trabajos de Azure Pipelines de uno en uno. Hay varias maneras de implementar el acceso:

• Use agentes autohospedados en la misma red virtual o en la red virtual de emparejamiento, como se muestra en el diagrama de arquitectura.

• Use agentes hospedados en Azure y agregue sus intervalos de direcciones IP a una lista de permitidos en la configuración del firewall de los servicios de Azure de destino.

• Use agentes hospedados en Azure (como clientes VPN) y VPN Gateway.

Cada una de estas opciones tiene ventajas y desventajas. En la tabla siguiente se comparan los agentes hospedados en Azure con agentes autohospedados.

En función de las comparaciones de la tabla y de las consideraciones de seguridad y complejidad, este escenario de ejemplo usa un agente autohospedado para Azure Pipelines para desencadenar canalizaciones de Azure Machine Learning en la red virtual.

Para configurar un agente autohospedado, dispone de las siguientes opciones:

• Instale el agente en Azure Virtual Machines.

• Instalar los agentes en un conjunto de escalado de máquinas virtuales de Azure, que se puede escalar automáticamente para satisfacer la demanda.

• Instale el agente en un contenedor Docker. Esta opción no es factible, ya que este escenario podría requerir la ejecución del contenedor Docker en el agente para el entrenamiento del modelo de Machine Learning.

El código de ejemplo siguiente aprovisiona dos agentes autohospedados mediante la creación de máquinas virtuales y extensiones de Azure:

resource "azurerm_linux_virtual_machine" "agent" {
  ...
}

resource "azurerm_virtual_machine_extension" "update-vm" {
  count                = 2
  name                 = "update-vm${format("%02d", count.index)}"
  publisher            = "Microsoft.Azure.Extensions"
  type                 = "CustomScript"
  type_handler_version = "2.1"
  virtual_machine_id   = element(azurerm_linux_virtual_machine.agent.*.id, count.index)

  settings = <<SETTINGS
    {
        "script": "${base64encode(templatefile("../scripts/terraform/agent_init.sh", {
          AGENT_USERNAME      = "${var.AGENT_USERNAME}",
          ADO_PAT             = "${var.ADO_PAT}",
          ADO_ORG_SERVICE_URL = "${var.ADO_ORG_SERVICE_URL}",
          AGENT_POOL          = "${var.AGENT_POOL}"
        }))}"
    }
SETTINGS
}

Como se muestra en el bloque de código anterior, el script de Terraform llama a agent_init.sh, que se muestra en el siguiente bloque de código, para instalar el software del agente y las bibliotecas necesarias en la máquina virtual del agente según los requisitos del cliente.

#!/bin/sh
# Install other required libraries 
...

# Creates directory and downloads Azure DevOps agent installation files
# Find more agent versions at https://github.com/microsoft/azure-pipelines-agent/releases
AGENT_VERSION="3.240.1"
sudo mkdir /myagent 
cd /myagent
sudo wget https://vstsagentpackage.azureedge.net/agent/${AGENT_VERSION}/vsts-agent-linux-x64-${AGENT_VERSION}.tar.gz
sudo tar zxvf ./vsts-agent-linux-x64-${AGENT_VERSION}.tar.gz
sudo chmod -R 777 /myagent

# Unattended installation
sudo runuser -l ${AGENT_USERNAME} -c '/myagent/config.sh --unattended  --url ${ADO_ORG_SERVICE_URL} --auth pat --token ${ADO_PAT} --pool ${AGENT_POOL}'

cd /myagent
#Configure as a service
sudo ./svc.sh install ${AGENT_USERNAME}
#Start service
sudo ./svc.sh start

Uso de Container Registry en la red virtual

Hay algunos requisitos previos para proteger un área de trabajo de Azure Machine Learning en una red virtual. Para obtener más información, consulte Requisitos previos. Container Registry es un servicio necesario cuando se usa un área de trabajo de Azure Machine Learning para entrenar e implementar los modelos.

En este escenario de ejemplo, para asegurarse de que el agente autohospedado puede acceder al registro de contenedor en la red virtual, usamos el emparejamiento de red virtual y agregamos un vínculo de red virtual para vincular la zona de DNS privado, privatelink.azurecr.io a la red virtual de Azure Bastion. El siguiente fragmento de código de Terraform muestra la implementación.

# Azure Machine Learning Container Registry is for private access 
# by the Azure Machine Learning workspace
resource "azurerm_container_registry" "acr" {
  name                     = "my_acr"
  resource_group_name      = "my_resource_group"
  location                 = "eastasia"
  sku                      = "Premium"
  admin_enabled            = true
  public_network_access_enabled = false
}

resource "azurerm_private_dns_zone" "acr_zone" {
  name                     = "privatelink.azurecr.io"
  resource_group_name      = "my_resource_group"
}

resource "azurerm_private_dns_zone_virtual_network_link" "acr_zone_link" {
  name                  = "link_acr"
  resource_group_name   = "my_resource_group"
  private_dns_zone_name = azurerm_private_dns_zone.acr_zone.name
  virtual_network_id    = azurerm_virtual_network.amlvnet.id
}

resource "azurerm_private_endpoint" "acr_ep" {
  name                = "acr_pe"
  resource_group_name = "my_resource_group"
  location            = "eastasia"
  subnet_id           = azurerm_subnet.aml_subnet.id

  private_service_connection {
    name                           = "acr_psc"
    private_connection_resource_id = azurerm_container_registry.acr.id
    subresource_names              = ["registry"]
    is_manual_connection           = false
  }

  private_dns_zone_group {
    name                 = "private-dns-zone-group-app-acr"
    private_dns_zone_ids = [azurerm_private_dns_zone.acr_zone.id]
  }
}

Este escenario de ejemplo también garantiza que el registro de contenedor tenga un rol de colaborador para la identidad administrada asignada por el sistema del área de trabajo de Azure Machine Learning.

Uso de un clúster de proceso o una instancia en la red virtual

Un clúster de proceso o una instancia de Azure Machine Learning en una red virtual requiere un grupo de seguridad de red (NSG) con algunas reglas específicas para su subred. Para obtener una lista de esas reglas, consulte Limitaciones.

Tenga en cuenta también que, para el clúster o la instancia de proceso, ahora es posible quitar la dirección IP pública, lo que ayuda a proporcionar una mejor protección para los recursos de proceso de la solución de MLOps. Para más información, consulte No hay ninguna dirección IP pública para las instancias de proceso.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Creadores de entidad de seguridad:

• Gary Wang | Ingeniero principal de software

Otros colaboradores:

• Gary Moore | Programador/escritor

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes

• Terraform en la documentación de Azure
• Ejemplos de Terraform de Azure Machine Learning Enterprise
• Repositorio de GitHub de Azure MLOps v2
• Precios de Azure Virtual Network
• Precios de Azure DevOps

Recursos relacionados

• Protección de un área de trabajo de Azure Machine Learning con redes virtuales
• Agentes de Azure Pipelines