¿Qué son las áreas de trabajo de Azure API Management?

SE APLICA A: Premium

En API Management, las áreas de trabajo aportan un nuevo nivel de autonomía a los equipos de API de una organización, lo que les permite crear, administrar y publicar API de forma más rápida, confiable, segura y productiva dentro de un servicio de API Management. Al proporcionar acceso administrativo aislado y tiempo de ejecución de API, las áreas de trabajo potencian a los equipos de API a la vez que permiten al equipo de la plataforma de API conservar la supervisión. Esto incluye la supervisión central, el cumplimiento de las directivas de API y el cumplimiento, y la publicación de API para la detección a través de un portal para desarrolladores unificado.

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.
• El acceso 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.
• Cada área de trabajo está asociada a una puerta de enlace de área de trabajo para enrutar el tráfico de API a los servicios back-end de las API del área de trabajo.

Administración de API federada con áreas de trabajo

Las áreas de trabajo agregan compatibilidad de primera clase para un modelo federado de administración de API Management, además de modelos centralizados y en silos ya admitidos. Consulte la tabla siguiente para ver una comparación de estos modelos.

Modelo	Descripción
Centralizado	Ventajas • Gobernanza y observabilidad centralizadas de API • Portal para desarrolladores unificado para la detección e incorporación de API eficaces • Rentabilidad de la infraestructura Desventajas • No segregación de permisos administrativos entre equipos • La puerta de enlace de API es un único punto de error • Incapacidad de atribuir problemas en tiempo de ejecución a equipos específicos • La carga del equipo de plataforma para facilitar la colaboración puede reducir el crecimiento de la API
En silos	Ventajas • La segregación de permisos administrativos entre equipos aumenta la productividad y la seguridad • La segregación del tiempo de ejecución de la API entre los equipos aumenta la confiabilidad, la resistencia y la seguridad de las API • Los problemas en tiempo de ejecución están contenidos y se atribuyen a equipos específicos Desventajas • Falta de gobernanza y observabilidad centralizadas de API • Falta de un portal para desarrolladores unificado • Mayor costo y administración de plataformas más difícil
Federada	Ventajas • Gobernanza y observabilidad centralizadas de API • Portal para desarrolladores unificado para la detección e incorporación de API eficaces • La segregación de permisos administrativos entre equipos aumenta la productividad y la seguridad • La segregación del tiempo de ejecución de la API entre los equipos aumenta la confiabilidad, la resistencia y la seguridad de las API • Los problemas en tiempo de ejecución están contenidos y se atribuyen a equipos específicos Desventajas • Dificultad de administración y costo de plataforma mayor que en el modelo centralizado, pero menor que en el modelo en silos

Información general del escenario de ejemplo

Una organización que administra las API mediante Azure API Management podría tener varios equipos de desarrollo que desarrollan, definen, mantienen y producen diferentes conjuntos de API. Las áreas de trabajo permiten a estos equipos usar API Management para administrar, acceder y proteger sus API por separado e independientemente de administrar la infraestructura de servicio.

A continuación, se muestra un flujo de trabajo 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 utilizando roles RBAC, por ejemplo, permisos para crear o leer recursos en el área de trabajo. También se crea una puerta de enlace de API dedicada para el área de trabajo.

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.

API Management en un área de trabajo

Teams administra sus propias API, productos, suscripciones, back-end, directivas, registradores y otros recursos dentro de las áreas de trabajo. 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.

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.

Puerta de enlace del área de trabajo

Cada área de trabajo se puede asociar a las puertas de enlace del área de trabajo para habilitar el tiempo de ejecución de las API administradas en el área de trabajo. La puerta de enlace del área de trabajo es un recurso de Azure independiente con la misma funcionalidad básica que la puerta de enlace integrada en el servicio API Management.

Las puertas de enlace del área de trabajo se administran independientemente del servicio API Management y entre sí. Garantizan el aislamiento del tiempo de ejecución entre áreas de trabajo, el aumento de la confiabilidad de la API, la resistencia y la seguridad, y permiten la atribución de problemas en tiempo de ejecución a las áreas de trabajo.

• Para obtener información sobre el costo de las puertas de enlace del área de trabajo, consulte Precios de API Management.
• Para obtener una comparación detallada de las puertas de enlace de API Management, consulte Introducción a las puertas de enlace de API Management.

Nombre de host de la puerta de enlace

Cada asociación de un área de trabajo a una puerta de enlace de área de trabajo crea un nombre de host único para las API administradas en esa área de trabajo. Los nombres de host predeterminados siguen el patrón <workspace-name>-<hash>.gateway.<region>.azure-api.net. Actualmente, no se admiten nombres de host personalizados para las puertas de enlace del área de trabajo.

Aislamiento de red avanzado

Opcionalmente, una puerta de enlace de área de trabajo se puede configurar en una red virtual privada para aislar el tráfico entrante o saliente. Si se configura, 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.

Escalar la capacidad

Administre la capacidad de puerta de enlace agregando o quitando manualmente unidades de escalado, de forma similar a las unidades que se pueden 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

Las puertas de enlace del área de trabajo están disponibles actualmente en las siguientes regiones:

• Oeste de EE. UU.
• Centro-Norte de EE. UU
• Este de EE. UU. 2
• Sur de Reino Unido
• Centro de Francia
• Centro-oeste de Alemania
• Norte de Europa
• Este de Asia
• Sudeste de Asia
• Este de Australia
• Japón Oriental

Restricciones de puerta de enlace

Las restricciones siguientes se aplican actualmente a las puertas de enlace del área de trabajo:

• Una puerta de enlace de á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.
• Una puerta de enlace solo se puede asociar con un área de trabajo
• Un área de trabajo no se puede asociar a una puerta de enlace autohospedada
• Las puertas de enlace del área de trabajo no admiten puntos de conexión privados entrantes
• Las API de las puertas de enlace del área de trabajo no se pueden asignar nombres de host personalizados
• Las API de las áreas de trabajo no están cubiertas por Defender para API
• Las puertas de enlace del área de trabajo no admiten el administrador de credenciales del servicio API Management
• Las puertas de enlace del área de trabajo solo admiten caché interna; no se admite la caché externa
• Las puertas de enlace del área de trabajo no admiten API de GraphQL sintéticas ni API de WebSocket
• Las puertas de enlace del área de trabajo no admiten la creación de API directamente a partir de recursos de Azure, como Azure OpenAI Service, App Service, Function Apps, etc.
• 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
• Los registros de Azure Monitor se agregan en el nivel de servicio; los registros de nivel de área de trabajo no están disponibles
• Las puertas de enlace del área de trabajo no admiten certificados de entidad de certificación
• Las puertas de enlace del área de trabajo no admiten el escalado automático
• Las puertas de enlace del área de trabajo no admiten identidades administradas, incluidas características relacionadas, como almacenar secretos en Azure Key Vault y usar la directiva authentication-managed-identity

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, los miembros del área de trabajo deben tener asignados roles (o permisos equivalentes mediante roles personalizados) con ámbito al servicio API Management, el área de trabajo y la puerta de enlace del á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.

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

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

• 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 es posible 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.

  Importante

  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 haber ningún recurso del mismo tipo y con el mismo nombre de recurso de 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. Las API y los productos de un área de trabajo se pueden publicar en el portal para desarrolladores, al igual que las API y los productos en el nivel de servicio.

  Nota:

  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, se eliminan todos sus recursos secundarios (API, productos, etc.) y su puerta de enlace asociada, si va a eliminar el área de trabajo mediante la interfaz de Azure Portal. No elimina la instancia de API Management ni otras áreas de trabajo.

Contenido relacionado

• Creación de un área de trabajo
• Cambios importantes en las áreas de trabajo: junio de 2024
• Cambios importantes en las áreas de trabajo: marzo de 2025
• Límites: áreas de trabajo de API Management