Infraestructura adaptable a la demanda con AWS Auto Scaling - Diseño y optimización de políticas de escalado
Presenta cómo utilizar los 3 tipos de políticas (Target Tracking, Predictive y Scheduled) y lograr la optimización de costos con instancias Spot mediante Mixed Instances Policy.
Descripción general de Auto Scaling
Auto Scaling es un servicio que escala automáticamente los recursos según la demanda. Agrega instancias cuando el tráfico aumenta y las elimina cuando disminuye. Previene tanto el desperdicio de costos por sobreaprovisionamiento como la degradación del rendimiento por insuficiencia. Proporciona 3 tipos de políticas de escalado: Target Tracking, Step y Predictive, que se utilizan según las características de la carga de trabajo. Auto Scaling no solo aplica a EC2, sino también a servicios ECS, tablas DynamoDB, réplicas Aurora y endpoints de SageMaker, aunque este artículo se enfoca en el caso más común: EC2 Auto Scaling Groups.
Diseño de políticas de escalado
Target Tracking Scaling es la política más recomendada, donde basta con configurar un valor objetivo como uso de CPU al 70% o 1000 solicitudes ALB/minuto para que Auto Scaling ajuste automáticamente la capacidad. Internamente genera automáticamente dos alarmas de CloudWatch (una para scale-out, otra para scale-in) y ajusta instancias gradualmente cuando las métricas se desvían del objetivo. Predictive Scaling analiza los patrones de tráfico de los últimos 14 días con ML, predice la demanda futura y reserva capacidad de forma anticipada. En patrones donde el tráfico aumenta bruscamente cada mañana a las 9, inicia el scale-out a las 8:50. Warm Pool mantiene instancias con el inicio desde AMI y la inicialización de la aplicación completados previamente, permitiendo ponerlas en servicio inmediatamente durante el scale-out. Step Scaling permite configurar diferentes cantidades de escalado según el grado de desviación de la métrica, como agregar 1 instancia sobre 70% CPU y 3 instancias sobre 90%, siendo ideal para respuestas graduales.
Predictive Scaling y Scheduled Scaling
Predictive Scaling analiza los patrones de métricas de los últimos 14 días con machine learning, predice la demanda futura y ejecuta acciones de escalado de forma anticipada. Complementa el retraso de reacción de las políticas Target Tracking (varios minutos desde la recopilación de métricas hasta la finalización del inicio de instancias), permitiendo responder a aumentos bruscos de tráfico. Scheduled Scaling reserva capacidad de forma anticipada para variaciones de demanda predecibles como antes del inicio del horario laboral diario o la hora de inicio de una venta. Es efectivo combinar Predictive y Scheduled Scaling, cubriendo los patrones regulares con predicción y la demanda por eventos con programación. Predictive Scaling ofrece un modo forecast-only que permite verificar la precisión de la predicción sin ejecutar escalado real, antes de habilitarlo en producción. Para comprender en profundidad el diseño y construcción de escalado, los libros especializados en Amazon son útiles.
Optimización de costos con Auto Scaling
Utilizando instancias Spot y Mixed Instances Policy en Auto Scaling Groups, se puede lograr una reducción de costos de hasta 90% comparado con On-Demand. Se especifican múltiples tipos de instancia y se distribuye el riesgo de interrupción de Spot con la estrategia de asignación de optimización de capacidad. Una configuración que asegura la capacidad mínima con On-Demand y cubre el exceso con Spot ofrece un buen balance entre estabilidad y costo. Configurar Warm Pool permite mantener instancias pre-inicializadas en un pool, reduciendo el tiempo de inicio durante el scale-out. Usar métricas personalizadas de CloudWatch (profundidad de cola, conexiones activas) en las políticas de escalado logra un escalado más preciso que no depende solo del uso de CPU.
Trampas de diseño y anti-patrones
Comprender los problemas comunes en el diseño de Auto Scaling ayuda a evitar incidentes en producción. Primero, un scale-in demasiado agresivo puede interrumpir solicitudes en curso. Esto se aborda configurando adecuadamente el retraso de desregistro del ALB (connection draining) desde los 300 segundos predeterminados e implementando apagado graceful mediante lifecycle hooks de instancia. Segundo, los errores en el diseño de health checks son frecuentes. Los status checks de EC2 por sí solos no detectan estados donde el OS está sano pero la aplicación está congelada; se debe habilitar el ELB health check con un endpoint de aplicación /health. Tercero, configurar umbrales simétricos de scale-out y scale-in causa flapping cuando las métricas oscilan cerca del umbral. El umbral de scale-in debe ser sustancialmente menor que el de scale-out (ej: out al 70%, in al 40%) y usar un cooldown de scale-in más largo (300 segundos o más). Cuarto, escalar en una sola AZ es frágil para la disponibilidad; siempre distribuya en múltiples AZs y habilite el rebalanceo de AZ.
Elección entre Kubernetes HPA/Karpenter y EC2 Auto Scaling
Para cargas de trabajo en contenedores, EKS Horizontal Pod Autoscaler (HPA) + Karpenter (autoscaler de nodos) es una alternativa a EC2 Auto Scaling. HPA realiza escalado horizontal a nivel de Pod, y Karpenter aprovisiona automáticamente nodos con tipos de instancia apropiados basándose en las solicitudes de recursos de los Pods. EC2 Auto Scaling requiere predefinir una lista de tipos de instancia candidatos, mientras que Karpenter selecciona dinámicamente la instancia óptima según los requisitos del Pod, reduciendo el esfuerzo de selección de instancias. Por otro lado, EC2 Auto Scaling es más adecuado para cargas de trabajo sin contenedores (aplicaciones basadas en AMI, workloads GPU) y ofrece funcionalidades no disponibles en EKS como Warm Pool y Predictive Scaling. Lambda es completamente gestionado sin necesidad de diseño de escalado, pero tiene restricciones como el límite de 15 minutos de ejecución y la latencia de cold start con VPC, por lo que EC2 Auto Scaling es más apropiado para workloads de larga duración o con estado.
Resumen
Auto Scaling construye infraestructura que sigue la demanda con 3 tipos de políticas de escalado: Target Tracking, Step y Predictive. Verifique la precisión con el modo forecast-only de Predictive Scaling antes de habilitarlo en producción, y aproveche las instancias Spot mediante Mixed Instances Policy para optimizar costos. Prevenga el flapping y las interrupciones mediante la configuración del retraso de desregistro, ELB health checks y umbrales asimétricos para operaciones estables.