Un banco requiere flujos de trabajo de integración que: se ejecuten en una red virtual aislada con conectividad de entrada y salida privada, accedan a sistemas SAP y SQL Server a través de ExpressRoute sin usar un data gateway local, utilicen conectores administrados y proporcionen un rendimiento predecible a escala. ¿Qué modelo de alojamiento debería recomendar para estos flujos de trabajo?

La opción correcta es Azure Logic Apps (Consumption) implementado en un Integration Service Environment (ISE) con inyección de VNET. Un ISE proporciona un entorno aislado y dedicado dentro de una red virtual, lo que permite conectividad privada de entrada y salida, y acceso seguro a recursos locales como SAP y SQL Server a través de ExpressRoute sin necesidad de un data gateway local. Los conectores administrados para SAP y SQL están disponibles dentro del ISE, cumpliendo con los requisitos de integración. Las otras opciones son incorrectas porque: Azure Logic Apps (Consumption) en el servicio multi-tenant con un data gateway local: Requiere un data gateway local, lo cual se quiere evitar, y no ofrece el aislamiento de red necesario. Azure Logic Apps (Standard) en un plan de App Service sin integración de VNET: No cumple con el requisito de red virtual aislada y conectividad privada. Azure Functions en el plan Consumption con Durable Functions: Aunque potente, requeriría código personalizado para SAP, lo cual es menos eficiente que los conectores administrados, y el plan Consumption no ofrece el aislamiento de red requerido. Azure API Management self-hosted gateway en Kubernetes: Es una solución para la gestión de APIs, no para flujos de trabajo de integración complejos con conectores administrados.