Administración de API federada con áreas de trabajo

SE APLICA A: Básico v2 | Estándar v2 | Premium | Premium v2

En este artículo se proporciona información general sobre las áreas de trabajo de API Management y cómo permiten a los equipos de desarrollo de API descentralizados administrar y productivizar sus API en una infraestructura de servicio común.

¿Por qué las organizaciones deben federar la administración de API?

Hoy en día, las organizaciones enfrentan cada vez más desafíos en la administración de una proliferación de API. A medida que crece el número de API y equipos de desarrollo de API, también lo hace la complejidad de administrarlas. Esta complejidad puede dar lugar a un aumento de la sobrecarga operativa, los riesgos de seguridad y la agilidad reducida. Por un lado, las organizaciones quieren establecer una infraestructura de API centralizada para garantizar la gobernanza, la seguridad y el cumplimiento de la API. Por otro lado, quieren que sus equipos de API innoven y respondan rápidamente a las necesidades empresariales, sin la sobrecarga de administrar una plataforma de API.

Un modelo federado de administración de API aborda estas necesidades. La administración de API federada permite la administración de la API descentralizada por parte de los equipos de desarrollo con el aislamiento adecuado de los planos de control y datos, a la vez que mantiene la gobernanza centralizada, la supervisión y la detección de API administradas por un equipo de la plataforma de API. Este modelo supera las limitaciones de los enfoques alternativos, como la administración de API totalmente centralizada por el equipo de la plataforma o la administración de API en silos por cada equipo de desarrollo.

La administración de API federadas proporciona:

  • Gobernanza y observabilidad centralizadas de API
  • Un portal para desarrolladores unificado para la detección e incorporación de API eficaces
  • Permisos administrativos separados entre equipos de API, mejora de la productividad y la seguridad
  • Entorno de ejecución de API segregado entre equipos de API, mejora de la confiabilidad, la resistencia y la seguridad

Cómo permiten las áreas de trabajo la administración de API federada

En Azure API Management, use áreas de trabajo para implementar una API administrada federada. Las áreas de trabajo funcionan como "carpetas" dentro de un servicio API Management:

  • Cada área de trabajo contiene API, productos, suscripciones, valores con nombre y recursos relacionados. Consulte la referencia de la API de REST de API Management para obtener una lista completa de los recursos y las operaciones admitidos en las áreas de trabajo.
  • El acceso de Teams a los recursos de un área de trabajo se administra a través del control de acceso basado en rol (RBAC) de Azure con roles integrados o personalizados que se pueden asignar a las cuentas de Microsoft Entra y se limita a un área de trabajo.
  • Cada área de trabajo está asociada a una o varias puertas de enlace para enrutar el tráfico de api a los servicios back-end de las API del área de trabajo. Según el nivel de servicio y sus requisitos, un área de trabajo puede usar la puerta de enlace administrada predeterminada del servicio o una o varias puertas de enlace de área de trabajo.
  • El equipo de la plataforma puede aplicar directivas que abarcan api y productos en áreas de trabajo para controlar el entorno de ejecución de la API en toda la organización. Una definición de Azure Policy integrada (API Management policies should inherit parent scope policies using <base/>) permite auditar o aplicar que estas directivas se aplican en todos los recursos del área de trabajo.
  • El equipo de plataforma puede implementar una experiencia centralizada de detección de API con un portal para desarrolladores.
  • Cada equipo de área de trabajo puede recopilar y analizar registros de recursos de puerta de enlace para supervisar sus propias API de área de trabajo, mientras que el equipo de la plataforma tiene acceso federado a los registros en todas las áreas de trabajo del servicio API Management, lo que proporciona supervisión, seguridad y cumplimiento en su ecosistema de API.

Diagrama conceptual del servicio API Management con áreas de trabajo.

Note

  • Nuevo La característica de áreas de trabajo ahora está disponible en los niveles Básico v2 y Estándar v2, además de los niveles Premium y Premium v2. Las áreas de trabajo de los niveles v2 se pueden asociar a la puerta de enlace administrada de API Management predeterminada o a un recurso de puerta de enlace de área de trabajo independiente, lo que proporciona flexibilidad para configurar y escalar las áreas de trabajo.
  • Para más consideraciones sobre el precio, consulte Precios de API Management.

Aunque las áreas de trabajo se administran independientemente del servicio API Management y otras áreas de trabajo, por diseño pueden hacer referencia a los recursos de nivel de servicio seleccionados. Consulte Áreas de trabajo y otras características de API Management, más adelante en este artículo.

Información general del escenario de ejemplo

Una organización que administra las API mediante Azure API Management puede tener varios equipos de desarrollo que desarrollan, definen, mantienen y productoizan diferentes conjuntos de API. Mediante el uso de áreas de trabajo, estos equipos pueden usar API Management para administrar, acceder y proteger sus API por separado e independientemente de la administración de la infraestructura de servicio.

El flujo de trabajo siguiente muestra un proceso de ejemplo para crear y usar un área de trabajo.

  1. Un equipo central de la plataforma de API que administra la instancia de API Management crea un área de trabajo y asigna permisos a los colaboradores del área de trabajo mediante roles de RBAC. Por ejemplo, asigne permisos para crear o leer recursos en el área de trabajo. El equipo crea o asocia una puerta de enlace de API al área de trabajo para enrutar el tráfico de api.

  2. Un equipo central de la plataforma de API usa herramientas de DevOps para crear una canalización de DevOps para las API de esa área de trabajo.

  3. Los miembros del área de trabajo desarrollan, publican, producen y mantienen las API en el área de trabajo.

  4. El equipo central de la plataforma de API administra la infraestructura del servicio, como la supervisión, la resistencia y la aplicación de todas las directivas de API.

Puerta de enlace del espacio de trabajo

Cada área de trabajo se configura con una o varias puertas de enlace para habilitar el tiempo de ejecución de las API administradas dentro del área de trabajo. Según el nivel de servicio y sus requisitos, puede usar la puerta de enlace administrada predeterminada del servicio o una o varias puertas de enlace de área de trabajo (recursos de puerta de enlace independientes).

Opción Disponibilidad Ventajas Consideraciones
Puerta de enlace administrada predeterminada Actualmente disponible en los niveles v2 Sin costo adicional para el recurso de puerta de enlace; disponibilidad en todas las regiones en las que el nivel está disponible; las áreas de trabajo pueden aprovechar las funcionalidades de puerta de enlace integradas que no están disponibles en las puertas de enlace del área de trabajo, como implementaciones de varias regiones, nombres de host personalizados o conectividad de vínculo privado si se admiten en el nivel de servicio. Menos aislamiento; todas las áreas de trabajo comparten la capacidad y la configuración de la puerta de enlace
Puerta de enlace del espacio de trabajo Básico v2, Estándar v2, Premium, Premium v2 Aislamiento sólido en tiempo de ejecución; escalado independiente, nombre de host y configuración de red para cada puerta de enlace del área de trabajo Costo adicional; tiempo de implementación más largo; compatibilidad con menos regiones

Puerta de enlace administrada predeterminada

En los niveles v2, puede configurar un área de trabajo para enrutar el tráfico de API a través de la puerta de enlace administrada predeterminada del servicio, además de uno o varios recursos de puerta de enlace de área de trabajo independientes. Cuando un área de trabajo usa la puerta de enlace administrada predeterminada:

  • El tráfico de API se enruta a través del nombre de host predeterminado del servicio (por ejemplo, <service-name>.azure-api.net).
  • El espacio de trabajo comparte la capacidad y la configuración de la puerta de enlace con otros espacios de trabajo y las API de nivel de servicio.

Note

Actualmente, puede asociar un área de trabajo a la puerta de enlace administrada predeterminada solo en los niveles de servicio v2 y a través del área de trabajo de API Management: creación o actualización de la API REST.

Puerta de enlace del espacio de trabajo

Una puerta de enlace de área de trabajo es un recurso de Azure independiente (workspace gateway Premium) con la misma funcionalidad básica que la puerta de enlace administrada predeterminada.

Las puertas de enlace del área de trabajo se gestionan de forma independiente del servicio API Management y unas de otras. Permiten el aislamiento del tiempo de ejecución entre áreas de trabajo o casos de uso, lo que aumenta la confiabilidad, la resistencia y la seguridad de la API. También habilitan la atribución de problemas en tiempo de ejecución a las áreas de trabajo.

Asociación de áreas de trabajo con una puerta de enlace de área de trabajo

En función de las necesidades de su organización, puede asociar un área de trabajo o varias áreas de trabajo a una puerta de enlace de área de trabajo.

Note

La asociación de varias áreas de trabajo con una puerta de enlace de área de trabajo solo está disponible para las puertas de enlace del área de trabajo creadas después del 15 de abril de 2025.

  • Una puerta de enlace del área de trabajo tiene ciertas opciones de configuración, como la red virtual, la escala y el nombre de host, y los recursos informáticos asignados, incluidos los recursos de CPU, memoria y redes.
  • Todas las áreas de trabajo implementadas en una puerta de enlace comparten la configuración y los recursos informáticos.
  • Los errores en una API o el tráfico anómalo pueden provocar el agotamiento de estos recursos, lo que afecta a todas las áreas de trabajo de esa puerta de enlace. En otras palabras, cuantos más áreas de trabajo implemente en una puerta de enlace, mayor será el riesgo de que una API de un área de trabajo experimente problemas de confiabilidad causados por una API de otra área de trabajo.
  • Supervise el rendimiento de la puerta de enlace del área de trabajo mediante métricas integradas para el uso de cpu y memoria.

Considere la confiabilidad, la seguridad y el costo al elegir un modelo de implementación para las áreas de trabajo.

  • Asignación de un área de trabajo a su propia puerta de enlace de área de trabajo dedicada para cargas de trabajo críticas: para maximizar la confiabilidad y la seguridad de la API, asigne cada área de trabajo crítica a su propia puerta de enlace, evitando el uso compartido con otras áreas de trabajo.
  • Equilibrio de confiabilidad, seguridad y costo : asocie varias áreas de trabajo a una puerta de enlace de área de trabajo (o, si procede, la puerta de enlace administrada predeterminada) para equilibrar la confiabilidad, la seguridad y el costo de las cargas de trabajo no críticas. Distribuya los espacios de trabajo entre al menos dos puertas de enlace para ayudar a evitar que problemas como el agotamiento de recursos o los errores de configuración afecten a todas las API de la organización.
  • Usar puertas de enlace distintas para distintos casos de uso : agrupe áreas de trabajo en una puerta de enlace de área de trabajo en función de un caso de uso o requisitos de red. Por ejemplo, puede distinguir entre las API internas y externas asignandolas a puertas de enlace independientes, cada una con su propia configuración de red.
  • Prepárese para poner en cuarentena áreas de trabajo con problemas - use un proxy, como Azure Application Gateway o Azure Front Door, delante de las puertas de enlace compartidas de las áreas de trabajo para simplificar el traslado de un área de trabajo que esté provocando un agotamiento de recursos a una puerta de enlace diferente. Este enfoque evita el impacto en otras áreas de trabajo que comparten la puerta de enlace.

Note

  • Una puerta de enlace del área de trabajo debe estar en la misma región que la región principal de Azure de la instancia de API Management y en la misma suscripción.
  • Todos los espacios de trabajo asociados a una puerta de enlace del espacio de trabajo deben estar en la misma instancia de API Management.
  • Puede asociar hasta 30 espacios de trabajo con una puerta de enlace del espacio de trabajo. Póngase en contacto con el soporte técnico para aumentar este límite.

Nombre de host de la puerta de enlace del espacio de trabajo

Cada puerta de enlace de área de trabajo proporciona un nombre de host único para las API administradas en un área de trabajo asociada. Los nombres de host predeterminados siguen el patrón <gateway-name>-<hash>.gateway.<region>.azure-api.net. Use el nombre de host de puerta de enlace para enrutar las solicitudes de API a las API del área de trabajo.

Actualmente, las puertas de enlace del área de trabajo no admiten nombres de host personalizados. Puede configurar Azure Application Gateway o Azure Front Door con un nombre de host personalizado delante de una puerta de enlace de área de trabajo.

Aislamiento de red para puertas de enlace de espacios de trabajo

Opcionalmente, puede configurar un recurso de puerta de enlace de área de trabajo en una red virtual privada para aislar el tráfico entrante y saliente. Si configura este aislamiento, la puerta de enlace del área de trabajo debe usar una subred dedicada en la red virtual.

Para obtener requisitos detallados, consulte Requisitos de recursos de red para las puertas de enlace del área de trabajo.

Note

  • La configuración de red de una puerta de enlace del área de trabajo es independiente de la configuración de red de la instancia de API Management.
  • Actualmente, una puerta de enlace de área de trabajo solo se puede configurar en una red virtual cuando se crea la puerta de enlace. No se puede cambiar la configuración de red de la puerta de enlace ni la configuración posterior.

Escalar la capacidad de las puertas de enlace del espacio de trabajo

Gestione la capacidad de una puerta de enlace del área de trabajo agregando o quitando unidades de escala, de forma similar a las unidades que puede agregar a la instancia de API Management en determinados niveles de servicio. Los costos de una puerta de enlace del área de trabajo se basan en el número de unidades que seleccione.

Disponibilidad regional de las puertas de enlace del espacio de trabajo

Para obtener una lista actual de las regiones en las que están disponibles las puertas de enlace del área de trabajo, consulte Disponibilidad de los niveles v2 y las puertas de enlace del área de trabajo.

Restricciones del espacio de trabajo y de la puerta de enlace del espacio de trabajo

Restricciones de áreas de trabajo

  • Un área de trabajo no se puede asociar a una puerta de enlace autohospedada
  • Las API de las áreas de trabajo no están cubiertas por Defender para API
  • Las áreas de trabajo no admiten el administrador de credenciales
  • Las áreas de trabajo solo admiten caché interna; No se admite la caché externa
  • Los espacios de trabajo no admiten API sintéticas de GraphQL
  • Las áreas de trabajo no admiten la creación de API directamente desde recursos de Azure, como Azure OpenAI Service, App Service, Function Apps, etc. en el portal de Azure
  • Las áreas de trabajo no admiten servidores MCP
  • Las métricas de solicitud no se pueden dividir por área de trabajo en Azure Monitor; todas las métricas del área de trabajo se agregan en el nivel de servicio
  • Las áreas de trabajo no admiten certificados de CA
  • Las áreas de trabajo no admiten identidades administradas, incluidas características relacionadas, como almacenar secretos en Azure Key Vault y usar la directiva de authentication-managed-identity

Restricciones de la puerta de enlace del espacio de trabajo

Las restricciones siguientes se aplican al recurso de puerta de enlace del área de trabajo administrada. No se aplican al usar áreas de trabajo en la puerta de enlace administrada predeterminada del servicio.

  • Las puertas de enlace del área de trabajo no admiten puntos de conexión privados entrantes
  • Las puertas de enlace del área de trabajo no admiten nombres de host personalizados
  • Los espacios de trabajo solo se pueden asociar a puertas de enlace del espacio de trabajo ubicadas en la misma región y suscripción que el recurso de API Management.

Herencia de directivas globales en las puertas de enlace del área de trabajo

Las puertas de enlace del área de trabajo ejecutan la cadena completa de directivas, incluida la directiva de nivel de servicio global (global.policy.xml). Este comportamiento significa que las directivas definidas en el ámbito global se evalúan y ejecutan para las llamadas API procesadas por puertas de enlace del área de trabajo, igual que para la puerta de enlace predeterminada. Este comportamiento responde al diseño previsto y es coherente con el modelo de evaluación de directivas de API Management, donde las directivas se aplican jerárquicamente en los siguientes ámbitos: global (servicio) > área de trabajo > producto > API > operación.

Recomendaciones para directivas globales con puertas de enlace de área de trabajo

  • Revise la directiva global para asegurarse de que solo contiene directivas destinadas a aplicarse en todas las puertas de enlace, incluidas las puertas de enlace del área de trabajo.

  • Si necesita un comportamiento diferente por puerta de enlace, use la directiva choose con context.Deployment.Gateway.Id para ejecutar directivas condicionalmente en función de la puerta de enlace que procesa la solicitud.

  • Si define una identidad administrada por autenticación en el ámbito global, pero el token no debe estar disponible para las API con ámbito del área de trabajo, mueva la directiva a un ámbito más limitado (por ejemplo, producto o nivel de API) en lugar de la directiva global.

Roles RBAC para áreas de trabajo

RBAC de Azure se usa para configurar los permisos de los colaboradores del área de trabajo para leer y editar entidades en el área de trabajo. Para obtener una lista de roles, consulte Cómo usar el control de acceso basado en roles en API Management.

Para administrar las API y otros recursos del área de trabajo, asigne roles a miembros del área de trabajo (o permisos equivalentes a través de roles personalizados) que tienen como ámbito el servicio API Management y el área de trabajo. El rol con ámbito de servicio permite hacer referencia a determinados recursos de nivel de servicio de los recursos de nivel de área de trabajo. Por ejemplo, organice un usuario en un grupo de nivel de área de trabajo para controlar la API y la visibilidad del producto.

Si el espacio de trabajo usa un gateway dedicado, los miembros que administran el gateway también deben tener asignado un rol con ámbito en el recurso de gateway del espacio de trabajo.

Note

Para facilitar la administración, configure grupos de Microsoft Entra para asignar permisos de área de trabajo a varios usuarios.

Áreas de trabajo y otras características de API Management

Las áreas de trabajo son independientes para maximizar la segregación del acceso administrativo y el entorno de ejecución de la API. Para garantizar una mayor productividad y habilitar la gobernanza, la observabilidad, la reutilización y la detección de API en toda la plataforma, existen varias excepciones.

  • Referencias de recursos: los recursos de un área de trabajo pueden hacer referencia a otros recursos del área de trabajo y a los recursos seleccionados del nivel de servicio, como usuarios, servidores de autorización o grupos de usuarios integrados. No pueden hacer referencia a recursos desde otra área de trabajo.

    Por motivos de seguridad, no puede hacer referencia a recursos de nivel de servicio desde directivas de nivel de área de trabajo (por ejemplo, valores con nombre) o por nombres de recursos, como backend-id en la directiva set-backend-service .

    Important

    Todos los recursos de un servicio API Management (por ejemplo, API, productos, etiquetas o suscripciones) deben tener nombres únicos, incluso si se encuentran en áreas de trabajo diferentes. No puede tener recursos del mismo tipo y con el mismo nombre de recurso Azure en la misma área de trabajo, en otras áreas de trabajo o en el nivel de servicio.

  • Portal para desarrolladores: las áreas de trabajo son un concepto administrativo y no se exponen como tal a los consumidores del portal para desarrolladores, incluyendo a través de la interfaz de usuario del portal para desarrolladores y la API subyacente. Puede publicar API y productos dentro de un área de trabajo en el portal para desarrolladores, al igual que las API y los productos en el nivel de servicio.

    Note

    API Management admite la asignación de servidores de autorización definidos en el nivel de servicio a las API dentro de áreas de trabajo.

Migración desde áreas de trabajo en versión preliminar

Si ha creado áreas de trabajo en versión preliminar en Azure API Management y quiere seguir usándolas, migre las áreas de trabajo a la versión disponible con carácter general mediante la asociación de una puerta de enlace de área de trabajo con cada área de trabajo.

Para obtener más información sobre otros cambios que podrían afectar a las áreas de trabajo en versión preliminar, consulte Cambios importantes en las áreas de trabajo (marzo de 2025).

Eliminación de un área de trabajo

Al eliminar un área de trabajo mediante la interfaz del portal de Azure, también se eliminan todos sus recursos secundarios (API, productos, etc.) y una puerta de enlace de área de trabajo dedicada si está asociada. No elimina la instancia de API Management ni otras áreas de trabajo.

Contenido relacionado

  • Last updated on