Cloud Run vs Compute Engine in GCP: Cost, Scaling, and When to Use Each

Simple explanation

Cloud Run is a serverless container platform. You give Google a container image. Google runs it, scales it, and shuts it down when nobody is using it. You never see a server, never patch an OS, and never pay for idle time.

Compute Engine is a virtual machine service. You pick a machine type, choose an operating system, attach disks, and manage the entire stack. The VM runs until you stop it, and you pay for every second it is on regardless of whether it handles traffic.

How the decision works

The Cloud Run vs Compute Engine choice comes down to five trade-offs:

Control vs ops overhead. Compute Engine gives you root access to the machine. You choose the OS, install any software, and configure networking at the kernel level. Cloud Run removes that control, along with all the work that comes with it. If you do not need root access, Cloud Run saves significant operational time.

Scaling model. Cloud Run scales automatically from zero to thousands of instances based on incoming requests. Scaling behaviour is built in. You set minimums and maximums, and the platform handles the rest. Compute Engine requires managed instance groups with autoscaling policies to get similar behaviour, and even then it cannot scale to zero.

Billing model. Cloud Run charges per 100ms of execution plus memory. Zero traffic means zero cost. Compute Engine charges per second the VM is running regardless of utilisation. At low traffic, Cloud Run wins easily. At sustained high utilisation, Compute Engine with committed use discounts can be 40-60% cheaper.

Workload shape. Stateless, request-driven workloads fit Cloud Run naturally. Stateful workloads like databases, caches, and message queues need persistent storage that Cloud Run cannot provide. Cloud Run’s filesystem is writable but ephemeral: data written to disk does not survive instance recycling.

Startup speed. Cloud Run cold starts take 1-3 seconds. Compute Engine VMs take 30-90 seconds to boot. For services that need to handle sudden traffic spikes, Cloud Run responds far faster.

Direct comparison table

When Cloud Run is the better choice

Cloud Run wins when your workload is stateless, request-driven, and does not need OS-level control.

• REST and GraphQL APIs with variable or unpredictable traffic. Scale to zero between requests and pay nothing when idle.
• Webhook receivers that process events from external services or Pub/Sub triggers.
• Microservices that need to scale independently without managing infrastructure for each one.
• Scheduled jobs and batch processing using Cloud Scheduler with Cloud Run Jobs.
• Development and staging environments where zero idle cost avoids wasting budget on environments nobody is using overnight.
• Internal tools and dashboards with low, intermittent traffic.

Cloud Run deploys in under a minute and gives you an HTTPS URL immediately. There is no load balancer to configure, no firewall rules to write, and no TLS certificate to provision.

When Compute Engine is the better choice

Compute Engine wins when you need persistent state, full machine control, or sustained high-throughput compute.

• Self-managed databases (PostgreSQL, MySQL, Redis, Elasticsearch) that need persistent disk with consistent IOPS. Cloud Run cannot provide this. Use Compute Engine or a managed service like Cloud SQL.
• Legacy applications that cannot be containerised and need a specific OS environment.
• GPU-heavy workloads that require custom driver installation, persistent model storage on local SSD, or long-running training jobs. While Cloud Run supports GPUs for inference, Compute Engine gives you broader GPU selection and full VM-level tuning.
• High-utilisation services running above 50-70% sustained CPU where committed use discounts make VMs significantly cheaper.
• Custom networking requiring specific routes, kernel-level parameters, or software-defined networking configurations.
• Build agents and CI runners that need root access, arbitrary software installation, and full OS control.

Use managed instance groups with Compute Engine to get auto-healing and rolling updates. Even for a single VM, an instance group adds self-healing without extra cost.

Common real-world scenarios

APIs with uneven traffic

Use Cloud Run. A product API that handles 50 requests per second during business hours and near zero at night is a textbook Cloud Run workload. You pay only during active request handling, and scaling is automatic in both directions.

Internal services

Use Cloud Run. Internal admin dashboards, Slack bots, and reporting tools typically have low, intermittent traffic. Cloud Run with Serverless VPC Access can reach private resources without exposing anything to the public internet.

Scheduled jobs and background processing

Use Cloud Run Jobs. Nightly data exports, report generation, and cleanup tasks run as Cloud Run Jobs triggered by Cloud Scheduler. The job starts, runs to completion, and costs nothing between runs.

Databases and stateful applications

Use Compute Engine or a managed service. Self-managed databases need persistent disks and consistent IOPS. Cloud Run’s filesystem is writable but ephemeral, so it is not a substitute for real storage. For managed options, consider Cloud SQL or another managed storage service.

Legacy applications

Use Compute Engine. Applications that depend on a specific OS, require kernel modules, or were never designed to run in a container belong on a VM. Containerising these applications may be a long-term goal, but forcing them into Cloud Run causes more problems than it solves.

ML inference and GPU workloads

It depends. Cloud Run now supports NVIDIA GPUs, which works well for stateless inference behind an API. For workloads that need custom driver tuning, persistent model storage on local SSD, training jobs, or broader GPU selection, Compute Engine gives you full control. For GPU workloads at scale, GKE is also worth evaluating.

Always-on services with high utilisation

Use Compute Engine. A service running at 70%+ CPU utilisation around the clock costs less on a Compute Engine VM with a committed use discount than on Cloud Run’s per-request billing. Use Spot VMs for fault-tolerant high-utilisation workloads to save even more.

CI runners and build agents

Use Compute Engine. Build agents need root access, arbitrary software installation, and often large local disk for caches and build artifacts. These requirements exceed what Cloud Run can provide.

Cost comparison

Low traffic: 5 million requests/month

Assumptions: 200ms average duration, 256 MB memory, us-central1.

• Cloud Run: ~$2-5/month (within or just above the free tier)
• Compute Engine (e2-micro, always on): ~$7/month

Cloud Run wins. The free tier covers most of this workload, and even above it the per-request cost is low.

High traffic: 500 million requests/month

Assumptions: 200ms average duration, 256 MB memory, sustained utilisation, us-central1.

• Cloud Run: ~$200-400/month
• Compute Engine (e2-standard-4, 1-year CUD): ~$80-100/month

Compute Engine wins at sustained high utilisation. The committed use discount reduces the per-hour cost by 37%, and because you are paying for the machine anyway, high utilisation means you get more value per dollar.

The crossover

The break-even point where Compute Engine becomes cheaper is typically around 50-70% sustained CPU utilisation on equivalent resources. Below that threshold, Cloud Run’s pay-per-use billing wins. Above it, committed use discounts on Compute Engine pull ahead. For a deeper look at reducing Cloud Run spend, see Cloud Run cost optimisation.

How it works in practice

After deploying to Cloud Run

You push a container image to Artifact Registry and run a single deploy command. Within seconds, Cloud Run gives you an HTTPS URL. Traffic arrives, instances spin up automatically. Traffic drops, instances spin down. At zero traffic, you pay nothing. Scaling, load balancing, and TLS are handled for you. Your operational work is limited to building and pushing container images, setting environment variables, and monitoring logs and metrics.

After deploying to Compute Engine

You create a VM from an instance template or manually configure one. The VM boots in 30-90 seconds. You SSH in, install your application, configure a process manager, set up monitoring agents, and manage firewall rules. Scaling means creating a managed instance group with an autoscaling policy. Updates mean rolling out new instance templates. You manage OS patches, disk snapshots, and startup scripts. The trade-off: full control in exchange for ongoing operational work.

Where GKE fits

Best practices

• Default to Cloud Run for new stateless services. The operational overhead of Compute Engine is rarely justified for request-driven workloads without persistence requirements.
• Set both min and max instances on Cloud Run. A minimum of 1 eliminates cold starts for user-facing services. A maximum caps runaway scaling and costs.
• Use managed instance groups for Compute Engine, even for single VMs. Auto-restart and health checks protect against failures without manual intervention.
• Use Serverless VPC Access when Cloud Run needs to reach private resources. Connect to Cloud SQL, Redis, or internal VMs through a VPC connector rather than exposing services to the public internet.
• Use IAM service accounts, not API keys. Both Cloud Run and Compute Engine should authenticate to other GCP services via attached service accounts.
• Monitor both services from day one. Cloud Run metrics are built in. Compute Engine needs the Ops Agent installed for application-level telemetry.
• Evaluate cost at your actual utilisation level. Use the Cloud Run Cost Calculator and GCP Pricing Calculator to compare at your real traffic volume, not hypothetical extremes.