Arquitectura de referencia de chat de Azure AI Foundry de línea base en una zona de aterrizaje de Azure
Este artículo forma parte de una serie que se basa en la arquitectura de referencia de chat de AI Foundry de línea base. Revise la arquitectura de línea de base para que pueda identificar los ajustes necesarios antes de implementarlo en una suscripción de zona de aterrizaje de aplicación de Azure.
En este artículo se describe una arquitectura de carga de trabajo de IA generativa que implementa la aplicación de chat de línea base, pero que usa recursos que están fuera del ámbito del equipo de carga de trabajo. Los equipos de plataforma administran centralmente los recursos y varios equipos de carga de trabajo los usan. Los recursos compartidos incluyen recursos de red para conexiones entre locales, sistemas de administración de acceso a identidades y directivas. Esta guía ayuda a las organizaciones que usan zonas de aterrizaje de Azure a mantener una gobernanza y rentabilidad coherentes.
Azure AI Foundry usa cuentas y proyectos para organizar el desarrollo y la implementación de inteligencia artificial. Por ejemplo, una implementación de zona de aterrizaje podría usar una cuenta como un recurso centralizado en un nivel de grupo empresarial y proyectos como un recurso delegado para cada carga de trabajo de ese grupo empresarial. Debido a los factores de la organización de recursos y las limitaciones de asignación de costos, no se recomienda esta topología y este artículo no proporciona instrucciones sobre ella. En su lugar, esta arquitectura trata la carga de trabajo como propietario de la instancia de Azure AI Foundry, que es el enfoque recomendado.
Como propietario de la carga de trabajo, delegará la administración de recursos compartidos en los equipos de plataforma para que pueda centrarse en los esfuerzos de desarrollo de cargas de trabajo. En este artículo se presenta la perspectiva del equipo de carga de trabajo y se especifican recomendaciones para el equipo de la plataforma.
Importante
¿Qué son las zonas de aterrizaje de Azure?
Las zonas de aterrizaje de Azure dividen la superficie de nube de la organización en dos áreas clave:
Una zona de aterrizaje de aplicación es una suscripción de Azure donde se ejecuta una carga de trabajo. Una zona de aterrizaje de la aplicación se conecta a los recursos de la plataforma compartida de la organización. Esa conexión proporciona a la zona de aterrizaje acceso a la infraestructura que admite la carga de trabajo, como redes, administración de acceso a identidades, directivas y supervisión.
Una zona de aterrizaje de plataforma es una colección de varias suscripciones que varios equipos de la plataforma pueden administrar. Cada suscripción tiene una función específica. Por ejemplo, una suscripción de conectividad proporciona resolución centralizada del Sistema de nombres de dominio (DNS), conectividad entre locales y aplicaciones virtuales de red (NVA) para los equipos de plataforma.
Para ayudarle a implementar esta arquitectura, comprenda las zonas de aterrizaje de Azure, sus principios de diseño y sus áreas de diseño.
Diseño del artículo
| Arquitectura | Decisiones de diseño | Enfoque del Marco de buena arquitectura de Azure |
|---|---|---|
| ▪ Diagrama de la arquitectura ▪ Recursos de carga de trabajo ▪ Recursos federados |
▪ Configuración de suscripción ▪ Redes ▪ Acceso a científico de datos ▪ Supervisión de recursos ▪ Gobernanza organizativa ▪ Administración de cambios |
▪ Confiabilidad ▪ Seguridad ▪ Optimización de costos ▪ Excelencia operativa ▪ Eficiencia del rendimiento |
Sugerencia
La implementación de referencia de referencia del chat del servicio Azure AI Foundry Agent muestra los procedimientos recomendados descritos en este artículo. Revise y pruebe estos recursos de implementación antes de elegir e implementar sus decisiones de diseño.
Arquitectura
Descargue un archivo de Visio de esta arquitectura.
Componentes
Todas las arquitecturas de zona de aterrizaje de Azure separan la propiedad entre el equipo de la plataforma y el equipo de carga de trabajo, lo que se conoce como democratización de la suscripción. Los arquitectos de aplicaciones, los científicos de datos y los equipos de DevOps deben comprender claramente esta división para determinar qué está bajo su influencia directa o control y qué no.
Al igual que la mayoría de las implementaciones de la zona de aterrizaje de aplicaciones, el equipo de cargas de trabajo administra principalmente la configuración, la implementación y la supervisión de los componentes de carga de trabajo, incluidos los servicios de inteligencia artificial de esta arquitectura.
Recursos propiedad del equipo de carga de trabajo
Los siguientes recursos permanecen prácticamente sin cambios desde la arquitectura de línea de base.
Las cuentas y los proyectos de Azure AI Foundry permiten al equipo de carga de trabajo hospedar modelos de IA generativos como servicio, implementar la seguridad del contenido y establecer conexiones específicas de la carga de trabajo a fuentes de conocimiento y herramientas.
Si el Centro de excelencia de inteligencia artificial de la organización restringe el acceso a las implementaciones del modelo de IA, es posible que el equipo de cargas de trabajo no hospede modelos en proyectos y cuentas. En su lugar, es posible que necesiten usar recursos de inteligencia artificial centralizados. En este escenario, todo el consumo de modelos normalmente fluye a través de una puerta de enlace que proporciona el equipo de la plataforma de IA.
En este artículo se supone que los modelos de IA generativos en este escenario son recursos propiedad de la carga de trabajo. Si no lo son, el host del modelo o una puerta de enlace a los modelos, se convierte en una dependencia de carga de trabajo. El equipo de la plataforma debe mantener una conectividad de red confiable con las API.
Foundry Agent Service trata las dependencias del modelo de una manera específica, por lo que se pueden producir desafíos al consumir modelos hospedados centralmente. Es posible que tenga que usar un orquestador alternativo.
Foundry Agent Service proporciona la capa de orquestación para las interacciones de chat. Hospeda y administra el agente de chat que procesa las solicitudes de usuario.
Use la configuración del agente estándar en esta arquitectura. Conecte el agente a una subred dedicada en la red virtual de radio y enrute el tráfico de salida a través de la suscripción de conectividad.
El equipo de cargas de trabajo proporciona recursos de Azure dedicados para el estado del agente, el historial de chat y el almacenamiento de archivos. Estos recursos son Azure Cosmos DB para NoSQL, Azure Storage y Azure AI Search. La instancia del servicio Foundry Agent administra estos recursos y sus datos exclusivamente. Otros componentes de la aplicación de la carga de trabajo u otras cargas de trabajo de la organización no deben usarlos.
Azure App Service hospeda la aplicación web que contiene la interfaz de usuario (UI) de chat. App Service tiene tres instancias en distintas zonas de Azure.
Una cuenta de Azure Storage hospeda el código de la aplicación web como un archivo ZIP, que se monta en App Service.
AI Search recupera los datos indexados pertinentes para las consultas de usuario de la aplicación. La búsqueda de IA sirve como almacén de conocimiento de carga de trabajo para el patrón de generación aumentada de recuperación. Este patrón extrae una consulta adecuada de un símbolo del sistema, consulta la búsqueda de IA y usa los resultados como datos de base para un modelo de base de IA generativa.
Azure Application Gateway actúa como proxy inverso para enrutar las solicitudes de usuario a la interfaz de usuario de chat hospedada en App Service. La SKU seleccionada también hospeda un firewall de aplicaciones web de Azure para proteger la aplicación front-end frente al tráfico potencialmente malintencionado.
Azure Key Vault almacena el certificado de seguridad de la capa de transporte (TLS) de Application Gateway.
Azure Monitor, los registros de Azure Monitor y Application Insights recopilan , almacenan y visualizan datos de observabilidad.
Azure Policy aplica directivas específicas de la carga de trabajo para ayudar a controlar, proteger y aplicar controles a escala.
El equipo de carga de trabajo también mantiene los siguientes recursos:
Las subredes de red virtual de radio y los grupos de seguridad de red (NSG) de esas subredes mantienen la segmentación y controlan el flujo de tráfico.
Los puntos de conexión privados protegen la conectividad con soluciones de plataforma como servicio (PaaS).
Recursos que son propiedad del equipo de la plataforma
El equipo de la plataforma posee y mantiene los siguientes recursos centralizados. Esta arquitectura supone que estos recursos están aprovisionados previamente y los trata como dependencias.
Azure Firewall en las rutas de red del centro de conectividad, inspecciona y restringe el tráfico de salida que se origina en la carga de trabajo, incluido el tráfico del agente. El tráfico de salida de la carga de trabajo va a Internet, destinos entre locales o a otras zonas de aterrizaje de aplicaciones.
Cambie de la línea base: En la arquitectura de línea de base, el equipo de carga de trabajo posee este componente. En esta arquitectura, el equipo de la plataforma lo administra en la suscripción de conectividad.
Azure Bastion en la red central proporciona acceso operativo seguro a los componentes de carga de trabajo y permite el acceso a los componentes de Azure AI Foundry.
Cambie de la línea base: En la arquitectura de línea de base, el equipo de carga de trabajo posee este componente.
La red virtual de radio es donde se implementa la carga de trabajo.
Cambie de la línea base: En la arquitectura de línea de base, el equipo de cargas de trabajo posee esta red.
Las rutas definidas por el usuario (UDR) aplican la tunelización a la red del concentrador.
Cambie de la línea base: En la arquitectura de línea de base, el equipo de cargas de trabajo posee esta red.
Las restricciones de gobernanza basadas en Azure Policy y
DeployIfNotExists(DINE) se aplican a la suscripción de carga de trabajo. Puede aplicar estas directivas en el nivel de grupo de administración propiedad del equipo de la plataforma o directamente a la suscripción de la carga de trabajo.Cambio desde la línea de base: estas directivas son nuevas en esta arquitectura. El equipo de la plataforma aplica directivas que restringen la carga de trabajo. Algunas directivas pueden duplicar las restricciones de carga de trabajo existentes o introducir nuevas restricciones.
Registros de host
Apara puntos de conexión privados. Para más información, consulte Integración de Azure Private Link y DNS a gran escala.Cambie de la línea base: En la arquitectura de línea de base, el equipo de cargas de trabajo posee esta red. En esta arquitectura, el equipo de la plataforma administra este componente en la suscripción de conectividad.
El servicio de resolución DNS admite redes virtuales de radio y estaciones de trabajo entre locales. Este servicio normalmente usa Azure Firewall como proxy DNS o solucionador privado de Azure DNS. En esta arquitectura, el servicio resuelve los registros DNS del punto de conexión privado para todas las solicitudes DNS del radio. La resolución privada dns y los conjuntos de reglas vinculados es la manera recomendada para que el equipo de la plataforma habilite estos requisitos de resolución de arquitectura debido a las características de resolución DNS del servicio foundry Agent.
Azure DDoS Protection ayuda a proteger las direcciones IP públicas frente a ataques distribuidos.
Cambie de la línea base: En la arquitectura de línea de base, el equipo de cargas de trabajo compra DDoS Protection.
Importante
Las zonas de aterrizaje de Azure proporcionan algunos de los recursos anteriores como parte de las suscripciones de la zona de aterrizaje de la plataforma. La suscripción de carga de trabajo proporciona otros recursos. Muchos de estos recursos residen en la suscripción de conectividad, que también incluye Azure ExpressRoute, Azure VPN Gateway y resolución privada de DNS. Estos recursos proporcionan acceso entre locales y resolución de nombres. La administración de estos recursos está fuera del ámbito de este artículo.
Configuración de suscripción
El equipo de carga de trabajo debe informar al equipo de plataforma de los requisitos específicos de la zona de aterrizaje para implementar esta arquitectura. Y el equipo de la plataforma debe comunicar sus requisitos al equipo de carga de trabajo.
Por ejemplo, el equipo de cargas de trabajo debe proporcionar información detallada sobre el espacio de red necesario. El equipo de la plataforma usa esta información para asignar los recursos necesarios. El equipo de carga de trabajo define los requisitos y el equipo de la plataforma asigna las direcciones IP adecuadas dentro de la red virtual.
El equipo de la plataforma asigna un grupo de administración basado en la importancia empresarial y las necesidades técnicas de la carga de trabajo. Por ejemplo, si la carga de trabajo se expone a Internet, como esta arquitectura, el equipo de la plataforma selecciona un grupo de administración adecuado. Para establecer la gobernanza, el equipo de la plataforma también configura e implementa grupos de administración. El equipo de carga de trabajo debe diseñar y operar la carga de trabajo dentro de las restricciones de esta gobernanza. Para más información sobre las diferencias típicas de grupos de administración, consulte Personalización de la arquitectura de la zona de aterrizaje de Azure.
El equipo de la plataforma configura la suscripción para esta arquitectura. En las secciones siguientes se proporcionan instrucciones sobre la configuración de la suscripción inicial.
Requisitos y cumplimiento de cargas de trabajo
El equipo de carga de trabajo y el equipo de plataforma deben colaborar en detalles como la asignación de grupos de administración, la gobernanza de Azure Policy y la configuración de redes. Prepare una lista de comprobación de los requisitos para iniciar la discusión y la negociación con el equipo de la plataforma. La siguiente lista de comprobación sirve como ejemplo.
| Consideraciones acerca del diseño | Requisito de carga de trabajo para esta arquitectura | |
|---|---|---|
| ☐ | Número de redes virtuales de radio y su tamaño: El equipo de la plataforma crea y configura la red virtual y, a continuación, la empareja con el centro regional para designarla como radio. También deben asegurarse de que la red pueda adaptarse al crecimiento futuro de la carga de trabajo. Para llevar a cabo estas tareas de forma eficaz, deben conocer el número de radios necesarios. | Implemente todos los recursos en una sola red virtual de radio dedicado. Solicite /22 espacio de direcciones contiguo para admitir operaciones a escala completa y escenarios como implementaciones en paralelo. Los siguientes factores determinan la mayoría de las necesidades de direcciones IP: - Requisitos de Application Gateway para el tamaño de subred (tamaño fijo). - Puntos de conexión privados con direcciones IP únicas para servicios PaaS (tamaño fijo). - El tamaño de subred de los agentes de compilación (tamaño fijo). - Foundry Agent Service requiere una subred dentro de un /24 prefijo. |
| ☐ | Prefijos de dirección de red virtual: Normalmente, el equipo de la plataforma asigna direcciones IP basadas en convenciones existentes, evitando la superposición con redes emparejadas y disponibilidad dentro del sistema de administración de direcciones IP (IPAM). | La subred de integración del agente debe usar un prefijo de dirección que comience por 172. o 192. como 192.168.45.1/24. Una restricción en tiempo de ejecución en el host de funcionalidad del servicio Foundry Agent aplica este requisito. Foundry Agent Service no admite subredes que usan 10.. Pida al equipo de plataforma que proporcione un radio que tenga un prefijo de dirección válido para la subred del agente. |
| ☐ | Región de implementación: El equipo de la plataforma debe implementar un centro en la misma región que los recursos de carga de trabajo. | Comunique la región seleccionada para la carga de trabajo y las regiones de los recursos de proceso subyacentes. Asegúrese de que las regiones admiten zonas de disponibilidad. Azure OpenAI en Foundry Models tiene una disponibilidad regional limitada. |
| ☐ | Tipo, volumen y patrón de tráfico: El equipo de la plataforma debe determinar los requisitos de entrada y salida de los recursos compartidos de la carga de trabajo. | Proporcione información sobre los siguientes factores: - Cómo deben consumir los usuarios esta carga de trabajo. - Cómo consume esta carga de trabajo los recursos de su entorno. - El protocolo de transporte configurado. - El patrón de tráfico y las horas punta y valle previstas. Comunicarse cuando se espera un gran número de conexiones simultáneas a Internet (chatty) y cuando se espera que la carga de trabajo genere un tráfico de red mínimo (ruido en segundo plano). |
| ☐ | Configuración del firewall: El equipo de la plataforma debe establecer reglas para permitir el tráfico de salida legítimo. | Comparta detalles sobre el tráfico saliente de la red de radio, incluido el tráfico del agente. Las máquinas de jump box y agente de compilación necesitan revisiones normales del sistema operativo. Es posible que los agentes necesiten interactuar con orígenes, herramientas u otros agentes hospedados fuera de la carga de trabajo. |
| ☐ | Tráfico de entrada de roles especializados: El equipo de la plataforma debe proporcionar los roles especificados con acceso de red a la carga de trabajo e implementar la segmentación adecuada. | Trabaje con el equipo de la plataforma para determinar la mejor manera de permitir el acceso autorizado para los siguientes roles: - Científicos de datos y desarrolladores que acceden al portal de Azure AI Foundry desde sus estaciones de trabajo en conexiones de red corporativas - Operadores que acceden a la capa de proceso a través de un jump box administrado por la carga de trabajo |
| ☐ |
Acceso público a Internet a la carga de trabajo: El equipo de la plataforma usa esta información para la evaluación de riesgos, lo que impulsa varias decisiones: - La colocación de la carga de trabajo en un grupo de administración con límites de protección adecuados - Protección de denegación de servicio distribuida (DDoS) para la dirección IP pública notificada por el equipo de carga de trabajo - Adquisición y administración de certificados TLS |
Informe al equipo de la plataforma sobre el perfil de tráfico de entrada: - Tráfico de origen de Internet que tiene como destino la dirección IP pública en Application Gateway - Nombres de dominio completos (FQDN) asociados a la dirección IP pública para la adquisición de certificados TLS |
| ☐ | Uso del punto de conexión privado: El equipo de la plataforma debe configurar zonas DNS privadas de Azure para los puntos de conexión privados y asegurarse de que el firewall de la red del concentrador realiza correctamente la resolución DNS. | Informe al equipo de la plataforma sobre todos los recursos que usan puntos de conexión privados, incluidos los siguientes recursos: - AI Search - Azure Cosmos DB para NoSQL - Key Vault - Azure AI Foundry - Cuentas de almacenamiento Comprenda cómo el centro controla la resolución DNS y define las responsabilidades del equipo de carga de trabajo para la administración de registros de zona DNS privada y vinculación del conjunto de reglas del solucionador privado de DNS. |
| ☐ |
Recursos de IA centralizados: El equipo de plataforma debe comprender el uso esperado de los modelos y las plataformas de hospedaje. Usan esta información para establecer redes en recursos de inteligencia artificial centralizados dentro de su organización. Cada organización define sus propios planes de adopción y gobernanza de inteligencia artificial, y el equipo de cargas de trabajo debe funcionar dentro de esas restricciones. |
Informe al equipo de la plataforma sobre los recursos de inteligencia artificial y aprendizaje automático que planea usar. Esta arquitectura usa azure AI Foundry, Foundry Agent Service y modelos de base generativos hospedados en Azure AI Foundry. Comprenda claramente qué servicios de inteligencia artificial centralizados debe usar y cómo afectan esas dependencias a la carga de trabajo. |
Importante
El equipo de la plataforma debe seguir un proceso de vending de suscripciones que use un conjunto estructurado de preguntas para recopilar información del equipo de carga de trabajo. Estas preguntas pueden variar entre organizaciones, pero el objetivo es recopilar la entrada necesaria para implementar suscripciones de forma eficaz. Para más información, consulte Venta de suscripciones.
Calcular
La capa de orquestación y el hospedaje de la interfaz de usuario de chat siguen siendo los mismos que la arquitectura de línea de base.
Redes
En la arquitectura de línea de base, la carga de trabajo se aprovisiona en una sola red virtual.
Cambie de la línea base: Esta arquitectura divide la carga de trabajo en dos redes virtuales. Una red hospeda componentes de carga de trabajo. La otra red administra Internet y la conectividad híbrida. El equipo de la plataforma determina cómo se integra la red virtual de la carga de trabajo con la arquitectura de red más grande de la organización, que normalmente sigue una topología en estrella tipo hub-spoke.
Descargue un archivo de Visio de esta arquitectura.
Red virtual del concentrador: Esta red virtual actúa como un centro regional que contiene servicios centralizados y, a menudo compartidos, que se comunican con recursos de carga de trabajo en la misma región. El centro reside en la suscripción de conectividad. El equipo de la plataforma posee los recursos de esta red.
Red virtual de radio: En esta arquitectura, la única red virtual de la arquitectura de línea base se convierte esencialmente en la red virtual de radio. El equipo de plataforma empareja esta red de radio con la red del concentrador. Poseen y administran la red de radios, incluida su configuración de emparejamiento y DNS. El equipo de carga de trabajo posee los recursos de esta red, incluidas sus subredes. Esta red contiene muchos de los recursos de la carga de trabajo.
Debido a esta división de administración y propiedad, el equipo de carga de trabajo debe comunicar claramente los requisitos de la carga de trabajo al equipo de la plataforma.
Importante
Para el equipo de la plataforma: No empareja directamente la red de radio con otra red de radios, a menos que la carga de trabajo lo requiera específicamente. Esta práctica protege los objetivos de segmentación de la carga de trabajo. El equipo debe facilitar todas las conexiones de red virtual transitivas. Sin embargo, si los equipos de zona de aterrizaje de aplicaciones conectan directamente sus redes mediante puntos de conexión privados autoadministrados, el equipo no administra esas conexiones.
Comprender qué recursos de carga de trabajo administran los equipos externos. Por ejemplo, comprenda la conectividad de red entre los agentes de chat y una base de datos de vectores de contexto de base que administra otro equipo.
Subredes de la red virtual
En la red virtual de radio, creará y asignará las subredes en función de los requisitos de carga de trabajo. Para proporcionar segmentación, aplique controles que restrinjan el tráfico hacia y fuera de las subredes. Esta arquitectura no agrega subredes más allá de las subredes de la arquitectura de línea de base. Sin embargo, la arquitectura de red ya no requiere las AzureBastionSubnet subredes o AzureFirewallSubnet porque es probable que el equipo de la plataforma hospede esta funcionalidad en sus suscripciones.
Al implementar la carga de trabajo en una zona de aterrizaje de Azure, todavía tiene que implementar controles de red. Su organización podría imponer más restricciones de red para proteger contra la filtración de datos y garantizar la visibilidad del centro de operaciones de seguridad central y el equipo de red de TI.
Tráfico de entrada
El flujo de tráfico de entrada sigue siendo el mismo que la arquitectura de línea base.
Los recursos relacionados con la entrada pública de Internet se administran en la carga de trabajo. Por ejemplo, en esta arquitectura, Application Gateway y su dirección IP pública residen en la red de radios en lugar de en la red del concentrador. Algunas organizaciones colocan recursos orientados a la entrada en una suscripción de conectividad mediante una red perimetral centralizada (también conocida como RED perimetral, zona desmilitarizada y subred filtrada). La integración con esa topología específica está fuera del ámbito de este artículo.
Enfoque alternativo para inspeccionar el tráfico entrante
Esta arquitectura no usa Azure Firewall para inspeccionar el tráfico entrante, pero a veces la gobernanza de la organización lo requiere. En esos casos, el equipo de la plataforma admite la implementación para proporcionar a los equipos de carga de trabajo una capa adicional de detección y prevención de intrusiones. Esta capa ayuda a bloquear el tráfico entrante no deseado. Para admitir esta topología, esta arquitectura requiere más configuraciones udR. Para más información, consulte Red de confianza cero para aplicaciones web con Azure Firewall y Application Gateway.
Configuración de DNS
En la arquitectura de línea de base, todos los componentes usan Azure DNS directamente para la resolución dns.
Cambie de la línea base: En esta arquitectura, normalmente uno o varios servidores DNS del centro realizan la resolución DNS. Cuando se crea la red virtual, las propiedades DNS de la red virtual ya deben establecerse en consecuencia. El equipo de carga de trabajo no necesita comprender los detalles de implementación del servicio DNS.
Esta arquitectura configura los componentes de carga de trabajo con DNS de las maneras siguientes.
| Componente | Configuración de DNS |
|---|---|
| Application Gateway | Heredado de la red virtual |
| App Service (interfaz de usuario de chat) | Heredado de la red virtual |
| Búsqueda IA | No se puede invalidar, usa Azure DNS. |
| Azure AI Foundry | No se puede invalidar, usa Azure DNS. |
| Servicio de agente de fundición | No se puede invalidar, usa Azure DNS. |
| Azure Cosmos DB (la base de datos de Azure Cosmos) | No se puede invalidar, usa Azure DNS. |
| Jumpbox | Heredado de la red virtual |
| Agentes de compilación | Heredado de la red virtual |
Esta arquitectura no configura las opciones de DNS para los componentes que no inician la comunicación saliente. Estos componentes no requieren resolución DNS.
Muchos componentes de esta arquitectura se basan en registros DNS hospedados en los servidores DNS del centro para resolver los puntos de conexión privados de esta carga de trabajo. Para más información, consulte Zonas DNS privadas de Azure.
Cuando la resolución dns basada en concentrador no es posible, esos componentes se enfrentan a las siguientes limitaciones:
El equipo de la plataforma no puede registrar solicitudes DNS, lo que podría infringir un requisito del equipo de seguridad de la organización.
La resolución de servicios expuestos a Private Link en la zona de aterrizaje u otras zonas de aterrizaje de aplicaciones podría ser imposible.
Se recomienda familiarizarse con la forma en que el equipo de la plataforma administra DNS. Para más información, vea Integración de Private Link y DNS a gran escala. Al agregar características de componente que dependen directamente de Azure DNS, puede introducir complejidades en la topología de DNS proporcionada por la plataforma. Puede rediseñar componentes o negociar excepciones para minimizar la complejidad.
Tráfico de salida
En la arquitectura de línea de base, todo el tráfico de salida se enruta a Internet a través de Azure Firewall.
Cambie de la línea base: En esta arquitectura, la plataforma proporciona una UDR que apunta a una instancia de Azure Firewall que hospeda. Aplique esta UDR a las mismas subredes de la arquitectura de línea de base.
Todo el tráfico que sale de la red virtual de radio, incluido el tráfico de la subred de integración del agente, vuelve a enrutar a través de la red del concentrador emparejado a través de un firewall de salida.
Descargue un archivo de Visio de esta arquitectura.
La comunicación del cliente este-oeste con los puntos de conexión privados para Key Vault, Azure AI Foundry y otros servicios sigue siendo el mismo que la arquitectura de línea base. El diagrama anterior no incluye esa ruta de acceso.
Enrutamiento del tráfico de Internet al firewall
Todas las subredes de la red radial incluyen una ruta que dirige todo el tráfico enlazado a Internet o 0.0.0.0/0 al tráfico a la instancia de Azure Firewall del centro.
| Componente | Mecanismo para forzar el tráfico de Internet a través del concentrador |
|---|---|
| Application Gateway | Ninguno. El tráfico enlazado a Internet que se origina en este servicio no se puede forzar a través del firewall del equipo de la plataforma. |
| App Service (interfaz de usuario de chat) | La integración de red virtual regional y la configuración vnetRouteAllEnabled están habilitadas. |
| Búsqueda IA | Ninguno. El tráfico que se origina en este servicio no se puede forzar a través de un firewall. Esta arquitectura no usa aptitudes. |
| Servicio de agente de fundición | Una UDR aplicada a la subred snet-agentsEgress. |
| Cuadros de salto | Una UDR aplicada a la subred snet-jumpbox. |
| Agentes de compilación | Una UDR aplicada a la subred snet-agents. |
Esta arquitectura no configura la tunelización forzada para los componentes que no inician la comunicación saliente.
En el caso de los componentes o características que no pueden enrutar el tráfico de salida a través del centro, el equipo de cargas de trabajo debe alinearse con los requisitos de la organización. Para cumplir esos requisitos, use controles de compensación, rediseñe la carga de trabajo para excluir características no admitidas o solicitar excepciones formales. Usted es responsable de mitigar la filtración y el abuso de datos.
Aplique la ruta de Internet proporcionada por la plataforma a todas las subredes, incluso si no espera que la subred tenga tráfico saliente. Este enfoque garantiza que las implementaciones inesperadas de esa subred pasen por el filtrado de salida rutinario. En el caso de las subredes que contienen puntos de conexión privados, habilite las directivas de red para admitir el enrutamiento completo y el control de NSG.
Esta configuración de ruta garantiza que todas las conexiones salientes de App Service, Azure AI Foundry y sus proyectos, y cualquier otro servicio que se origine en la red virtual de la carga de trabajo se inspeccione y controle.
Zonas DNS privadas de Azure
Las cargas de trabajo que usan puntos de conexión privados para el tráfico este-oeste requieren registros de zona DNS en el proveedor DNS configurado. Para admitir Private Link, esta arquitectura se basa en muchos registros de zona DNS para servicios como Key Vault, Azure AI Foundry y Azure Storage.
Cambie de la línea base: En la arquitectura de línea de base, el equipo de cargas de trabajo administra directamente las zonas DNS privadas. En esta arquitectura, el equipo de la plataforma normalmente mantiene zonas DNS privadas. El equipo de carga de trabajo debe comprender claramente los requisitos y expectativas del equipo de plataforma para la administración de los registros de zona DNS privada. El equipo de la plataforma puede usar otra tecnología en lugar de registros de zona DNS privadas.
En esta arquitectura, el equipo de la plataforma debe configurar DNS para los siguientes puntos de conexión de la API FQDN de Azure AI Foundry:
privatelink.services.ai.azure.comprivatelink.openai.azure.comprivatelink.cognitiveservices.azure.com
El equipo de la plataforma también debe configurar DNS para los siguientes FQDN, que son dependencias del servicio de agente de Foundry:
privatelink.search.windows.netprivatelink.blob.core.windows.netprivatelink.documents.azure.com
Importante
La resolución DNS debe funcionar correctamente desde dentro de la virtual de radio antes de implementar el host de funcionalidad para el servicio del agente foundry y durante el funcionamiento del servicio del agente foundry. La funcionalidad Servicio de agente de Foundry no usa la configuración dns de la red virtual de radio. Por lo tanto, se recomienda que el equipo de la plataforma configure un conjunto de reglas para las zonas DNS privadas de la carga de trabajo en la resolución privada de DNS y vincule esas reglas al radio de la zona de aterrizaje de la aplicación.
Antes de implementar Azure AI Foundry y su funcionalidad de agente, debe esperar hasta que las dependencias del servicio foundry Agent se puedan resolver completamente a sus puntos de conexión privados desde la red de radios. Este requisito es especialmente importante si las directivas DINE controlan las actualizaciones de las zonas privadas dns. Si intenta implementar la funcionalidad del servicio foundry Agent antes de que los registros DNS privados se puedan resolver desde dentro de la subred, se produce un error en la implementación.
El equipo de la plataforma también debe hospedar las zonas DNS privadas para otras dependencias de carga de trabajo en esta arquitectura:
privatelink.vaultcore.azure.netprivatelink.azurewebsites.net
Acceso para desarrolladores de científicos de datos y agentes
Al igual que la arquitectura de línea de base, esta arquitectura deshabilita el acceso de entrada público al portal de Azure AI Foundry y a otras experiencias basadas en exploradores. La arquitectura de línea de base implementa un jump box para proporcionar un explorador con una dirección IP de origen de la red virtual que usan varios roles de carga de trabajo.
Cuando la carga de trabajo se conecta a una zona de aterrizaje de Azure, el equipo obtiene más opciones de acceso. Trabaje con el equipo de plataforma para ver si puede obtener acceso privado a varios portales de Azure AI Foundry basados en explorador sin administrar ni gobernar una máquina virtual (VM). Este acceso puede ser posible a través del enrutamiento transitivo desde una conexión de ExpressRoute o VPN Gateway existente.
El acceso nativo basado en estación de trabajo requiere enrutamiento entre locales y resolución DNS, que el equipo de la plataforma puede ayudar a proporcionar. Incluya este requisito en la solicitud de vending de suscripción.
Proporcionar acceso nativo basado en estación de trabajo a estos portales mejora la productividad y simplifica el mantenimiento en comparación con la administración de los jump boxes de máquina virtual.
Rol del jump box
El jump box de esta arquitectura proporciona valor para la compatibilidad operativa, no para fines en tiempo de ejecución ni para el desarrollo de inteligencia artificial y aprendizaje automático. El jump box puede solucionar problemas de enrutamiento de red y DNS, ya que proporciona acceso de red interno a componentes que, de otro modo, serían inaccesibles desde el exterior.
En la arquitectura de línea de base, Azure Bastion accede al jump box, que administra.
En esta arquitectura, Azure Bastion se implementa en la suscripción de conectividad como un recurso regional compartido que administra el equipo de la plataforma. Para demostrar que el caso de uso de esta arquitectura, Azure Bastion se encuentra en la suscripción de conectividad y el equipo no lo implementa.
La máquina virtual que actúa como jump box debe cumplir los requisitos de la organización para las máquinas virtuales. Estos requisitos pueden incluir elementos como identidades corporativas en Microsoft Entra ID, imágenes base específicas y regímenes de aplicación de revisiones.
Supervisión de recursos
La plataforma de zona de aterrizaje de Azure proporciona recursos de observabilidad compartidos como parte de la suscripción de administración. Sin embargo, se recomienda aprovisionar sus propios recursos de supervisión para facilitar las responsabilidades de propiedad de la carga de trabajo. Este enfoque se alinea con la arquitectura de línea base.
Aprovisiona los siguientes recursos de supervisión:
Application Insights actúa como servicio de administración del rendimiento de la aplicación (APM) para el equipo. Este servicio se configura en la interfaz de usuario de chat, el servicio de agente de Foundry y los modelos.
El área de trabajo Registros de Azure Monitor actúa como receptor unificado para todos los registros y métricas de los recursos de Azure propiedad de la carga de trabajo.
De forma similar a la arquitectura de línea de base, todos los recursos deben enviar registros de diagnóstico de Azure al área de trabajo Registros de Azure Monitor que aprovisiona el equipo. Esta configuración forma parte de la implementación de la infraestructura como código (IaC) de los recursos. Es posible que también tenga que enviar registros a un área de trabajo central de Azure Monitor Logs. En las zonas de aterrizaje de Azure, esa área de trabajo normalmente reside en la suscripción de administración.
Es posible que el equipo de la plataforma tenga más procesos que afecten a los recursos de la zona de aterrizaje de la aplicación. Por ejemplo, pueden usar directivas DINE para configurar diagnósticos y enviar registros a suscripciones de administración centralizadas. También pueden aplicar alertas de línea base de Azure Monitor a través de la directiva. Asegúrese de que la implementación no bloquea estos flujos de registro y alerta adicionales.
Azure Policy
La arquitectura de línea de base recomienda directivas generales para ayudar a controlar la carga de trabajo. Al implementar esta arquitectura en una zona de aterrizaje de la aplicación, no es necesario agregar ni quitar directivas adicionales. Para ayudar a aplicar la gobernanza y mejorar la seguridad de esta carga de trabajo, siga aplicando directivas a su suscripción, grupos de recursos o recursos.
Espere que la suscripción a la zona de aterrizaje de la aplicación tenga directivas existentes, incluso antes de implementar la carga de trabajo. Algunas directivas ayudan a la gobernanza de la organización mediante la auditoría o el bloqueo de configuraciones específicas en las implementaciones.
Las directivas de ejemplo siguientes podrían dar lugar a complejidades de implementación de cargas de trabajo:
Policy:Secrets [en Key Vault] debe tener el período de validez máximo especificado.
Complicación: Azure AI Foundry puede almacenar secretos relacionados con las conexiones de conocimientos y herramientas en una instancia de Key Vault conectada. Esos secretos no tienen una fecha de expiración establecida por el servicio. La arquitectura de línea base no usa estos tipos de conexiones, pero puede ampliar la arquitectura para admitirlas.
Policy:AI Search services debe usar claves administradas por el cliente para cifrar los datos en reposo.
Complicación: Esta arquitectura no requiere claves administradas por el cliente. Pero puede ampliar la arquitectura para admitirla.
Los modelos Policy:AI Foundry no deben estar en versión preliminar.
Complicación: Es posible que esté en desarrollo con un modelo de versión preliminar que prevé que esté disponible con carácter general en el momento en que habilite la funcionalidad del agente en la carga de trabajo de producción.
Los equipos de la plataforma podrían aplicar directivas de DINE para controlar las implementaciones automatizadas en una suscripción de zona de aterrizaje de aplicaciones. Incorpore y pruebe previamente los cambios y restricciones iniciados por la plataforma en las plantillas de IaC. Si el equipo de la plataforma usa directivas de Azure que entran en conflicto con los requisitos de la aplicación, puede negociar una resolución.
Gestionar los cambios a lo largo del tiempo
En esta arquitectura, los servicios y las operaciones proporcionados por la plataforma sirven como dependencias externas. El equipo de la plataforma sigue aplicando cambios, incorporando zonas de aterrizaje y aplicando controles de costes. Es posible que el equipo de la plataforma no dé prioridad a las cargas de trabajo individuales. Los cambios en esas dependencias, como las modificaciones del firewall, pueden afectar a varias cargas de trabajo.
Debe comunicarse con los equipos de plataforma de forma eficaz y oportuna para administrar todas las dependencias externas. Es importante probar los cambios antes para que no afecten negativamente a las cargas de trabajo.
Cambios de plataforma que afectan a la carga de trabajo
En esta arquitectura, el equipo de la plataforma administra los siguientes recursos. Los cambios en estos recursos pueden afectar potencialmente a los objetivos de confiabilidad, seguridad, operaciones y rendimiento de la carga de trabajo. Evalúe estos cambios antes de que el equipo de la plataforma los implemente para determinar cómo afectan a la carga de trabajo.
Directivas de Azure: los cambios en las directivas de Azure pueden afectar a los recursos de carga de trabajo y sus dependencias. Estos cambios pueden incluir actualizaciones directas de directivas o movimiento de la zona de aterrizaje en una nueva jerarquía de grupos de administración. Estos cambios pueden pasar desapercibidos hasta que se produzca una nueva implementación, por lo que debe probarlos exhaustivamente.
Ejemplo: Una directiva ya no permite la implementación de instancias de Azure Cosmos DB que requieren cifrado de claves administradas por el cliente y la arquitectura usa el cifrado de claves administradas por Microsoft.
Reglas de firewall: las modificaciones en las reglas de firewall pueden afectar a la red virtual o las reglas de la carga de trabajo que se aplican ampliamente en todo el tráfico. Estas modificaciones pueden dar lugar a un tráfico bloqueado e incluso a errores silenciosos en los procesos. Estos posibles problemas se aplican tanto al firewall de salida como a las reglas de NSG aplicadas a Azure Virtual Network Manager.
Ejemplo: El tráfico bloqueado a las API de Bing conduce a invocaciones de herramientas de agente con errores para datos de conexión a Internet.
Enrutamiento en la red del concentrador: los cambios en la naturaleza transitiva del enrutamiento en el concentrador pueden afectar potencialmente a la funcionalidad de la carga de trabajo si una carga de trabajo depende del enrutamiento a otras redes virtuales.
Ejemplo: Un cambio de enrutamiento impide que los agentes de Azure AI Foundry accedan a un almacén de vectores operado por otro equipo o impide que los equipos de ciencia de datos accedan al portal de AI Foundry desde sus estaciones de trabajo.
Host de Azure Bastion: cambios en la disponibilidad o configuración del host de Azure Bastion.
Ejemplo: un cambio de configuración impide el acceso a los jump boxes y a las máquinas virtuales del agente de compilación.
Cambios de la carga de trabajo que afectan a la plataforma
En los ejemplos siguientes se describen los cambios de carga de trabajo que debe comunicar al equipo de la plataforma. El equipo de la plataforma debe validar los objetivos de confiabilidad, seguridad, operaciones y rendimiento del servicio de plataforma con respecto a los nuevos cambios antes de que entren en vigor.
Salida de red: supervise cualquier aumento significativo de la salida de red para evitar que la carga de trabajo se convierta en un vecino ruidoso en los dispositivos de red. Este problema puede afectar potencialmente a los objetivos de rendimiento o confiabilidad de otras cargas de trabajo. Esta arquitectura es principalmente independiente y es poco probable que experimente un cambio significativo en los patrones de tráfico saliente.
Acceso público: Los cambios en el acceso público para los componentes de carga de trabajo pueden requerir pruebas adicionales. El equipo de la plataforma podría reubicar la carga de trabajo en otro grupo de administración.
Ejemplo: en esta arquitectura, si quita la dirección IP pública de Application Gateway y hace que esta aplicación sea solo interna, la exposición de la carga de trabajo a Internet cambia. Otro ejemplo es exponer los portales de inteligencia artificial basados en explorador a Internet, lo que no se recomienda.
Clasificación de importancia empresarial: Los cambios en los acuerdos de nivel de servicio (SLA) de la carga de trabajo pueden requerir un nuevo enfoque de colaboración entre los equipos de la plataforma y de la carga de trabajo.
Ejemplo: La carga de trabajo puede pasar de baja a alta empresa de forma crítica debido al aumento de la adopción y el éxito.
Equipo de arquitectura empresarial
Algunas organizaciones tienen un equipo de arquitectura empresarial que podría influir en el diseño de la carga de trabajo y su arquitectura. Ese equipo entiende la estrategia de adopción de la inteligencia artificial de la empresa y los principios y recomendaciones de las cargas de trabajo de IA en el diseño de Azure. Trabaje con este equipo para asegurarse de que esta carga de trabajo de chat cumple los objetivos específicos del escenario y se alinea con la estrategia y las recomendaciones de la organización.
Consideraciones
Estas consideraciones implementan los pilares del Azure Well-Architected Framework, que es un conjunto de principios rectores que puede utilizar para mejorar la calidad de una carga de trabajo. Para obtener más información, vea Well-Architected Framework.
Fiabilidad
La confiabilidad ayuda a garantizar que la aplicación pueda cumplir los compromisos que realice para sus clientes. Para obtener más información, consulte Lista de comprobación de revisión de diseño para confiabilidad.
Esta arquitectura mantiene las garantías de confiabilidad en la arquitectura de línea base. No presenta nuevas consideraciones de confiabilidad para los componentes principales de la carga de trabajo.
Dependencias críticas
Trate todas las funciones que realiza la carga de trabajo en la zona de aterrizaje de la plataforma y de la aplicación como dependencias. Mantenga planes de respuesta a incidentes que incluyan métodos de contacto y rutas de escalación para cada dependencia. Incluya estas dependencias en el análisis del modo de error de la carga de trabajo (FMA).
Tenga en cuenta las siguientes dependencias de carga de trabajo y escenarios de ejemplo que pueden producirse:
Firewall de salida: El firewall de salida centralizado sufre cambios no relacionados con la carga de trabajo. Varias cargas de trabajo comparten el firewall.
Resolución DNS: Esta arquitectura usa DNS proporcionado por el equipo de plataforma para la mayoría de los recursos, combinados con Azure DNS y conjuntos de reglas de resolución privada de DNS vinculados para el servicio Foundry Agent. Como resultado, la carga de trabajo depende de las actualizaciones oportunas de los registros DNS para los puntos de conexión privados y la disponibilidad de los servicios DNS.
Directivas de DINE: Las directivas DINE para zonas DNS privadas de Azure, o cualquier otra dependencia proporcionada por la plataforma, funcionan mejor y no incluyen un Acuerdo de Nivel de Servicio. Por ejemplo, un retraso en la configuración de DNS para los puntos de conexión privados de esta arquitectura puede impedir que la interfaz de usuario de chat se convierta en lista para el tráfico o impedir que los agentes completen las consultas del servicio de agente foundry.
Directivas de grupo de administración: Las directivas coherentes entre los entornos admiten la confiabilidad. Asegúrese de que los entornos de preproducción coinciden con entornos de producción para proporcionar pruebas precisas y evitar desviaciones específicas del entorno que pueden bloquear una implementación o una escala. Para más información, consulte Administración de entornos de desarrollo de aplicaciones en zonas de aterrizaje de Azure.
Muchas de estas consideraciones pueden existir sin zonas de aterrizaje de Azure. Debe trabajar con equipos de plataforma de forma colaborativa para solucionar estos problemas y asegurarse de que cumple todos los requisitos. Para obtener más información, consulte Identificación de dependencias.
Seguridad
La seguridad proporciona garantías contra ataques deliberados y el uso indebido de sus valiosos datos y sistemas. Para obtener más información, consulte Lista de comprobación de revisión de diseño para seguridad.
Control del tráfico de entrada
Para aislar la carga de trabajo de otros radios de carga de trabajo de la organización, aplique grupos de seguridad de red en las subredes y use la naturaleza o los controles notransitivos del centro regional. Cree grupos de seguridad de red completos que solo permitan los requisitos de red entrantes de la aplicación y su infraestructura. Se recomienda no confiar únicamente en la naturaleza no transitiva de la red del concentrador para la seguridad.
El equipo de la plataforma implementa directivas de Azure para la seguridad. Por ejemplo, una directiva podría garantizar que Application Gateway tenga un firewall de aplicaciones web establecido con el modo de denegación, lo que restringe el número de direcciones IP públicas disponibles para la suscripción. Además de esas directivas, debe implementar más directivas centradas en la carga de trabajo que refuerzan la posición de seguridad de entrada.
En la tabla siguiente se muestran ejemplos de controles de entrada en esta arquitectura.
| Fuente | Propósito | Control de carga de trabajo | Control de plataforma |
|---|---|---|---|
| Internet | Flujos de tráfico de aplicaciones | Embudo de todas las solicitudes de carga de trabajo a través de un grupo de seguridad de red, un firewall de aplicaciones web y reglas de enrutamiento antes de permitir que el tráfico público pase al tráfico privado para la interfaz de usuario de chat. | Ninguno |
| Internet | Acceso al portal de Azure AI Foundry y acceso a la API REST del plano de datos | Denegar todo el acceso a través de la configuración de nivel de servicio. | Ninguno |
| Internet | Acceso al plano de datos a todos los servicios excepto Application Gateway | Deniegue todo el acceso a través de reglas de NSG y configuración de nivel de servicio. | Ninguno |
| Azure Bastion | Acceso a jump box y al agente de compilación | Aplique un NSG en la subred jump box que bloquee todo el tráfico a los puertos de acceso remoto, a menos que el origen sea la subred de Azure Bastion designada de la plataforma. | Ninguno |
| Red | Acceso al portal de Azure AI Foundry y acceso a la API REST del plano de datos | Denegar todo el acceso. Si no usa el jump box, permita el acceso solo desde estaciones de trabajo en subredes autorizadas para científicos de datos. | Aplicación del enrutamiento no transacciontivo o uso de Azure Firewall en un centro protegido de Azure Virtual WAN |
| Otros radios | Ninguno | Bloqueado a través de reglas de NSG. | Aplicación del enrutamiento notransitivo o uso de Azure Firewall en un centro protegido de Virtual WAN |
Control del tráfico de salida
Aplique reglas de NSG que expresen los requisitos de conectividad de salida necesarios de la solución y denieguen todo lo demás. No confíe solo en los controles de red del concentrador. Como operador de carga de trabajo, debe detener el tráfico de salida no deseado lo más cerca posible del origen.
Posee las subredes de la carga de trabajo dentro de la red virtual, pero es probable que el equipo de la plataforma cree reglas de firewall para representar específicamente los requisitos capturados como parte del proceso de vending de suscripciones. Asegúrese de que los cambios en las subredes y la ubicación de los recursos durante la vigencia de la arquitectura siguen siendo compatibles con la solicitud original. Trabaje con el equipo de red para garantizar la continuidad del control de salida de acceso mínimo.
En la tabla siguiente se muestran ejemplos de controles de salida en esta arquitectura.
| Punto final | Propósito | Control de carga de trabajo | Control de plataforma |
|---|---|---|---|
| Orígenes de Internet públicos | Es posible que el agente requiera búsqueda en Internet para establecer una solicitud de Azure OpenAI en Foundry Models. | Aplicación de grupos de seguridad de red en la subred de integración del agente | Aplicación de reglas de aplicación de firewall para almacenes de conocimiento externos y herramientas |
| Plano de datos de Azure AI Foundry | La interfaz de usuario de chat interactúa con el agente de chat. | Permitir TCP/443 desde la subred de integración de App Service a la subred del punto de conexión privado de Azure AI Foundry | Ninguno |
| Azure Cosmos DB (la base de datos de Azure Cosmos) | Para acceder a la base de datos de memoria desde el servicio del agente foundry | Permitir TCP en cada puerto a la subred del punto de conexión privado de Azure Cosmos DB | Ninguno |
Para el tráfico que sale de la red virtual de la carga de trabajo, esta arquitectura aplica controles en el nivel de carga de trabajo a través de grupos de seguridad de red y en el nivel de plataforma a través de un firewall de red de concentrador. Los NSG proporcionan reglas de tráfico de red iniciales y amplias. En el centro de la plataforma, el firewall aplica reglas más específicas para la seguridad agregada.
Esta arquitectura no requiere tráfico este-oeste entre componentes internos, como Foundry Agent Service y su instancia dependiente de AI Search, para enrutar a través de la red del concentrador.
Protección contra DDoS
Determine quién debe aplicar el plan DDoS Protection que cubre las direcciones IP públicas de la solución. El equipo de la plataforma podría usar planes de protección de direcciones IP o podría usar Azure Policy para aplicar planes de protección de red virtual. Esta arquitectura requiere cobertura de DDoS Protection porque tiene una dirección IP pública para la entrada desde Internet. Para obtener más información, consulte Recomendaciones para redes y conectividad.
Administración de identidades y acceso
A menos que la automatización de la gobernanza del equipo de la plataforma requiera controles adicionales, esta arquitectura no introduce nuevos requisitos de autorización debido a la participación del equipo de la plataforma. El control de acceso basado en rol (RBAC) de Azure debe seguir cumpliendo el principio de privilegios mínimos, lo que concede acceso limitado solo a los usuarios que lo necesitan y solo cuando sea necesario. Para obtener más información, consulte Recomendaciones para la administración de identidades y acceso.
Certificados y cifrado
Normalmente, el equipo adquiere el certificado TLS para la dirección IP pública en Application Gateway. Trabaje con el equipo de plataforma para comprender cómo los procesos de adquisición y administración de certificados deben alinearse con las expectativas de la organización.
Todos los servicios de almacenamiento de datos de esta arquitectura admiten claves de cifrado administradas por Microsoft o administradas por el cliente. Use claves de cifrado administradas por el cliente si el diseño de la carga de trabajo u organización requiere más control. Las zonas de aterrizaje de Azure no exigen un método específico.
Optimización de costos
La optimización de costos se centra en 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.
Todas las estrategias de optimización de costos de la arquitectura de línea base se aplican a los recursos de carga de trabajo de esta arquitectura.
Esta arquitectura se beneficia en gran medida de los recursos de la plataforma de la zona de aterrizaje de Azure. Por ejemplo, los recursos como Azure Firewall y DDoS Protection pasan de la carga de trabajo a los recursos de la plataforma. Incluso si usa esos recursos a través de un modelo de contracargo, la seguridad agregada y la conectividad entre locales son más rentables que la autoadministración de esos recursos. Aproveche otras ofertas centralizadas del equipo de la plataforma para ampliar esas ventajas a la carga de trabajo sin poner en peligro su objetivo de nivel de servicio, objetivo de tiempo de recuperación o objetivo de punto de recuperación.
Importante
No intente optimizar los costos consolidando las dependencias de Azure AI Foundry como recursos de plataforma. Estos servicios deben seguir siendo recursos de carga de trabajo.
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.
Sigue siendo responsable de todas las consideraciones de excelencia operativa de la arquitectura de línea de base. Estas responsabilidades incluyen la supervisión, GenAIOps, la garantía de calidad y las prácticas de implementación seguras.
Correlación de datos de varios receptores
El área de trabajo Registros de Azure Monitor de la carga de trabajo almacena los registros y métricas de la carga de trabajo y sus componentes de infraestructura. Sin embargo, un área de trabajo central de registros de Azure Monitor suele almacenar registros y métricas de servicios centralizados, como Azure Firewall, resolución privada de DNS y Azure Bastion. La correlación de datos de varios receptores puede ser una tarea compleja.
Los datos correlacionados ayudan a admitir la respuesta a incidentes. El runbook de evaluación de prioridades de esta arquitectura debe abordar esta situación e incluir información de contacto de la organización si el problema se extiende más allá de los recursos de carga de trabajo. Los administradores de la carga de trabajo pueden necesitar ayuda de los administradores de la plataforma para correlacionar las entradas de registro de la red de la empresa, la seguridad u otros servicios de la plataforma.
Importante
Para el equipo de la plataforma: Cuando sea posible, conceda permisos de RBAC para consultar y leer receptores de registro para los recursos de plataforma pertinentes. Habilite los registros de firewall para las evaluaciones de reglas de red y aplicación y el proxy DNS. Los equipos de aplicaciones pueden usar esta información para solucionar problemas de tareas. Para obtener más información, consulte Recomendaciones para la supervisión y detección de amenazas.
Agentes de compilación
Muchos servicios de esta arquitectura usan puntos de conexión privados. De forma similar a la arquitectura de línea de base, este diseño podría requerir agentes de compilación. El equipo implementa los agentes de compilación de forma segura y confiable. El equipo de la plataforma no participa en este proceso.
Asegúrese de que la administración del agente de compilación cumple los estándares de la organización. Estos estándares pueden incluir el uso de imágenes de sistema operativo aprobadas por la plataforma, programaciones de aplicación de revisiones, informes de cumplimiento y métodos de autenticación de usuario.
Eficiencia del rendimiento
La eficiencia del rendimiento hace referencia a la capacidad de escalado de la carga de trabajo para satisfacer las demandas de los usuarios de forma eficaz. Para obtener más información, consulte Lista de comprobación de revisión de diseño para la eficiencia del rendimiento.
Las consideraciones de eficiencia del rendimiento de la arquitectura de línea de base también se aplican a esta arquitectura. El equipo conserva el control sobre los recursos de los flujos de aplicación, no sobre el equipo de la plataforma. Escale el host de la interfaz de usuario de chat, los modelos de lenguaje y otros componentes según las restricciones de carga de trabajo y costo. En función de la implementación final de la arquitectura, tenga en cuenta los siguientes factores al medir el rendimiento con respecto a los objetivos de rendimiento:
- Latencia de salida y entre locales
- Limitaciones de SKU de la gobernanza de la contención de costos
Implementación de este escenario
Implemente una implementación de zona de aterrizaje de esta arquitectura de referencia.
Colaboradores
Microsoft mantiene este artículo. Los colaboradores siguientes escribieron este artículo.
Autores principales:
- Bilal Amjad | Arquitecto de soluciones en la nube de Microsoft
- Freddy Ayala | Arquitecto de soluciones en la nube de Microsoft
- Chad Kittel | Ingeniero principal de software: Patrones y prácticas de Azure
Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.
Paso siguiente
Obtenga información sobre cómo colaborar en detalles técnicos con el equipo de la plataforma.
Recurso relacionado
- Perspectiva de Well-Architected Framework sobre las cargas de trabajo de inteligencia artificial de en Azure