A las 10 a.m. (hora del Este) del 28 de noviembre de 2025, el gasto en línea en los Estados Unidos subió hacia los $12.5 millones por minuto y se mantuvo cerca de ese ritmo durante horas. Detrás de cada una de esas transacciones había un servidor web, una conexión a base de datos y una política de autoescalado que se mantuvo a la altura o no. Para el equipo que gestiona esa infraestructura, los códigos de descuento importaban menos que si la flota podía agregar capacidad antes de que las páginas de pago se agotaran por tiempo. Esa decisión se toma semanas antes, en archivos de configuración que la mayoría de los compradores nunca ven.
Reglas de autoescalado bajo presión antes de la temporada festiva
Amazon Web Services recomienda el seguimiento de objetivos como la política inicial para la mayoría de las cargas de trabajo. Un equipo elige una métrica, a menudo la utilización de la CPU, y establece un valor objetivo. Una política de escalado de seguimiento de objetivos puede apuntar a una utilización promedio de CPU del 50 por ciento. A partir de ahí, el proveedor de la nube agrega o elimina instancias por sí mismo para mantener esa línea.
La política tiene una particularidad que toma por sorpresa a los equipos nuevos. Una política de escalado de seguimiento de objetivos asume que debe escalar horizontalmente cuando la métrica especificada supera el valor objetivo, pero no puede escalar cuando la métrica se sitúa por debajo de ese objetivo. Eso significa que un aumento lento y constante en el tráfico se maneja bien. Una caída repentina en una métrica diferente, una que la política nunca se configuró para observar, no provocará ninguna respuesta en absoluto.
Esta es la razón por la que la documentación de AWS trata el seguimiento de objetivos como una base y no como una respuesta completa. En la mayoría de los casos, una política de escalado de seguimiento de objetivos es suficiente para escalar un grupo de Auto Scaling horizontalmente de forma automática. Pero la frase operativa es "en la mayoría de los casos", no en todos.
Grupos de reserva, escalado por pasos y el límite mínimo de capacidad
El escalado reactivo tiene un problema de retraso incorporado durante un pico repentino. Un pico que llega más rápido que el ciclo de evaluación de métricas excederá el objetivo antes de que el seguimiento de objetivos responda. Para cuando la política se da cuenta, el daño a los tiempos de carga de la página ya ha comenzado.
Dos herramientas cierran esa brecha. La primera es el escalado por pasos, que reacciona con saltos mayores una vez que se supera un umbral; esto es útil para el tráfico viral o de ventas flash, en lugar del ritmo diario lento que maneja bien el seguimiento de objetivos. La segunda es el grupo de reserva (warm pool). Los grupos de reserva mantienen instancias de EC2 preinicializadas en estados detenidos o en ejecución, listas para unirse a un grupo de Auto Scaling inmediatamente durante los eventos de escalado horizontal. Los equipos deberían usar grupos de reserva cuando una aplicación tiene secuencias de inicio largas, cuando la latencia de escalado afecta directamente a la experiencia del usuario o cuando se aplican objetivos estrictos de disponibilidad durante los picos de tráfico.
Un ajuste merece una segunda mirada antes de que comience la temporada. Los tiempos de espera de los ganchos de ciclo de vida (lifecycle hooks) tienen un valor predeterminado de 3,600 segundos, y si la automatización vinculada a ese gancho falla silenciosamente, las instancias permanecen bloqueadas en un estado de espera hasta que pasa el tiempo de espera, lo que puede bloquear el escalado horizontal durante el pico exacto que un equipo está tratando de sobrevivir. Verificar ese valor predeterminado con sus propios scripts de implementación toma minutos. Enterarse durante un pico de tráfico, no.
El escalado programado y predictivo cubre la brecha que las políticas reactivas no pueden. El escalado programado se ajusta al inicio de una campaña conocida, mientras que el escalado predictivo ayuda cuando el tráfico sigue patrones recurrentes respaldados por suficientes datos históricos. Ninguno reemplaza al seguimiento de objetivos. Ambos se sitúan junto a él como un suelo preventivo, de modo que la flota ya es más grande antes de que el primer comprador llegue a la página de inicio.
Las decisiones de costos siguen la misma lógica. Un grupo de instancias mixtas puede combinar capacidad bajo demanda y de Spot, y extraer de múltiples tipos de instancia, lo que distribuye el riesgo si un tipo de instancia se agota. Los Savings Plans reducen las tarifas de cómputo elegibles pero no proporcionan una reserva de capacidad de EC2, por lo que un descuento comprometido no es lo mismo que una garantía de que la capacidad existirá cuando la necesite.
Quién siente la presión cuando la capacidad se queda atrás
Los grandes minoristas con equipos de plataforma dedicados suelen tener esto resuelto con meses de antelación. La presión recae con mayor fuerza sobre las tiendas en línea pequeñas y medianas que funcionan con alojamiento compartido, un solo servidor web o una cuenta en la nube ligeramente gestionada. Estos son los sitios dirigidos por una o dos personas que hacen malabarismos con el marketing, el inventario y la infraestructura a la vez.
La elección de la plataforma determina cuánto de esta carga recae directamente sobre el comerciante. Shopify informó que sus comerciantes generaron $6.2 mil millones en ventas globales en línea en el Black Friday de 2025, un tráfico que la propia infraestructura de la plataforma absorbió en lugar de cada propietario de tienda individual. Una tienda WooCommerce o Magento autohospedada carga con ese mismo pico de tráfico sin ese amortiguador compartido, y es por eso que las reglas de autoescalado subyacentes a un sitio autogestionado importan más, no menos, a medida que aumenta el volumen de pedidos.
Las agencias y los desarrolladores independientes que gestionan varios sitios de clientes se enfrentan a una versión agravada del mismo problema. Cada sitio puede necesitar su propio umbral, su propio tamaño de grupo de reserva y su propia ventana de escalado programada, sincronizada con el calendario de promociones específico de ese cliente.
Lo que muestran las cifras del Black Friday 2025
La magnitud del problema es visible en las cifras de la temporada pasada. Los consumidores estadounidenses gastaron $11.8 mil millones en línea durante el Black Friday de 2025, y los dispositivos móviles representaron $6.5 mil millones de ese total, o el 55.2 por ciento de las ventas en línea, según Adobe. La mayor parte de ese tráfico llegó a través de teléfonos, a menudo sobre redes móviles inconsistentes, lo que eleva el costo de cualquier retraso en la respuesta de la página.
La composición del tráfico está cambiando de una manera que complica la previsión. Adobe informó que el tráfico de IA a los sitios minoristas de EE. UU. aumentó un 805 por ciento en comparación con el Black Friday anterior. Esa es una fuente de carga nueva y de rápido crecimiento que los modelos de tráfico históricos de temporadas pasadas no capturan completamente, lo que debilita el argumento de confiar únicamente en el escalado predictivo sin una red de seguridad reactiva.
Los números a nivel de plataforma cuentan una historia similar sobre la escala. Los comerciantes de Shopify vendieron $14.6 mil millones durante el Black Friday y el Cyber Monday de 2025, un aumento del 27 por ciento, sirviendo a más de 81 millones de clientes. Esa tasa de crecimiento supera la planificación de capacidad interanual de la mayoría de los equipos, lo que significa que el conteo máximo de instancias del año pasado rara vez es la línea base segura de este año.
Lo que viene a continuación para el autoescalado en días festivos
Los proveedores de la nube se están inclinando más hacia la predicción en lugar de la reacción pura. La función de escalado predictivo de AWS pronostica la demanda a partir de patrones históricos y agrega capacidad de EC2 antes de un pico esperado, en lugar de esperar a que una métrica cruce un umbral. La pregunta abierta es si esa previsión puede mantener el ritmo con una mezcla de tráfico que está cambiando tan rápido como lo hace ahora las compras referidas por IA.
Las pruebas siguen siendo la parte que los equipos omiten con más frecuencia. Las pruebas de carga que aumentan gradualmente desde cero hasta el pico le dan tiempo a Auto Scaling para agregar capacidad antes de la demanda simulada, pero no validan el comportamiento ante picos repentinos. Una prueba construida en torno a una rampa suave pasará limpiamente y aun así dejará a un sitio expuesto al tipo de aumento repentino e irregular que produce el tráfico real de las fiestas.
Si la temporada festiva de 2026 repite la tasa de crecimiento del tráfico de IA observada en 2025, o se asienta en un patrón más constante, es el número que cada equipo de plataforma estará observando en el próximo ciclo de previsión.
