Google Compute Engine: IaaS Virtual Machines on GCP

Q: GCE or a higher-level GCP service?

Use GCE when you need OS-level control, specific software, GPUs, or lift-and-shift of existing servers. Use Cloud Run (serverless containers), Cloud Functions (FaaS), or GKE (Kubernetes) when you don't want to manage servers. GCP pushes toward these managed options; reach for GCE when you have a concrete reason to own the VM.

Q: What is live migration and why does it matter?

Google can move a running VM to a different physical host during maintenance without rebooting or stopping it — your workload continues uninterrupted through host events that would require a reboot on other clouds. It reduces maintenance-related downtime, a genuine operational advantage of GCE, especially for workloads sensitive to restarts.

Q: How do GCE VMs access other GCP services securely?

Via service accounts — a VM runs as a service account identity that GCP services authorize, with credentials managed automatically and no keys stored on the VM. It's the equivalent of AWS IAM roles / Azure managed identities. Scope service accounts to least privilege rather than using the broadly-permissioned default.

Google Compute Engine

Google Compute Engine (GCE) is Google Cloud's infrastructure-as-a-service compute — virtual machines running on Google's global infrastructure, with full control over the OS and configuration. It's GCP's equivalent of AWS EC2 and Azure Virtual Machines: the flexible, full-control compute you use when you need a specific OS, custom software, or capabilities that higher-level GCP services (Cloud Run, Cloud Functions, GKE) abstract away.

GCE carries a few Google-distinctive features worth knowing: live migration (VMs keep running through host maintenance, no reboot), per-second billing, sustained-use and committed-use discounts that apply automatically, and famously flexible custom machine types. As with any IaaS, the control comes with ownership — you patch, secure, scale, and manage availability yourself.

TL;DR

GCE is IaaS: virtual machines with full OS control (Linux/Windows), running on Google's infrastructure — you own everything above the hypervisor.
Pick a machine type (predefined families E2/N2/C3 for general/balanced/compute, or custom machine types with exactly the vCPU/RAM you want).
Managed Instance Groups (MIGs) provide autoscaling, health-checked self-healing, and rolling updates behind a load balancer — the elasticity/HA primitive.
Google-distinctive: live migration (no downtime for host maintenance), per-second billing, automatic sustained-use discounts, and preemptible/Spot VMs (very cheap, interruptible).
Runs in a VPC with firewall rules; uses service accounts for keyless access to other GCP services (like AWS IAM roles).
Choose GCE when you need OS-level control; prefer Cloud Run/Functions/GKE when you don't want to manage servers.

Core Concepts

Machine Types

GCE offers predefined machine families plus a signature flexibility:

The Google-distinctive option is custom machine types — instead of choosing from fixed sizes, you specify exactly the vCPUs and memory you need, avoiding paying for capacity you won't use (e.g., a workload wanting 6 vCPU and 20 GB RAM doesn't have to round up to a fixed size). Right-sizing directly controls cost.

Scaling and Availability: Managed Instance Groups

A single VM is a single point of failure. Production resilience comes from Managed Instance Groups (MIGs) — a group of identical VMs (from an instance template) that provide:

Autoscaling — add/remove VMs based on CPU, load-balancer utilization, or custom metrics.
Self-healing — health checks recreate failed instances automatically.
Rolling updates — deploy new versions gradually across the group.
Regional distribution — spread across zones for high availability.

Behind a Cloud Load Balancer, a regional MIG is the standard resilient-compute pattern — analogous to EC2 Auto Scaling groups and Azure VM Scale Sets.

Google-Distinctive Features

A few GCE features stand out:

Live migration — Google can move a running VM to another host for maintenance without rebooting it; your VM keeps running through host events that would require a reboot on other clouds. Reduces maintenance-related disruption.
Per-second billing with a one-minute minimum — you pay for exactly the time used.
Sustained-use discounts — automatic discounts for VMs that run a large fraction of the month, no commitment needed.
Committed-use discounts — deeper savings for 1–3 year commitments (like reserved instances).
Spot/Preemptible VMs — up to ~90% cheaper, but can be reclaimed with short notice — ideal for fault-tolerant batch, CI, and stateless workloads.

Networking and Identity

VMs live in a VPC (Google's virtual network) — notably, GCP VPCs are global (subnets are regional, but the VPC spans regions), simplifying multi-region networking. Firewall rules control traffic; keep databases and app servers in private subnets.
Service accounts give a VM an identity to access other GCP services (Cloud Storage, etc.) without stored keys — the equivalent of AWS IAM roles / Azure managed identities. Scope them to least privilege.

GCE vs AWS EC2 vs Azure VMs

The three are directly comparable IaaS offerings. GCE's differentiators are live migration (less maintenance disruption), custom machine types (precise sizing), and automatic sustained-use discounts (savings without commitment). AWS leads on ecosystem breadth; Azure on Microsoft/enterprise integration; GCP often appeals for networking (global VPC), data/ML integration, and these operational conveniences. All are solid IaaS.

Common Mistakes

Single VM in Production

One VM fails with its host or zone. Use a regional Managed Instance Group across zones behind a load balancer for autoscaling and self-healing. A lone VM is fine for dev, not for anything needing uptime. See high availability.

Not Using Spot/Sustained-Use Discounts

Running on-demand VMs 24/7 without leveraging automatic sustained-use discounts, committed-use discounts for steady workloads, or Spot VMs for interruptible work leaves significant savings on the table. GCE's discount model rewards matching pricing to workload. See cloud costs.

Oversized VMs Instead of Custom Types

Picking an oversized predefined machine type "to be safe" wastes money. Use custom machine types to allocate exactly the vCPU/RAM needed, and right-size based on actual utilization metrics.

Open Firewall Rules and Public IPs

Exposing SSH (22), RDP (3389), or databases to 0.0.0.0/0 invites brute-force attacks. Keep VMs in private subnets, use Identity-Aware Proxy (IAP) for keyless SSH without public IPs, and scope firewall rules tightly. Same VPC security discipline as any cloud.

Overprivileged Service Accounts

Attaching the default service account with broad scopes means a compromised VM has wide GCP access. Create dedicated service accounts scoped to least privilege for each workload — the IAM discipline applied to GCE.

FAQ

GCE or a higher-level GCP service?

Use GCE when you need OS-level control, specific software, GPUs, or lift-and-shift of existing servers. Use Cloud Run (serverless containers), Cloud Functions (FaaS), or GKE (Kubernetes) when you don't want to manage servers. GCP pushes toward these managed options; reach for GCE when you have a concrete reason to own the VM.

What is live migration and why does it matter?

Google can move a running VM to a different physical host during maintenance without rebooting or stopping it — your workload continues uninterrupted through host events that would require a reboot on other clouds. It reduces maintenance-related downtime, a genuine operational advantage of GCE, especially for workloads sensitive to restarts.

How do GCE VMs access other GCP services securely?

Via service accounts — a VM runs as a service account identity that GCP services authorize, with credentials managed automatically and no keys stored on the VM. It's the equivalent of AWS IAM roles / Azure managed identities. Scope service accounts to least privilege rather than using the broadly-permissioned default.

What are preemptible/Spot VMs?

Deeply discounted (up to ~90% off) VMs that Google can reclaim with short notice when it needs the capacity. Ideal for fault-tolerant, stateless, or batch workloads (CI, data processing, rendering) that can handle interruption. Not for stateful or always-on services. Every cloud has an equivalent (AWS Spot, Azure Spot).

How does GCE compare to EC2?

Directly comparable IaaS. Concepts map (MIGs ≈ Auto Scaling, Spot ≈ Spot, service accounts ≈ IAM roles). GCE's distinctive edges: live migration (no-reboot maintenance), custom machine types (precise sizing), automatic sustained-use discounts (no commitment needed), and GCP's global VPC. EC2 has the larger ecosystem. Choose by cloud; the IaaS fundamentals are the same.