Azure API Management (APIM)

Desde la publicación en Azure hasta la aplicación distribuida en la API Gateway

Principio central

APIM separa las operaciones de gobernanza, publicación y tráfico, pero cada decisión de nivel y red cambia las capacidades y los límites.

Edición en profundidad: material de estudio y consulta profesional.

radio_button_unchecked Presentación del capítulo

El capítulo anterior estudió la arquitectura de Axway API Gateway , separando diseño, dominio administrativo, instancias de ejecución, persistencia y operación . Azure API Management, conocido como APIM , resuelve un conjunto similar de problemas en un modelo de servicio administrado en Azure. Combina un plano de gestión expuesto por el portal y las API , una API Gateway responsable del tráfico, capacidades de publicación y un portal para el consumidor.

La función administrada reduce las tareas de instalación y mantenimiento del producto , pero no elimina las decisiones arquitectónicas. La elección del nivel, la topología de la red, la capacidad , la región, el modelo de identidad, las políticas, los certificados, el developer portal y la estrategia de alta disponibilidad sigue siendo responsabilidad de la organización. La nube abstrae parte de la infraestructura; no reemplaza el diseño, la gobernanza y la retroubleshooting.

APIM también ha evolucionado para escenarios híbridos y federados. Además de la API Gateway administrada, la plataforma ofrece una API Gateway autohospedada para ejecutarse en contenedores fuera del servicio administrado y espacios de trabajo para descentralizar la administración de API en una infraestructura compartida. Como la disponibilidad de estos recursos varía según el nivel, la API Gateway y la región, las decisiones deben verificarse en la documentación oficial y en la matriz de recursos actual.

Este capítulo construye un modelo mental completo: componentes, objetos de configuración, procesamiento de políticas, importación de contratos, seguridad, redes, escalabilidad, observabilidad, automatización y fallas recurrentes. El objetivo no es simplemente enseñar los clics en el portal, sino permitir al lector razonar sobre el comportamiento del runtime y diseñar una plataforma empresarial sostenible.

Cómo estudiar este capítulo

Separe siempre tres preguntas: qué pertenece al plano de gestión, qué ejecuta la API Gateway en la ruta de solicitud y qué pertenece al ecosistema del consumidor. Luego, identifique en qué nivel y tipo de API Gateway está disponible la funcionalidad.

Objetivos de aprendizaje

• Explicar la arquitectura lógica de Azure API Management y sus componentes principales.
• Distinga entre plano de administración, API Gateway administrada, API Gateway autohospedada, API Gateway del espacio de trabajo y portal de desarrollador.
• Comprender el modelo de API , operaciones, backends , productos, suscripciones, usuarios y grupos.
• Explicar apartados, scopes , herencia y orden de ejecución de las políticas.
• Diseño de autenticación, mTLS , certificados, identidades administradas e integración con Microsoft Entra ID.
• Compare conectividad pública, VNet, endpoint privado y topologías híbridas.
• Planificar unidades de escala, zonas de disponibilidad, multirregión y recuperación.
• Aplique observabilidad con Azure Monitor, Application Insights, registros y seguimiento.
• Automatice la configuración con ARM, Bicep, Terraform, REST , CLI y canalizaciones.
• Diagnosticar fallas de políticas, redes, certificados, backend , capacidad y publicación.

Estructura del capítulo

• 24.1 Posicionamiento y arquitectura lógica
• 24.2 Plano de gestión, API Gateway y portal de desarrollador
• 24.3 Niveles, pasarelas y criterios de selección
• 24.4 Modelo de recursos APIM
• 24.5 Importación y publicación de API
• 24.6 Políticas: secciones, orden y contexto
• 24.7 Scopes , herencia y fundamento
• 24.8 Valores con nombre y expresiones de política
• 24.9 Identidad, suscripciones y autorización
• 24.10 TLS , mTLS , certificados y Key Vault
• Redes 24.11, VNet, Private Link y backends privados
• 24.12 Alta disponibilidad, zonas y multirregión
• 24.13 Backends , resiliencia, caché y límites
• 24.14 Espacios de trabajo y gobernanza federada
• 24.15 Portal de desarrolladores, productos e incorporación
• 24.16 Observabilidad y retroubleshooting
• 24.17 Automatización, CI/CD e infraestructura como código
• 24.18 Seguridad, refuerzo y estudios de casos
• Resumen, lista de verificación, laboratorios, glosario y referencias.

radio_button_unchecked 24.1 Posicionamiento y arquitectura lógica

Azure API Management es una plataforma de administración de API que recibe tráfico a través de una API Gateway , aplica políticas y reenvía la llamada a un backend . Durante este runtime, la plataforma ofrece registro e importación de API , productos, suscripciones, usuarios, grupos, análisis, developer portal e interfaces administrativas. El servicio no necesariamente aloja la lógica de negocio: crea una fachada gobernada frente a backends que pueden estar en Azure, en centros de datos, en otras nubes o en servicios SaaS.

La puerta de entrada es el plano de datos. Finaliza conexiones, selecciona API y operación , ejecuta políticas, llama al backend y procesa la respuesta. El plano de administración se usa para crear o cambiar la configuración a través de Azure Portal, REST , ARM, Bicep, Terraform, PowerShell o CLI. El portal para desarrolladores organiza el descubrimiento, la documentación, las pruebas y la incorporación. Esta separación permite que la configuración se administre de forma centralizada mientras el tráfico circula a través de API Gateways administradas o distribuidas.

El modelo mental más importante es no confundir el recurso de Azure con el endpoint de tráfico. Una instancia APIM tiene recursos administrativos, endpoints de API Gateway y, según la configuración, portal, API de administración y otros nombres de host. DNS , certificados, firewall y monitoreo pueden ser diferentes para cada endpoint . Un error en el portal administrativo no significa automáticamente un error en la API Gateway y lo contrario también ocurre.

radio_button_unchecked 24.2 Plano de gestión, API Gateway y portal de desarrollador

El plan de gestión almacena y distribuye la configuración del servicio: API , operaciones, políticas, backends , valores con nombre, certificados, productos, suscripciones y diagnósticos. Los cambios se realizan como operaciones de administración de Azure y pueden tardar algún tiempo en llegar a todos los tiempos de ejecución. Esto significa que la implementación completa y la propagación completa no son exactamente el mismo evento. Las canalizaciones deben incluir validación posterior a la implementación y pruebas sintéticas.

La API Gateway administrada es operada por Microsoft y procesa el tráfico según el nivel y la topología. Debe tratarse como un componente distribuido: las unidades de escala, regiones y zonas afectan la capacidad y la resiliencia. La API Gateway tiene un endpoint de estado que se puede utilizar para monitorear y validar la disponibilidad. Sin embargo, una verificación del estado de la plataforma no reemplaza una transacción sintética que ejercita DNS , TLS , política, identidad y backend .

El portal para desarrolladores es una aplicación independiente de la propia API . Permite a los consumidores descubrir API agrupadas en productos, leer documentación, probar operaciones y solicitar suscripciones. La experiencia del portal depende de la publicación de contenido, las identidades permitidas, la configuración de CORS y la disponibilidad de la API Gateway . En entornos regulados, debe revisar cuidadosamente lo que se muestra, qué muestras contienen datos y cómo se invita o elimina a los usuarios externos.

Separación operativa

La falta de disponibilidad del plan de gestión puede impedir cambios sin reducir inmediatamente el tráfico existente. Un error en la API Gateway afecta a los consumidores incluso si se puede acceder al portal y a Azure Resource Manager.

radio_button_unchecked 24.3 Niveles, pasarelas y criterios de selección

APIM tiene familias de niveles con diferentes características de capacidad , red, escala, alta disponibilidad y recursos de gobernanza. La familia clásica incluye Developer, Basic, Standard y Premium, además del modelo de Consumo. La familia v2 moderniza las opciones Básica, Estándar y Premium. Como la disponibilidad de funciones varía y cambia con el tiempo, la arquitectura debe utilizar la matriz oficial como fuente de verdad y no suposiciones basadas únicamente en el nombre del nivel.

El nivel de Desarrollador está dirigido a escenarios no productivos y no debe elegirse como base para la disponibilidad. Los niveles de producción deben seleccionarse según el rendimiento, el SLA , la conectividad privada, las zonas, las múltiples regiones, los espacios de trabajo, la API Gateway autohospedada y los requisitos de cumplimiento. Consumo utiliza un modelo sin servidor apropiado para cargas específicas, pero tiene diferencias operativas y de funcionalidad que deben evaluarse.

La API Gateway autohospedada es un contenedor asociado con una instancia APIM , que se ejecuta en la infraestructura del cliente, como Kubernetes, OpenShift, local u otra nube. Mantiene la gestión central en Azure y acerca el plano de datos a los backends o consumidores. Esta arquitectura requiere conectividad saliente para la sincronización de la configuración y, cuando está habilitada, el envío de telemetría. También requiere responsabilidad local por la capacidad , actualización, seguridad y disponibilidad de los contenedores.

Los espacios de trabajo le permiten delegar la administración de API y el producto a los equipos, manteniendo la infraestructura compartida. Tienen sus propios recursos y API Gateways dentro del modelo compatible. Los espacios de trabajo no son sólo carpetas: introducen límites de administración, propiedad y runtime que deben incorporarse al diseño de gobernanza.

radio_button_unchecked 24.4 Modelo de recursos APIM

Una API en APIM es una fachada administrada. Tiene nombre, nombre para mostrar, ruta, protocolos, requisitos de suscripción y operaciones. Cada operación define un método y una plantilla de URL y puede tener sus propios parámetros, representaciones y políticas. El backend identifica el destino real y puede encapsular URL , credenciales, disyuntor, grupo u otras propiedades según los recursos disponibles.

API de grupo de productos y define una unidad de consumo. Un producto puede requerir suscripción , tener términos y cuotas o políticas asociadas. Las suscripciones generan credenciales de acceso, normalmente una clave primaria y una clave secundaria, que facilitan la rotación. Los usuarios y grupos controlan quién accede a los productos a través del portal. Este modelo es útil para la incorporación, pero no debe confundirse con la autorización comercial fina.

Los valores con nombre almacenan parámetros reutilizables en políticas. Pueden contener valores simples, valores secretos o referencias a Key Vault, según la configuración. Los certificados representan certificados utilizados en nombres de host, validación de clientes o autenticación de backend . Los registradores y diagnósticos conectan la API Gateway con los objetivos de observabilidad. El diseño debe tratar estos recursos como código y mantener la propiedad, el nombre y el ciclo de vida.

radio_button_unchecked 24.5 Importación y publicación de API

APIM puede crear o importar API de fuentes como OpenAPI , WSDL, OData, Azure Compute Services, WebSocket , GraphQL y gRPC backends , según lo admitido actualmente por el servicio y el nivel. La importación acelera el registro, pero no transforma automáticamente un contrato frágil en una API gobernada. Las rutas, los ID de operación , los esquemas, la seguridad, los servidores, los ejemplos y las descripciones deben revisarse antes de publicar.

OpenAPI es la opción más común para las API HTTP . El proceso de importación crea operaciones y metadata, pero ciertas extensiones, límites y versiones de la especificación pueden tener restricciones. Para SOAP , se puede importar un WSDL como transferencia o utilizarlo en escenarios de conversión REST . GraphQL y WebSocket tienen sus propios modelos y políticas que se aplican de manera diferente. La canalización debe validar el tipo de API y probar el comportamiento real en la API Gateway .

Publicar una API implica más que importarla. Es necesario configurar la base de URL , backend , políticas, seguridad, producto , suscripción , documentación, versionado, revisión y observabilidad. Las revisiones le permiten probar cambios en la misma versión pública; Las versiones representan interfaces distintas para los consumidores. La promoción deberá estar automatizada y acompañada de pruebas de humo.

Canalización conceptual: publicación de API en APIM

# Flujo conceptual de publicación
Contrato validado
  -> importación o actualización de la API
  -> configuración de backend y named values
  -> aplicación de policies por ámbito
  -> asociación a product
  -> pruebas en el gateway
  -> publicación en el developer portal
  -> observabilidad y rollout

radio_button_unchecked 24.6 Políticas: secciones, orden y contexto

Las políticas son documentos XML ejecutados por la API Gateway . La configuración se divide en entrante, backend , saliente y en caso de error. El entrante procesa la solicitud antes de reenviarla: autenticación, límite de velocidad, reescritura, validación y transformación son ejemplos comunes. El backend controla la interacción con el destino, incluidos el reenvío y los reintentos. La salida procesa la respuesta. On-error se ejecuta cuando ocurre una falla y le permite estandarizar el error, registrar telemetría o implementar rutas controladas.

El orden de las declaraciones es semántico. Una validación JWT realizada después de una solicitud de envío confidencial no protege la llamada ya realizada. Una reescritura antes de la selección correcta de la operación puede cambiar el contexto. Una respuesta de retorno detiene la ejecución y produce una respuesta inmediata. Si ocurre una falla, los pasos restantes de las secciones normales se omiten y la ejecución pasa a error.

Las expresiones de política utilizan C# limitado para evaluar el contexto, los headers , las variables y los resultados. Son poderosos y pueden introducir una lógica compleja. La API Gateway no debe convertirse en una aplicación monolítica escrita en XML . Las políticas deben seguir siendo breves, comprobables y centradas en preocupaciones transversales. La lógica empresarial extensa pertenece al backend o a un componente específico.

Ejemplo simplificado - policy XML
<policies>
  <inbound>
    <base />
    <set-variable name="correlationId"
                  value="@(context.Request.Headers.GetValueOrDefault("x-correlation-id", Guid.NewGuid().ToString()))" />
    <validate-jwt header-name="Authorization" failed-validation-httpcode="401">
      <openid-config url="https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration" />
    </validate-jwt>
  </inbound>
  <backend>
    <base />
    <forward-request timeout="30" />
  </backend>
  <outbound><base /></outbound>
  <on-error><base /></on-error>
</policies>

radio_button_unchecked 24.7 Scopes , herencia y fundamento

Las políticas se pueden aplicar a scopes como global, espacio de trabajo , producto , API y operación , según el recurso y el tipo de API Gateway . La composición permite imponer controles generales y normas especializadas cercanas a la operación . El elemento base incluye políticas heredadas del ámbito superior. El lugar donde se coloca la base define cuándo se ejecuta la cadena heredada en relación con las declaraciones en el scope actual.

Omitir la base puede romper la herencia y permitir que una API ya no reciba autenticación, registro o límites definidos globalmente. Por otro lado, heredar ciegamente todas las políticas puede producir duplicación, orden incorrecto o impacto inesperado. La gobernanza madura define qué controles son obligatorios y cómo se aprueban las excepciones.

El scope del producto debe usarse con cuidado porque una API puede asociarse con varios productos o llamarse mediante suscripción en un scope diferente. La autorización comercial no debe depender únicamente de la presencia de un producto . Global y el espacio de trabajo ayudan a implementar la línea base, mientras que la API y la operación especializan el comportamiento. Cada política debe declarar el scope esperado y sus dependencias.

radio_button_unchecked 24.8 Valores con nombre y expresiones de política

Los valores con nombre le permiten reemplazar literales repetidos con nombres administrados, como URL , audiences, tiempos de espera, indicadores y claves. Los valores secretos se pueden proteger y las referencias a Azure Key Vault reducen la necesidad de almacenar material confidencial en APIM . Aún así, es necesario monitorear la política de acceso a Key Vault, la identidad administrada y la conectividad. La referencia externa no elimina la dependencia operativa.

Las expresiones de política acceden a contexto.Solicitud, contexto.Respuesta, contexto. Api , contexto. Operación , contexto. Suscripción y variables. Pueden procesar cadenas, fechas, JSON , certificados y claims dentro del conjunto permitido. Debido a que los errores en las expresiones ocurren en runtime, las canalizaciones deben probar rutas positivas, negativas y valores faltantes. Es preferible el uso de GetValueOrDefault cuando es posible que no exista un encabezado.

Los fragmentos de políticas permiten la reutilización, pero requieren control de versiones y propiedad. Un cambio en el fragmento compartido puede afectar a muchas API . Se recomienda mantener pruebas de catálogo, unitarias o funcionales, revisión por pares y despliegue progresivo. Los valores con nombre deben tener nombres estables y no incorporar el entorno de forma confusa.

El secreto no es una configuración común.

Nunca registre claves, tokens , contraseñas o certificados directamente en la política, el repositorio o el seguimiento. Utilice valores con nombre secreto, Key Vault, identidades administradas y enmascaramiento de registros.

radio_button_unchecked 24.9 Identidad, suscripciones y autorización

APIM puede requerir claves de suscripción , validar JWT , autenticar clientes mediante certificado, usar Basic en integraciones heredadas y obtener tokens para backends . La clave de suscripción identifica una suscripción y habilita cuotas o análisis, pero no reemplaza una identidad de usuario sólida ni una autorización comercial. Las llaves deben estar separadas por aplicación, rotadas y protegidas contra fugas.

validate- jwt y validate-azure-ad- token se utilizan para validar tokens según el issuer, la audience, la suscripción y las claims . La póliza debe verificar los elementos requeridos por el contrato, no simplemente aceptar cualquier token emitido por un tenant. Después de la validación, los claims pueden usarse para decisiones simples o enviarse a un PDP externo. Las autorizaciones complejas deben evitar listas extensas codificadas en XML .

La identidad administrada permite que la API Gateway obtenga access tokens de Microsoft Entra ID para acceder a backends y recursos protegidos sin almacenar secretos del cliente. La política de authentication-managed-identity solicita y mantiene el token en caché hasta su vencimiento. Debe otorgar permisos a la identidad correcta y garantizar la conectividad con el recurso. En entornos con identidades asignadas por el usuario, el diseño debe documentar qué identidad utiliza cada backend .

radio_button_unchecked 24.10 TLS , mTLS , certificados y Key Vault

La API Gateway finaliza TLS en el nombre de host publicado. Los dominios personalizados le permiten utilizar sus propios nombres y certificados corporativos. Se recomienda Azure Key Vault para administrar certificados de nombre de host y facilitar la renovación, siempre que la identidad administrada tenga acceso y la referencia siga siendo válida. La operación necesita monitorear el vencimiento, la cadena, el nombre, la versión secreta y la actualización en APIM .

mTLS se puede aplicar en la entrada para autenticar a los consumidores mediante certificado y en la salida para autenticar el APIM en el backend . Al ingresar, la API Gateway debe negociar y validar el certificado de acuerdo con la topología. Los poderes anteriores pueden cambiar la forma en que se presenta el certificado y deben considerarse. En el resultado, la política asocia o hace referencia al certificado del cliente y debe contener una clave privada utilizable.

Los certificados autofirmados o las cadenas privadas requieren una instalación y confianza explícitas. La troubleshooting debe separar el error de negociación de TLS , el error de cadena, la discrepancia de nombre de host, la caducidad y el rechazo de la política. La renovación del certificado sin pruebas puede provocar indisponibilidad cuando el nuevo material no contiene la cadena o el formato esperado.

Ejemplo conceptual: certificados en política

<authentication-certificate thumbprint="{{backend-client-cert-thumbprint}}" />
<!-- Validación simplificada del certificado de cliente -->
<choose>
  <when condition="@(context.Request.Certificate == null)">
    <return-response>
      <set-status code="401" reason="Client certificate required" />
    </return-response>
  </when>
</choose>

radio_button_unchecked Redes 24.11, VNet, Private Link y backends privados

La arquitectura de red APIM necesita distinguir el acceso entrante a la API Gateway y la conectividad saliente al backend . Un punto de conexión privado crea una entrada privada al punto de conexión de la API Gateway a través de Azure Private Link. Por sí solo, no proporciona una ruta privada desde APIM a los servidores. Para lograr servicios privados, la API Gateway necesita conectividad saliente que cumpla con los niveles, como integración o inyección de VNet, emparejamiento, DNS privado y rutas adecuadas.

En los niveles clásicos que admiten VNet, el modo externo mantiene la API Gateway accesible externamente y al mismo tiempo le permite acceder a los recursos de la red; El modo interno publica endpoints en la red virtual y requiere una capa posterior o acceso privado. En los niveles v2, los modelos de integración y de endpoint privado tienen sus propias características. Como las diferencias son significativas, la elección debe validarse en la documentación de la familia de niveles adoptada.

DNS es una dependencia frecuente. La API Gateway debe resolver nombres de host de backend , puntos de enlace de identidad, Key Vault y servicios de telemetría. Un endpoint privado sin la zona DNS privada correcta puede resolverse en una dirección pública. Las UDR, NSG, firewalls y la inspección TLS pueden bloquear llamadas de control o de datos. Las pruebas deberán registrar origen, destino, resolución y recorrido efectivo.

En marzo de 2026, Microsoft eliminó el mecanismo de conectividad de servicios confiables de la API Gateway para ciertos servicios de Azure en el plano de datos. Las arquitecturas que dependían de esta derivación deben utilizar conectividad de red explícita. Este cambio refuerza un principio general: la conectividad implícita y las excepciones del firewall deben tratarse como dependencias versionadas y monitoreadas.

radio_button_unchecked 24.12 Alta disponibilidad, zonas y multirregión

La escala en APIM se expresa en unidades, capacidad de nivel y, en algunos modelos, comportamiento elástico. Agregar unidades aumenta la capacidad y puede contribuir a la redundancia. La métrica de Capacidad debe interpretarse junto con la latencia, las solicitudes, la CPU lógica, las políticas pesadas y las dependencias de backend . Las pruebas de carga son esenciales porque el rendimiento varía según la carga útil, TLS , la política y el caché.

Las zonas de disponibilidad protegen contra fallas de zona en regiones y niveles admitidos. La recomendación de redundancia debe considerar un número mínimo de unidades y distribución automática o configurada según el servicio. Las zonas no protegen contra fallas regionales, errores de configuración global o backend no disponibles. La multirregión agrega API Gateways regionales a una instancia y puede reducir la latencia y mejorar la resiliencia, pero requiere diseño de enrutamiento, certificados, backends y datos compartidos.

Una implementación multirregional necesita decidir cómo el consumidor elige la región, generalmente con DNS o servicio entrante global. Las políticas y la configuración están distribuidas, pero los servidores pueden tener diferentes topologías. Los valores nombrados y las rutas regionales deben ser explícitos. Se debe probar la conmutación por error, incluida la posibilidad de que una región APIM esté en buen estado mientras el backend regional no esté disponible.

Las API Gateways autohospedadas añaden otra dimensión: pueden mantener el procesamiento cerca del backend incluso cuando la conectividad de baja latencia con Azure se degrada, dentro de los límites de salud y sincronización admitidos. La organización es responsable de las réplicas, las sondas, las actualizaciones y los recursos del clúster.

radio_button_unchecked 24.13 Backends , resiliencia, caché y límites

Los backends deben definirse como recursos reutilizables cuando varias API comparten objetivos, credenciales o parámetros. Políticas como set- backend -service seleccionan el backend . Los reintentos deben utilizarse con discreción: repetir una operación no idempotente puede duplicar el efecto. El reintento APIM ejecuta políticas secundarias según la condición y el recuento; no hace que la operación sea segura automáticamente.

Los tiempos de espera deben formar un presupuesto de un extremo a otro. El tiempo de espera del consumidor debe ser mayor de lo necesario para la API Gateway y el backend , pero no tan alto como para mantener los recursos indefinidamente. La llamada auxiliar mediante solicitud de envío también consume mucho tiempo. Los grupos de disyuntores y backend , cuando están disponibles en el modelo adoptado, ayudan a contener las fallas, pero requieren umbrales coherentes y observabilidad.

El cache puede reducir la latencia y la carga, pero sólo se deben almacenar las respuestas adecuadas. Los datos personalizados, los tokens , los headers confidenciales y las variaciones por usuario requieren claves y reglas correctas. El límite de velocidad controla las ráfagas o la velocidad por ventana; La cuota controla el volumen acumulado. Las políticas pueden utilizar suscripción , IP , reclamo u otra clave, pero es necesario evaluar la cardinalidad y la distribución.

La API Gateway no debe compensar indefinidamente un backend de tamaño deficiente. Los reintentos, el cache y la limitación son controles de resiliencia, no sustitutos de la capacidad y la corrección. Una política agresiva puede amplificar las fallas: los reintentos sincronizados aumentan la carga, el registro de la carga útil consume recursos y las transformaciones extensas aumentan la latencia.

radio_button_unchecked 24.14 Espacios de trabajo y gobernanza federada

Se crearon espacios de trabajo para permitir que los equipos descentralizados administren y publiquen API en una infraestructura APIM compartida. Un espacio de trabajo contiene API , productos, suscripciones y otros recursos compatibles, con acceso administrativo independiente y API Gateway asociada. Esto permite un modelo federado: la plataforma central opera la infraestructura y la línea base; Los equipos de dominio controlan el ciclo de vida de sus API .

El beneficio llega con nuevas fronteras. Las políticas globales, locales y de espacio de trabajo deben diseñarse sin elusiones. Se deben estandarizar los nombres, las etiquetas, la propiedad, los diagnósticos, los costos y los límites. No se deben otorgar permisos para todo el servicio a los equipos cuando solo se necesita un espacio de trabajo . Al mismo tiempo, la plataforma debe evitar una centralización excesiva que convierta cada cambio en una cola operativa.

Los espacios de trabajo no significan un aislamiento físico completo. Según el nivel y la API Gateway , es posible que se compartan los recursos y los límites de la infraestructura. La evaluación de cumplimiento debe verificar el plano de datos, los registros, las identidades, la red y el radio de la explosión. La característica evoluciona rápidamente y es necesario revisar su matriz antes de asumir compromisos arquitectónicos.

radio_button_unchecked 24.15 Portal de desarrolladores, productos e incorporación

El portal para desarrolladores transforma el catálogo técnico en una experiencia para el consumidor. Las API se presentan directamente o dentro de los productos, con documentación, ejemplos y una consola de prueba. Los consumidores pueden crear una cuenta, solicitar una suscripción y obtener claves según el flujo de trabajo configurado. En las API externas, los términos de uso, contacto, límites y procesos de soporte deben ser visibles.

Los productos deben representar ofertas coherentes, no sólo agrupaciones arbitrarias. Un producto puede diferenciar entre sandbox y producción, socio e interno o niveles de servicio. Las políticas de productos pueden aplicar cuotas, pero los contratos comerciales y la autorización permanecen en los niveles apropiados. El portal debe evitar publicar endpoints internos, headers confidenciales o cargas útiles reales en ejemplos.

Es necesario versionar y probar la personalización del portal. Los cambios de identidad, dominio, CORS o contenido pueden impedir la incorporación incluso si la API Gateway está en buen estado. API Center puede complementar el descubrimiento empresarial de múltiples API Gateways , mientras que el portal para desarrolladores de APIM sigue centrado en consumir las API administradas en esa plataforma.

radio_button_unchecked 24.16 Observabilidad y retroubleshooting

APIM expone métricas y registros de recursos a través de Azure Monitor y puede integrar diagnósticos con Application Insights. Las métricas muestran volumen, latencia, capacidad y códigos de respuesta. Los registros de API Gateway le permiten investigar solicitudes, operaciones, backend , políticas y errores. Application Insights agrega correlación y análisis distribuido cuando el backend también participa en el seguimiento.

La observabilidad debe equilibrar el detalle y la seguridad. El registro de carga útil puede capturar datos personales, tokens y secretos. Los headers deben estar en la lista permitida y enmascarados. El muestreo reduce los costos, pero puede ocultar errores poco comunes. Los ID de correlación deben propagarse al backend y devolverse al consumidor cuando corresponda. El seguimiento de políticas puede agregar eventos personalizados a los seguimientos y la telemetría según la configuración.

El diagnóstico debe separar el error generado por APIM del error devuelto por el backend . Un 401 puede provenir de validate- jwt , suscripción , mTLS o servicio comercial. Un 502 puede indicar un error en la conexión DNS , TLS o backend , pero también una transformación de respuesta no válida. El contexto LastError en caso de error proporciona fuente, motivo, mensaje, scope , sección y ruta, lo que es útil para clasificar el paso fallido.

Los rastreos de prueba son útiles, pero deben protegerse y no utilizarse como sustituto de la telemetría continua. Los controles de salud validan la API Gateway ; las transacciones sintéticas validan el viaje. Los paneles deben separar la latencia total, el tiempo de backend y el tiempo de la política para evitar culpar al componente equivocado.

radio_button_unchecked 24.17 Automatización, CI/CD e infraestructura como código

La configuración manual a través del portal es útil para el aprendizaje y el diagnóstico , pero no debería ser la forma principal de promover entornos. APIM puede ser administrado por ARM, Bicep, Terraform, REST , PowerShell y CLI. Los contratos, políticas, valores con nombre, backends , productos y diagnósticos deben tener versiones. Los secretos deben ingresar a través de referencias seguras, no del repositorio.

Las canalizaciones deben separar la infraestructura de la plataforma y el contenido de la API cuando la propiedad es diferente. Un equipo central puede aprovisionar instancias, redes, identidades y registros; Los equipos de dominio publican API y políticas dentro de las barreras de seguridad. XML Lint, validación de OpenAPI , diferenciación de contratos, pruebas de políticas, pruebas de humo y aprobación de cambios reducen las regresiones.

Las revisiones le permiten probar un cambio sin cambiar inmediatamente la versión pública. Después de la validación, una revisión pasa a ser actual. Las versiones permiten la coexistencia de contratos incompatibles. La reversión debe considerar qué configuración puede haberse propagado y qué consumidores pueden haber observado el cambio. La copia de seguridad y la restauración, cuando corresponda al nivel y modelo, no reemplazan el código fuente ni la reconstrucción automatizada.

El drift entre el portal y el repositorio es un riesgo. Azure Policy, RBAC, locks y pipelines ayudan a reducir los cambios no rastreados. Cuando
se realiza manualmente una corrección de emergencia, debe reconciliarse inmediatamente con el código.
Ejemplo conceptual - API Management as code
# Estructura de repositorio sugerida
infra/
  apim.bicep
  networking.bicep
  diagnostics.bicep
apis/
  clientes/openapi.yaml
  clientes/policies/
    api-policy.xml
    operations/
shared/
  policy-fragments/
  naming-and-standards.md

radio_button_unchecked 24.18 Seguridad, refuerzo y estudios de casos

El hardening comienza reduciendo la exposición. El plan de gestión debe utilizar RBAC , PIM y pistas de auditoría con least privilege. Gateway sólo debe aceptar protocolos, conjuntos de cifrado y nombres de host necesarios dentro de las capacidades del servicio. El acceso a la red pública debe estar deshabilitado cuando se valida la arquitectura privada. Los dominios, certificados y DNS personalizados necesitan propiedad y renovación automatizada.

Las políticas globales deben imponer líneas de base, headers , límites y registros de autenticación, pero las excepciones deben ser explícitas. Los valores y certificados con nombre deben usar Key Vault cuando sea apropiado. Los seguimientos y registros no pueden registrar credenciales. Los portales y las API administrativas deben protegerse por separado del endpoint de la API Gateway . Dependencias como Entra ID, Key Vault, Application Insights y DNS necesitan supervisión.

Estudio de caso 1: una API pública utiliza Azure Front Door con WAF delante de APIM , un punto de conexión privado en la API Gateway y backends privados. Front Door proporciona entrada global y protección L7; APIM realiza OAuth , cuotas y transformación. El diseño debe garantizar DNS privado, certificado entre capas y preservación segura de la IP original.

Estudio de caso 2: una empresa mantiene backends de OpenShift localmente y utiliza una API Gateway autohospedada en el clúster. Azure mantiene la configuración y el catálogo, mientras que el tráfico sigue siendo local. La operación necesita escalar réplicas, usar mTLS , garantizar la salida 443 para la sincronización y monitorear las versiones del contenedor.

Estudio de caso 3: Los equipos de pagos, crédito y registro utilizan espacios de trabajo. La plataforma central aplica líneas de base y observabilidad, mientras que cada dominio gestiona API y productos. El principal riesgo es que una política de espacio de trabajo ignore la herencia o cree un comportamiento inconsistente; Pruebas automáticas verifican bases y estándares obligatorios.

Siguiente paso del curso

Con Axway y Azure APIM estudiados, el siguiente capítulo profundiza en la seguridad de API según el OWASP API Security Top 10, conectando amenazas concretas a los controles de API Gateway , aplicaciones, identidad y operación .

radio_button_unchecked Resumen del capítulo

Azure API Management separa el plano de administración, el plano de datos y la experiencia de consumo. La API Gateway ejecuta políticas y reenvía tráfico; el plan de gestión gestiona la configuración; El portal para desarrolladores organiza el descubrimiento y la incorporación. Las API Gateways administradas, autohospedadas y de espacio de trabajo sirven diferentes topologías y transfieren diferentes responsabilidades operativas.

El modelo de recursos combina API , operaciones, backends , productos, suscripciones, valores con nombre, certificados y diagnósticos. Las políticas se ejecutan en entrada, backend , salida y en caso de error, con scopes y herencia controlados por base. El orden de las declaraciones es parte del comportamiento y necesita pruebas.

La red y la disponibilidad dependen del nivel. El endpoint privado protege la entrada, mientras que la conectividad backend requiere un diseño de salida. Las unidades de escala, zonas y multiregiones resuelven diferentes clases de fallas. La identidad administrada , Key Vault, TLS y mTLS reducen los secretos, pero dependen de los permisos y la conectividad.

La operación madura requiere observabilidad, automatización, control de deriva, pruebas de contrato, capacidad y runbooks. APIM se gestiona, pero la organización sigue siendo responsable de la arquitectura, las políticas, la identidad, los datos, los servidores y la experiencia del cliente.

radio_button_unchecked Lista de verificación de arquitectura y operación

• El nivel y el tipo de API Gateway se eligieron en función de la matriz de recursos actual y el SLA requerido.
• La entrada a la API Gateway y la salida a los servidores tienen un diseño de red independiente y documentado.
• Los DNS , los certificados, los dominios personalizados y los endpoints privados tienen pruebas y propiedad.
• Las políticas globales y de espacio de trabajo utilizan la base y tienen un proceso de excepción formal.
• Las claves de suscripción no se utilizan como sustituto de la identidad y la autorización comercial.
• Las identidades administradas solo tienen los permisos necesarios y no dependen de la omisión implícita del firewall.
• Los valores, secretos y certificados con nombre utilizan el almacenamiento y la rotación adecuados.
• Se probaron tiempos de espera, reintentos, caché, límites de velocidad y cuotas en escenarios de falla.
• Métricas, registros, Application Insights y transacciones sintéticas cubren el recorrido.
• La configuración se versiona y se publica mediante canalización con prueba de humo y plan de reversión.
• La alta disponibilidad incluye backends , identidad, DNS , ingreso global y proceso de recuperación.
• El portal y los productos para desarrolladores exponen únicamente documentación y ejemplos aprobados.

radio_button_unchecked laboratorios y ejercicios

• Importe una OpenAPI e identifique las API , las operaciones y el backend generados.
• Cree políticas de entrada, salida y en caso de error y observe el orden de ejecución.
• Aplicar una política global y API usando base; Pruebe el efecto de omitir la base en el laboratorio.
• Configure un valor con nombre y reemplace un literal de política.
• Validar un JWT y diferenciar 401 de 403 en respuestas controladas.
• Utilice una identidad administrada para autenticar APIM en un backend protegido.
• Configure un dominio personalizado con un certificado de Key Vault en un entorno de prueba.
• Diseñar una topología con Front Door, endpoint privado y backend privado, indicando DNS y rutas.
• Cree un panel con solicitudes, estado, duración y capacidad del backend .
• Simule el tiempo de espera del backend y capture LastError en caso de error.
• Modele un espacio de trabajo con responsabilidades de plataforma y dominio.
• Escriba una canalización conceptual de importación, política, prueba y publicación.

radio_button_unchecked Glosario

radio_button_unchecked Referencias técnicas

• Microsoft aprende. Azure API Management: descripción general y conceptos clave. Actualizado en 2025.
• Microsoft aprende. API Gateway en Azure API Management. Actualizado en mayo de 2026.
• Microsoft aprende. Niveles de Azure API Management v2. Actualizado en marzo de 2026.
• Microsoft aprende. Comparación basada en características de los niveles de Azure API Management. Actualizado en 2026.
• Microsoft aprende. Políticas en Azure API Management. Actualizado en mayo de 2026.
• Microsoft aprende. Espacios de trabajo en Azure API Management. Actualizado en junio de 2026.
• Microsoft aprende. Descripción general de la API Gateway autohospedada y políticas de soporte. Actualizado en 2026.
• Microsoft aprende. Configure un punto de conexión privado entrante para Azure API Management. Actualizado en junio de 2026.
• Microsoft aprende. Fiabilidad en Azure API Management e implementación multirregional.
• Microsoft aprende. Utilice identidades administradas en Azure API Management. Actualizado en abril de 2026.
• Microsoft aprende. Integre Azure API Management con Application Insights. Actualizado en marzo de 2026.
• Microsoft aprende. Observabilidad en Azure API Management. Actualizado en junio de 2026.
• Microsoft aprende. Importe las API de OpenAPI y SOAP a Azure API Management.
• Marco de buena arquitectura de Microsoft Azure. Guía de servicios para Azure API Management.

Nota de actualización

Azure API Management evoluciona con frecuencia. Los niveles, regiones, límites, espacios de trabajo, API Gateways y políticas pueden cambiar. Antes de implementar una decisión, valide la documentación oficial y la matriz de recursos para la región y el nivel seleccionados.