Autoescalamiento en EC2 con Auto Scaling Groups

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:008:48

Autoescalamiento en EC2 con Auto Scaling Groups

Curso de AWS Certified Solutions Architect Associate

Clase 28 de 69

Clase 28 / 69

Recursos

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.

Resumen

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.

Escalado programado y predictivo

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.

¿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

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.

Eduard Giraldo Martínez

Hace 8 meses•editado

Vamos a practicar, aqui hay preguntas de Load Balancer y Auto Scaling

Perfecto. Aquí tienes preguntas largas, con contexto realista y trampas clásicas, EXACTAMENTE del estilo del AWS Certified Solutions Architect – Associate. 👉 No te doy respuestas aún. Respóndelas y luego las revisamos como en el examen.

🧪 Question 1

A company runs a web application on EC2 instances across multiple Availability Zones. Traffic is highly variable and unpredictable. The application must be able to scale automatically and route traffic based on URL paths such as /api and /static.

Which solution best meets these requirements?

A. Network Load Balancer with an Auto Scaling Group

B. Application Load Balancer with an Auto Scaling Group

C. Classic Load Balancer with EC2 instances

D. Application Load Balancer without Auto Scaling

🧪 Question 2

An online gaming platform requires ultra-low latency and must support millions of concurrent TCP connections. The architecture must be highly available and scale automatically based on demand.

Which solution should a Solutions Architect recommend?

A. Application Load Balancer with Auto Scaling

B. Network Load Balancer with Auto Scaling

C. Classic Load Balancer with scheduled scaling

D. Application Load Balancer with manual scaling

🧪 Question 3

A web application uses an Application Load Balancer in front of an Auto Scaling Group. Some EC2 instances become unresponsive, but the Auto Scaling Group does not replace them automatically.

What is the MOST likely reason?

A. The Auto Scaling Group uses only EC2 health checks

B. The Application Load Balancer is deployed in a single Availability Zone

C. The Auto Scaling Group minimum capacity is set to zero

D. The Application Load Balancer does not support health checks

🧪 Question 4

A company wants to scale its EC2 fleet automatically to maintain average CPU utilization at 60%. The company wants the simplest configuration and does not need granular control over scaling steps.

Which scaling policy should be used?

A. Scheduled Scaling

B. Step Scaling

C. Target Tracking Scaling

D. Manual Scaling

🧪 Question 5

A Solutions Architect is designing a highly available web application using an Application Load Balancer and an Auto Scaling Group. The application must continue operating even if one Availability Zone fails.

Which design meets this requirement?

A. Deploy the ALB in one AZ and EC2 instances in multiple AZs

B. Deploy EC2 instances in one AZ and ALB in multiple AZs

C. Deploy both the ALB and EC2 instances across multiple AZs

D. Deploy a Network Load Balancer in a single AZ

🧪 Question 6

A company uses an Auto Scaling Group with minimum capacity set to 2 and maximum capacity set to 10. The desired capacity is set to 2. A sudden traffic spike causes CPU utilization to rise above scaling thresholds.

What happens next?

A. The Auto Scaling Group cannot scale because desired capacity is fixed

B. The Auto Scaling Group increases the number of instances up to the maximum capacity

C. The Load Balancer automatically launches new EC2 instances

D. EC2 instances scale vertically by adding CPU

🧪 Question 7

A company is migrating a legacy application that requires basic load balancing with minimal configuration changes. The application does not require advanced routing features.

Which load balancer should be used?

A. Application Load Balancer

B. Network Load Balancer

C. Classic Load Balancer

D. Application Load Balancer with Lambda integration

🧪 Question 8

A Solutions Architect wants to ensure that unhealthy EC2 instances are automatically replaced as soon as they fail application-level health checks.

Which configuration best achieves this?

A. Use EC2 health checks only in the Auto Scaling Group

B. Use ALB health checks integrated with the Auto Scaling Group

C. Use CloudWatch alarms without a Load Balancer

D. Use scheduled scaling policies

Answers:

1. B

2. B

3. A

4. C

5. C

6. B

7. C

8. B

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