Lección 42 — Nube

Stack: AWS/GCP/Azure (visión general) · Proyecto: TicketFlow Estado: Publicada — cómputo, almacenamiento, redes e IAM sin vendor-lock del syllabus Prerrequisito: Lección 41 — CI/CD

Objetivos

1. Mapear los conceptos de TicketFlow (app, Postgres, Redis, storage, DNS) a los servicios equivalentes de cualquier nube, sin casarse con un proveedor.
2. Entender el IAM como el muro real de la seguridad en la nube: roles de servicio, el mínimo privilegio y el error del Access Key eterna.
3. Estimar el costo del despliegue de TicketFlow y saber qué mueve la factura (egreso, NAT, overhead de alta disponibilidad).

1. El mapa: TicketFlow en los tres idiomas

El proyecto necesita 6 piezas; los tres proveedores las venden con otro nombre:

El concepto es el mismo; la API y la factura varían. La disciplina del proyecto: dockerizar y configurar por entorno (27/40) para que el proveedor sea una decisión reversible — la imagen es la misma; solo cambian el manifest de despliegue y el IaC (44). El error del principiante: escribir el negocio contra la API del proveedor (boto3 por todos lados): el servicio de storage de la 23 define su Protocol y la implementación S3/GCS queda en el borde (24).

2. Cómputo: dónde corre el contenedor

Las tres opciones generales: PaaS de contenedores (Cloud Run/Fargate/Container Apps: subes la imagen, el proveedor escala y parchea; el precio es por uso), K8s gestionado (GKE/EKS/AKS: control total, costo de operación y complejidad — la 43 decide cuándo vale), VM clásica (una máquina con docker-compose: la opción del presupuesto mínimo con la operación a tu cargo). Para TicketFlow hoy: PaaS de contenedor — la imagen del 40 despliega igual, el autoscaling (55) viene gratis, y el equipo de 1 no opera nodos. La decisión se revisa con el umbral del 30 (el ADR que pone el plazo): si el volumen ×10 o el negocio exige redes entre servicios complejas, K8s entra.

Las configuraciones que sí importan en PaaS: la concurrencia por instancia (Cloud Run: requests simultáneos por contenedor — con gunicorn sync, 1; con async, más), el timeout del request (32/54: el timeout de la plataforma debe exceder el p99 de tus endpoints, o el edge mata requests sanos), y la sonda de salud (40: el healthcheck del contenedor ES la señal de vida del despliegue en la nube).

3. Los datos: gestionados vs. hecho-en-casa

Postgres gestionado (RDS/Cloud SQL): el proveedor hace backups, réplicas de lectura (55), failover y parcheo — a cambio de ~2-3× el costo de una VM con Postgres a mano. El cálculo del equipo de 1: la hora de operación de un DBA (tú) vale más que el delta del mes. La decisión: gestionado SIEMPRE para prod; la VM con docker compose para el lab. Lo que el gestionado NO te regala: la migración con expand-contract (11) sigue siendo tuya, el pool/aritmética del 39 sigue aplicando (el max_connections del gestionado es chico: 100-500 según tier — la aritmética del 39 es la primera reunión con la nube), y los backups hay que PROBARLOS (el restore drill del 47: un backup nunca restaurado es un pendrive esperando fallar).

El storage de objetos (S3/GCS/Blob): los exports RGPD (23), los assets estáticos, los logos del proyecto. Tres reglas: los buckets SIN listado público (Block Public Access on), los objetos con URLs firmadas con expiración (el export del usuario se descarga con un link de 15 min, no un bucket abierto), y el versionado ON para lo que el RGPD exige poder demostrar.

4. Redes: el VPC que separa y el NAT que factura

La topología mínima: una VPC con dos subnets (privada: BD, Redis, workers — SIN IP pública; pública/proxy: el app que sirve tráfico), los security groups permitiendo SOLO lo necesario (el app habla al 5432 del Postgres; nada más llega al Postgres — la 22 aplicada a la red). El detalle que factura: los recursos privados sin salida directa usan NAT Gateway (~32 €/mes + egreso) — el worker que solo habla a la BD y al broker NO necesita NAT si su salida es por endpoints privados (VPC endpoints/Private Service Connect). El egreso (datos que SALEN de la nube a Internet) es el ítem sorpresa de la factura: el CDN del 38/39 no solo acelera: el tráfico cacheado sale por el edge del CDN (más barato que el egreso del origen).

5. IAM: el muro real

El Access Key del root account pegado en un archivo de configuración es el pecado original de la nube. El diseño correcto: identidades de servicio (roles de IAM adjuntos al contenedor/función — Cloud Run service account, ECS task role) SIN claves de larga vida: el app "es" su identidad y el token rota solo. El mínimo privilegio por servicio:

{
  "Role": "ticketflow-export-worker",
  "Permite": ["s3:PutObject en bucket exports/*"],
  "Prohibido": ["s3:*", "s3:DeleteBucket", "iam:*", "el resto del mundo"]
}

El worker de export RGPD (23) puede ESCRIBIR en el bucket de exports y nada más: si lo comprometen (22), el radio del daño es ese bucket. La política de las Access Keys cuando son inevitables (CI que no soporta OIDC): rotación programada (27: la rotación dual ya la diseñaste), en el gestor de secretos (Secrets Manager/Secret Manager), nunca en el repo ni en la imagen (40 lo probó). Y la auditoría: CloudTrail/Cloud Audit Logs encendido SIEMPRE — el "¿quién borró el bucket?" del 47 tiene respuesta solo si se registró.

6. La factura: los cinco ítems de TicketFlow

Estimación mensual (equipo de 1, ~50k reservas/mes): PaaS contenedor 2 vCPU/4GB ~35-60 €; Postgres gestionado small ~25-50 €; Redis managed small ~15-30 €; storage+CDN ~5-15 €; NAT ~0-35 € (si el diseño del §4 evita el NAT: 0). Total: ~80-190 €/mes. Lo que la mueve: el egreso (CDN lo mitiga), la alta disponibilidad multi-zona (×2-3: el SLO del 46 decide si se paga), y los entornos olvidados (el staging encendido 24/7 que nadie usa: apágalo por schedule — y el ADR del 53 dice que el monolito modular también reduce factura). La revisión mensual de la factura es una tarea del 31: los recursos huérfanos (IP elástica sin instancia, disco de una BD borrada) son el.impuesto del crecimiento.

Autoevaluación

1. ¿Por qué dockerizar por entorno (27/40) mantiene reversible la decisión de proveedor y qué capa SUFRE si no?
2. PaaS de contenedores vs K8s vs VM: ¿qué vende cada uno y qué configuraciones de PaaS sí importan para TicketFlow?
3. ¿Qué te regala el Postgres gestionado, qué NO te regala, y cuál es la aritmética que sigue siendo tuya?
4. Dibuja la VPC mínima de TicketFlow: ¿quién vive en la subnet privada y por qué el worker puede NO necesitar NAT?
5. ¿Por qué el rol de servicio vence a la Access Key eterna y qué radio de daño tiene el worker de export con el mínimo privilegio?

Continúa con los ejercicios. Las solutions.md solo tras intentarlo.