Hasta ahora, cada pieza de Kilómetro Cero ha corrido en máquinas concretas: los tres nodos de Cassandra que Ansible configuró en 07-05, los brokers de Kafka que se reinician de uno en uno respetando las ISR, el clúster de Patroni con su etcd, el MinIO con sus discos, el clúster de Kubernetes sobre el que se despliegan los seis servicios. Alguien ha comprado esas máquinas, las ha instalado en un centro de datos, les ha puesto discos y red, y las sustituye cuando fallan. Y cuando en 07-03 se decidió un plan de recuperación ante desastres en pilot light con una "región secundaria", se dejó abierta la pregunta de dónde está esa región y quién la opera. Esta lección responde a eso cambiando la premisa: la infraestructura pasa a ser una API que un proveedor ofrece bajo demanda, con regiones y zonas de disponibilidad, redes virtuales, balanceadores, autoescalado y, sobre todo, servicios gestionados que hacen por nosotros lo que en el curso hemos montado a mano. Veremos los modelos de servicio y de despliegue, los conceptos que cambian el diseño (regiones y zonas, VPC, elasticidad), la correspondencia entre cada componente de Kilómetro Cero y su equivalente gestionado en AWS y GCP, las ventajas y los desafíos (incluido el que exige una revisión legal), la infraestructura como código con Terraform, los pilares de una arquitectura bien diseñada, y una introducción a FinOps con el coste mensual aproximado de la plataforma. La práctica despliega Kilómetro Cero en AWS con Terraform y los manifiestos k8s/ de 07-05. Serverless, edge y CDN quedan para 08-04.

1. Modelos de servicio: IaaS, PaaS, SaaS y la responsabilidad compartida
2. Modelos de despliegue: pública, privada, híbrida y multinube
3. Regiones, zonas de disponibilidad y recuperación ante desastres
4. Redes en la nube: VPC, subredes, balanceadores y autoescalado
5. Servicios gestionados: qué sustituye a cada pieza de Kilómetro Cero
6. Ventajas y desafíos: elasticidad, pago por uso, lock-in, egress y cumplimiento
7. Infraestructura como código con Terraform
8. Arquitectura bien diseñada: los pilares
9. FinOps: etiquetas, reservas, spot, presupuestos y el coste de Kilómetro Cero
10. Práctica: Kilómetro Cero en AWS con Terraform y EKS
11. Errores Comunes y Consejos
12. Ejercicios
13. Conclusión

La nube se define por lo que el proveedor asume y lo que sigue siendo responsabilidad del cliente. Esa línea se mueve según el modelo de servicio, y saber dónde está en cada caso es lo que evita tanto pagar por lo que no se usa como asumir que "la nube lo hace" cuando no lo hace.

Dos filas no cambian nunca de columna: los datos y las identidades son siempre del cliente. Ese es el modelo de responsabilidad compartida que todos los proveedores publican: el proveedor responde de la seguridad de la nube (que nadie acceda físicamente al disco, que el hipervisor aísle), el cliente de la seguridad en la nube (que el bucket no sea público, que el rol IAM no tenga *, que los datos personales estén cifrados y en la región correcta). Un bucket km0-facturas accesible sin autenticación es responsabilidad del cliente en cualquier modelo.

Para Kilómetro Cero, el reparto natural es: PaaS para todo lo que tiene equivalente gestionado (bases de datos, Kafka, Kubernetes, caché, objetos), IaaS solo donde no lo hay o donde el control compensa (los nodos de trabajo de Kubernetes son IaaS por debajo, pero gestionados como grupo), y SaaS para lo que no aporta diferencia (identidad, observabilidad si se decide externalizarla).

Kilómetro Cero, que hoy tiene su propio hardware, pasará a nube pública con un periodo híbrido durante la migración (el enlace VPN entre el centro de datos y la VPC permite que Kafka replique con MirrorMaker y que Patroni tenga una réplica en la nube antes del corte). La multinube se descarta explícitamente: con cuatro equipos, operar dos proveedores costaría más que el riesgo que mitiga, y la portabilidad se mantiene de otra forma, con Kubernetes como capa de despliegue y con contenedores para lo que no es gestionado (apartado 6).

Un proveedor organiza su infraestructura en regiones (una zona geográfica: Irlanda, Fráncfort, París...) y, dentro de cada región, en varias zonas de disponibilidad (availability zones, AZ): centros de datos físicamente separados (kilómetros de distancia, energía y red independientes) pero conectados con latencia de 1-2 ms. Esta estructura mapea directamente sobre los dominios de fallo de 07-03:

• Una AZ es un dominio de fallo de centro de datos: incendio, corte de energía, fallo de red del edificio. Distribuir las réplicas entre AZ (los tres nodos de Cassandra en tres AZ; el primario de Patroni y su réplica síncrona en AZ distintas; los brokers de Kafka con broker.rack = AZ para que las réplicas de cada partición se repartan) hace que la pérdida de una AZ no sea un desastre, solo un failover. Es lo que en 07-05 hacía topologySpreadConstraints con la etiqueta de zona.
• Una región es un dominio de fallo geográfico (y regulatorio): un desastre natural, un fallo de un servicio regional del proveedor, o un cambio legal. La región secundaria de 07-03 es otra región del mismo proveedor, a cientos o miles de kilómetros, con latencia de 10-80 ms, lo que descarta la replicación síncrona entre ellas.

Con eso, las tres estrategias de DR de 07-03 se concretan en la nube:

Kilómetro Cero mantiene la decisión de 07-03 (pilot light) por coste, con una diferencia importante respecto al centro de datos propio: en la nube, la región secundaria no cuesta nada mientras está vacía. Terraform puede crear la infraestructura de la región secundaria en 20 minutos a partir del mismo código; lo único que debe existir de antemano son los datos replicados. La activa-activa se deja como siguiente paso en 08-05, porque implica resolver conflictos de escritura entre regiones (03-04) y cambiaría el modelo de consistencia del stock.

Una VPC (Virtual Private Cloud) es una red privada aislada dentro de la región, con su rango de direcciones (10.0.0.0/16), dividida en subredes que pertenecen cada una a una AZ. La convención que Kilómetro Cero adopta, y que es la habitual, es de tres capas por AZ:

Los grupos de seguridad son cortafuegos con estado por recurso, y expresan las mismas reglas que las políticas de red de Kubernetes de 07-05 pero en la capa de la VPC: RDS solo acepta 5432 desde el grupo de seguridad de los nodos de EKS; MSK solo 9094 (TLS) desde EKS; nada desde fuera. Los servicios gestionados como S3 se alcanzan por endpoints de VPC, que evitan que el tráfico hacia km0-fotos salga a Internet (y evitan el coste del NAT).

Los balanceadores gestionados sustituyen al Ingress + Kong de 07-05 en su capa externa: un balanceador de aplicación (ALB en AWS, HTTP(S) Load Balancer en GCP) termina TLS con certificados gestionados y renovados automáticamente, reparte entre las AZ, hace health checks y expone una IP en varias AZ. Kong sigue existiendo detrás, como gateway con sus plugins (06-05); el balanceador es solo la puerta de la región. El WebSocket de 08-02 exige que el balanceador soporte Upgrade y tenga un timeout de inactividad largo (el ALB lo permite; un balanceador de red de capa 4 lo pasa sin mirar).

El autoescalado opera en dos niveles que hay que distinguir: el HPA de 07-05 añade Pods según CPU o lag de Kafka, pero los Pods necesitan nodos; el autoescalador del clúster (Cluster Autoscaler o Karpenter en EKS, el autoescalado de node pools en GKE) añade y quita máquinas virtuales cuando hay Pods pendientes o nodos vacíos. Por debajo, un grupo de autoescalado de máquinas virtuales (Auto Scaling Group) las reemplaza si fallan un health check y las reparte entre AZ. La Semana de la Vendimia con k6 (07-06) se convierte así en: HPA sube pedidos de 3 a 12 Pods → 6 Pods pendientes por falta de CPU → Karpenter arranca 2 nodos en 90 s → los Pods se programan. Esos 90 s son la razón de mantener margen (nodos con capacidad libre) antes de una campaña anunciada, o de escalar por calendario.

Esta tabla es la correspondencia entre lo construido en el curso y lo que el proveedor ofrece gestionado. En cada fila, lo que se gana es lo que el proveedor asume (instalación, parches, failover, backups, escalado) y lo que se pierde es control y portabilidad.

Tres notas sobre esta tabla. Primera: Pub/Sub de GCP no es Kafka: no tiene particiones ni offsets al estilo Kafka (aunque ofrece ordenación por clave y reproducción), y el código de consumidores con grupos y commits cambia; si se quiere Kafka en GCP, es Confluent Cloud. Segunda: Keyspaces es compatible con CQL pero no es Cassandra: el nivel de consistencia y las transacciones ligeras tienen diferencias que hay que verificar con el repositorio de 04-04 antes de migrar. Tercera: lo gestionado no elimina la operación, la cambia: ya no se parchea PostgreSQL, pero sigue habiendo que dimensionar la instancia, elegir la ventana de mantenimiento (RDS reinicia para aplicar parches mayores), probar las restauraciones y vigilar las conexiones.

En 07-05 se distinguieron las herramientas de configuración (Ansible: dejar una máquina existente en un estado) de las de aprovisionamiento (Terraform: crear la infraestructura misma), y se remitió aquí. Cuando la infraestructura es una API, describirla como código es lo que permite revisarla en pull request, reproducirla en otra región y saber qué existe. Terraform (y su bifurcación abierta OpenTofu) es declarativo: se describe el estado deseado en ficheros .tf (lenguaje HCL) y la herramienta calcula y ejecuta las llamadas a la API necesarias para llegar a él, en el orden que dictan las dependencias.

Cuatro conceptos bastan para leer y escribir la práctica del apartado 10:

1. Proveedores (providers): plugins que traducen recursos a llamadas de API (aws, google, kubernetes, helm, kafka...). Se declaran con versión fijada.
2. Recursos y datos: resource "aws_db_instance" "inventario" { ... } crea; data "aws_availability_zones" "disponibles" {} consulta. Se referencian entre sí (aws_vpc.km0.id), y esas referencias son el grafo de dependencias.
3. Estado remoto: Terraform guarda en un fichero de estado la correspondencia entre lo declarado y lo que existe (ids reales). Ese fichero es crítico y compartido: se guarda en un backend remoto (S3 con versionado, y una tabla de DynamoDB como cerrojo para que dos personas no apliquen a la vez; es el mismo problema de exclusión mutua de 03-03 resuelto con un servicio gestionado), se cifra y nunca se sube a Git. Contiene secretos (contraseñas iniciales de RDS), lo que refuerza lo anterior.
4. Módulos: carpetas de .tf reutilizables con variables de entrada y salidas (module "vpc" { source = "terraform-aws-modules/vpc/aws" ... }). Kilómetro Cero usa módulos de la comunidad para VPC y EKS (cientos de recursos que no merece la pena escribir a mano) y módulos propios para cada entorno.

El ciclo es terraform init (descarga proveedores y módulos, conecta con el estado), terraform plan (calcula el diff entre lo declarado y el estado y lo muestra: + crear, ~ modificar, - destruir, -/+ reemplazar), y terraform apply (lo ejecuta tras confirmar). El plan es la pieza más valiosa: se ejecuta en el pipeline (07-05) y se pega en la pull request; un -/+ sobre aws_db_instance.inventario (reemplazar la base de datos) es lo que una revisión debe detener. En GitOps, apply solo lo ejecuta el pipeline tras el merge, nunca una persona desde su portátil.

Los proveedores publican marcos de "arquitectura bien diseñada" (well-architected) con pilares que sirven como lista de comprobación. Los seis de AWS (GCP tiene una lista equivalente) coinciden casi uno a uno con módulos del curso:

Su utilidad práctica es la revisión periódica: cada semestre, recorrer las preguntas del marco sobre la plataforma y anotar qué falta. Es un ejercicio del proyecto final (08-05).

En la nube, el coste es una métrica más del sistema, y como cualquier métrica hay que medirla, atribuirla y ponerle alertas. La disciplina se llama FinOps y, en su nivel básico, se reduce a cinco prácticas:

1. Etiquetado (tagging): todo recurso lleva etiquetas equipo, servicio, entorno, centro_coste. Sin ellas, la factura es un número; con ellas, "el equipo de reparto gastó 1 840 € en septiembre, el 60 % en MSK". Terraform las aplica por defecto a todo (default_tags).
2. Reservas y planes de ahorro: comprometerse a un uso durante 1 o 3 años a cambio de un 30-60 % de descuento. Se aplica a la base que siempre está encendida (los nodos mínimos de EKS, RDS, MSK, ElastiCache), nunca al pico.
3. Instancias spot: capacidad sobrante del proveedor con un 60-90 % de descuento, que puede ser retirada con 2 minutos de aviso. Ideal para lo que tolera interrupciones y reinicia solo: los ejecutores de Spark (05-03 ya toleraba la pérdida de ejecutores recomputando particiones), los nodos de EKS para cargas sin estado con varias réplicas. Nunca para RDS, Cassandra, Kafka ni el plano de control.
4. Presupuestos y alertas: un presupuesto por equipo y entorno, con alerta al 80 % y al 100 % previstos, y detección de anomalías (un NAT gateway que de repente mueve 2 TB porque alguien sirvió las fotos sin CDN). Son alertas como las de 07-01, hacia el mismo canal.
5. Apagar lo ocioso: entornos de staging apagados de noche y en fin de semana (con Terraform o con programaciones), clústeres de Spark efímeros (EMR arranca para el DAG km0_ventas_diarias y se destruye al acabar), volúmenes y snapshots huérfanos.

Los precios siguientes son ficticios y orientativos, del orden de magnitud correcto para una región europea, y sirven para el razonamiento, no como presupuesto. El ejercicio útil es ver dónde está el coste, no la cifra exacta.

Lo que la tabla enseña: el cómputo (EKS + bases de datos + Kafka) es dos tercios del total; las reservas ahorran un 25-30 % sobre la base; el egress es la partida más sensible al diseño (la CDN de 08-04 la divide por seis); y dos servicios gestionados (MWAA, Flink gestionado) cuestan más que sus equivalentes autogestionados en el clúster, lo que ilustra que "gestionado" no siempre gana: la decisión depende de cuánto cuesta el tiempo del equipo que lo operaría.

La estructura del código de infraestructura, que se añade al proyecto km0/:

Lo que sigue es main.tf explicado bloque a bloque. Está simplificado (faltan algunos parámetros de seguridad y de red que un módulo real incluye), pero cada bloque es real y corresponde a una decisión de las secciones anteriores.

Los Pods de pedidos y catalogo llevan en k8s/pedidos-deployment.yaml una toleration para km0/spot y una affinity que prefiere base, de modo que en campaña desbordan a spot; Cassandra, Kafka (si fuera autogestionado) y las bases de datos no toleran el taint y nunca caen en spot. El autoescalador del clúster (Karpenter, instalado con el proveedor helm) es quien pasa el grupo campana de 0 a 12 según los Pods pendientes.

Lo que aquí sustituye a lo construido a mano: multi_az = true es Patroni + etcd + réplica síncrona + failover automático (RDS cambia el DNS del endpoint al standby en ~60 s; la aplicación solo necesita reconectar, que es lo que el pool con reintentos de 07-04 ya hace); backup_retention_period es el pgBackRest y el archivado de WAL de 07-03. Lo que no sustituye: la prueba de restauración semanal, que sigue siendo un trabajo de Airflow que restaura el último snapshot en una instancia temporal y ejecuta comprobaciones.

Los Pods de catalogo necesitan escribir en km0-fotos; los de pedidos, leer sus secretos. En lugar de credenciales de larga duración en un Secret de Kubernetes (lo que 06-04 evitaba con Vault), EKS permite asociar un rol IAM a una service account de Kubernetes: el Pod obtiene credenciales temporales automáticamente, con el mínimo privilegio, y CloudTrail registra quién hizo qué. Es la identidad de carga de trabajo de 06-04 (SPIFFE) con el IAM del proveedor.

En el manifiesto k8s/catalogo-deployment.yaml basta con serviceAccountName: catalogo y la anotación eks.amazonaws.com/role-arn: <arn del rol> en la ServiceAccount; el SDK de AWS en el Pod (boto3, el mismo fotos.py de 04-03 apuntando a S3 en lugar de a MinIO) encuentra las credenciales solo.

Los manifiestos no cambian de forma: cambian los valores de configuración que apuntan a las dependencias. En 07-05, pedidos-config tenía KAFKA_BOOTSTRAP=kafka-0.kafka:9092; ahora lo genera el pipeline a partir de las salidas de Terraform:

Lo que desaparece de k8s/ al pasar a servicios gestionados: los StatefulSets de PostgreSQL con Patroni, de Kafka y de Redis, y sus operadores. Lo que se queda: los seis servicios, Kong, el mesh, Cassandra (si no se adopta Keyspaces), Prometheus/Loki/Tempo (si no se adopta CloudWatch) y Mosquitto. El HPA de 07-05 funciona igual; lo nuevo es Karpenter debajo. Y las pruebas de 07-06 se repiten contra el entorno staging desplegado con staging.tfvars (instancias pequeñas, sin Multi-AZ, sin DR), que se apaga por las noches.

• Suponer que "gestionado" significa "sin operar". RDS sigue reiniciando en la ventana de mantenimiento, MSK sigue necesitando dimensionar particiones, y nadie prueba las restauraciones por nosotros. Cambia el trabajo, no desaparece.
• Una sola AZ "para ahorrar". Un NAT, una subred, RDS sin Multi-AZ: la primera incidencia de AZ del proveedor es una caída total. Multi-AZ para todo lo que esté en el camino de un pedido.
• Olvidar el egress y el tráfico entre AZ en el presupuesto. Son las dos partidas que sorprenden en la primera factura. CDN para lo público, endpoints de VPC para S3, client.rack en los consumidores de Kafka.
• Roles IAM con *. Un rol de servicio con s3:* sobre todos los buckets convierte un Pod comprometido en una fuga total. Una política por service account, con acciones y recursos concretos (bloque 6).
• El estado de Terraform en Git o en un portátil. Contiene secretos y es el único mapa de lo que existe. Backend remoto cifrado con versionado y cerrojo, siempre.
• Aplicar sin leer el plan. Un -/+ sobre una base de datos es una destrucción con recreación. El plan va en la pull request y deletion_protection en producción.
• Elegir la región solo por precio o latencia. Los datos personales tienen restricciones de residencia; la región es una decisión con revisión legal, y documentada.
• Comprar reservas para el pico. Las reservas cubren la base que siempre está encendida; el pico va a spot o a bajo demanda. Comprar de más es pagar por capacidad que no se usa.
• Consejo: despliega primero staging con la misma configuración de Terraform y tamaños pequeños; el 90 % de los errores de red, IAM y grupos de seguridad aparecen ahí a coste mínimo.
• Consejo: pon el coste en Grafana junto al resto de métricas (los proveedores exportan el gasto diario por etiqueta). Un gráfico de euros por pedido es la métrica de negocio que más conversaciones útiles genera.

Revisa el main.tf del apartado 10 y responde: (a) si la AZ b desaparece entera, qué componentes de Kilómetro Cero se ven afectados, qué mecanismo recupera cada uno y en cuánto tiempo aproximado; (b) qué habría pasado con one_nat_gateway_per_az = false; (c) qué componente del main.tf no sobreviviría a la pérdida de la región y qué habría que ejecutar para recuperarlo.

Usando la tabla de costes del apartado 9 (precios ficticios), calcula el ahorro o el sobrecoste mensual aproximado de estas tres decisiones y razona si compensan: (a) sustituir MWAA por Airflow en EKS (estimado: 40 € de nodos); (b) pasar km0_analitica de RDS a Multi-AZ; (c) mover los nodos permanentes de EKS de bajo demanda a una reserva de 3 años (descuento estimado 55 % en lugar de 40 %) sabiendo que el equipo planea reducir a 4 nodos permanentes dentro de un año.

Para cada uno de estos componentes, decide si Kilómetro Cero debería usar el servicio gestionado del proveedor o desplegarlo en EKS, aplicando el criterio de "lock-in selectivo" del apartado 6 (beneficio del gestionado frente a coste de la dependencia): PostgreSQL, Kafka, Cassandra, Keycloak, Vault, Prometheus/Grafana. Justifica cada una en dos frases.

Ejercicio 1.

(a) Con la AZ b caída: RDS km0_inventario: el standby estaba en b (o el primario; RDS lo decide); si era el standby, no pasa nada visible y RDS crea uno nuevo en otra AZ; si era el primario, failover automático al standby en ~60 s, durante los cuales las reservas de stock fallan y la saga reintenta (07-04). MSK: el broker 2 cae; las particiones cuyo líder estaba allí eligen nuevo líder entre las ISR (03-03) en segundos; con min.insync.replicas=2 y RF=3 se sigue escribiendo. Cassandra: un nodo de tres; con QUORUM (2 de 3) se sigue leyendo y escribiendo. ElastiCache: si el primario estaba en b, failover automático a la réplica (~30 s) y la caché se rellena; si era la réplica, nada. EKS: los nodos de b desaparecen; Kubernetes reprograma sus Pods en a y c (07-05: topologySpreadConstraints garantizaba que ningún servicio tuviera todas sus réplicas en b) en 1-3 minutos, y Karpenter añade nodos si falta capacidad. ALB: deja de enviar a b tras fallar los health checks (segundos). NAT: el de b cae, pero los nodos de b también, así que nadie lo necesita.

(b) Un solo NAT en, por ejemplo, la AZ a: si cae a, los nodos de b y c siguen vivos pero pierden la salida a Internet: pagos no alcanza la pasarela, el pipeline no descarga imágenes. Un componente sano queda inutilizado por un dominio de fallo ajeno: exactamente lo que 07-03 llamaba redundancia no independiente.

(c) Todo lo de la región primaria. Lo que hay en la secundaria: la réplica de RDS (inventario_dr), el bucket replicado y el MSK mínimo con MirrorMaker. Para recuperar: terraform apply del mismo código con region = "eu-central-1" (unos 20-30 min para VPC + EKS + ElastiCache), promover la réplica de RDS (aws rds promote-read-replica, ~5 min), desplegar los manifiestos apuntando a los nuevos endpoints, restaurar Cassandra desde los snapshots replicados en S3 (el paso más largo y el que fija el RPO de pedidos), y cambiar el registro de Route 53. Es el runbook del pilot light de 07-03, y el RTO real es el que salga en el game day, no el de la tabla.

Ejercicio 2.

(a) MWAA 320 € → Airflow en EKS 40 €: ahorro ≈ 280 €/mes (3 360 €/año). Compensa si el equipo de plataforma asume operar Airflow (actualizaciones, base de metadatos, guardia); con el operador de Kubernetes y una instancia pequeña de RDS para los metadatos (~30 € más), sigue compensando, y además evita una dependencia específica del proveedor. Es el ejemplo de que lo gestionado no siempre gana.

(b) 210 € → aproximadamente el doble, ≈ 420 €: sobrecoste ≈ 210 €/mes. Para km0_analitica, cuya pérdida temporal no impide vender (RTO de horas en 07-03, se reconstruye desde el lago), no compensa; la decisión de 07-03 sigue siendo válida.

(c) Base de nodos: 900 € bajo demanda; con reserva de 1 año al 40 %: 540 €; con reserva de 3 años al 55 %: 405 €. Diferencia a favor de 3 años: 135 €/mes. Pero la reserva de 3 años cubre 6 nodos y dentro de un año solo se usarán 4: se pagarían 2 nodos reservados sin usar durante 2 años (≈ 2 × 67 € × 24 meses ≈ 3 200 €), frente a un ahorro de 135 × 12 = 1 620 € el primer año. No compensa: reserva de 1 año, renegociable cuando el dimensionamiento cambie. Las reservas se compran para la base estable, y "estable" incluye el futuro previsible.

Ejercicio 3.

• PostgreSQL → RDS (gestionado). Beneficio alto (Multi-AZ, PITR, parches sustituyen al clúster de Patroni completo) y lock-in bajo: es PostgreSQL estándar, un pg_dump lo mueve a cualquier sitio.
• Kafka → MSK (gestionado). Beneficio alto (el rolling de brokers de 07-05 y la gestión de discos desaparecen) y lock-in bajo: protocolo Kafka estándar, MirrorMaker lo replica a cualquier Kafka. En GCP, Confluent antes que Pub/Sub por la misma razón.
• Cassandra → en EKS (o EC2), no Keyspaces. Keyspaces cambia la semántica (transacciones ligeras, algunos tipos, modelo de coste por petición) y el repositorio de 04-04 necesitaría revisión: lock-in alto para un beneficio medio. Se mantiene autogestionado con el operador de 07-05, y se revisa si el equipo de plataforma no da abasto.
• Keycloak → en EKS, no Cognito. Cognito es más limitado en flujos y personalización, y migrar usuarios y clientes de un proveedor de identidad es doloroso: lock-in alto. Keycloak en dos réplicas con RDS detrás es fácil de operar.
• Vault → Secrets Manager (gestionado), con matiz. Para los secretos estáticos y su rotación, Secrets Manager con IRSA es más simple y se integra con IAM. Las credenciales dinámicas de base de datos y la PKI para mTLS que Vault daba en 06-04 no tienen equivalente directo: si el mesh asume el mTLS (08-01), Vault puede retirarse; si no, se mantiene Vault en EKS solo para eso.
• Prometheus/Grafana → en EKS. La instrumentación de servicios/comun/ es estándar (OpenTelemetry, exposición Prometheus) y los dashboards y alertas de 07-01 existen ya; CloudWatch costaría más y cambiaría el lenguaje de consulta (PromQL). Lock-in evitable a coste bajo. Los servicios gestionados de Prometheus/Grafana del proveedor son un punto medio aceptable si el almacenamiento de métricas crece.

La nube convierte la infraestructura en una API, y con ello cambia tres cosas en el diseño de Kilómetro Cero. La primera es la responsabilidad: IaaS, PaaS, SaaS y FaaS mueven la línea entre lo que hace el proveedor y lo que hace el cliente, pero los datos y las identidades quedan siempre a este lado. La segunda es la geografía: regiones y zonas de disponibilidad son dominios de fallo con nombre, las AZ absorben los fallos cotidianos con Multi-AZ en todo lo que toca un pedido, y la región secundaria del pilot light de 07-03 pasa a ser código de Terraform que no cuesta nada mientras no se ejecuta. La tercera es la sustitución: RDS por Patroni, MSK por los brokers de Ansible, S3 por MinIO, EKS por el clúster propio, con una tabla que dice qué se gana y qué se pierde en cada fila, y un criterio de lock-in selectivo (gestionado donde el beneficio es alto y la API estándar, propio donde la dependencia costaría más que la operación). Terraform describe la VPC de tres capas por AZ, EKS con nodos base y spot, RDS Multi-AZ con su réplica en otra región, MSK, ElastiCache, S3 con versionado y replicación, e IRSA para que cada Pod tenga solo los permisos que necesita; los manifiestos de 07-05 se despliegan casi sin cambios, y el plan de Terraform se revisa en la pull request como cualquier código. Los pilares de la arquitectura bien diseñada resumen el curso como lista de comprobación, y FinOps añade el coste como métrica: etiquetas, reservas para la base, spot para Spark y los picos, presupuestos con alerta, y una tabla que muestra que el cómputo es dos tercios de la factura, que dos servicios gestionados cuestan más que sus equivalentes en el clúster, y que el egress es la partida que el diseño más puede reducir.

Precisamente esa partida, y dos preguntas más, abren la siguiente lección. ¿Hace falta un servicio en Kubernetes, con sus réplicas, sus sondas y su guardia, para generar una miniatura cada vez que la Quesería Montblanc sube una foto, o para producir un PDF cuando llega un pago.confirmado? ¿Y por qué las fotos de queso-curado tienen que viajar desde Irlanda hasta el móvil de Ana en Valencia en cada visita, cuando podrían estar a veinte kilómetros de ella? Funciones que existen solo mientras hay un evento que procesar, y cómputo y caché en el borde de la red: Arquitecturas Serverless y Edge Computing.