Cómo crear un Auto Scaling Group en EC2

Curso de AWS Certified Solutions Architect Associate

Contenido del curso

Fundamentos de AWS

Identidad, Acceso y Gobernanza Multicuenta

Servicios de Computo en AWS

Contenedores en AWS

Redes en AWS

Escalamiento y balanceo en AWS

Almacenamiento en AWS

Bases de datos en AWS

Migración en AWS

Monitoreo y Auditoria en AWS

DNS y CDN en AWS

Servicios de Seguridad

Serverless

Servicios de Datos en AWS

Servicios de AI y ML em AWS

64
Servicios de IA y ML en AWS
04:09 min

Servicios de Backup y Recuperación ante desastres

Architect Solutions Certificate

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:007:02

Cómo crear un Auto Scaling Group en EC2

Curso de AWS Certified Solutions Architect Associate

Clase 29 de 69

Clase 29 / 69

Recursos

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.

Miguel Angel Reyes Moreno

Hace un año

Los servicios de ELB (Elastic Load Balancer) y ASG (Auto Scaling Group) en AWS se integran para crear una arquitectura escalable, disponible y resiliente. El Auto Scaling Group supervisa la salud y la demanda de las instancias EC2, agregando o eliminando instancias automáticamente según las políticas definidas. ELB distribuye el tráfico entrante equilibradamente entre las instancias activas dentro del grupo, asegurando que solo las instancias saludables reciban tráfico.

La integración funciona de la siguiente forma: El ASG lanza instancias EC2 según la carga y las reemplaza si alguna falla; estas instancias se registran automáticamente en el ELB para que este las incluya en el balanceo de carga. ELB enruta el tráfico solo a instancias saludables, mientras ASG mantiene el número deseado de instancias para responder a la demanda. Esto proporciona alta disponibilidad, escalabilidad automática y tolerancia a fallos sin intervención manual.

Además, ELB puede distribuir el tráfico en múltiples zonas de disponibilidad, mientras que ASG puede lanzar instancias en esas zonas para maximizar la resiliencia. ASG también soporta políticas y hooks que permiten acciones personalizadas durante el ciclo de vida de las instancias, complementando la dinámica de balanceo y escalado. Esta colaboración entre ELB y ASG optimiza recursos y costos al ajustar capacidad y rendimiento según la necesidad real del sistema.

En resumen, ELB actúa como un punto de entrada para el tráfico distribuido, y ASG gestiona el número y salud de las instancias que ELB utiliza para entregar esa carga, haciendo la infraestructura altamente escalable y disponible en AWS. Esta integración es fundamental para aplicaciones que requieren adaptabilidad y alta disponibilidad continuas en la nube.

Fundamentos de AWS

Certificación AWS Solutions Architect Associate: Fundamentos y Preparación

Preparación para certificación AWS Arquitecto de Soluciones

Configuración de presupuestos en AWS para controlar costos

Los 6 pilares del Well-Architected Framework

Identidad, Acceso y Gobernanza Multicuenta

Cómo evitar brechas de seguridad con IAM

Creación de usuarios administrador y practicante en AWS IAM

Gestión de cuentas con AWS Organizations

Detecta recursos AWS expuestos con Access Analyzer

Cómo gestionar múltiples cuentas AWS

Servicios de Computo en AWS

Servicios de cómputo AWS: EC2, procesadores Graviton y AMIs

Compute Savings Plan para EC2 y Lambda

Cómo lanzar tu primera instancia EC2

Optimizar latencia en EC2 con tenencia dedicada

Cómo consultar metadatos de EC2 con IMDSv2

AWS Outposts: ejecutar AWS en tu data center

Despliegue de app web en Elastic Beanstalk

Contenedores en AWS

Contenedores en AWS: ECS, EKS y ECR

Gestión de imágenes de contenedores con ECR y Fargate

Configuración de clusters, tareas y servicios en Amazon ECS

Redes en AWS

Direccionamiento IP y bloques CIDR para redes AWS

NAT Gateway para subredes privadas en AWS

Configuración de instancias públicas y privadas con NAT Gateway

NACL y Security Groups en AWS

Cómo reparar un Security Group en EC2

Conectividad híbrida en AWS: VPC Peering, Transit Gateway y Endpoints

Escalamiento y balanceo en AWS

Tipos de balanceadores de carga en AWS

Configuración de balanceadores de carga en AWS para alta disponibilidad

Autoescalamiento en EC2 con Auto Scaling Groups

Cómo crear un Auto Scaling Group en EC2

Almacenamiento en AWS

Tipos de almacenamiento en AWS: EBS, EFS y S3

Instance Store vs EBS en AWS

EFS vs FSx para compartir archivos en AWS

Creación y configuración de volúmenes EBS en AWS

Transfer Acceleration para datos globales en S3

Configuración de EFS para compartir almacenamiento entre instancias

Recuperar objetos borrados en Amazon S3

Bases de datos en AWS

Bases de datos relacionales vs no relacionales en AWS

Cómo funciona DynamoDB en AWS

Creación y configuración de bases de datos Dynamo en AWS

Elasticache y DAX

RDS vs Aurora: réplicas y alta disponibilidad

Cómo configurar Aurora con alta disponibilidad en RDS

Migración en AWS

Estrategias de migración AWS: las 6 R para trasladar aplicaciones

Cómo migramos 500 TB a AWS sin downtime

Migración de datos con AWS Snow Family: opciones y características

DMS y SCT para migrar bases de datos en AWS

Monitoreo y Auditoria en AWS

CloudTrail y EventBridge en arquitecturas AWS

Monitoreo de AWS con CloudWatch

DNS y CDN en AWS

Zonas locales y de borde en AWS

CloudFront vs Global Accelerator en AWS

Failover en Route 53 para arquitectura activo-pasiva

Configuración de políticas de geoproximidad en AWS Route 53

Servicios de Seguridad

KMS vs CloudHSM para datos regulados

AWS Shield y WAF contra ataques DDoS

Servicios AWS para detectar vulnerabilidades

GuardDuty y Trusted Advisor para detectar amenazas en AWS

Serverless

API Gateway y Lambda en arquitecturas serverless

Creación y configuración de funciones Lambda para automatización

AWS SQS: Tipos de filas y configuración para arquitecturas serverless

AWS SNS y Step Functions para comunicación y workflows visuales

Servicios de Datos en AWS

Servicios de datos en AWS para tu examen

Kinesis, EMR, Glue

Casos de uso de Amazon Redshift en AWS

Servicios de AI y ML em AWS

Servicios de IA y ML en AWS

Servicios de Backup y Recuperación ante desastres