Tienes un balanceador repartiendo tráfico entre varios servidores. Pero queda una pregunta: ¿quién crea esos servidores y cuántos debe haber? Si pones 10 fijos, pagas de más por la noche cuando hay poco tráfico; si pones 2, te saturas en hora punta. La solución es el Auto Scaling Group (ASG): el componente que crea y elimina servidores automáticamente según la demanda. Esta es la otra mitad de una arquitectura elástica.

El tráfico de casi cualquier aplicación sube y baja:

Si dimensionas para el pico, desperdicias dinero la mayor parte del tiempo. Si dimensionas para la media, te caes en los picos. La respuesta es no tener un número fijo: ajustar la cantidad de servidores en tiempo real. Eso es el autoescalado, y es una de las grandes ventajas de la nube que vimos en el Capítulo 1 (elasticidad).

Un Auto Scaling Group (ASG) es un grupo de instancias EC2 que AWS mantiene y ajusta automáticamente. Tú defines unos límites y unas reglas, y el ASG se encarga de crear o destruir servidores para cumplirlas.

Se configura con tres números clave:

• Mínimo: el número que siempre habrá, aunque no haya tráfico (garantiza disponibilidad).
• Deseado: cuántos hay en este momento; este es el que el ASG va ajustando.
• Máximo: el tope, para que un pico (o un error) no dispare la factura sin control.

El ASG no solo escala: también se autorrepara. Si una instancia se cae o falla su health check, el ASG la detecta y crea una nueva para mantener el número deseado.

Esto es potentísimo: combinado con el balanceador del subcapítulo anterior, tu aplicación se cura sola. Si un servidor muere a las 3 de la madrugada, nadie tiene que levantarse: el ASG crea uno nuevo y el balanceador empieza a usarlo en cuanto está sano. Aquí cobra sentido el user_data del subcapítulo 12.2: cada servidor nuevo se autoconfigura solo al nacer.

¿Cómo decide el ASG que hace falta escalar? Mediante políticas de escalado basadas en métricas (datos de CloudWatch, que veremos en el Capítulo 24). La más común es el uso de CPU.

Le dices al ASG un objetivo y él hace lo necesario para mantenerlo. Por ejemplo: «mantén el uso medio de CPU en el 50 %».

Es como el climatizador de un coche: le dices «mantén 22 grados» y él solito enciende o apaga el aire según haga falta. No te preocupas de los detalles. Por su sencillez, es la política recomendada para empezar.

Un ejemplo de escalado programado (scheduled): una web de venta de entradas sabe que cada lunes a las 10:00 saca entradas y recibe una avalancha. Programa el ASG para subir a 20 servidores a las 9:55, antes de que llegue la gente, en vez de esperar a que la CPU suba.

Las políticas reaccionan a métricas. Las más habituales:

• Uso de CPU: la más común; alta CPU = servidores saturados.
• Número de peticiones por servidor: muy útil con un balanceador (peticiones del Target Group).
• Uso de memoria o de red.
• Métricas personalizadas: por ejemplo, el número de mensajes en una cola (lo veremos con SQS, Capítulo 15).

Juntando los tres subcapítulos, esta es la arquitectura elástica clásica:

El balanceador reparte entre los servidores que haya; el ASG ajusta cuántos hay y los mantiene sanos. Juntos dan una aplicación que escala sola y se cura sola.

• Un Auto Scaling Group (ASG) crea y elimina servidores automáticamente según la demanda, dentro de unos límites: mínimo, deseado y máximo.
• El ASG también se autorrepara: si un servidor falla, crea uno nuevo para mantener el número deseado (aquí brilla el user_data que autoconfigura cada servidor).
• Las políticas de escalado deciden cuándo escalar según métricas (la más común, el uso de CPU).
• Target Tracking («mantén la CPU al 50 %») es la política más sencilla y recomendada para empezar; existen también Step y Scheduled (escalado programado para picos previsibles).
• Balanceador + ASG = arquitectura que escala sola y se cura sola.

En el último subcapítulo del capítulo veremos dos técnicas avanzadas para afinar el autoescalado: los warm pools y los lifecycle hooks.