Uno de los errores más caros que veo en proyectos de Google Cloud es elegir el servicio de cómputo por costumbre y no por el tipo de carga. Una VM encendida 24/7 para una API que recibe 200 peticiones al día es tirar dinero. Y al revés: meter en Cloud Run un proceso que consume CPU sin parar puede salir más caro que una VM bien dimensionada.

En este post vamos a comparar Cloud Run y Compute Engine desde el punto de vista que más duele: la factura. Verás cómo cobra cada uno, cuándo gana cada opción y qué palancas tienes para recortar costes en ambos.

Cómo cobra cada servicio

Compute Engine: pagas por tiempo encendido

Compute Engine son máquinas virtuales clásicas. Pagas por cada segundo que la VM está encendida (con un mínimo de un minuto), da igual que esté al 90% de CPU o al 1%. A eso se suman el disco persistente, la IP externa y el tráfico de salida.

La clave: una VM ociosa cuesta exactamente lo mismo que una VM trabajando.

Cloud Run: pagas por uso (o por instancia)

Cloud Run ejecuta contenedores sin que gestiones servidores. Tiene dos modelos de facturación:

• Request-based (por petición): solo pagas CPU y memoria mientras se procesa una petición, más una pequeña tarifa por millón de peticiones. Si no hay tráfico, escala a cero y no pagas cómputo.
• Instance-based (por instancia): pagas mientras la instancia está viva, pero con una tarifa por segundo más baja. Pensado para servicios con tráfico constante o trabajo en segundo plano.

Además, Cloud Run tiene un free tier mensual por cuenta de facturación (en el modelo por petición: 2 millones de peticiones y unas 180.000 vCPU-segundo, que son unas 50 horas de CPU). Para APIs pequeñas o herramientas internas, es muy habitual que la factura de cómputo sea literalmente 0 €.

Tabla comparativa rápida

Aspecto	Cloud Run	Compute Engine
Modelo de cobro	Por uso real (o por instancia)	Por tiempo encendida
Escala a cero	Sí	No (salvo que la apagues tú)
Free tier	Generoso, mensual	Una e2-micro en ciertas regiones de EE. UU.
Tamaño máximo	Limitado (vCPU y RAM por instancia)	Prácticamente ilimitado
Gestión del SO	Ninguna	Toda tuya (parches, hardening…)
Estado local / disco	Efímero	Disco persistente
Descuentos	CUDs	CUDs, sustained use, Spot VMs
Ideal para	APIs, webs, jobs con tráfico variable	Cargas constantes, bases de datos, software legacy

Tres escenarios reales

1. API interna con poco tráfico → Cloud Run gana por goleada

Una API que usa tu equipo en horario laboral, con unas pocas miles de peticiones al día. En Compute Engine necesitas al menos una VM pequeña encendida todo el mes, más disco e IP. En Cloud Run con facturación por petición, lo más probable es que ni siquiera salgas del free tier.

Veredicto: Cloud Run. Ahorro cercano al 100% del cómputo.

2. Web con picos de tráfico → Cloud Run, bien configurado

Un e-commerce o un blog con picos en ciertos momentos del día. Con VMs tienes que dimensionar para el pico (y pagar ese tamaño 24/7) o montar un Managed Instance Group con autoescalado. Cloud Run escala solo, y fuera de los picos baja a cero o a las instancias mínimas que configures.

Veredicto: Cloud Run, vigilando la concurrencia y las min-instances (luego vemos por qué).

3. Proceso que consume CPU sin parar → Compute Engine

Un worker que procesa colas todo el día, una base de datos o un servicio con uso de CPU alto y constante. Aquí el «pago por uso» de Cloud Run deja de ser ventaja: pagas por segundo de CPU a una tarifa mayor que la de una VM equivalente, y encima una VM puede combinar descuentos por uso sostenido, CUDs o incluso Spot.

Veredicto: Compute Engine (o GKE si ya tienes clúster). Como regla práctica: si tu servicio está ocupado más o menos la mitad del tiempo o más, haz números con una VM.

Cómo calcular cuál te sale más barato

No te fíes de comparativas genéricas (tampoco de esta 😄). Haz tus números con tres datos:

1. Peticiones al mes y latencia media por petición.
2. vCPU y memoria que necesita tu contenedor.
3. Concurrencia: cuántas peticiones puede atender una instancia a la vez.

Con eso, el tiempo facturable aproximado en Cloud Run es:

segundos_facturables ≈ (peticiones_mes × latencia_media_s) / concurrencia_efectiva

Multiplica por tus vCPU y GiB, resta el free tier y compáralo con el precio mensual de la VM equivalente en la calculadora de precios de Google Cloud. Los precios cambian por región, así que calcula siempre con la tuya (por ejemplo europe-southwest1, Madrid).

8 trucos para reducir costes

En Cloud Run

1. Sube la concurrencia. Por defecto una instancia puede atender varias peticiones a la vez. Si tu app lo soporta, aprovecharlo reduce drásticamente las instancias necesarias:

gcloud run services update mi-api \
  --region=europe-southwest1 \
  --concurrency=80

2. Cuidado con min-instances. Mantener instancias calientes elimina los cold starts, pero se cobran aunque no haya tráfico. Antes de subirlo, prueba el startup CPU boost, que suele resolver el problema por mucho menos:

gcloud run services update mi-api \
  --region=europe-southwest1 \
  --cpu-boost \
  --min-instances=0

3. Ajusta CPU y memoria. Muchos servicios corren sobrados con 1 vCPU y 512 MiB, o incluso menos. Revisa las métricas de uso en Cloud Monitoring y baja hasta donde sea seguro.

4. Limpia Artifact Registry. Cada despliegue deja una imagen nueva. Configura una política de limpieza para no acumular gigas de imágenes antiguas que también facturan.

En Compute Engine

5. Haz caso a las recomendaciones de rightsizing. GCP analiza el uso de tus VMs y te sugiere tipos más pequeños. Puedes consultarlas desde la CLI:

gcloud recommender recommendations list \
  --project=mi-proyecto \
  --location=europe-southwest1-a \
  --recommender=google.compute.instance.MachineTypeRecommender

6. Usa Spot VMs para cargas tolerantes a interrupciones. Batch, CI runners, renderizados… Tienen descuentos muy grandes respecto al precio normal a cambio de que Google pueda reclamarlas:

gcloud compute instances create worker-batch \
  --zone=europe-southwest1-a \
  --machine-type=e2-standard-4 \
  --provisioning-model=SPOT \
  --instance-termination-action=STOP

7. Apaga lo que no se usa. Los entornos de desarrollo no necesitan estar encendidos por la noche ni el fin de semana. Usa instance schedules para arrancarlas y pararlas automáticamente:

gcloud compute resource-policies create instance-schedule horario-oficina \
  --region=europe-southwest1 \
  --vm-start-schedule="0 8 * * 1-5" \
  --vm-stop-schedule="0 20 * * 1-5" \
  --timezone=Europe/Madrid

gcloud compute instances add-resource-policies vm-dev \
  --zone=europe-southwest1-a \
  --resource-policies=horario-oficina

Solo con esto, una VM de desarrollo pasa de 730 horas al mes a unas 260. Es un recorte de casi dos tercios.

8. Compromete uso si es estable. Si sabes que vas a tener una carga base durante uno o tres años, los Committed Use Discounts (CUDs) rebajan bastante el precio. Existen tanto para Compute Engine como para Cloud Run.

Bonus: no te olvides de los costes «invisibles»

• Discos huérfanos: discos persistentes que quedaron tras borrar una VM. Búscalos con gcloud compute disks list --filter="-users:*".
• IPs estáticas sin usar: se cobran igualmente. Revísalas con gcloud compute addresses list --filter="status=RESERVED".
• Snapshots antiguos y logs con retención excesiva.
• Tráfico de salida (egress) entre regiones o hacia internet.

Y lo más importante: configura alertas de presupuesto en Billing desde el primer día. No reducen costes por sí mismas, pero evitan sustos a fin de mes.

Conclusión

No hay un ganador absoluto. Cloud Run suele ser más barato para cargas con tráfico variable o bajo, gracias al escalado a cero y al free tier. Compute Engine gana en cargas constantes e intensivas, sobre todo si combinas rightsizing, Spot y CUDs. La decisión correcta sale de mirar el patrón de uso de tu servicio, no de la costumbre.

Si trabajas con contenedores, repasa también Introducción a Docker. Y si tu siguiente paso es Kubernetes, tienes la guía de Kubernetes para principiantes.

En el próximo post del módulo compararemos GCP vs Azure para DevOps. ¿Cuánto te ahorraste tú moviendo algo a Cloud Run (o sacándolo de ahí)? Cuéntalo en los comentarios.