Cuando un balanceador de carga ya no basta para absorber picos de tráfico, entran en juego las políticas de autoescalamiento en AWS. Con Auto Scaling Groups (ASG) puedes aumentar o reducir instancias EC2 de forma automática según la demanda, evitando caídas y costos innecesarios.

Esto es clave si administras infraestructura en la nube y necesitas que tus aplicaciones respondan a tráfico variable sin intervención manual.

¿Qué servicios de AWS soportan autoescalamiento?

AWS ofrece autoescalamiento nativo en varios servicios, no solo en cómputo. Aquí los más relevantes:

• Servicios de cómputo: instancias EC2, cargas de trabajo en ECS y EKS, y serverless como Lambda.
• Bases de datos administradas.
• Otros servicios gestionados que escalan según métricas configurables.

El foco práctico aquí está en EC2, porque es el caso más común y el que mejor ilustra la lógica de los ASG [00:36].

¿Qué es un Auto Scaling Group? Es un grupo lógico de instancias EC2 que escala su número hacia arriba o abajo de forma automática, según los parámetros y métricas que tú configures.

¿Cuáles son los tipos de escalado en un ASG?

Un ASG no escala de una sola manera. Puedes elegir entre cuatro tipos de escalado, y cada uno responde a un escenario distinto [01:10].

Escalado manual y dinámico

El manual es el más básico: tú entras a la consola o usas la CLI para agregar o quitar instancias. Útil para pruebas, no para producción.

El dinámico es el más usado. Configuras una métrica, normalmente uso de CPU, aunque también puede ser memoria o capacidad de red, y el ASG reacciona cuando esa métrica cruza un threshold. Si la CPU promedio sube del 70%, se crean nuevas instancias.

Escalado programado y predictivo

El programado funciona por franjas horarias. Si sabes que tu e-commerce recibe más tráfico entre 6 p. m. y 10 p. m., puedes pedirle al ASG que aumente instancias en ese rango y las baje después.

El predictivo usa un modelo de machine learning de AWS que analiza el histórico del ASG y anticipa los patrones de tráfico. Tú no defines umbrales: el modelo lo hace por ti [02:20].

¿Cómo se conectan los ASG con balanceadores, AMIs y Launch Templates?

Un ASG rara vez vive solo. Lo normal es conectarlo a un balanceador de carga para distribuir tráfico, y apoyarlo en AMIs y Launch Templates para mantener consistencia entre instancias.

Una AMI (Amazon Machine Image) es la imagen base de tu instancia. Puedes usar las predeterminadas de AWS o crear las tuyas con software y configuraciones específicas ya instaladas. Esto evita configurar cada máquina desde cero.

Un Launch Template define cómo se crea cada instancia: qué AMI usar, el tipo de instancia, volúmenes, tags, interfaces de red (ENI o ENA) y opciones avanzadas como hibernación o DNS sobre IPv6. Además, los Launch Templates se versionan, lo que permite hacer rollback si una nueva configuración falla [04:30].

¿Cuál es la diferencia entre Launch Template y Launch Configuration? El Launch Configuration era la versión anterior y solo servía para un ASG. El Launch Template puede reutilizarse entre varios ASGs y soporta versionado.

Así, toda instancia que entre al ASG arranca con la misma configuración, lo que reduce errores manuales y protege la disponibilidad de tus aplicaciones.

¿Cómo crear un ASG y un Launch Template desde la CLI?

La consola web es lo más visual, pero crear estos recursos desde la AWS CLI te da reproducibilidad y permite versionar tu infraestructura como código.

Crear un Launch Template

Con el comando create-launch-template puedes definir todo lo que verías en la consola, pero por terminal. Los parámetros típicos son:

• Nombre del template y datos de configuración.
• ID de la AMI que vas a usar.
• Tipo de instancia.
• Security groups asociados.
• Perfil de IAM para la instancia.
• Script de inicialización como user-data codificado en base 64.

Crear el Auto Scaling Group

Con create-auto-scaling-group configuras el grupo y lo enlazas al Launch Template. Los parámetros clave incluyen:

• Nombre del ASG.
• Launch Template asociado y versión a usar.
• Capacidad mínima, máxima y deseada, que son los límites donde el ASG puede moverse.
• Subredes (públicas o privadas) donde se desplegarán las instancias.
• Health check con un periodo de gracia, por ejemplo, 300 segundos antes de empezar a verificar si una instancia está viva [07:40].

Configurar una política de escalamiento

La política le dice al ASG cuándo agregar o quitar instancias. En el ejemplo, se crea una política llamada CPU-TT-70 sobre un ASG llamado Web-ASG, que hace target tracking sobre el uso de CPU: cuando el promedio llega al 70%, el ASG levanta una nueva instancia, siempre dentro de los límites mínimo y máximo configurados.

Este tipo de política es la base del escalado dinámico y la forma más directa de que tu infraestructura reaccione sola al tráfico real.

¿Qué comandos usarías para crear un ASG, un Launch Template y una política de escalamiento para un caso de uso de tu organización? Déjalo en los comentarios.