Compañero de trino-absorcion.md. Aquel dice cómo levantar el
motor; éste, cuánto cuesta y qué lo baja. Se escribe ahora, con F0 cerrado y F1 sin
empezar, porque las dos palancas grandes son irreversibles en caliente (la
regionalidad del cluster y la familia de máquina de un pool) y elegirlas tarde
significa recrear.

⚠️ Todos los precios de este documento están MEDIDOS, no copiados de una web:
salen del Cloud Billing Catalog API de la propia cuenta
(services/6F81-5844-456A/skus, currencyCode=EUR, filtrado a europe-west1),
consultado el 2026-08-06. Son precios de lista: no incluyen el sustained use
discount que GCP aplica solo a N2 (hasta ~20 % si la instancia corre el mes entero),
así que la factura real de on-demand es algo menor que la de las tablas.

Lo marcado [confirmar] cambia con el tiempo y se re-mide antes de decidir.

Actualización del mismo día: tras el right-sizing de P4 el cluster bajó a un solo
nodo, así que la factura en reposo es hoy ≈ 140 €/mes (63 + 68,46 + 8,78). El
segundo nodo lo levantará el autoescalador cuando F1 despliegue Trino.

⭐ Un disco no deja de costar porque su VM esté apagada. Es el cargo huérfano
clásico, y aquí está vivo: pagamos 14 €/mes por el disco de una máquina parada.
No se puede borrar sin más — dentro vive el Postgres de OpenMetadata con toda la
metadata ingerida. La salida es snapshot y borrar el disco: un snapshot cobra sólo
el espacio usado y comprimido, así que baja de ~14 € a ~2-4 €/mes, y restaurarlo es un
comando. Se hace cuando F8 haya repuntado la ingesta, no antes.

🔴 La trampa: en Spot, N2 es la MÁS barata — al revés que en on-demand

En on-demand, N2D es un 13 % más barata que N2 (0,026556 vs 0,030524), y de ahí
sale la intuición habitual de «para ahorrar, AMD». En Spot se invierte: N2 sale a
0,007031 y N2D a 0,012105 — N2D cuesta un 72 % MÁS que N2.

Quien elija la familia del pool de workers mirando la tabla de on-demand —que es la que
sale en todas partes— paga casi el doble en el sitio donde iba a estar el grueso
del gasto. El descuento de Spot no es un porcentaje fijo: es un precio propio por
familia, y hay que mirarlo por separado.

(Y tiene una consecuencia buena: carbon-compute.sh ya usa n2 por defecto, elegida
por inventario para esquivar el stockout. Resulta ser también la correcta para Spot.)

⛔ MEDIDO 2026-08-07 · P1 ESTÁ BLOQUEADA, y no por FTE

PREEMPTIBLE_CPUS     usage 0     limit 0        (europe-west1, trino-k8s)

Los Spot VM consumen la cuota PREEMPTIBLE_CPUS, y la nuestra es CERO. No es que
sobre poca: no hay ninguna. Y la causa es el cabo suelto nº 4 del §F0 del runbook, que
estaba anotado sin conectarlo con esto: la cuenta está en trial, y Google no
concede cuota de preemptible/Spot a cuentas de prueba — la ampliación se deniega hasta
convertirla en de pago.

⇒ La palanca más grande de todo este documento no la desbloquea terminar F5. La
desbloquea una decisión de facturación. F5·a (FTE) se cerró el 2026-08-07 con su
control negativo, y Spot sigue siendo imposible.

Lo que sigue —el orden FTE→Spot y el precio por familia— es correcto y se aplica el
día que haya cuota. Pero el prerrequisito de P1 no es FTE: es la cuota, y eso no
estaba escrito.

⛔ El coordinador NUNCA va en Spot. Nunca.

Es el error que anula todo lo demás. FTE protege contra la pérdida de un worker,
no del coordinador: si desalojan al coordinador, se caen todas las queries del
cluster a la vez, las tolerantes a fallos incluidas, porque él es quien las está
coordinando. Se ahorrarían 15 €/mes y se compraría una caída completa cada pocos días.

⇒ Dos pools: main-pool on-demand (sistema + coordinador) y workers-pool Spot.
Es exactamente lo que el runbook §F0 ya anticipa —«los workers de Trino van en su
propio pool, con máquinas mayores y Spot»— y ahora tiene precio.

🔴 MEDIDO 2026-08-07 · el 76 % es de borrar, no de suspender — y el suelo NO es cero

Con infra/gke/trino-suspend.sh off (F5·b1, clusterOperation.stopped), dos ciclos
completos:

	nodos	€/mes de tasa
trabajando	3 (techo 4)	≈ 297 (≈ 370)
suspendido	2, y en otro ciclo 1	≈ 224 (≈ 151)

⇒ la suspensión ahorra 73 €/mes (25 %), o 146 (49 %) si cae a un nodo. A ritmo real
(~76 % de las horas suspendido) son ~55-111 €/mes, no el 76 % del cómputo.

⭐ Y el motivo principal no estaba escrito: el suelo oscila entre 1 y 2 nodos porque
kube-dns corre con 2 réplicas y anti-afinidad — no pueden compartir nodo, así que
hay un n2-standard-2 entero sosteniendo un pod de DNS. Es un lazo con histéresis
(bajó a 1 en un ciclo y se quedó en 2 en el siguiente), no un número fijo. A eso se
suman los 63 €/mes de gestión y el NAT+IP, que la suspensión no toca.

⇒ Las dos formas de P3 no son «más ahorro / menos ahorro»: son dos palancas con dos
precios. Suspender cuesta 330 s de despertar y da el 25-49 %. Borrar da el 76 % y
cuesta rehacer operadores y CRs. Este epígrafe las tenía juntas.

⭐ Y aquí pasó algo que merece ser la lección de esta sección

Liberar 1010m no dejó 1010m libres. Dejó el nodo A al 26 % de utilización, y el
autoescalador lo retiró; el nodo B absorbió sus pods y volvió a 81 %. La CPU
liberada no se quedó en la mesa: se convirtió en un nodo menos.

	en reposo	con F1 encima
antes	2 nodos	3
ahora	1 nodo	2

⇒ −68,46 €/mes con Trino encima, y otros −68,46 €/mes mientras no lo esté.

La lección, que se aplica a toda la sección P4: en un cluster con autoescalado, el
right-sizing no se cobra en «CPU libre» sino en nodos que no existen. Medir el
efecto mirando Allocated resources de un nodo subestima el ahorro o lo hace
desaparecer —el nodo superviviente vuelve a marcar 81 %, igual que antes— cuando en
realidad se acaba de eliminar una máquina entera. El KPI correcto es el número de
nodos, no el porcentaje por nodo.

El criterio, que se reutiliza en cada operador que se instale: requests bajos,
limits holgados. Un controlador duerme el 99 % del tiempo y despierta a reconciliar;
necesita poder usar CPU en el pico, no tenerla reservada mientras duerme. Y el
scheduler mira requests, no uso — por eso una reserva fantasma cuesta nodos reales.

⚠️ Y esto NO se le aplica a Trino. Un motor con requests != limits es Burstable
y puede ser desalojado bajo presión de memoria del nodo. Para Trino, requests =
limits y QoS Guaranteed. La regla es de controladores, no universal.

🔴 P5 no ahorraba 9 €/mes: era el bloqueante de F5, y estaba agendada como propina

Al intentar levantar el 2º worker que exige el gate de FTE, el autoescalador contestó:

Warning  FailedScaleUp  cluster-autoscaler
  Node scale up in zones europe-west1-b … failed: GCE quota exceeded

Y la cuota era ésta:

SSD_TOTAL_GB     usage 202     limit 250

⭐ pd-balanced cuenta contra la cuota de SSD. Dos nodos × 100 GB = 200; un tercero
pide 302 > 250. El cluster estaba a un nodo de su techo, y el techo no era dinero: era
cuota.

	SSD usado	nodos que caben
antes (100 GB/nodo)	202 / 250	2
ahora (50 GB/nodo)	102 / 250	5

Ejecutado recreando el pool (main-pool-2 → main-pool-3), y el orden lo impuso la
propia cuota: no cabía crear el pool nuevo antes de encoger el viejo (202 + 50 = 252

250, se pasaba por 2 GB). ⇒ bajar main-pool-2 a 1 nodo → crear main-pool-3 con 2
nodos de 50 GB → borrar el viejo. Después, TriggeredScaleUp 2->3 a la primera.

La lección para este documento entero: una palanca valorada sólo en euros puede
estar bloqueando una fase. El orden de §5 estaba ordenado por ahorro, y P5 iba de las
últimas — cuando era la que abría la puerta.

El 80 % existe, y sale de tres palancas, no de veinte: Spot en los workers (P1),
el cargo de gestión (P2) y apagar lo que no se usa (P3). Todo lo demás de este
documento son decenas de euros; éstas son centenares.

Y las tres tienen un prerrequisito común que no es de coste: P1 exige FTE (F5),
y P3 exige el autoescalado por cola (F5). ⇒ F5 no es sólo la fase de
resiliencia: es la que desbloquea el 80 % del ahorro. Vale la pena saberlo al
priorizar, porque hoy está listada como una fase intermedia más.

⛔ CORREGIDO 2026-08-07 — el 80 % tiene un prerrequisito ANTERIOR a F5

Con F5·a (FTE) ya cerrada y verificada, Spot sigue siendo imposible:
PREEMPTIBLE_CPUS = 0/0. ⇒ De las tres palancas del 80 %, P1 (los 843 € de los
workers, o sea el grueso) no la desbloquea F5 sino salir del trial.

Palanca	€	Qué la desbloquea DE VERDAD
P1 · Spot	843 €	⛔ cuota PREEMPTIBLE_CPUS — hoy 0, y en trial no se concede
P2 · zonal	63 €	recrear el cluster — nada más
P3 · apagar / scale-to-zero	~160 €	F5·b (KEDA), que sigue pendiente

La frase «F5 desbloquea el 80 %» seguía siendo verdad como dependencia lógica y
era falsa como plan: se puede terminar F5 entera y no cobrar la parte grande.
Es el mismo error de encuadre que P5 en sentido contrario — allí una palanca barata
escondía un bloqueante, y aquí una fase cara esconde que el bloqueante está fuera.

⚠️ Nada de esto se hace hoy salvo P3. El runbook tiene una regla —una variable por
fase— y F1 responde a «¿funciona el motor, cifrado, en nuestro cluster?». Meter una
recreación del cluster por delante convierte cualquier fallo de F1 en cuatro causas
candidatas. P4 se hizo hoy porque era el bloqueante de F1, no porque tocara.