Compute Engine

Compute Engine provides virtual machines running on Google's infrastructure. You choose the amount of CPU and memory, the operating system image, the disks attached to it and the network it sits on. From that point you administer the machine exactly as you would a physical server: you install software, apply patches and manage the operating system.

This is the most flexible compute option and the one with the most responsibility attached. Every other compute product trades some of that control for something you would otherwise have to build yourself.

Virtual machines remain the destination for most workloads that move to the cloud, because they let existing software run unchanged. A migration that would require rewriting an application becomes a migration that requires copying a disk image.

They are also the right answer whenever you genuinely need what they offer: a specific operating system version, kernel modules, licensed software tied to a machine, long-running stateful processes, or GPU workloads with particular driver requirements.

• Machine type — the CPU and memory configuration. Predefined families cover general-purpose, compute-optimised and memory-optimised needs; custom machine types let you specify an exact combination.
• Image — the operating system and software a disk starts from. Custom images let you bake configuration in so instances start ready to serve.
• Persistent disk — network-attached block storage that survives the instance. Can be resized while attached and snapshotted for backup.
• Local SSD — physically attached storage that is very fast and entirely ephemeral. It is lost when the instance stops. Never put data you care about on it.
• Snapshot — an incremental backup of a persistent disk, stored separately and usable to create new disks in other zones.
• Instance template — an immutable definition of how to create instances. Templates cannot be edited; you create a new one.
• Managed instance group (MIG) — a set of identical instances created from a template, with autoscaling, autohealing and rolling updates.
• Spot / preemptible VM — heavily discounted capacity that can be reclaimed at short notice. Correct for fault-tolerant batch work, wrong for anything that must stay up.
• Sole-tenant node — dedicated physical hardware for licensing or compliance requirements that forbid shared tenancy.

• Sustained use discounts apply automatically when an instance runs for a large part of the month. You do nothing to earn them.
• Committed use discounts require promising a level of usage for one or three years, in exchange for a substantially lower rate. Right for predictable baseline load.
• Spot instances cost a fraction of standard pricing but can be reclaimed. Right for batch processing, rendering and CI runners; wrong for databases and user-facing services.
• Right-sizing — machines are routinely provisioned larger than needed. Recommendations based on actual utilisation are often the fastest cost win available.
• Stopping instances — a stopped instance stops charging for CPU and memory but continues charging for its persistent disks.

A frequent exam pattern: a scenario describes a steady baseline plus unpredictable spikes. The correct answer is usually committed use discounts for the baseline and spot or on-demand instances for the spikes, rather than committing to peak capacity.

• Lifting an existing application from a data centre with minimal changes.
• Running commercial software with licensing tied to specific hardware or an operating system version.
• Batch and high-performance computing on spot instances at low cost.
• GPU workloads for training or rendering that need particular driver versions.
• Self-managed databases where a managed service does not meet a specific requirement.