Azure Front Door Standard y Premium ya permiten actualizar un conjunto de reglas como una única operación. El cambio busca evitar estados intermedios cuando una automatización añade, modifica, elimina o reordena varias reglas relacionadas.
Hasta ahora, cada regla se gestionaba de forma independiente. En un rule set grande, un despliegue podía dejar durante unos instantes una combinación parcial, fallar a mitad o complicar el rollback. Con el modo batch, Front Door recibe el estado final completo y aplica todos los cambios o ninguno.
Qué está disponible
Microsoft publicó la disponibilidad general el 12 de agosto de 2026 para Azure Front Door Standard y Premium. No afecta a Front Door clásico. La característica está pensada especialmente para Terraform, ARM o REST, Azure CLI y PowerShell, aunque no obliga a cambiar los rule sets existentes.
El comportamiento clásico sigue siendo el predeterminado. Para usar actualizaciones en bloque hay que crear un rule set nuevo con batch mode habilitado expresamente. Esa elección es inmutable: después no se puede convertir el conjunto a modo clásico ni activar batch en uno existente. Cambiar de modalidad exige crear otro rule set y volver a asociar las rutas.
No se anuncia un cargo específico por utilizar batch. Se mantienen los costes normales del perfil Standard o Premium, las solicitudes y la transferencia. Antes de interpretar esto como una función gratuita en términos absolutos, conviene recordar que cada perfil tiene tarifa base y que Premium cuesta más que Standard; la novedad no cambia ese modelo.
Dónde aporta valor real
El caso claro es una configuración declarativa con muchas reglas y un orden significativo. Si una regla reescribe una URL, otra cambia cabeceras y una tercera modifica el comportamiento de caché, aplicarlas por separado puede crear una ventana de configuración incoherente. La operación atómica reduce esa ventana y hace más predecible el resultado del pipeline.
También simplifica la gestión del estado deseado. En batch, el array enviado representa el contenido final del rule set. Front Door calcula las diferencias y ejecuta la sustitución coordinada. Esto encaja mejor con Infrastructure as Code que una secuencia de altas, parches, cambios de orden y eliminaciones.
Para conjuntos pequeños modificados ocasionalmente desde el portal, Microsoft sigue recomendando el modo clásico. Batch introduce una semántica distinta y obliga a declarar el conjunto completo; no es una mejora automática para cualquier configuración.
Los límites que pueden sorprender
El máximo efectivo sigue siendo de 100 reglas por rule set. Una regla que activa caché mediante Route Override cuenta como dos. Por ejemplo, 99 reglas, de las que dos habilitan caché, suman un total efectivo de 101 y la actualización falla.
Hay además un límite durante el reemplazo. Un conjunto con 50 reglas, todas con caché, ya consume el equivalente a 100. Sustituirlas de una sola vez puede superar temporalmente la cuota porque las antiguas deben eliminarse antes de añadir las nuevas. Microsoft recomienda dividir ese caso en dos operaciones de 25, aunque el objetivo general sea reducir estados parciales.
Cómo plantearía la migración
- Inventariar reglas, orden, acciones de caché y asociaciones de rutas.
- Calcular el recuento efectivo, no solo el número visible de reglas.
- Crear un rule set batch paralelo en un entorno de prueba y generar siempre el estado completo desde IaC.
- Validar redirecciones, reescrituras, cabeceras y caché con tráfico sintético.
- Reasociar rutas de forma controlada y conservar un procedimiento de vuelta al conjunto clásico.
La mejora merece la pena cuando el riesgo está en la coordinación entre reglas. No elimina la necesidad de probar el resultado ni convierte una configuración incorrecta en segura; evita que una configuración correcta llegue a producción a medias.