SECCIÓN 3- BALANCEO Y AUTOSCALING

[CS01] Captura de la creación de la AMI

Qué se ve:

Imagen de la AMI creada a partir del servidor web base (Web Server), con su AMI ID, nombre y Estado: available

Cómo se hizo (resumen):

EC2 → Instances → seleccionar Web Server.

Actions → Image and templates → Create image.

Nombre: Lab AMI (o el usado) → dejar root volume por defecto → Create image.

EC2 → AMIs: esperar a available.

Una AMI estandariza el servidor web (Apache + página de prueba) y permite lanzar instancias idénticas en Auto Scaling, garantizando consistencia y homogeneidad en los despliegues

[CS02] Captura de la infraestructura VPC creada

La VPC de laboratorio(Lab VPC) con sus subredes en dos AZ (públicas para el ALB y privadas para las instancias del ASG), pasarela asociada y tablas de rutas aplicadas.

Cómo se hizo (resumen):

Usando la VPC pre-creada del lab (o CloudFormation del entorno):

• Subredes públicas (p. ej., Public Subnet 1/2 en us-east-1a/1b) con ruta 0.0.0.0/0 → IGW
• Subredes privadas (p. ej., Private Subnet 1/2) para las instancias del ASG (sin IP pública).

• Security Group Web: permite HTTP 80 desde 0.0.0.0/0.

Por qué importa:

La separación pública/privada y el enrutado correcto aseguran que el ALB reciba tráfico de Internet mientras las instancias del ASG quedan aisladas, mejorando seguridad y disponibilidad multi-AZ.

[CS03] Captura del ELB creado

Qué se ve:

El Application Load Balancer LabELB con:

• Listener HTTP:80 → Target Group LabGroup.
• Mapping a dos subredes públicas (multi-AZ).
• Security Group Web (HTTP 80 abierto).

Cómo se hizo (resumen):

• EC2 → Target groups → Create: tipo Instances, nombre LabGroup, HTTP:80, health check /.
• EC2 → Load balancers → Create: tipo Application.
• Nombre LabELB, VPC: Lab VPC, Public Subnet 1 y 2.
• Security group: Web Security Group (HTTP 80).
• Listener: HTTP:80 → Forward a LabGroup.

• Finalizar y anotar el DNS del ALB para pruebas

Por qué importa: El ALB distribuye el tráfico entrante entre múltiples instancias, habilitando escalado horizontal y alta disponibilidad sin exponer directamente las instancias del ASG.

[CS04] Captura del autoscaling creado

El

Auto Scaling Group (Lab Auto Scaling group) con:

• Desired/Min/Max (p. ej., 2 / 2 / 6).
• Launch template/config basada en la AMI del [CS01].
• Subredes privadas (multi-AZ).
• Target tracking policy (CPU objetivo) o las políticas dinámicas configuradas.
• Asociación al Target Group LabGroup.

Cómo se hizo (resumen):

• EC2 → Launch templates(o Launch configuration):
• AMI: Lab AMI, tipo t2.micro (lab), SG: Web Security Group.
• EC2 → Auto Scaling groups → Create:
• Elegir la plantilla anterior, VPC: Lab VPC, Private Subnet 1/2.
• Attach to an existing load balancer → Target group LabGroup.
• Capacity: Desired=2, Min=2, Max=6.
• Scaling policy: Target tracking – Average CPU (p. ej., 45–50%) (se usa Target Tracking porque el entorno del lab restringe cloudwatch:PutMetricAlarm para crear alarmas manuales)

Por qué importa:

El ASG mantiene el número deseado de instancias y escala automáticamente según la carga, asegurando resiliencia, coste eficiente y consistencia gracias a la AMI.









[CS05] Captura de las alarmas en Cloudwatch

Qué se ve:

En CloudWatch → Alarms aparecen dos alarmas “TargetTracking-…” asociadas al ASG:

• Una para scale-out (CPU por encima del objetivo).
• Otra para scale-in (CPU por debajo del objetivo).

  Se muestra el estado (OK / In alarm) y la condición (umbral y periodos)

Cómo se hizo (resumen):

• Al crear la Target tracking policy del ASG (CPU media), Auto Scaling genera automáticamente ambas alarmas con su service-linked role.
• No se crearon manualmente porque el entorno del lab no autoriza cloudwatch:PutMetricAlarm.

Por qué importa: Estas alarmas son el gatillo del escalado: cuando la CPU supera/baja del objetivo, el ASG añade o retira instancias. Validan que la observabilidad y el escalado reactivo están configurados correctamente.

En la consola CloudWatch → Alarms se observan las dos alarmas generadas automáticamente por la política de Target tracking del ASG:

• AlarmHigh (OK): se activa cuando la CPUUtilization supera el umbral (p. ej., >60% durante N periodos) y desencadena scale-out.
• AlarmLow (In alarm en la captura): se activa cuando la CPUUtilization cae por debajo del objetivo (p. ej., <42% durante N periodos) y desencadena scale-in.

  Estas alarmas no se crean manualmente (el entorno limita cloudwatch:PutMetricAlarm); las gestiona el servicio de Auto Scaling con su rol vinculado, garantizando escalado automático basado en la carga real de CPU.