Auto Scaling y alta disponibilidad tratan de asegurarse de que tu servicio nunca se caiga, incluso cuando componentes individuales fallan.
Piensa en gestionar un restaurante. Durante la hora del almuerzo, llamas a personal adicional (Auto Scaling hacia afuera). Cuando se calma por la tarde, liberas personal (Auto Scaling hacia adentro). Distribuyes a los clientes en todas las mesas disponibles (Balanceo de carga). Si una cocina se incendia, la otra cocina sigue cocinando (failover Multi-AZ). Esta es la esencia del diseno de alta disponibilidad en AWS.
Auto Scaling Group (ASG) — Ajustar automaticamente el numero de servidores
Un ASG anade o elimina instancias EC2 automaticamente segun la demanda.
Launch Template — La receta para crear instancias
Un Launch Template es como una receta de cocina: define que ingredientes usar (AMI, tipo de instancia) y como prepararlos (grupos de seguridad, par de claves, configuracion de red). Tambien incluye el script de User Data que se ejecuta automaticamente cuando se inicia una instancia, permitiendote instalar software o configurar ajustes en el arranque.
Launch Configuration es un metodo anterior que aun funciona pero ya no se recomienda. Launch Template tiene mas funciones: control de versiones, soporte para multiples tipos de instancias y configuracion de Spot.
Configuracion de capacidad
| Ajuste | Significado | Ejemplo | |--------|------------|---------| | Minimo | Nunca bajar de este numero | Siempre mantener al menos 2 | | Deseado | El numero objetivo ahora mismo | Actualmente apuntando a 5 | | Maximo | Nunca superar este numero | Nunca exceder 20 sin importar la carga |
Establecer el Minimo en 0 permite escalar a cero (sin costo cuando no hay trafico), pero esto es arriesgado para sistemas de produccion. La mayoria de los entornos de produccion mantienen un minimo de 2 instancias.
Politicas de escalado — Cuando anadir y eliminar servidores
Target Tracking
La politica de escalado mas simple y recomendada. Estableces un valor de metrica objetivo y el ASG ajusta automaticamente el numero de instancias para mantenerlo. Por ejemplo: "mantener el uso promedio de CPU al 50%." Piensa en un termostato: configuras la temperatura y el sistema maneja la calefaccion y el enfriamiento automaticamente.
Step Scaling
Diferentes umbrales de alarma activan diferentes acciones de escalado. Por ejemplo: CPU 60-70%: agregar 1 instancia CPU 70-80%: agregar 2 instancias CPU por encima del 80%: agregar 3 instancias
Cuando la carga es alta pero no extrema, agregas un poco. Cuando la carga es muy alta, agregas mas agresivamente.
Scheduled Scaling
Escalado basado en tiempo para patrones de trafico predecibles. Por ejemplo: "a las 8:30 AM cada dia de semana, establece la capacidad en 10; a las 6:00 PM, reduce a 3." Perfecto para aplicaciones de negocios internas donde el uso es alto durante el horario laboral y casi nulo por la noche.
Predictive Scaling
Usa aprendizaje automatico para analizar patrones de trafico historico y escalar de forma proactiva antes de que llegue la demanda. Si tu aplicacion siempre ve un pico de trafico cada lunes por la manana, Predictive Scaling empieza a agregar instancias el domingo por la noche.
| Politica | Mecanismo | Mejor para | |---------|-----------|-----------| | Target Tracking | Establecer valor objetivo, ASG lo mantiene | La mayoria de las cargas de trabajo | | Step Scaling | Diferentes acciones en diferentes umbrales | Control detallado | | Scheduled Scaling | Programacion basada en tiempo | Patrones de trafico predecibles | | Predictive Scaling | ML pronostica demanda futura | Picos recurrentes, escalado proactivo |
!4 tipos de políticas de Auto Scaling
ELB — Distribuyendo el trafico entre multiples servidores
ELB (Elastic Load Balancer) distribuye las solicitudes entrantes entre multiples instancias EC2. Como un banco: en lugar de que todos los clientes hagan cola para un solo cajero, se distribuyen entre multiples ventanillas.
Cuatro tipos de ELB
ALB (Application Load Balancer) opera en la Capa 7 (HTTP/HTTPS). Puede enrutar solicitudes a diferentes grupos de servidores basandose en la ruta URL, el nombre de host, los encabezados HTTP o los parametros de consulta. Por ejemplo: las solicitudes a van a tus servidores API, y las solicitudes a van a tus servidores de contenido. Usa ALB para aplicaciones web y microservicios.
NLB (Network Load Balancer) opera en la Capa 4 (TCP/UDP). Maneja millones de solicitudes por segundo con latencia extremadamente baja. Puede tener direcciones IP estaticas. Usa NLB para servidores de juegos, dispositivos IoT, sistemas de trading financiero.
CLB (Classic Load Balancer) es el balanceador de carga original de AWS. Aun funciona pero tiene menos caracteristicas. No lo uses para nuevos sistemas.
GWLB (Gateway Load Balancer) opera en la Capa 3 y se usa para insertar dispositivos de red (firewalls, sistemas de deteccion/prevencion de intrusiones) de forma transparente en tu ruta de trafico.
| Tipo ELB | Capa | Caracteristica clave | Caso de uso | |---------|------|---------------------|------------| | ALB | Capa 7 (HTTP) | Enrutamiento por ruta/host | Apps web, microservicios | | NLB | Capa 4 (TCP/UDP) | Ultra baja latencia, IP estatica | Gaming, IoT, finanzas | | CLB | Capa 4/7 | Legado | Solo sistemas existentes | | GWLB | Capa 3 | Insercion transparente de appliances | Firewalls, IDS/IPS |
Health Checks — Saber cuando un servidor esta roto
Un health check verifica periodicamente si cada instancia esta funcionando. Si una instancia falla el health check, el balanceador de carga deja de enviarle trafico y el ASG la reemplaza.
Health Check EC2 vs Health Check ELB
| Tipo | Que verifica | Que detecta | |------|------------|------------| | Health check EC2 | Hardware fisico e hipervisor | Fallo de hardware: la maquina fisica esta muerta | | Health check ELB | Respuesta de la aplicacion (codigo HTTP) | Fallo de la aplicacion: la app devuelve errores |
Este es uno de los puntos de examen mas importantes en este dominio: si configuras un ASG solo con el health check EC2 predeterminado (sin el health check ELB), tu aplicacion puede colapsar y devolver errores HTTP 500, pero la instancia EC2 en si (la maquina fisica) sigue funcionando normalmente. El health check EC2 dice "saludable." El ASG nunca reemplaza la instancia rota.
Para solucionar esto, habilita los health checks ELB en el ASG. Ahora cuando la aplicacion falla y devuelve errores, el health check ELB falla y le dice al ASG que la instancia no esta saludable, y el ASG la termina y reemplaza automaticamente.
Diseno Multi-AZ — Sobrevivir cuando falla una ubicacion
Una Zona de Disponibilidad (AZ) es esencialmente un centro de datos independiente. Si una AZ cae debido a un corte de energia o desastre natural, las otras AZs no se ven afectadas.
El principio central del diseno Multi-AZ: distribuye tus recursos en al menos dos AZs.
Configura tu ASG para abarcar multiples AZs. Si una AZ tiene problemas, las instancias en las otras AZs continuan manejando el trafico.
ALB y NLB distribuyen automaticamente el trafico entre instancias en multiples AZs.
RDS Multi-AZ replica sincrónicamente tu base de datos a una instancia en espera en una AZ diferente. Si la base de datos primaria falla, AWS promueve automaticamente la instancia en espera, generalmente en 60-120 segundos. El endpoint permanece igual, por lo que no se necesitan cambios en el codigo de la aplicacion.
ElastiCache con replicas en multiples AZs mejora el rendimiento de lectura y proporciona capacidad de failover.
Politica de Instancias Mixtas — Reducir costos con instancias Spot
Las instancias On-Demand siempre estan disponibles a un precio fijo pero son caras. Las instancias Spot usan la capacidad sobrante de AWS con hasta un 90% de descuento, pero AWS puede recuperarlas con 2 minutos de aviso.
La Politica de Instancias Mixtas permite que un solo ASG combine ambas. Usas On-Demand para tu capacidad base estable y Spot para capacidad adicional cuando necesitas escalar.
Ejemplo: siempre mantener 4 instancias On-Demand funcionando. Cuando el trafico aumenta, el ASG agrega instancias Spot. Cuando el trafico disminuye, las instancias Spot se terminan primero.
Capacity Rebalancing: cuando AWS esta a punto de recuperar una instancia Spot, proactivamente inicia una instancia de reemplazo antes de terminar la antigua, evitando caidas repentinas de capacidad.
Especificar multiples tipos de instancias: listando varios tipos similares (m5.large, m5a.large, m4.large), das al ASG mas opciones en el mercado Spot.
Capacity Reservations
Pre-reserva capacidad de instancias en una AZ especifica. Usalo cuando tienes requisitos de cumplimiento o planes de DR que garantizan "siempre debemos tener 10 instancias c5.xlarge disponibles en us-east-1a."
Puntos clave del examen
"Forma mas simple de mantener CPU al 50%" -- Target Tracking
"Anadir diferentes numeros de instancias segun el nivel de CPU" -- Step Scaling