Cuando lanzas un producto y la demanda explota, tu infraestructura tiene que responder. En Nexia pasó justo eso con un nuevo producto de tarjetas de crédito: picos de solicitudes que los servidores no alcanzaban a atender. La pregunta clave es cómo escalar sin desperdiciar recursos, y la respuesta vive en los grupos de autoescalamiento de AWS EC2.

A continuación verás cómo crear paso a paso un Auto Scaling Group, qué decisiones técnicas tomar en cada pantalla y cómo integrarlo con otros servicios de AWS para responder a la demanda real de tu negocio.

¿Qué es un Auto Scaling Group y por qué lo necesitas?

Un grupo de autoescalamiento es un conjunto de instancias EC2 que AWS levanta o apaga automáticamente según la demanda. Así evitas dos problemas comunes: quedarte corto cuando llegan picos de tráfico y pagar de más cuando la demanda baja.

¿Qué es un Auto Scaling Group en AWS? Es un grupo lógico de instancias EC2 que escala de forma automática hacia arriba o hacia abajo según reglas de capacidad y políticas que tú defines.

En el caso de Nexia, el equipo configura este grupo para garantizar que cada cliente que solicita una tarjeta reciba respuesta, sin importar si llegan diez o diez mil solicitudes simultáneas.

¿Cómo creas la plantilla de lanzamiento en EC2?

Antes del grupo, necesitas una launch template: la receta que define cómo se ven las instancias que se van a desplegar. La encuentras en el servicio EC2, en la sección de plantillas de lanzamiento [00:54].

Para este caso usamos:

• Nombre de la plantilla: Plantilla Nexia, versión uno.
• AMI: Amazon Linux con la arquitectura por defecto.
• Tipo de instancia: T2.micro, que pertenece a la capa gratuita de AWS.
• Par de llaves, red, almacenamiento y volúmenes: valores por defecto.

Una vez creada, la plantilla queda visible justo debajo de la sección de instancias y lista para asociarse al grupo de autoescalamiento.

¿Cómo configurar el Auto Scaling Group paso a paso?

Ahora sí, vas a Auto Scaling Groups en el menú lateral de EC2 y creas el grupo con el nombre Nexia. Seleccionas la plantilla recién creada, eliges la versión y avanzas con Next [01:54].

¿Qué configuras en la red y las zonas de disponibilidad?

En el segundo paso defines la VPC y las subnets donde vivirán las instancias. Aquí seleccionas las dos subredes públicas del laboratorio. También eliges cómo se distribuye la carga entre zonas de disponibilidad: best effort, balanceo estricto o únicamente balanceo.

Esta decisión importa porque distribuir entre varias zonas te da alta disponibilidad: si una zona falla, las otras siguen respondiendo.

¿Cómo se integra con un balanceador de carga?

En el paso tres AWS te pregunta si quieres asociar un load balancer. El balanceador de carga y el grupo de autoescalamiento se integran muy bien: el balanceador reparte el tráfico entre las instancias activas y el grupo se encarga de añadir o quitar instancias.

Para este ejercicio se selecciona la opción de no usar balanceador todavía, y se dejan los health checks por defecto.

¿Cómo defines la capacidad y las políticas de escalamiento?

Esta es la parte donde decides cuánto puede crecer o encogerse tu infraestructura [03:50]:

• Capacidad deseada: 2 instancias.
• Capacidad mínima: 1 instancia siempre activa.
• Capacidad máxima: 8 instancias para absorber picos altos.

¿Qué hace una política de target tracking? Ajusta automáticamente el número de instancias para mantener una métrica, por ejemplo el uso de CPU, en un valor objetivo que tú defines.

También puedes elegir comportamientos del grupo: priorizar disponibilidad, control de costos o flexibilidad. Para esta demo se deja en mixed behavior sin política activa.

¿Qué otras integraciones potencian tu Auto Scaling Group?

Dos integraciones que vale la pena conocer aparecen en los pasos finales del wizard.

La primera es SNS, el servicio de notificación simple de AWS. Puedes recibir notificaciones cuando una instancia del grupo se despliega o se termina, lo que te permite monitorear eventos críticos sin entrar a la consola.

La segunda son las etiquetas o tags. Aunque por simplicidad la demo no las agrega, etiquetar recursos es una buena práctica que te ayuda a identificar, filtrar costos y auditar tu infraestructura.

¿Para qué sirven las etiquetas en AWS? Sirven para clasificar recursos por proyecto, ambiente o equipo, y facilitan el control de costos y la búsqueda dentro de la consola.

¿Qué revisas antes de desplegar el grupo?

En la última pantalla AWS te muestra un resumen con el nombre, configuración de red, balanceo de carga, tipos de instancia, políticas, health checks y tamaño del grupo. Es tu checkpoint final antes de que las instancias empiecen a levantarse.

Con este grupo configurado, casos como el de Nexia dejan de ser un problema: la infraestructura responde sola a los picos, los clientes reciben respuesta y no se desperdician recursos cuando baja la demanda. ¿Tú cómo dimensionarías la capacidad mínima y máxima para tu propio producto? Cuéntamelo en los comentarios.