Google Compute Engine Explained: What It Is and When to Use It

Compute Engine in simple terms

Compute Engine lets you rent a server in Google’s data centre. You decide what kind of server (CPU count, memory size), what operating system runs on it, what disks are attached, and how it connects to the network. Google owns and maintains the physical machine. You own and manage everything that runs inside the VM.

When you create a VM, you get a private Linux or Windows server that you can connect to over SSH or RDP, install any software on, and configure however you need. It behaves exactly like a physical server — because from your perspective, it is one.

How Compute Engine works

Creating and running a VM follows a straightforward sequence:

1. Choose a machine type — this sets the vCPU count and memory. See Machine Types Explained for guidance on picking the right size.
2. Choose an OS image — Debian, Ubuntu, RHEL, Windows Server, or a custom image you have built. See VM Images for how images work.
3. Choose a region and zone — the physical location where the VM runs. See Regions and Zones to understand the difference.
4. Attach storage — a boot disk is required; additional data disks are optional. See Persistent Disks for disk types and sizing.
5. Connect to a VPC and subnet — the VM joins your private network and gets an internal IP address. See VPC Networks Explained for networking basics.
6. Assign a service account — the identity the VM uses to call GCP APIs. See Service Accounts for how to set one up with the right permissions.
7. Start the VM and pay while it runs — billing is per second with a 1-minute minimum. Stopping the VM stops compute billing.

You can connect over SSH within 30 to 60 seconds of the VM booting. From that point it behaves like any Linux server: install packages, configure services, and manage files using standard tools.

When to use Compute Engine

Compute Engine is the right choice when you need OS-level control or when your workload genuinely does not fit a serverless model.

• Lift-and-shift migrations — moving an existing on-premises workload to GCP without rewriting it. If it runs on a Linux or Windows server today, it runs on a Compute Engine VM.
• Legacy applications — software that depends on specific OS versions, kernel modules, or system libraries that a container cannot satisfy.
• Windows Server workloads — Windows-based apps, .NET Framework services, and anything that needs a full Windows environment with RDP access.
• Self-managed databases — running Postgres, MySQL, MongoDB, or Redis directly on a VM when you need control over configuration, tuning, or storage layout that a managed database does not expose.
• Long-running background services — daemons, queue workers, or batch jobs that run indefinitely and do not fit Cloud Run’s HTTP request model or Cloud Functions’ execution time limits.
• Custom networking or low-level access — workloads that need to bind to specific ports, use non-HTTP protocols, or configure network interfaces in ways that serverless platforms do not support.
• GPU workloads — machine learning training, video processing, and simulation jobs that need NVIDIA GPUs attached directly to the VM.

When Compute Engine is not the best choice

Compute Engine requires you to manage the VM: OS updates, security patches, disk resizing, and monitoring. For many workloads, a managed service removes that overhead entirely.

• Stateless HTTP services and APIs — if your app handles HTTP requests and holds no local state between requests, Cloud Run scales to zero, removes all VM management, and is almost always cheaper at variable traffic levels.
• Event-driven functions — short tasks triggered by a Pub/Sub message, HTTP event, or Cloud Storage upload are a better fit for Cloud Functions.
• Container orchestration at scale — if you need Kubernetes features like custom scheduling, stateful sets, or advanced networking across many containers, GKE provides a managed control plane without requiring you to manage individual VMs.
• Managed databases — Cloud SQL, Cloud Spanner, and Firestore remove the operational burden of database administration. Only run a database on Compute Engine when a managed option genuinely cannot meet your requirements.

Compute Engine vs Cloud Run vs GKE

These three options cover most GCP compute workloads. Here is how they compare in plain terms:

Quick guidance for beginners: start with Cloud Run for new web services and APIs. Use Compute Engine when the workload needs OS control, persistent local state, or cannot be containerised. See the full decision guide at Cloud Run vs Compute Engine or the three-way breakdown at Choosing Between Cloud Run, GKE, and Compute Engine.

What you choose when creating a VM

Every Compute Engine VM requires five core settings at creation time:

Firewall rules are defined at the VPC level and control which ports are reachable on the VM’s IP. By default, inbound traffic is blocked unless you explicitly open a port. For most beginner setups, you open port 22 for SSH and the port your application listens on.

Compute Engine pricing and billing basics

Pay as you go

The default pricing model. You are billed per second with a 1-minute minimum per VM start. No commitment is required. Use this for short-lived experiments, development VMs, and workloads where runtime is unpredictable.

Sustained use discounts

Applied automatically with no action required. If a VM runs for more than 25% of a calendar month, GCP applies incremental discounts to the hours beyond that threshold. A VM running continuously for a full month saves roughly 30% compared to the base hourly rate. No sign-up or configuration is needed — it happens automatically.

Committed use discounts

You commit to a specific vCPU and memory allocation for 1 or 3 years in exchange for a significant discount — up to 57% for general-purpose machine types. Commitments apply to resource capacity across matching VMs in a region, not to specific VM instances. Best for stable production workloads with predictable resource needs.

For additional savings on fault-tolerant batch workloads, see Preemptible and Spot VMs, which offer up to 91% off the on-demand price in exchange for the VM being reclaimed by GCP with 30 seconds notice.

Stopped VM costs

For a deeper look at reducing costs, see Compute Engine Cost Optimisation.

What a typical beginner workflow looks like

Most beginners follow the same sequence when using Compute Engine for the first time:

1. Create a VM — pick a small machine type like e2-micro or e2-small, choose Debian or Ubuntu, and leave other settings at defaults to start.
2. Connect over SSH — run gcloud compute ssh or use the SSH button in the Cloud Console. No key management is needed if OS Login is enabled.
3. Install software — run apt install, configure your application, or set up a web server. The VM behaves exactly like a normal Linux server.
4. Test the application — open the relevant port in firewall rules and access the app via the VM’s external IP address.
5. Stop the VM when finished — compute billing stops immediately. The disk and its data remain.
6. Snapshot or delete when no longer needed — take a snapshot to preserve the disk state cheaply before deleting, or delete the VM and disk entirely if you are done.

For a step-by-step walkthrough of this entire flow, see Creating Your First VM.

Creating and managing VMs with gcloud

The following commands cover the full lifecycle of a basic VM. Each flag is written explicitly so you can see exactly what is being configured.

# Create a basic VM
gcloud compute instances create my-first-vm \
  --zone=europe-west2-a \
  --machine-type=e2-medium \
  --image-family=debian-12 \
  --image-project=debian-cloud \
  --boot-disk-size=20GB

# List running VMs
gcloud compute instances list

# SSH into the VM
gcloud compute ssh my-first-vm --zone=europe-west2-a

# Stop the VM (compute billing stops; disk billing continues)
gcloud compute instances stop my-first-vm --zone=europe-west2-a

# Delete the VM and its boot disk
gcloud compute instances delete my-first-vm --zone=europe-west2-a

The —image-family flag selects the latest image from that family automatically. Using a family name rather than a specific image version means you always get the most recently patched OS build without having to track individual image names.

Cutting dev VM costs with instance schedules

A development VM that runs around the clock costs roughly three times more than one that runs only during business hours. Instance schedules start and stop VMs automatically on a cron-based pattern — no manual action required.

# Create a schedule: start at 08:00, stop at 19:00, Monday to Friday
gcloud compute resource-policies create instance-schedule dev-hours \
  --region=europe-west2 \
  --vm-start-schedule="0 8 * * 1-5" \
  --vm-stop-schedule="0 19 * * 1-5" \
  --timezone="Europe/London"

# Attach the schedule to a VM
gcloud compute instances add-resource-policies my-dev-vm \
  --zone=europe-west2-a \
  --resource-policies=dev-hours

An 11-hour weekday window runs approximately 220 hours per month versus 720 hours for a VM running 24/7 — roughly a 70% reduction in compute cost. Disk storage continues to bill during off-hours, but disk costs are a small fraction of compute costs for most VM sizes.

The instance metadata server

Every Compute Engine VM has access to a built-in metadata server at http://metadata.google.internal. This endpoint exposes configuration about the VM itself: its project ID, zone, service account credentials, and any custom key-value pairs you attached at creation time. Applications query this endpoint instead of hardcoding environment-specific values into config files.

This is how your application knows which project it is running in, how it gets a short-lived access token to call GCP APIs without storing a key file, and how startup scripts can read custom variables you passed in at launch time.

# Get the project ID from inside the VM
curl -s -H "Metadata-Flavor: Google" \
  "http://metadata.google.internal/computeMetadata/v1/project/project-id"

# Get the current zone
curl -s -H "Metadata-Flavor: Google" \
  "http://metadata.google.internal/computeMetadata/v1/instance/zone"

# Get a short-lived access token for the attached service account
curl -s -H "Metadata-Flavor: Google" \
  "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token"

Compute Engine best practices for beginners

1. Start with the smallest viable machine type. Use e2-micro or e2-small for learning and testing. Resize later based on actual usage. Oversized VMs waste money every hour they run. See Machine Types Explained for guidance on right-sizing.

2. Use a dedicated service account with least-privilege roles. The default Compute Engine service account has the Editor role on the whole project — far more permission than any application needs. Create a dedicated account with only the roles your workload actually requires. See Service Accounts.

3. Use OS Login for SSH access. OS Login ties SSH access to IAM instead of requiring you to manage SSH key files manually. It is simpler, more auditable, and easier to revoke when team members leave. See OS Login Explained.

4. Schedule snapshots for stateful disks. Persistent disks are durable but they are not a backup. A snapshot policy automatically captures disk state on a schedule so you can recover from data corruption or accidental deletion. See Persistent Disks.

5. Avoid single-VM production designs. A single VM is a single point of failure. For production workloads, use a Managed Instance Group across multiple zones so that a zone outage is handled automatically without manual intervention.

6. Monitor idle instances and set budget alerts. VMs that are running but not handling load still bill at full rate. Set up a budget alert and use the recommendations in the cost optimisation guide to identify and clean up idle resources.