Módulo 3: Domain 2 Resilient Architectures

6. Task 2.2 cont.: EC2 Auto Scaling, RDS Proxy y service quotas

Descripción

Esta lección cierra Task 2.2 con tres piezas que el task statement oficial nombra explícitamente: escalado dinámico de cómputo, "proxy concepts (for example, Amazon RDS Proxy)", "service quotas and throttling", y "workload visibility (for example, AWS X-Ray)". La primera —EC2 Auto Scaling— es la pieza de mayor peso de las tres, y la más citada en preguntas de examen real sobre resiliencia de cómputo. aws-core-services-guide Módulo 5 lanzó exactamente una instancia EC2 — nunca un grupo, nunca una política de escalado. Esta lección construye ese vocabulario completo, con una referencia directa a algo que sí conoces a fondo: el HorizontalPodAutoscaler de Kubernetes.

Conexión con el módulo

Vas a reconocer la analogía del termostato de kubernetes-and-eks-in-production-guide Módulo 3 — la misma idea, aplicada a un nivel distinto (instancias completas de EC2, en vez de Pods dentro de un clúster). Es, con precisión, la comparación que el examen espera que sepas hacer sin ayuda: dos mecanismos de escalado automático, dos capas distintas de la misma pila.

EC2 Auto Scaling: el termostato, un nivel más abajo

kubernetes-and-eks-in-production-guide Módulo 3, lección 7, construyó de verdad el HorizontalPodAutoscaler de andes-cargo-status-api, con esta analogía exacta: "un Deployment con replicas: 3 fijo es como una regla de aire acondicionado fija ('9 a 5, sin importar la temperatura real'). Un HorizontalPodAutoscaler es el termostato: mide una métrica real (CPU) y ajusta las réplicas en consecuencia." EC2 Auto Scaling es el mismo termostato, aplicado un nivel más abajo en la pila: en vez de ajustar cuántos Pods corren dentro de un clúster ya existente, ajusta cuántas instancias EC2 completas existen, encendidas y facturando, dentro de un Auto Scaling Group.

   MISMO TERMOSTATO, DOS CAPAS DISTINTAS

   HorizontalPodAutoscaler (kubernetes M3.7, EJECUTADO)      EC2 Auto Scaling (NUEVO, esta lección)
   ─────────────────────────────────────────────────         ───────────────────────────────────────
   Ajusta:  spec.replicas de un Deployment                    Ajusta:  DesiredCapacity de un Auto Scaling Group
   Unidad:  Pods, dentro de un clúster ya existente            Unidad:  Instancias EC2 completas
   Fuente de métrica:  metrics-server (metrics.k8s.io)         Fuente de métrica:  Amazon CloudWatch
   Objetivo típico:  % de CPU de cada Pod                      Objetivo típico:  % de CPU de cada instancia
   Health check:  liveness/readiness probes de Kubernetes      Health check:  EC2 status checks y/o ELB health checks
   Requiere instalar algo primero:  Sí — metrics-server         Requiere instalar algo primero:  No — CloudWatch ya está integrado

La decisión de examen: cuándo el escenario pide EC2 Auto Scaling y no HPA (o viceversa). Si el escenario describe una carga corriendo directamente sobre instancias EC2 —sin mencionar contenedores ni un clúster de Kubernetes/ECS—, o si describe explícitamente "escalar el número de servidores" en vez de "escalar el número de réplicas de un Pod", la respuesta es EC2 Auto Scaling. Si ya existe un clúster de Kubernetes en el escenario y la pregunta es sobre escalar las réplicas de una carga específica dentro de él, la respuesta es el HorizontalPodAutoscaler — dos herramientas del mismo principio, en dos niveles distintos de la pila, y el examen las trata como respuestas mutuamente excluyentes según en qué nivel viva el problema descrito.

Los tres componentes de un Auto Scaling Group

Un Auto Scaling Group (ASG) se define con tres números que gobiernan su comportamiento: capacidad mínima (nunca menos instancias que esto, sin importar qué), capacidad deseada (el número que el grupo intenta mantener en operación normal) y capacidad máxima (nunca más instancias que esto, sin importar cuánto suba la demanda — el techo de costo). Cada instancia nueva se lanza a partir de un launch template, la receta de qué AMI, tipo de instancia, security groups y user data usar — el mismo concepto de "receta escrita" que ya conoces de la task definition de ECS (aws-serverless-and-containers-guide Módulo 7).

Las políticas de escalado, según la documentación oficial de AWS:

Política	Cómo decide escalar
Target tracking	Mantiene una métrica en un valor objetivo (por ejemplo, 70% de CPU promedio del grupo) — la política recomendada por defecto, el equivalente directo al `targetCPUUtilizationPercentage` de un HPA
Step scaling	Ajusta la capacidad en escalones según qué tan lejos del umbral está la alarma que dispara el escalado — más control granular que target tracking
Simple scaling	Un solo umbral, una sola acción, con un período de enfriamiento (cooldown) entre acciones — el mecanismo más básico de los cuatro
Predictive scaling	Usa aprendizaje automático para anticipar patrones de tráfico cíclicos y escalar antes de que la demanda suba, no solo reaccionando después

Health checks de un Auto Scaling Group: dos capas, no una

Un ASG puede verificar la salud de sus instancias de dos formas, y la documentación oficial recomienda combinarlas: EC2 status checks, que detectan problemas a nivel de hipervisor (hardware o software del host, con reemplazo típicamente rápido) y health checks de un Elastic Load Balancer, que verifican la aplicación misma —si responde correctamente en el endpoint configurado, no solo si la máquina está encendida—. Una instancia puede pasar el chequeo de EC2 (la máquina está viva) y aun así fallar el de ELB (la aplicación que corre adentro está colgada) — es exactamente la misma distinción entre un liveness probe y un readiness probe que ya construiste con kubernetes-and-eks-in-production-guide Módulo 3.

La decisión de examen: cuando un escenario describe una aplicación que puede "colgarse" sin que la instancia subyacente se caiga (un proceso trabado, una conexión de base de datos agotada), la respuesta es habilitar health checks de ELB además de los de EC2 —solo el chequeo de EC2, por sí solo, nunca detecta ese tipo de falla.

Warm pools: reducir la latencia de arranque sin sobreaprovisionar

Un problema real que EC2 Auto Scaling resuelve, y que el examen menciona explícitamente: algunas aplicaciones tienen un tiempo de arranque largo (escribir grandes volúmenes de datos a disco, precargar un modelo, compilar activos) — sin ayuda adicional, cada evento de escalado hacia afuera sufre esa latencia completa antes de poder servir tráfico. Un warm pool, según la documentación oficial de AWS, es un conjunto de instancias pre-inicializadas que vive junto al Auto Scaling Group, listas para incorporarse de inmediato cuando el grupo necesita crecer — sin repetir el arranque en frío cada vez.

Las instancias de un warm pool pueden vivir en tres estados: Stopped (la opción de menor costo — pagas solo el volumen EBS y cualquier IP elástica asociada, no la instancia en sí), Hibernated (similar a Stopped, pero preserva el contenido de la memoria RAM en el volumen raíz, para que al reanudar la instancia no pierda el estado que tenía en memoria) o Running (desaconsejado por costo, salvo un caso muy específico). La documentación es explícita: crear un warm pool cuando el arranque en frío no causa latencia perceptible es un gasto innecesario — no es una práctica recomendada por defecto para cualquier ASG.

La decisión de examen: cuando el escenario describe instancias con tiempo de arranque largo (por ejemplo, escribir grandes volúmenes de datos al disco antes de estar lista) y pide reducir la latencia de un evento de escalado sin sobreaprovisionar instancias completamente activas todo el tiempo, un warm pool es la respuesta — ni una instancia corriendo de más, ni la latencia completa de un arranque en frío en cada evento.

RDS Proxy: nombrado aquí, a fondo en el Módulo 6

El task statement oficial nombra "proxy concepts (for example, Amazon RDS Proxy)" como conocimiento explícito de Task 2.2. Esta lección lo presenta a nivel conceptual — el Módulo 6 de esta guía, dedicado por completo a los servicios que ningún laboratorio de este ecosistema pudo ejecutar, desarrolla RDS/Aurora en profundidad completa, con RDS Proxy como parte de ese desarrollo.

Qué resuelve, según la documentación oficial de AWS: RDS Proxy administra un conjunto de conexiones agrupadas (connection pooling) hacia tu base de datos, reutilizándolas en vez de abrir una conexión nueva cada vez — evitando la sobrecarga de memoria y CPU que implica crear conexiones nuevas constantemente, un problema real cuando una carga con muchas funciones Lambda de corta duración (cada invocación, potencialmente, su propia conexión) satura el límite de conexiones simultáneas de una base de datos relacional. La segunda función, igual de citada en preguntas de examen: RDS Proxy hace que las aplicaciones sean más resilientes a un failover de base de datos, porque mantiene las conexiones de la aplicación abiertas mientras conmuta, por debajo, hacia la instancia en espera (standby) — sin que la aplicación necesite reconectarse manualmente.

La decisión de examen: cuando un escenario describe una carga con muchas conexiones cortas y concurrentes hacia una base de datos relacional —el patrón típico de Lambda a RDS—, o pide explícitamente reducir el impacto de un failover de Multi-AZ en la aplicación cliente, RDS Proxy es la respuesta — sin necesitar rediseñar la base de datos misma.

Service quotas y throttling: los límites que toda arquitectura resiliente respeta

Toda cuenta de AWS opera bajo límites de servicio (service quotas) — el número máximo de un recurso u operación que puedes usar, por cuenta o por región. La documentación oficial de AWS Service Quotas lo define con precisión: "quotas, also referred to as limits in AWS services, are the maximum values for the resources, actions, and items in your AWS account". Algunos límites son ajustables (puedes solicitar un aumento desde la consola, la CLI o el SDK, sujeto a revisión); otros son fijos por diseño.

Throttling es lo que pasa cuando tu carga intenta superar un límite de tasa de solicitudes: el servicio de AWS rechaza la solicitud excedente en vez de procesarla, típicamente con un código de error específico (ThrottlingException o similar, según el servicio). La práctica recomendada frente a un error de throttling no es reintentar inmediatamente ni a un ritmo fijo — es implementar retroceso exponencial con jitter (exponential backoff with jitter): cada reintento espera más tiempo que el anterior, con una variación aleatoria pequeña añadida, para evitar que un grupo grande de clientes reintente exactamente al mismo tiempo y sature al servicio de nuevo.

La decisión de examen: cuando un escenario describe errores intermitentes de una aplicación que hace muchas llamadas a una API de AWS bajo carga alta, sin que haya ningún problema de permisos ni de configuración de red, la causa más probable es throttling contra una service quota —y la solución de arquitectura es implementar retroceso exponencial en el cliente, y, si el volumen legítimo de tráfico lo justifica, solicitar un aumento de cuota antes de que vuelva a ocurrir.

AWS X-Ray: nombrado, visibilidad de carga de trabajo distribuida

El task statement nombra "workload visibility (for example, AWS X-Ray)" — el servicio de tracing distribuido de AWS. Según su documentación oficial, X-Ray "collects data about requests that your application serves" y construye un mapa de trazas (trace map) que muestra, para una sola solicitud de cliente, cada servicio río abajo que participó en responderla — útil, con precisión, para encontrar dónde exactamente vive un cuello de botella o una falla en una arquitectura de microservicios con muchos saltos entre servicios (API Gateway → Lambda → DynamoDB → un servicio externo, por ejemplo), algo que ningún log individual de un solo servicio puede mostrar por sí solo.

La decisión de examen: cuando un escenario describe una arquitectura con varios servicios encadenados y pide identificar en cuál salto específico ocurre la latencia o el error —no solo "algo está lento", sino "¿qué parte exacta de la cadena?"—, X-Ray es la respuesta — ningún otro servicio de este módulo ofrece visibilidad de solicitud-por-solicitud a través de múltiples saltos de servicio.

Errores comunes

Confundir EC2 Auto Scaling con el HorizontalPodAutoscaler cuando el escenario ya menciona un clúster de Kubernetes o ECS (de nivel equivocado de la pila). Qué pasa: alguien, frente a un escenario que ya describe contenedores orquestados, responde "EC2 Auto Scaling" para el problema de escalar la carga. Cómo detectarlo: si tu respuesta a "escalar los Pods de una carga en un clúster EKS" menciona un Auto Scaling Group directamente. Cómo corregirlo: dentro de un clúster ya existente, la unidad que escala en respuesta a demanda de la carga es el Pod (HorizontalPodAutoscaler), no la instancia EC2 subyacente que sostiene al clúster — esa capa (los node groups del clúster) tiene su propio mecanismo de escalado, generalmente independiente y de nivel distinto, cubierto en kubernetes-and-eks-in-production-guide.

Olvidar el health check de ELB y confiar solo en el de EC2 (de cobertura incompleta). Qué pasa: alguien configura un Auto Scaling Group sin health checks de ELB, asumiendo que el chequeo de estado de la instancia (EC2 status check) es suficiente para detectar cualquier problema. Cómo detectarlo: si tu diseño no distingue entre "la máquina está encendida" y "la aplicación responde correctamente". Cómo corregirlo: habilita ambos tipos de health check — el de EC2 detecta fallas de hardware/hipervisor; el de ELB detecta que la aplicación en sí dejó de responder, un tipo de falla completamente distinto que el chequeo de EC2, por diseño, nunca detecta.

Reintentar inmediatamente tras un error de throttling, sin retroceso (de manejo de error ingenuo). Qué pasa: alguien diseña un cliente que reintenta una llamada fallida por throttling de inmediato, en un bucle ajustado. Cómo detectarlo: si tu manejo de error para un ThrottlingException no menciona ningún retraso creciente entre reintentos. Cómo corregirlo: reintentar sin espera creciente empeora el problema — cada reintento inmediato añade más presión sobre un límite que ya se superó. El retroceso exponencial con jitter, la práctica recomendada por AWS, da tiempo a que la carga baje antes del siguiente intento.

❓ Pregunta de práctica — Dominio 2 (Resilient) — Select TWO

Escenario: TicketMax, una plataforma de venta de entradas para eventos, sufre picos de tráfico extremos durante los primeros minutos de venta de un concierto popular — hasta 50 veces el tráfico normal, sostenido por menos de 10 minutos. El equipo detecta dos problemas durante el último pico: (1) las instancias EC2 nuevas que el Auto Scaling Group lanzó tardaron casi 3 minutos en estar listas para servir tráfico, porque cada una necesita precargar un catálogo grande de eventos antes de responder solicitudes, y (2) varias funciones Lambda empezaron a recibir errores de ThrottlingException al conectarse directamente a la base de datos RDS del catálogo.

Pregunta: ¿Cuáles dos mecanismos, combinados, resuelven ambos problemas descritos? (Elige dos.)

A. Un warm pool para el Auto Scaling Group, con instancias pre-inicializadas listas para incorporarse de inmediato. B. Amazon RDS Proxy, agrupando las conexiones de las funciones Lambda hacia la base de datos. C. Una política de escalado de tipo simple scaling, con un período de enfriamiento más largo. D. AWS X-Ray, para medir la latencia exacta de cada solicitud durante el pico de tráfico. E. Aumentar manualmente la capacidad máxima del Auto Scaling Group a un número ilimitado.

✅ Respuesta correcta: A y B

Por qué es correcta: los dos problemas del escenario son independientes y cada uno tiene, en esta lección, un mecanismo específico. El primero —instancias nuevas que tardan casi 3 minutos en estar listas por un arranque largo (precargar el catálogo)— es exactamente el caso de uso de un warm pool: instancias pre-inicializadas, ya con el catálogo cargado, listas para incorporarse al Auto Scaling Group sin repetir ese arranque en frío durante el pico. El segundo —errores de ThrottlingException de muchas funciones Lambda de corta duración conectándose directo a RDS— es, con precisión, el problema que RDS Proxy resuelve agrupando y reutilizando conexiones, evitando que cada invocación agote el límite de conexiones simultáneas de la base de datos.

Por qué las demás fallan:

C: un período de enfriamiento más largo en una política de simple scaling retrasa la reacción del Auto Scaling Group ante el pico — es lo opuesto a lo que un pico de 10 minutos, que necesita reaccionar rápido, requiere; además, no resuelve el problema de arranque lento de cada instancia individual, solo cuándo se lanza una nueva.
D: X-Ray ofrece visibilidad de dónde ocurre la latencia dentro de una cadena de servicios — es una herramienta de diagnóstico, útil para encontrar el problema, pero no lo resuelve por sí sola; el escenario ya identificó ambos problemas con precisión, así que lo que falta es la solución de arquitectura, no más visibilidad.
E: una capacidad máxima "ilimitada" no es una configuración real de un Auto Scaling Group (siempre existe un techo, aunque sea alto) ni resuelve el problema de fondo —instancias que tardan 3 minutos en estar listas siguen tardando 3 minutos, sin importar cuántas se permita lanzar—; tampoco toca el problema de throttling contra RDS.

Resumen y siguiente paso

En esta lección cerraste Task 2.2 completo: EC2 Auto Scaling como el mismo termostato del HorizontalPodAutoscaler de Kubernetes, aplicado a instancias completas en vez de Pods; health checks de EC2 y de ELB como dos capas complementarias, nunca sustitutas una de la otra; warm pools para arranques largos; RDS Proxy nombrado con profundidad completa pendiente en el Módulo 6; service quotas/throttling con retroceso exponencial como la respuesta de arquitectura correcta; y AWS X-Ray como la herramienta de visibilidad distribuida del examen.

Antes de avanzar deberías poder explicar, en una frase, la diferencia entre un health check de EC2 y uno de ELB, y nombrar qué problema específico resuelve un warm pool.

La lección 7 cierra el módulo nombrando el pilar de confiabilidad del Well-Architected Framework, y conectándolo explícitamente con el vocabulario de SLI/SLO/error budget que ya construiste, de verdad, en sre-and-incident-response-guide.

Recursos

AWS Certification — SAA-C03 Domain 2: Design Resilient Architectures — fuente oficial de las cuatro piezas de esta lección: escalado, proxies, service quotas y visibilidad.
Amazon EC2 Auto Scaling — What is Amazon EC2 Auto Scaling? — fuente oficial de políticas de escalado y health checks.
Amazon EC2 Auto Scaling — Warm pools — fuente oficial de los tres estados de instancia (Stopped/Running/Hibernated), citada en esta lección.
Amazon RDS — What is RDS Proxy? — fuente oficial de connection pooling y resiliencia a failover.
AWS Service Quotas — What is Service Quotas? — fuente oficial de la definición de cuota, citada textualmente.
AWS X-Ray — What is AWS X-Ray? — fuente oficial del trace map y visibilidad de solicitud distribuida.
kubernetes-and-eks-in-production-guide, Módulo 3, lección 7 (NIEVA) — el HorizontalPodAutoscaler real que esta lección usa como punto de comparación directo.

← Anterior5. Task 2.2 cont.: estrategias de recuperación ante desastres Siguiente →7. El pilar de confiabilidad del Well-Architected Framework