¿Ingresos Pasivos? Yo monté un gasto pasivo!
Estos son mis propios errores y conclusiones después de meses explorando GCP. La nube no tiene piedad.
Sea donde sea que mires, todo el mundo habla de lo que la IA puede hacer — automatizar procesos, generar contenido, analizar datos, tomar decisiones. Pero nadie está hablando de lo que cuesta mantenerla encendida.
Cualquier sistema mínimamente serio que quieras poner en marcha hoy — un agente de IA, un pipeline de datos, una API que llame a un modelo — necesita infraestructura cloud detrás. Servidores, bases de datos, servicios de orquestación, redes de comunicación entre componentes. Y toda esa infraestructura tiene un taxímetro que no para nunca, aunque tu sistema no esté haciendo absolutamente nada en ese momento.
Este es el coste invisible que nadie está calculando bien. Y lo digo con datos propios sobre la mesa.
Escribo esto desde un hotel. Y hay algo poéticamente exacto en esa circunstancia: igual que un hotel te cobra cada noche aunque no salgas de la habitación, o ni siquiera estés en la habitación, Google Cloud te cobra cada hora que tienes un servicio levantado aunque no procese ni una sola petición. La nube no duerme. La nube no tiene piedad. Y la nube, desde luego, no hace el check-out por ti.
Lo que vais a leer no es teoría ni un artículo de marketing sobre eficiencia cloud. Son mis propios datos de facturación, mis propios errores, y las conclusiones que he sacado después de meses explorando Google Cloud Platform como laboratorio personal de aprendizaje. Si estáis construyendo cualquier cosa con IA — aunque sea un proyecto pequeño, aunque sea solo para aprender — este artículo es para vosotros.
El free tier: la mejor trampa con buenas intenciones
Google Cloud Platform, como AWS o Azure, ofrece créditos gratuitos para atraer nuevos usuarios. El trial estándar da 300 dólares durante 90 días. Los programas para startups llegan a 200.000 dólares según el tier. La mecánica es siempre la misma: recibes un saldo de créditos, cada servicio que usas lo descuenta de ese saldo, y mientras haya créditos tu factura muestra cero euros.
Suena perfecto. Y lo es para aprender. El problema es la ilusión que crea: que los servicios son gratuitos. No lo son. Los créditos los están pagando. Y cuando se agoten — y siempre se agotan — la factura real llegará con todos los servicios que hayas dejado corriendo.
Esto es especialmente relevante si estáis usando la nube para experimentar con IA. Un modelo de lenguaje que llamáis desde una API, un pipeline que procesa datos para alimentar un sistema de recomendación, un agente que ejecuta tareas de forma autónoma — todo eso necesita infraestructura, y esa infraestructura tiene costes que se acumulan silenciosamente mientras los créditos los absorben.
El salto que nadie espera: de €0,22 a €30,29 en un mes
Mi cuenta pasó de gastar €0,22 en diciembre a €30,29 en enero. Un incremento del 13.724% en un solo mes. Los créditos lo cubrieron todo — el coste neto fue €0,00. Pero la arquitectura real que tenía levantada costaba eso cada mes, y ese ticker seguía corriendo.
[GRÁFICO 1 — Evolución del coste bruto]
Ese salto no fue un accidente ni un error puntual. Fue el resultado natural de hacer exactamente lo que hay que hacer para aprender tecnología en serio: ir probando servicios, explorar capacidades, desplegar pipelines, probar configuraciones. El problema no fue explorar. El problema fue no tener el hábito del check-out: revisar periódicamente qué tengo levantado y si sigue siendo necesario.
Aquí está el desglose de lo que tenía encendido y cuánto costaba cada pieza:
[GRÁFICO 2 — Desglose por servicio]
Cinco servicios. Todos cobrando. Ninguno haciendo nada útil la mayor parte del tiempo.
Los culpables: qué es cada servicio y por qué cobra sin hacer nada
Antes de hablar de soluciones, os explico brevemente qué hace cada uno de estos servicios. Porque el primer problema es que la mayoría de la gente los activa sin entender bien para qué sirven ni cuándo tienen sentido.
Kubernetes Engine Autopilot · €8,59/mes
¿Qué es Kubernetes? Es el sistema que usan las grandes empresas para gestionar muchas aplicaciones a la vez en la nube. Imaginad que tenéis diez servicios diferentes corriendo — un servicio de usuarios, un servicio de pagos, un servicio de notificaciones — y necesitáis que se comuniquen entre sí, que escalen cuando hay más carga, que se reinicien si fallan. Kubernetes hace todo eso automáticamente.
El problema: Kubernetes tiene un coste fijo de gestión — lo que se llama el “control plane” — que se paga aunque no haya ningún servicio corriendo dentro. Es como alquilar un almacén enorme con un portero 24 horas y pagar el alquiler completo aunque el almacén esté vacío.
Cuándo tiene sentido: cuando tenéis 10 o más servicios interdependientes, un equipo de ingeniería de al menos 5 personas, y necesidades complejas de despliegue. Para un laboratorio personal o un proyecto pequeño: es un Ferrari para ir al supermercado.. de debajo de tu casa.
La alternativa correcta: Cloud Run. Desplegáis un servicio, escala automáticamente, y pagáis solo cuando hay peticiones activas. Sin peticiones = €0,00.
Cloud Dataflow · €5,85/mes
¿Qué es Dataflow? Es el servicio de GCP para procesar grandes volúmenes de datos. Pensad en él como una cadena de montaje para información: los datos entran por un lado, se transforman, se limpian, se combinan con otros datos, y salen por el otro lado ya procesados. Los bancos lo usan para detectar fraude en tiempo real. Las plataformas de streaming lo usan para procesar millones de eventos por segundo.
El problema: cuando se configura en modo “streaming” — que es el modo en tiempo real — mantiene trabajadores activos las 24 horas esperando que lleguen datos. Aunque no llegue ninguno. Mi pipeline estuvo semanas sin procesar un solo registro, y los trabajadores seguían ahí, esperando, cobrando.
Cuándo tiene sentido el streaming: cuando el volumen de datos es constante y elevado, y la latencia importa — necesitáis procesar eventos en segundos, no en minutos. Para todo lo demás, un proceso batch programado que se ejecuta cuando hay datos y luego se apaga es entre 10 y 20 veces más barato.
Networking cross-region · €5,42/mes
¿Qué es el tráfico cross-region? Cuando dos servicios en la nube se comunican entre sí, el tráfico de red dentro de la misma región geográfica es prácticamente gratuito. Pero si un servicio está en Europa y el otro en Estados Unidos — aunque sean del mismo proveedor — cada mensaje que pasa entre ellos tiene un coste de entre €0,08 y €0,12 por gigabyte.
El problema en mi caso: tenía servicios desplegados en europe-west1 (Bélgica) y en us-central1 (Iowa) que se llamaban entre sí continuamente. Cada petición cruzaba el Atlántico. Y yo pagaba por ese viaje.
La solución: consolidar todos los servicios en la misma región. Simple, gratuito de implementar, y ahorra casi todo ese coste de golpe.
Compute Engine con n8n · €2,09/mes
¿Qué es n8n? Es una herramienta de automatización de tareas, similar a Zapier o Make, pero que instaláis en vuestro propio servidor. Permite conectar aplicaciones entre sí y automatizar procesos: “cuando llegue un email con estas características, guarda los datos en una hoja de cálculo y manda una notificación por Slack”. Muy útil para automatizar flujos de trabajo sin escribir código.
¿Qué es Compute Engine? Es simplemente una máquina virtual en la nube. Como tener un ordenador encendido en un servidor de Google, accesible desde cualquier parte.
El problema: la VM factura por hora de existencia, no por uso real. Mi n8n no había ejecutado ningún workflow en 9 días. La VM seguía encendida. La factura llegaba igual. Es la definición exacta de gasto pasivo: un recurso que consume dinero sin producir ningún valor mientras está en reposo.
La alternativa: migrar n8n a Cloud Run con “scale-to-zero”. Cuando no hay workflows ejecutándose, la instancia se apaga completamente y el coste es €0,00. Cuando llega un trigger, arranca en unos pocos segundos y ejecuta. De €2/mes a €0,10/mes.
Cloud Monitoring · €2,05/mes
¿Qué es Cloud Monitoring? Es el servicio de observabilidad de GCP — el panel de control que os muestra métricas de rendimiento, logs de lo que está pasando en vuestros sistemas, y alertas cuando algo falla. Muy útil cuando tenéis sistemas en producción que necesitáis monitorizar.
El problema en mi caso: cuando activé Kubernetes, Cloud Monitoring empezó automáticamente a recoger métricas del cluster — aunque yo no hubiera configurado ninguna alerta ni necesitara esas métricas. Nadie me avisó. El coste apareció en la factura como un cargo derivado que no había pedido explícitamente. Todo el tiempo cobrando por monitorizar un cluster que estaba vacío.
La lección: algunos servicios activan automáticamente otros servicios relacionados. Antes de levantar algo, conviene revisar qué arrastra consigo.
La magia (y la trampa) de los créditos
Lo que hace este problema especialmente invisible es que los créditos absorben todo. En mi caso, €30,29 de gasto bruto en enero → €0,00 de coste neto. Y acumulado entre los meses de uso, los créditos me han ahorrado €77,79. Es cierto que son importes pequeños en general, pero ese es el tema, que como cualquier pago repetitivo queda escondido en el conjunto de gastos mensuales y la tendencia es seguir pagando algo que no necesitas.
Kubernetes con cobertura del 99%. Dataflow con cobertura del 95%. Networking con cobertura del 95%. El único servicio sin cobertura: Compute Engine, la VM con n8n. El único que pagaba de mi bolsillo era precisamente el más fácil de optimizar.
Los créditos no son dinero gratis para siempre. Son tiempo de aprendizaje con red de seguridad. El problema es que esa red oculta el coste real y anula el incentivo para optimizar. Cuando se agoten — y siempre se agotan — la arquitectura que teníais seguirá siendo igual de cara, pero ahora la pagaréis vosotros.
Lo que cuesta vs. lo que podría costar
La migración que estoy haciendo va en una dirección clara: reemplazar todo lo que cobra por existir con servicios que solo cobran por ejecutar.
[GRÁFICO 3 — Antes y después por servicio]
De €24/mes a ~€1,40/mes. Una reducción del 94%. Sin perder ninguna funcionalidad. Todo el cambio es arquitectónico: reemplazar servicios con coste fijo por servicios con coste variable ligado al uso real.
La pregunta que deberías hacerte antes de levantar cualquier servicio
¿Escala a cero, o sigue cobrando aunque no lo use?
Esta es la pregunta más importante. Cloud Run escala a cero: sin peticiones, sin factura. Una VM de Compute Engine nunca escala a cero: existe, luego cobra. Kubernetes tampoco. Cloud SQL tampoco. Dataflow en modo streaming tampoco.
Antes de activar cualquier servicio cloud, especialmente si estáis construyendo algo con IA, haceos tres preguntas:
Primera: ¿sé exactamente para qué sirve este servicio y qué problema concreto resuelve ahora mismo? No “podría ser útil” sino ¿para qué sirve ahora? Concreto.
Segunda: ¿sé cuándo y cómo voy a apagarlo? Todo servicio necesita tener una condición de apagado. “Lo dejo corriendo por si acaso” es la frase más cara de la nube.
Tercera: ¿escala a cero o sigue cobrando en idle? Si no puede escalar a cero, necesito justificar activamente por qué vale la pena pagar por su existencia.
Los labs: aprende tocando, no leyendo
Os dejo tres laboratorios interactivos en IAxLabs (https://www.iaxlabs.com/) que construí para que podáis experimentar con todo esto sin necesidad de tener una cuenta de GCP ni arriesgar dinero real.
Lab 1 · El taxímetro del gasto pasivo Un panel con todos los servicios que tenía encendidos. Podéis activarlos y apagarlos con un botón para activar/desactivar y ver en tiempo real cuánto está corriendo el contador — por segundo, por hora, por mes, por año. El objetivo es visceral: que se vea físicamente lo que cuesta tener algo encendido sin hacer nada. El check-out tiene un botón.
Lab 2 · CloudBurn Simulator 3000 Sois el CTO de una startup con créditos de GCP y 10 meses de decisiones por delante. Cada mes os plantea un dilema real — el Project Manager que pregunta por qué tenéis Kubernetes, el dev que amenaza con dimitir, los créditos que se acaban. Hay decisiones que parecen buenas pero no lo son. El objetivo es aprender a identificar las trampas antes de caer en ellas en la vida real.
Lab 3 · Migrar n8n de VM a Cloud Run La migración real, paso a paso. Desde exportar los datos de la VM hasta el deploy en Cloud Run con scale-to-zero, pasando por la base de datos externa, los secretos, y el problema de los workflows con cron. En cada fase hay una pregunta de decisión — algunas con trampa — y la explicación de por qué cada elección tiene consecuencias. El objetivo es que cuando lo hagáis de verdad, ya lo hayáis hecho antes aquí.
Finalmente, os dejo en IAxLabs un cuestionario para ver si se han afianzado los conocimientos. No hace falta tener certificación en MLGCP Engineer, sólo sentido común -un poco-
Check-out
La nube es como ese hotel donde estoy escribiendo esto: cómoda, potente, con todos los servicios disponibles y funcionando perfectamente. Pero si no hacéis el check-out, os siguen cobrando. Y a diferencia del hotel, la nube no os manda un recordatorio por la mañana, no llama recepción, no pone una nota bajo la puerta.
La factura llega. Siempre llega. La única variable es si cuando llegue os sorprende o ya la esperabais.
Y si estáis construyendo algo con IA — aunque sea pequeño, aunque sea solo para aprender — calculad el coste de la infraestructura que necesitáis antes de empezar. No después.
Haced el check-out.
https://www.iaxlabs.com/#cloud-costs
¿Os animáis a probar los labs? Están en www.iaxlabs.com, si veis algún error, por favor avisad con un comentario o correo.
Si tenéis preguntas sobre vuestra propia arquitectura cloud, el Q&A del tema os puede dar respuestas concretas.