El SAP-C02 espera que diseñes arquitecturas de alta disponibilidad complejas seleccionando correctamente entre los tipos de load balancer, políticas de escalado y estrategias de compra de EC2 para optimizar costo y rendimiento.
Contenido
| Característica | ALB (Application) | NLB (Network) | GWLB (Gateway) |
|---|---|---|---|
| Capa OSI | L7 — HTTP/HTTPS/gRPC | L4 — TCP/UDP/TLS | L3 — IP (todos los protocolos) |
| Routing | Path, host, headers, query, método HTTP | IP:Port, solo TCP/UDP | N/A — inyección de appliance |
| Latencia | Milisegundos (L7 processing overhead) | Ultra-baja (<1ms), L4 passthrough | Variable según appliance |
| IPs estáticas | No (usa DNS) | Sí — IP estática o Elastic IP | No aplica |
| WebSocket | Sí nativo | Sí (TCP) | No aplica |
| gRPC | Sí nativo | No nativo | No aplica |
| Preserva IP cliente | X-Forwarded-For header | Sí nativo (PROXY Protocol) | Sí nativo |
| Target Types | EC2, ECS, Lambda, IP | EC2, ECS, IP (on-prem con PrivateLink) | Appliances de seguridad de 3ros |
| Use case principal | Microservicios HTTP, routing avanzado, APIs | Baja latencia extrema, TCP/UDP, IPs fijas | Inspección de tráfico con appliances 3rd party |
ALB — funciones avanzadas para el examen
NLB — funciones avanzadas para el examen
Tipos de políticas de escalado
Simple Scaling
Añade/quita N instancias cuando una alarma se dispara. Tiene cooldown period — no escalará de nuevo hasta que termine. Más básico.
Step Scaling
Escala en pasos según la magnitud de la alarma. ej: CPU 70-80% → +1 instancia, CPU 80-90% → +2, CPU >90% → +3. Sin cooldown obligatorio.
Target Tracking
Mantiene una métrica en un valor target (ej: CPU al 50%). ASG escala automáticamente hacia arriba/abajo. Más inteligente y simple de configurar.
Predictive Scaling
ML analiza el historial de uso y escala proactivamente antes de picos previsibles. Se combina con Target Tracking para cargas cíclicas.
Scheduled Scaling
Escala a horas específicas (ej: +10 instancias a las 8am). Para cargas predecibles por horario.
Configuración avanzada de ASG
Cluster Placement Group
Instancias agrupadas en el MISMO rack físico. Latencia de red ultra-baja y máximo throughput entre instancias.
Spread Placement Group
Instancias distribuidas en racks DISTINTOS (hasta 7 instancias por AZ). Máximo aislamiento de fallos de hardware.
Partition Placement Group
Divide instancias en particiones, cada partición en racks distintos. Hasta 7 particiones por AZ, muchas instancias por partición.
| Tipo | Descuento vs On-Demand | Compromiso | Mejor para |
|---|---|---|---|
| On-Demand | Sin descuento (precio base) | Ninguno — paga por segundo | Cargas impredecibles, dev/test, pruebas de carga |
| Reserved (Standard) | Hasta 72% con 3 años all-upfront | 1 o 3 años, familia/región/OS fijo | Producción estable con uso predecible 24/7 |
| Reserved (Convertible) | Hasta 54% con 3 años | 1 o 3 años, pero puedes cambiar familia/OS | Producción estable pero quizás cambies familia de instancia |
| Savings Plans (Compute) | Hasta 66% | 1 o 3 años, compromiso $ por hora | Producción estable, aplica a EC2 + Fargate + Lambda |
| Savings Plans (EC2 Instance) | Hasta 72% | 1 o 3 años, familia fija en región | Producción EC2 en familia/región específica |
| Spot Instances | Hasta 90% | Ninguno — puede ser interrumpido | Batch, CI/CD, ML training, cargas stateless tolerantes |
| Dedicated Instances | ~10% más caro que On-Demand | Ninguno | Cumplimiento que requiere HW dedicado (no compartido) |
| Dedicated Hosts | Más caro — pagas por host físico | On-Demand o Reserved (hasta 70% desc) | Licencias BYOL (SQL Server, Oracle), compliance estricto |
Spot Fleet
Solicita una mezcla de tipos de instancia y AZs para cumplir con una capacidad target. Maximiza la disponibilidad de Spot al diversificar entre múltiples pools.
Spot Interruption — cómo manejarlo
On-Demand Capacity Reservations
Reserva capacidad de EC2 en una AZ específica sin compromiso de tiempo. Garantiza disponibilidad para launches críticos (DR drills, traffic spikes planificados).
Dedicated Hosts vs Dedicated Instances
Dedicated Instances
Instancias en hardware dedicado a tu cuenta, pero el servidor físico puede cambiar entre reinicios. No puedes ver ni controlar el placement del host. Compliance básico.
Dedicated Hosts
Servidor físico completo dedicado a ti. Visibilidad de número de sockets, cores. Control de placement. Necesario para BYOL de Oracle, SQL Server, Windows Server (licencias por core/socket).
Reglas de diseño Multi-AZ
Anti-patrones comunes
Trampa: "Cluster Placement Group garantiza alta disponibilidad"
Realidad: FALSO. Cluster Placement Group maximiza el rendimiento de red agrupando instancias en el mismo rack — lo opuesto a HA. Si el rack falla, todas las instancias fallan. Para HA usa Spread Placement Group.
Trampa: "Reserved Instances se aplican automáticamente a cualquier instancia EC2"
Realidad: Depende del tipo. Standard Reserved Instances se aplican solo a instancias que coincidan exactamente (familia, AZ, OS). Convertible RIs tienen más flexibilidad. Savings Plans Compute se aplican más ampliamente (EC2 + Fargate + Lambda).
Trampa: "Dedicated Instances y Dedicated Hosts son equivalentes"
Realidad: Diferentes. Dedicated Instances garantizan que no hay otros tenants en el mismo servidor físico, pero no controlas qué servidor. Dedicated Hosts te dan el servidor físico específico — necesario para BYOL que licencian por socket/core.
Trampa: "ALB Cross-Zone Load Balancing tiene costo adicional"
Realidad: ALB tiene Cross-Zone LB habilitado por defecto y SIN costo extra. NLB tiene Cross-Zone LB deshabilitado por defecto y tiene costo de data transfer entre AZs si se habilita.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa de análisis financiero ejecuta jobs de ML de 6 horas que procesan datos históricos. Los jobs pueden recomenzar desde checkpoints guardados en S3 si se interrumpen. El equipo quiere minimizar costos manteniendo alta disponibilidad para completar los jobs. ¿Cuál es la configuración óptima de EC2?
Inicia sesión para llevar tu progreso.