SAA-C03
Deep Dive
La arquitectura estándar de alta disponibilidad en AWS es: ELB + Auto Scaling Group + Multi-AZ. Este patrón aparece en el 26% del examen (D2). Necesitas distinguir entre alta disponibilidad (Multi-AZ) y escalado de rendimiento (más instancias/réplicas).
Contenido
Un Auto Scaling Group (ASG) mantiene un conjunto de instancias EC2 ajustando automáticamente la capacidad según demanda. Garantiza que siempre haya el número correcto de instancias para manejar la carga.
Minimum
Número mínimo de instancias. Siempre activas aunque no haya demanda.
Desired
Número actual objetivo. ASG intentará mantener siempre este número.
Maximum
Número máximo. No se superará aunque la demanda sea mayor.
Launch Template (recomendado sobre Launch Configuration)
Launch Template define:
Ventajas vs Launch Configuration
Target Tracking Policy
RecomendadoEl tipo más sencillo. Defines un target metric (ej: CPU al 50%) y AWS ajusta las instancias automáticamente para mantener ese valor.
Cuándo: Default para la mayoría de casos. Ej: "Mantener CPU promedio al 60%".
Step Scaling Policy
Define pasos de escalado según el valor de una métrica. Más control que Target Tracking.
Cuándo: "Si CPU > 70%, añadir 2 instancias. Si CPU > 90%, añadir 4 instancias."
Scheduled Scaling
Programa cambios de capacidad en fechas/horas conocidas. Para patrones predecibles.
Cuándo: "Aumentar a 10 instancias los lunes a las 8am; reducir a 2 a las 8pm."
Predictive Scaling
Machine Learning analiza el historial y escala proactivamente antes de que llegue el tráfico.
Cuándo: "Tráfico pico predecible diariamente a las 12pm y 6pm."
| LB | Capa OSI | Protocolo | Características clave | Cuándo usar |
|---|---|---|---|---|
| ALB | L7 | HTTP/S, WebSocket, gRPC | Path/host-based routing, sticky sessions, lambdas como target, WAF integration | Web apps, microservicios, APIs REST |
| NLB | L4 | TCP, UDP, TLS | Latencia ultra-baja, IPs estáticas, targets por IP, preserva IP cliente | Gaming, IoT, VoIP, tráfico TCP/UDP de alto rendimiento |
| GLB | L3/L4 | IP (GENEVE tunnel) | Enruta tráfico a appliances virtuales (firewalls, IDS/IPS) | Seguridad de red con appliances de terceros |
Truco examen
ALB = L7 HTTP. NLB = L4 TCP/UDP + IPs estáticas. Si el escenario menciona "protocol non-HTTP", "static IPs" o "preserve client IP" — elige NLB. Si menciona "path routing", "host-based routing" o "microservices" — elige ALB.
Multi-AZ = tolerancia a fallos de zona de disponibilidad. Si una AZ falla, el tráfico/datos se redirigen automáticamente a otra AZ. Es HA (High Availability), no escalado.
Multi-AZ en RDS
Multi-AZ con ASG + ALB
ASG Health Check
El ASG verifica la salud de sus instancias. Si una instancia falla, la termina y lanza una nueva automáticamente. Puede usar EC2 status checks o ELB health checks.
ELB health check es más completo que EC2 check — detecta problemas a nivel de aplicación, no solo de VM.
Connection Draining (Deregistration Delay)
Cuando el ALB va a deregistrar una instancia (ej: scale-in), espera a que las conexiones activas terminen antes de terminarla.
Default: 300 segundos. Reducir para instancias que procesan requests cortos. Aumentar para requests de larga duración.
Route 53 + CloudFront + ALB + ASG Multi-AZ + RDS Multi-AZ.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una aplicación web tiene un ALB con un Auto Scaling Group. Durante una actualización de código, el equipo quiere reemplazar instancias gradualmente sin downtime. ¿Qué tipo de update debería usar el ASG?