Tema 8. Escalado, monitorización y cierre CLF-C02¶

Si el Tema 7 dice por qué varias AZ, este dice cómo reparte el tráfico un ALB, cómo un ASG sigue la demanda y cómo te enteras (CloudWatch) antes que el usuario. Cierra RA3 y RA4, y cierra la 2.ª evaluación del módulo con la preparación CLF-C02. Núcleo Foundations M10, más el catálogo corto de servicios que el examen nombra y Foundations apenas toca. Ver glosario.

Piensa este tema como el «tablero de control» de lo ya visto: la VPC (T3) y el cómputo (T4) son la materia; ELB/ASG/CloudWatch son cómo la mantienes viva bajo carga y cómo demuestras (con métricas) que no estás a ciegas. El catálogo CLF del final es reconocimiento rápido de logos.

Al empezar

Empieza por el cuestionario inicial. Si ya justificaste Multi-AZ en el Tema 7, aquí lo operas: tráfico, capacidad y alarmas.

Propuesta didáctica¶

RA3. Diseña y configura redes virtuales y servicios de cómputo en la nube, aplicando buenas prácticas de seguridad, estrategias de balanceo de carga, escalado automático y aprovechando tecnologías serverless, contenedores y máquinas virtuales según casos de uso específicos.

RA4. Gestiona servicios de almacenamiento y bases de datos en la nube, seleccionando tecnologías adecuadas para casos específicos, y diseña arquitecturas escalables y resilientes utilizando herramientas de monitoreo y optimización para mejorar el rendimiento.

Criterios de evaluación¶

RA3

e) Se ha llevado a cabo la configuración y gestión de balanceo de carga y escalado automático.
f) Se han desarrollado prácticas relacionadas con la optimización de recursos computacionales.

RA4

e) Se ha hecho uso de herramientas de monitoreo y recomendaciones de optimización.
f) Se ha participado en actividades que simulen el análisis y mejora de arquitecturas existentes.

Contenidos¶

ELB (ALB / NLB), health checks.
Auto Scaling: min / desired / max; métricas; apagar entornos de desarrollo.
CloudWatch, CloudTrail, Config, Trusted Advisor, Health.
Repaso CLF-C02: IA/ML, analítica, integración (reconocer el servicio).

Programación de aula (orientativa)¶

Quincena	En tutoría	Trabajo autónomo / evidencias
Q10	ELB + ASG + CloudWatch	PR801, AC802; Autocheck del tema
Q11	Repaso CLF-C02 y cierre de la 2.ª evaluación	Hub Certificación; prueba objetiva según Aules

Cuestionario inicial¶

Responde con lo que sepas

¿Qué problema resuelve un ALB delante de varias instancias de tu API?
¿Para qué sirve el health check del balanceador?
En un ASG, ¿qué significan min, desired y max en una frase cada uno?
¿CloudWatch o CloudTrail si quieres alarmar CPU al 80 %?
Al acabar el lab, ¿por qué dejar min=0 o terminate evita sorpresas en la factura?

Este cuestionario es solo para ti: te ayuda a ver qué dominas ya y qué te falta antes o mientras lees el tema. No se entrega en Aules; respóndelo con lo que sepas y, cuando quieras contrastar, abre el bloque Soluciones (autoevaluación) debajo o el índice en Soluciones.

Soluciones (autoevaluación)

Reparte el tráfico HTTP/HTTPS entre varias instancias y deja de mandar a las que fallan; evita una sola «mascota» como punto único de fallo.
El health check comprueba si el destino responde (p. ej. /health); si no, el ALB no le envía tráfico.
min: suelo que no baja; desired: cuántas quieres ahora; max: techo al escalar.
CloudWatch (métricas/alarmas). CloudTrail audita llamadas a la API.
Con min=0 o terminate dejas de pagar capacidad ociosa del lab; si no, el ASG/instancias siguen facturando.

Bloque Foundations (M10)¶

Elastic Load Balancing¶

Un balanceador de carga reparte peticiones entre varios destinos (instancias, contenedores…) y deja de enviar tráfico a los que fallan el health check. Sin comprobación de salud, sigues mandando al proceso que ya no responde /health. Para una API HTTP el tipo habitual es el ALB (capa 7: host, path).

En desarrollo web el ALB permite reglas del estilo «/api/* → grupo de la API» y «/ → front». No sustituye a nginx en todos los casos, pero en Foundations es el punto de entrada gestionado que encaja con varias AZ y con el ASG.

Idea de balanceo de carga entre destinos — ELB: reparte tráfico y deja fuera lo que falla el health check.

Características ELB (Foundations)

Distribuye la carga entre varias instancias (o destinos).
Detecta destinos unhealthy y deja de mandarles tráfico.
Encaja con varias AZ: si cae una zona, el resto sigue sirviendo.

Tipo	Uso típico
ALB	HTTP/HTTPS (capa 7): host, path, tu API REST
NLB	TCP/UDP, muy alto rendimiento
GWLB	Appliances; reconocer el nombre
CLB clásico	Legado; no es la respuesta moderna

Tipos / esquema de balanceadores — ALB frente a otros tipos (reconocer en examen).

El ALB en varias AZ complementa el ASG: si una AZ cae, el balanceador deja de mandar a esa zona.

ALB con destinos en varias AZ — Balanceador multi-AZ con health checks.

Práctica ALB (pasos que verás en consola)

Elige al menos dos AZ (y una subnet en cada una): si no, no hay HA real.
Crea el target group y registra las instancias; el health check debe apuntar a una ruta que tu app responda (p. ej. / o /health).
El DNS del ALB es el punto de entrada; deja de apuntar A records a una sola EC2.

Crear ALB: VPC y dos zonas de disponibilidad — Mapeo de red del ALB: VPC + mínimo dos AZ/subnets.

Registro de destinos / target group en el ALB — Target group: dónde manda el balanceador el tráfico sano.

Antes / después. Antes: una sola EC2 con IP pública y DNS A record; si cae, cae el servicio. Después: ALB delante, health check a /health, dos instancias en AZ distintas. El usuario sigue usando el mismo nombre DNS; tú dejas de apuntar a una mascota.

Auto Scaling¶

Un Auto Scaling Group (ASG) mantiene un conjunto de instancias con mínimo, deseado y máximo. Escala con CPU, peticiones o horario (dev a cero por la noche). Elasticidad = la capacidad sigue a la demanda, no una VM eterna «por si acaso».

ASG / elasticidad detrás del balanceador — Capacidad que sigue a la demanda (ASG + ELB).

En una API de prácticas el patrón sano es: min bajo en lab, desired acorde a la demo, max con techo consciente. Programar un horario que baje a cero por la noche evita la factura del fin de semana. En producción real el min suele ser ≥ 2 si quieres sobrevivir a una AZ; en el instituto el min=2 sin apagar es un error de coste.

Optimizar (CE f): máximo 20 en la cuenta del instituto no es un plan. Min=1 en lab; terminar al acabar.

Cuándo NO subir el máximo del ASG. Si la base o el ALB no aguantan, o si el lab no tiene presupuesto, subir max solo multiplica la factura. Primero rightsizing y health checks; después elasticidad.

Monitorización¶

Observar no es un lujo: es cómo detectas CPU al 10 % en un m5.2xlarge (coste) o una instancia unhealthy (fiabilidad). Cada servicio responde a una pregunta distinta —no uses CloudTrail para mirar la CPU:

Servicio	Pregunta
CloudWatch	¿CPU, latencia, logs? Alarmas
CloudTrail	¿Quién llamó a la API? (Tema 2)
Config	¿El SG sigue abierto?
Trusted Advisor	¿Checks de coste/seguridad/cuotas?
Health	¿AWS tiene un incidente en la región?

CPU al 10 % un mes en m5.2xlarge es un hallazgo de coste (y de sostenibilidad), no de «el servidor va fino».

Una alarma útil en lab: CPU alta sostenida, o UnHealthyHostCount > 0. Una alarma inútil: ruido cada minuto sin umbral ni acción. CloudWatch sin ALB/ASG igual sirve (métricas de una EC2), pero el valor didáctico de M10 es ver las tres piezas juntas.

ELB/ALB, Auto Scaling y CloudWatch — Reparto de tráfico, elasticidad de capacidad y observación: tres piezas que van juntas en Foundations M10.

El ALB reparte en capa 7 (host/path); CloudWatch te enseña el log stream o la métrica cuando algo falla. En el lab: captura un destino sano y una alarma o un log, no solo el diagrama.

Arquitectura de componentes de Application Load Balancer — Piezas del ALB (listeners, target groups…). Fuente: Elastic Load Balancing Application Guide (AWS).

Log stream de CloudWatch asociado a una función Lambda — Log stream en CloudWatch Logs. Fuente: AWS Lambda Developer Guide (AWS).

Para el repaso CLF, Skill Builder concentra cursos y materiales oficiales de preparación (p. ej. Cloud Practitioner Essentials): no confundas ese portal con la consola del lab.

Cabecera del portal AWS Skill Builder — Portal Skill Builder para la preparación CLF. Fuente: skillbuilder.aws (AWS).

Errores frecuentes (escala y observación)¶

ALB sin health check útil (siempre «healthy» aunque la app devuelva 500).
ASG con min=2 en lab y olvidar bajarlo → factura.
Mirar CloudTrail para ver la CPU (herramienta equivocada).
Confundir «aprobar CLF-C02» con «compensar un RA suspendido» en este módulo.

Cierre del módulo (sin 3.ª evaluación)¶

La 2.ª evaluación cierra Temas 5–8. Este tema concentra ELB/ASG/CloudWatch y el repaso de catálogo CLF. No hay «cierre» aparte ni 3.ª evaluación en 2.º GS: el módulo acaba antes de la FE.

Bloque Ampliación Practitioner (CLF-C02)¶

Con ALB, Auto Scaling y CloudWatch cierras el núcleo Foundations de este tema. El catálogo corto de servicios (IA, analítica, colas…) y el tono de examen viven en el hub de Certificación.

Para el CLF

El health check deja fuera lo que falla; el ASG se entiende con min, desired y max. CloudWatch mira métricas y alarmas; CloudTrail audita la API. En el catálogo basta reconocer el servicio con una frase de cuándo sí y cuándo no. Detalle y autocheck certificación en Certificación § Tema 8.

Para seguir hacia el examen, en Certificación tienes la serie Santos, los tests de práctica y el orden sugerido.

Videotutorial¶

Principal (Foundations). ALB ASG PublicSubnet (~27 min).

Vídeo: Profe Santos Cloud (YouTube). Qué mirar: health check del ALB + min/desired/max del ASG; al acabar, min=0 o terminate.

Extra (opcional). CloudWatch - CloudTrail - EventBridge (~22 min) — métrica/alarma frente a auditoría de API. Vídeo: Profe Santos Cloud (YouTube).

El M10 del LMS Academy se indica en clase / Aules.

Actividad / práctica¶

PR801 — Escalar y observar¶

PR801. (RA3 // e, f // RA4 // e // PR 0–10). Cierras Foundations M10 operando tráfico, capacidad y observación: ALB, ASG y una señal en CloudWatch, sin dejar el lab facturando.

Tareas: lab Academy M10; evidencia de ALB con al menos un destino sano; ASG con min ≥ 1 durante el lab y min = 0 o terminate al acabar; una alarma CloudWatch (CPU o unhealthy host) o captura de métrica.

Entrega: según Cómo entregar las prácticas — fichero PR801.md (o ZIP + img/ si hay capturas).

Guía de apoyo (no sustituye el enunciado): Soluciones · PR801.

Criterio	Descripción	Puntos
ALB	Destino sano documentado	0–3
ASG	Min/desired coherentes en lab	0–3
CloudWatch	Alarma o métrica	0–2
Limpieza	min=0 o terminate	0–2
Total		/10

AC802 — Mapa de servicios CLF¶

AC802. (RA3 // f // RA4 // f // AC 0–1). Preparas ocho tarjetas de reconocimiento (servicio → una frase → dominio CLF-C02). Sin dumps de examen: calidad frente a cantidad.

Tareas: elige ocho servicios del catálogo visto en el tema / hub; una frase de cuándo sí; dominio aproximado del CLF-C02.

Entrega: según Cómo entregar las prácticas — fichero AC802.md.

Guía de apoyo (no sustituye el enunciado): Soluciones · AC802.

Criterio	Descripción	Puntos
Ocho tarjetas útiles	Servicio + frase + dominio; sin dump	0–1
Total		/1

Encaje ALB + ASG + alarma (historia corta)¶

El ASG lanza instancias en varias AZ; el ALB solo envía a las que pasan el health check; CloudWatch alarma si el número de unhealthy hosts sube o si la CPU se dispara. Si escalas sin health check, multiplicas instancias rotas. Si alarmas sin ASG/ALB, solo miras una mascota.

Para el cierre CLF: Certificación (serie, tests, Skill Builder). Ocho tarjetas bien hechas (AC802) superan un dump de 200 nombres.

Autocheck del tema¶

Cierre Foundations (ELB/ASG/CloudWatch). El catálogo CLF largo y el estilo examen están en Certificación § Tema 8.

Un ALB opera sobre todo en…
a) capa 3 (IP) · b) capa 7 (HTTP/HTTPS) · c) solo como NAT de VPC
ASG con min=2 en dos AZ: si cae una AZ, ¿qué esperas a alto nivel?
V/F. Miras la CPU de la instancia en CloudTrail.
Empareja: ALB · ASG · CloudWatch con: (a) reparte a destinos sanos · (b) min/desired/max · (c) métricas y alarmas
V/F. Aprobar CLF-C02 te aprueba automáticamente un RA suspendido en este módulo.

Soluciones

b.
Que el ASG/ALB sigan sirviendo con capacidad en la AZ viva (si el diseño es multi-AZ); no «todo caído».
Falso — CPU → CloudWatch; CloudTrail = API.
El ALB encaja con (a) repartir a destinos sanos; el ASG, con (b) min/desired/max; CloudWatch, con (c) métricas y alarmas.
Falso — los RA no se compensan; el +1 no aprueba un RA.

Glosario¶

ELB Elastic Load Balancing: familia de balanceadores de AWS que reparte tráfico entre destinos sanos (ALB, NLB, GWLB…). Sin health checks, el balanceador puede seguir enviando a un proceso muerto.

ALB Application Load Balancer: balanceador de capa 7 (HTTP/HTTPS), con reglas por host y path. Habitual delante de APIs web REST. Encaja con varias AZ y con un ASG detrás.

ASG Auto Scaling Group: conjunto de instancias EC2 con mínimo, deseado y máximo, que crece o decrece según métricas o horarios. Es la elasticidad «con máquinas»; no sustituye elegir bien el tipo de instancia.

CloudWatch Servicio de métricas, logs y alarmas. Responde a «¿qué está pasando ahora en el recurso?» (CPU, latencia, unhealthy hosts…). No sustituye a CloudTrail (auditoría de API) ni aprueba un RA por arte de magia.