Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Microsoft Foundry Agent Service admite varias opciones de red, desde una configuración totalmente pública para crear prototipos rápidos para completar el aislamiento de red dentro de su propia red virtual. En este artículo se comparan las opciones, se asignan cada una a objetivos comunes y se apunta a la plantilla de implementación y la guía de configuración de la opción que elija.
Después de elegir una opción, siga el procedimiento vinculado para implementarla y, a continuación, valide la implementación. Si tiene problemas, use la guía de solución de problemas vinculada.
Comportamiento de red predeterminado
Al crear un recurso Foundry sin ninguna configuración de red, obtendrá una línea base totalmente pública:
- Entrante: se puede acceder al punto de conexión de Foundry a través de la red pública de Internet. Cualquier usuario con una credencial válida y la URL del punto de conexión puede acceder a él.
- Tráfico saliente: los agentes acceden a sus datos y a los recursos de Azure a través de redes públicas, y solo pueden acceder a puntos de conexión accesibles desde Internet.
- Almacenamiento: el estado del agente usa almacenamiento administrado por Microsoft de forma predeterminada. Si trae su propio almacenamiento y otros recursos de Azure, configure el acceso de red a esos recursos como parte de la configuración de red.
Nada es privado hasta que elija una de las opciones de la sección siguiente. Cada opción cambia el lado de entrada, el lado saliente o ambos.
Opciones de redes
Una configuración de red combina dos decisiones relacionadas:
- Acceso saliente (salida): cómo los agentes llegan a los datos y otros recursos de Azure. Esta decisión determina el aislamiento principal: mantener la salida pública o limitarla a una red virtual para que el tráfico permanezca en la red privada. La red virtual puede ser una que traiga y administre (red virtual BYO) o una Microsoft administra por usted.
- Acceso entrante: qué redes pueden llegar al punto de conexión de Foundry. Pública (opcionalmente restringida a direcciones IP seleccionadas) o privada a través de un punto de conexión privado.
Las dos decisiones están conectadas. Al aislar la salida en una red virtual, el acceso entrante al punto de conexión de Foundry también pasa por un punto de conexión privado, ya que los recursos de esa red virtual llegan al punto de conexión a través de la red privada. Comience con el modelo de salida, ya que esa opción determina el aislamiento y las opciones de entrada disponibles. En la tabla siguiente se muestran los tres modelos de salida y las opciones de entrada disponibles con cada una.
| Modelo de salida | Opciones entrantes | Más adecuado para |
|---|---|---|
| Egreso público | Pública (opcionalmente, direcciones IP seleccionadas) o un punto de conexión privado en la red virtual | Sin aislamiento de salida. Use tráfico entrante público para la creación de prototipos y las pruebas, o un punto de conexión privado para restringir quiénes pueden realizar llamadas mientras el tráfico saliente sigue siendo público. |
| Red virtual BYO | Punto de conexión privado en la red virtual | Aislamiento completo en el que se controlan los intervalos IP, el emparejamiento y el enrutamiento. Los agentes se insertan en una subred que delega y administra. |
| Red virtual administrada | Punto de conexión privado en la red virtual | Aislamiento total sin necesidad de administrar rangos de IP, o cuando su espacio de IP se solapa. Los agentes se ejecutan en una red virtual administrada por Microsoft. |
Con el egreso público, agregar un punto de conexión privado protege solo la ruta de entrada: quienes realizan las llamadas llegan al punto de conexión de Foundry de manera privada, pero el egreso del agente no está aislado.
Con la red virtual BYO, puede traer sus propios recursos de datos o usar recursos de datos administrados por la plataforma. Para más información, consulte Requisitos para la red virtual propia.
Note
El aislamiento de red se aplica a nivel de la cuenta de Foundry y del proyecto. Abarca los agentes hospedados, los agentes de solicitud y el resto de recursos de Foundry de la cuenta. Los dos tipos de agente consumen recursos de red de forma diferente dentro de una configuración aislada. Para más información, consulte Profundización en las redes del servicio Foundry Agent.
Opciones de redes por escenario
En la tabla siguiente se asignan objetivos comunes a una opción recomendada y una plantilla de implementación. Las plantillas de infraestructura como código se encuentran en el repositorio de configuración de infraestructura de ejemplos de Foundry (Bicep, con un espejo de Terraform).
| Su objetivo | Opción recomendada | Implementación con |
|---|---|---|
| La vía más rápida hacia un agente funcional, sin aislamiento | Almacenamiento público, administrado por Microsoft | Implementación del primer inicio rápido del agente hospedado (Azure CLI para desarrolladores o VS Code) |
| Mantener los datos del agente en sus propios recursos de Azure, sin aislamiento | Almacenamiento público, almacenamiento propio (estándar) | 41-standard-agent-setup |
| Restrinja quién puede llamar al punto de conexión; se acepta la salida pública | Salida pública con un punto de conexión privado | 10-private-network-basic |
| Aislamiento total sin salida pública; tú controlas la red y deseas aportar tus propios recursos de datos | Red virtual BYO con sus propios recursos de datos (estándar protegido por red) | 15-private-network-standard-agent-setup |
| Aislamiento total sin salida pública, controla la red, pero no quiere administrar los recursos de datos. | Red virtual BYO con recursos de datos administrados por la plataforma | 11-private-network-basic-vnet |
| Aislamiento completo, pero no puede administrar intervalos IP ni superposiciones de espacio IP. | Red virtual administrada | 18-managed-virtual-network |
| Aislamiento total detrás de una puerta de enlace de API | Red virtual BYO con Azure API Management | 16-private-network-standard-agent-apim-setup |
| Acceder a recursos locales desde los agentes | Red virtual BYO más VPN o ExpressRoute |
15-private-network-standard-agent-setup además de acceder a los recursos locales |
Para ver el catálogo completo de plantillas y lo que aprovisiona cada plantilla, consulte el README de configuración de la infraestructura.
Requisitos para aportar tu propia red virtual
Tanto la red virtual BYO como la red virtual administrada proporcionan aislamiento completo. La diferencia es quién ejecuta la red: con red virtual administrada, Microsoft controla los requisitos de esta sección. Elija la red virtual BYO cuando quiera controlar completamente una red que ya administra: sus propios intervalos IP, firewall, emparejamiento y enrutamiento.
Al elegir la red virtual BYO, planee estos requisitos antes de implementar. La guía de configuración y el análisis en profundidad las cubren por completo.
- Una subred dedicada y delegada. Delegue una subred en
Microsoft.App/environments. La subred no se puede compartir con más de un recurso Foundry. Dimensiónela para la escala prevista; consulte Planifique el tamaño de la subred. - Solo se admite el espacio de direcciones RFC 1918. Use
10.0.0.0/8,172.16.0.0/12, o192.168.0.0/16. No se admiten rangos públicos ni CGNAT. Los intervalos de clase A (10.x) solo están disponibles en determinadas regiones. - Su elección de recursos de datos. Con la red virtual BYO, puede elegir cómo se proporcionan los recursos de datos del agente (Azure Storage, Búsqueda de Azure AI y Azure Cosmos DB):
- Recursos de datos administrados por la plataforma. Utilice recursos de datos multicliente administrados por la plataforma para no tener que aportar ni configurar sus propios recursos. Elija esta opción cuando los agentes no necesiten recursos de datos administrados por el cliente (por ejemplo, muchos escenarios de agentes hospedados) o cuando desee evitar la planeación de capacidad para recursos como Azure Cosmos DB. Esta opción quita la necesidad de configurar los recursos de datos que no use.
- Traiga sus propios recursos de datos. Use su propio Azure Storage, Búsqueda de Azure AI y Azure Cosmos DB para que todos los datos del agente permanezcan en su tenant. Elija esta opción cuando necesite datos del agente en los recursos que posee y administra.
- Puntos de conexión privados y zonas DNS privadas para la cuenta de Foundry y para cada recurso de datos que incorpore, para que la resolución de nombres se mantenga dentro de la red virtual.
- La misma región para el recurso Foundry y la red virtual. Otros recursos pueden estar en diferentes regiones, con implicaciones de costos entre regiones.
Importante
Establezca la configuración de red virtual al crear la cuenta de Foundry. La inyección de red forma parte del flujo de creación de recursos y no se puede agregar a una cuenta existente. La configuración de red surte efecto al crear el primer agente hospedado y no se puede cambiar la inyección de red después. Para pasar a otra configuración de red, cree nuevos proyectos. La configuración se aplica a nivel de cuenta, por lo que abarca tanto los agentes hospedados como los de respuesta inmediata. Elija una red virtual propia (BYO) antes de crear la cuenta.
Para ver un diagrama de topología de la opción BYO de red virtual —la subred delegada, las microVM del agente hospedado y los puntos de conexión privados a sus recursos de datos—, vea Análisis detallado de las redes de Foundry Agent Service.
Compatibilidad de herramientas con aislamiento de red
No todas las herramientas del agente admiten el aislamiento de red. Algunas herramientas no se admiten detrás de una red virtual y algunas llegan a su destino a través de la red pública de Internet en lugar de la red privada. Antes de optar por una configuración aislada, consulte Herramientas de agente con aislamiento de red para confirmar que las herramientas que utilizan sus agentes son compatibles.
Planeamiento del tamaño de la subred
La subred debe ser como mínimo /27 y no puedes cambiar su tamaño una vez asignada, así que dimensiónala en función de la escala prevista. Todos los proyectos de la cuenta de Foundry comparten la subred, así que planee el uso combinado de cada proyecto, agente y sesión simultánea en la cuenta. Azure reserva cinco direcciones IP en cada subred para su uso interno.
- Los agentes hospedados se ejecutan en una máquina virtual micro dedicada con su propia interfaz de red, por lo que cada uno consume una dirección IP de la subred. El uso de IP se escala con el número de proyectos, los agentes hospedados en cada proyecto y sus sesiones simultáneas. Las nuevas revisiones también consumen direcciones IP temporalmente durante la implementación, cuando las revisiones antiguas y nuevas se ejecutan en paralelo.
- Los agentes de instrucciones no consumen una dirección IP en cada revisión. Utilizan un conjunto pequeño y estático de direcciones IP (hasta unas 10 por proyecto), independientemente de cuántos agentes de prompts o revisiones ejecutes.
| Tamaño de la subred | Recommendation |
|---|---|
| /24 | Recomendado para producción con agentes hospedados. Deja margen para escalar agentes alojados en distintos proyectos, soportar sesiones simultáneas y absorber actualizaciones in situ. |
| /27 | Mínimo admitido. Funciona para producción cuando se ejecutan agentes locales, o para implementaciones más pequeñas de agentes hospedados. Deja menos margen para escalar agentes hospedados y sesiones simultáneas. |
Para consultar el modelo de asignación de IP, los límites de sesiones simultáneas y los cálculos de dimensionamiento, consulte Análisis detallado de las redes de Foundry Agent Service.
Agentes hospedados frente a agentes locales
La opción de red se aplica a toda la cuenta de Foundry, pero los dos tipos de agente consumen recursos de red de forma diferente, como se describe en Planear el tamaño de la subred. Ambos tipos acceden a sus recursos mediante puntos de conexión privados en su red virtual.
Pasos siguientes
- Implemente la opción con el procedimiento de instalación o la plantilla de la tabla.
- Valida la implementación: confirma la delegación de la subred, que el acceso público esté deshabilitado y que los puntos de conexión se resuelvan en direcciones IP privadas desde el interior de la red virtual. Consulte Comprobación de la implementación.
- Solucione los errores de implementación o conectividad con la guía de solución de problemas.