Módulo 6 · 6 horas · Cierre integrador
Alta disponibilidad, escalado y costes
El módulo integrador. Aquí se junta todo: una arquitectura multi-AZ realista con balanceo y autoescalado, backups automatizados y — el bloque que más fricción genera en cualquier cliente — el control del coste. Si lo aprendido en los módulos anteriores no se materializa en una arquitectura concreta, no sirve. Aquí se materializa.
Objetivos de aprendizaje
- Configurar un Elastic Load Balancer (ALB para HTTP/HTTPS, NLB para TCP).
- Definir un Auto Scaling Group con launch template y políticas de escalado.
- Diseñar una arquitectura multi-AZ tipo: web + app + base de datos.
- Configurar AWS Backup con planes de retención y restauración cross-region.
- Usar Cost Explorer y Budgets para anticipar la factura.
- Aplicar etiquetado obligatorio y FinOps básico para reportar coste por cliente.
6.1 Elastic Load Balancing
Un load balancer distribuye tráfico entrante entre varios destinos (EC2, contenedores, IPs). En AWS hay varios; los dos que casi siempre usarás:
| ALB (Application Load Balancer) | NLB (Network Load Balancer) |
|---|
| Capa OSI | L7 · HTTP/HTTPS | L4 · TCP/UDP/TLS |
| Routing | Por host, path, header, cookie | Por puerto |
| Latencia | Baja | Ultra baja |
| WebSockets / HTTP/2 | Sí | N/A (es L4) |
| Caso típico | Webs y APIs (la mayoría) | Brokers, juegos, throughput muy alto, TLS passthrough |
Componentes
- Listener: en qué puerto y protocolo escucha (p.ej. 443 HTTPS).
- Rule (ALB): condiciones de routing → target group.
- Target group: conjunto de destinos (instancias, IPs, contenedores) con health checks.
Patrón estándar: ALB en subredes públicas distribuyendo tráfico HTTPS a EC2 en subredes privadas. El certificado TLS lo gestionas con AWS Certificate Manager (ACM) — gratis y renovación automática. El SG del ALB acepta del mundo en 443; el SG de las EC2 acepta solo del SG del ALB en 80/8080.
6.2 Auto Scaling Groups
Un Auto Scaling Group (ASG) mantiene N instancias de un tipo concreto y las escala arriba o abajo según demanda. Es lo que hace que tu app "respire" sola con el tráfico — y lo que evita que pagues 24/7 capacidad que solo necesitas en horario laboral.
Anatomía
- Launch template: cómo se lanza cada instancia nueva (AMI, tipo, user-data, SG, IAM role, tags). Es la "receta".
- ASG: cuántas instancias (
min, max, desired), en qué subredes (AZ), asociado a qué target group del ALB.
- Scaling policy: cuándo escalar. Las dos formas:
- Target tracking: "mantener CPU al 60% de media". AWS calcula los pasos. Es lo que más se usa.
- Step / Scheduled: pasos discretos o horarios concretos (p.ej. más instancias entre 9 y 18).
- Health checks: si una instancia falla los health checks (EC2 o del ALB), el ASG la mata y lanza otra.
Patrones útiles
- Warm pools: mantener instancias pre-arrancadas paradas para arrancar rápido en picos.
- Mixed instances policy: combinar On-Demand y Spot en el mismo ASG. AWS gestiona la mezcla.
- Lifecycle hooks: ejecutar acciones antes de matar una instancia (drenar conexiones, enviar logs).
Pequeño truco grande: activa instance refresh al subir una AMI nueva. El ASG sustituye las instancias antiguas por las nuevas en oleadas, sin parada. Es la forma cómoda de desplegar versiones sin downtime.
6.3 Arquitectura multi-AZ tipo
Junta todo lo del curso en una topología canónica que vais a desplegar muchas veces:
Arquitectura multi-AZ · flujo de tráfico de arriba abajo
🌐 Internet
↓
Route 53
DNS + health checks · failover automático
↓
⚖️ ALB · público
Subredes públicas en AZ-a / b / c · listener 443 · cert ACM
↓
EC2 appAZ-a · privada
EC2 appAZ-b · privada
EC2 appAZ-c · privada
↑ Auto Scaling Group · min=2, desired=3, max=10
↓
🗄️ RDS multi-AZ
Primary + standby sincronizado · failover automático en 30-60s
Esta topología sobrevive a la pérdida de una AZ entera sin intervención humana.
ALB sigue sirviendo, ASG lanza instancias en las AZ supervivientes, RDS hace failover.
Esa topología sobrevive a la pérdida de una AZ entera sin intervención humana: ALB sigue sirviendo desde las AZ supervivientes, ASG levanta instancias en las AZ que queden, RDS hace failover automático al standby.
Realidad de coste: esta arquitectura cuesta más que una EC2 sola — pero ese "más" se mide en €50-200/mes para una pyme y compra: cero downtime planificado, despliegues sin parada, capacidad de absorber un fallo de AZ. La conversación con cliente nunca es "es caro", es "esto es lo que cuesta no caerte".
6.4 AWS Backup en producción
Ya vimos AWS Backup en el módulo 4 a nivel concepto. En producción la receta concreta:
- Plan:
daily-7d-weekly-4w-monthly-12m — 7 diarios, 4 semanales, 12 mensuales. Cubre la mayoría de necesidades de recuperación.
- Vault cifrado con KMS propia (no la default).
- Cross-region copy a otra región (p.ej.
eu-west-1 ↔ eu-south-2) para DR.
- Cross-account copy a una cuenta de "vault" centralizada con permisos mínimos.
- Vault Lock para evitar el borrado durante el periodo de retención (compliance / anti-ransomware).
- Restore drills trimestrales: el backup que no se prueba, no existe.
Recuerda: un backup en la misma cuenta y misma región no es una estrategia de recuperación — es solo conveniencia. Para sobrevivir a un compromiso de cuenta o a un fallo regional, necesitas separación de cuenta y separación de región. Anti-patrón frecuente que cuesta caro.
6.5 Cost Explorer, Budgets y FinOps básico
El control de coste no es algo que se hace "a final de mes cuando llega la factura". Es algo que se diseña desde el principio. Tres herramientas + dos prácticas.
Cost Explorer
Visualización del gasto por servicio, por cuenta, por tag, por región, etc. Filtros, agrupaciones, comparativas con periodos anteriores. Es la herramienta de análisis post-mortem y de detección de anomalías.
AWS Budgets
Presupuestos con alertas. Defines un objetivo (p.ej. 500 €/mes) y AWS te avisa por correo (o SNS) cuando vas al 50%, 80% y 100%. Existen budgets de coste, de uso y de Savings Plans / RIs.
Mínimo que activar en cualquier cuenta: al menos un Budget de coste mensual con alerta al 80% del gasto esperado. Tres líneas de configuración que evitan facturas sorprendentes — y un argumento de venta para tu cliente: "tu cuenta tiene alertas de gasto activas, te aviso antes de que llegue la factura".
Etiquetado obligatorio
El tagging es la base del FinOps. Cada recurso lleva etiquetas estándar; Cost Explorer y reportes filtran por ellas. El esquema mínimo:
| Tag | Valores típicos | Para qué |
|---|
Environment | prod, staging, dev | Separar entornos |
Project | web-publica, api-clientes | Atribución por proyecto |
Owner | equipo-backend, ana@… | A quién avisar cuando algo va mal |
Client | acme, globex | Imprescindible en consultora multi-cliente |
CostCenter | código contable | Reporte a finanzas |
El etiquetado solo funciona si es obligatorio. Configúralo en AWS Organizations con SCPs ("nada se crea sin tag Owner y Project") y aplica reglas de AWS Config para detectar recursos sin etiquetas. Sin esto, el FinOps se queda en buenos deseos.
FinOps básico para una consultora
- Reporte mensual por cliente con coste por servicio y comparativa con el mes anterior.
- Top 5 servicios donde más se gasta — y revisión rutinaria de si se puede optimizar (Spot, Savings Plans, lifecycle de S3).
- Limpieza trimestral: EBS huérfanos, snapshots antiguos, instancias paradas, Elastic IPs sin asociar.
- Conversaciones con cliente: si la factura sube X%, explicar por qué; si baja, explicar el ahorro que aportaste.