Azure Load Testing: análisis del servicio de Microsoft

Azure Load Testing es el servicio gestionado de Microsoft para ejecutar pruebas de JMeter y Locust a gran escala desde Azure, con cobro por hora de usuario virtual. Encaja bien cuando el sistema que pruebas corre en Azure, porque puede traer métricas de servidor de Azure Monitor y llegar a endpoints privados dentro de una red virtual. A los equipos que escriben scripts de k6, no tienen suscripción de Azure o prueban desde fuera de las regiones de Azure les resultarán más sencillos otros servicios.

No hemos ejecutado Azure Load Testing para este análisis. Los datos salen de la documentación y la página de precios de Microsoft, comprobadas el 19 de octubre de 2026, y las valoraciones son nuestras.

¿Qué es Azure Load Testing?

Es un servicio totalmente gestionado que ejecuta tu prueba de carga en los motores de prueba de Microsoft, así que nunca montas ni parcheas generadores de carga. Creas un recurso de pruebas de carga en una región de Azure, le añades pruebas y lanzas ejecuciones desde el portal, la Azure CLI o un pipeline.

La página de introducción dice que la aplicación probada puede estar en cualquier sitio: en Azure, en tus instalaciones o en otra nube. Microsoft incluye ahora el servicio en el hub Azure App Testing, junto a Playwright Workspaces; el inicio rápido de Locust crea el recurso desde ese hub (comprobado el 19 de octubre de 2026).

¿Qué tipos de prueba y herramientas admite?

Tres caminos: una prueba rápida por URL, un script de JMeter subido o un script de Locust subido. La documentación dice claramente que no admite ningún otro framework de pruebas.

La prueba rápida admite hasta cinco peticiones HTTP y un objetivo de usuarios virtuales o de peticiones por segundo. Cada motor maneja hasta 250 usuarios virtuales, así que 400 usuarios corren en dos motores de 200 cada uno.

Con JMeter puedes usar plugins de jmeter-plugins.org o subir los tuyos, y la introducción afirma que funciona cualquier protocolo que admita JMeter, como una conexión a base de datos o una cola de mensajes. Con Locust puedes añadir plugins de Locust y otras bibliotecas de Python. La propia documentación de Locust remite al servicio como su opción alojada, y nuestro análisis de Locust cubre la herramienta en sí. Los scripts de k6, Gatling y Artillery no se ejecutan aquí (comprobado el 19 de octubre de 2026).

¿Cómo funcionan los motores, los usuarios virtuales y los límites?

Escalas una prueba añadiendo instancias de motor. En JMeter, la carga total es el número de usuarios del plan de prueba multiplicado por el número de motores; en Locust, fijas el total de usuarios y eliges cuántos motores los generan.

La página de conceptos da ambas fórmulas, y la página de límites del servicio fija los topes por región y suscripción (comprobado el 19 de octubre de 2026):

• Instancias de motor por ejecución: de 1 a 400 por defecto según la oferta, 400 como máximo.
• Instancias de motor simultáneas: de 5 a 400 por defecto, hasta 1.000 bajo petición.
• Duración de la prueba: de 3 a 24 horas por defecto, 24 horas como máximo.
• Criterios de fallo: hasta 50 por prueba.
• Conservación: métricas de servidor 90 días, métricas de cliente 365 días, resultados y registros 6 meses.

Subir un límite por defecto exige una solicitud a soporte; nada supera los máximos indicados.

¿Puede probar endpoints privados y generar carga desde varias regiones?

Sí a ambas cosas, con una pega: no se combinan. La carga desde varias regiones solo funciona contra endpoints públicos.

Por defecto, los motores corren en la región de tu recurso de pruebas de carga. La guía de varias regiones permite elegir hasta 5 regiones por prueba y repartir la carga entre ellas, y al hacerlo pasa la prueba a tráfico público. Para servicios sin endpoint público, la inyección en una red virtual coloca los motores dentro de la red que aloja la aplicación (comprobado el 19 de octubre de 2026).

¿Qué muestran los resultados y las métricas de servidor?

El panel muestra en directo durante la ejecución las métricas del lado del cliente, como usuarios virtuales, tiempo de respuesta y peticiones por segundo. Para aplicaciones alojadas en Azure añade métricas del lado del servidor de Azure Monitor, Application Insights y Container Insights en la misma línea de tiempo.

Esa combinación es la gran ventaja del servicio: ves la base de datos o el contenedor que se satura en el momento en que suben los tiempos de respuesta, sin montar un panel aparte. La guía de métricas de servidor describe los pasos. Las ejecuciones anteriores se pueden comparar lado a lado, y puedes descargar los resultados para otras herramientas.

¿Cómo funcionan los criterios de aprobación y la CI?

Defines criterios de fallo sobre métricas de cliente o de servidor, y la ejecución se marca como fallida en cuanto se incumple alguno. Los pipelines de Azure DevOps, GitHub Actions o cualquier herramienta de CI que pueda llamar a la Azure CLI pueden lanzar una prueba y decidir según ese resultado.

Según la guía de criterios de fallo, un criterio es un agregado de una métrica de cliente, como el tiempo de respuesta medio o el porcentaje de errores, comparado con un umbral, ya sea para toda la prueba o para una petición con nombre. Las métricas de servidor necesitan que la identidad administrada del recurso pueda leerlas. La parada automática corta una ejecución cuando la tasa de errores supera un límite, para que una URL equivocada no siga costando dinero. La guía de CI/CD cubre GitHub Actions y Azure Pipelines (comprobado el 19 de octubre de 2026). Nuestra guía de criterios de aprobación en pruebas de carga explica cómo elegir los límites.

¿Cuánto cuesta Azure Load Testing?

Pagas por hora de usuario virtual (VUH): 0,15 $ por VUH las primeras 10.000 y 0,06 $ por VUH a partir de ahí, igual en todas las regiones de la página de precios. Desde el 1 de marzo de 2026 hay además un cobro mínimo por ejecución.

La página de precios define una VUH como usuarios virtuales por minutos, dividido entre 60, contado cada 10 segundos; 1.000 usuarios durante 30 minutos son 500 VUH, o 75 $ con la tarifa del primer tramo. El mínimo es de 10 usuarios virtuales por motor durante toda la ejecución, y al menos 10 minutos. Una ejecución de 3 horas con 5 usuarios en un motor se cobra por tanto como 30 VUH, no 15 (comprobado el 19 de octubre de 2026).

¿Cuándo conviene elegir otra cosa?

Elige otra opción cuando tus scripts, tu nube o tu presupuesto apunten a otro sitio.

Nuestro repaso de herramientas de pruebas de carga open source cubre las herramientas que puedes ejecutar tú mismo.

Elige LoadFocus, que publica este sitio, si quieres ejecutar planes de prueba JMeter y scripts de k6 desde 25 regiones en la nube sin suscripción de Azure. No ejecuta Locust, y ejecuta los escenarios arrival-rate de k6 con un número fijo de usuarios.

Elige Grafana Cloud k6 o el k6-operator si tus pruebas están escritas para k6, que Azure Load Testing no puede ejecutar (comprobado el 19 de octubre de 2026).

Elige Locust en tu propia infraestructura si ya tienes Kubernetes o máquinas libres: su modo distribuido es gratis y solo pagas el hardware.

FAQ

¿Azure Load Testing admite k6? No. Ejecuta pruebas de Apache JMeter y de Locust, además de pruebas rápidas por URL que convierte él mismo en un script. Los scripts de k6 necesitan otro servicio o tu propia infraestructura.

¿Puedo usar Azure Load Testing con una aplicación que no está en Azure? Sí. Los motores de prueba pueden apuntar a cualquier endpoint público. Las métricas de servidor solo se recogen para recursos de Azure, así que con otro alojamiento lees las métricas de servidor en tu propia monitorización.

¿Hay un nivel gratuito? La página de precios solo muestra precios por hora para las pruebas de carga, con un mínimo por ejecución. Las cuentas nuevas de Azure reciben un crédito de 200 $ para sus primeros 30 días, según la misma página.

Lecturas relacionadas

• Pruebas de carga con Locust: análisis de la herramienta
• Herramientas de pruebas de carga open source: seis opciones
• Criterios de aprobación en pruebas de carga: cómo fijarlos
• Locust vs JMeter: ¿scripts de Python o planes de JMeter?
• Pruebas de carga en GitHub Actions: guía práctica

Las afirmaciones técnicas de este artículo no se han revisado de forma independiente.