Compute Engine

A Compute Engine instance is a virtual machine in one zone of one region (see Google Cloud Global Infrastructure). Its main parts are:

Instances are billed per second, with a one-minute minimum, while they run, and their disks and static addresses are billed as long as they exist, running or not. A stopped VM (status TERMINATED) costs nothing for compute, but keeps costing for disks.

The relationship between the templates, the group and the load balancer used later in this page is:

Machine types are grouped by workload. The families and the series inside each one are listed on the machine families resource and comparison guide, which is the page to consult before choosing, because new series appear every year.

Three practical rules follow:

Besides predefined machine types such as n4-standard-4, custom machine types let you pick the vCPU and memory independently, in series that support them, with the prefix n4-custom-4-20480, or --custom-cpu and --custom-memory flags on the CLI. Shared-core types (the e2-micro, e2-small and e2-medium sizes) can burst above a baseline and are the cheapest way to run a small VM.

See Machine families resource and comparison guide and Create a VM with a custom machine type.

Related options, covered only briefly here:

An image is a bootable disk snapshot. Google publishes public images for Debian, Ubuntu, Rocky Linux, Red Hat Enterprise Linux, SUSE, Windows Server and others, each in a project named for the vendor (for example debian-cloud). Rather than a specific image name, use an image family, a pointer that always resolves to the newest non-deprecated image in that family, such as debian-13. Checking the current list on 2026-09-30 shows the Debian 12 and 13 families, and Ubuntu 24.04 LTS and 26.04 LTS families.

Production fleets usually bake a custom image from a configured VM (or build it with Packer) so that new VMs start ready, instead of installing software on every boot. Custom images can be grouped into your own family, and each new version added to the family is picked up by the next template that references the family. Container-Optimized OS is a Google-maintained, minimal image for hosts that only run containers.

See Operating system details and Create custom images.

Every VM has a boot disk. Hyperdisk is the current block-storage family: Hyperdisk Balanced, Balanced High Availability, Extreme, Throughput and ML, with provisioned IOPS and throughput that you tune independently of the size. Older Persistent Disk types (pd-balanced, pd-ssd, pd-standard) remain available on the series that support them, such as E2 and N2. Local SSD is fast, ephemeral storage that is lost when the VM stops. This page uses the default boot disk for each example, and the details of disk types, regional disks, storage pools and file shares are on Block and File Storage on Google Cloud.

Spot VMs use spare Compute Engine capacity at a deeply discounted price, with the trade-off that Google can reclaim them at any time with a short notice (a 30-second ACPI signal). They replace the older preemptible VMs, which are still supported but had a fixed 24-hour maximum lifetime that Spot VMs do not. Use them for fault-tolerant, restartable work such as batch processing, CI runners and stateless worker pools, never for a single instance holding the only copy of data.

See Spot VMs and Create and use Spot VMs.

--instance-termination-action may be STOP (keep the disks, restart later) or DELETE. Spot VMs are excluded from the Compute Engine SLA, capacity may be unavailable in a zone, and they do not qualify for committed-use discounts. The same flag works in instance templates, so a MIG can maintain a pool of Spot VMs.

Metadata is a set of key-value pairs attached to an instance or a project. The VM reads it at http://metadata.google.internal/computeMetadata/v1/ (requests need the header Metadata-Flavor: Google). The special key startup-script holds a script that runs as root on every boot, and startup-script-url points to one in Cloud Storage. Because the script re-runs each time the VM starts, write it to be idempotent, and keep secrets out of it: fetch them from Secret Manager at run time using the VM’s service account (see Secret Manager and Cloud KMS).

Save the following as startup.sh. It installs NGINX and serves a page that shows the instance name read from metadata:

See Use startup scripts on Linux VMs and About VM metadata. Windows VMs use the windows-startup-script-ps1 key instead.

Older guides run a container on a VM with gcloud compute instances create-with-container or the Deploy container option in the console, both of which depend on the container startup agent (konlet). That agent was deprecated on 2025-07-21. Since 2026-07-31 you can no longer create VMs or managed instance groups that deploy a container through the agent (the gce-container-declaration metadata), and workflows relying on it stop working. On 2027-07-31 Google ends support for the agent entirely, with no further updates for VMs still running it. The current approaches are:

A startup script that pulls and runs catalog-api from Artifact Registry on a Container-Optimized OS VM (which includes Docker and the docker-credential-gcr helper) looks like this:

See Container startup agent deprecation and Container-Optimized OS. For the registry, see Container Registry and Builds; for Docker itself, the site’s Docker section.

A single VM is a pet; a managed instance group (MIG) is a fleet. A MIG creates identical VMs from an instance template (an immutable description of machine type, image, disks, service account, metadata and network), keeps the requested number running, replaces failed VMs, and can scale on load. A MIG is zonal (one zone) or regional (spread across zones of a region, which survives a zone outage and is the recommended choice for production).

A MIG becomes an HTTP back end by adding it to a backend service behind a load balancer, which provides one anycast IP address, TLS termination, health checks and, for the external application load balancer, optional Cloud CDN and Cloud Armor. The commands that build the URL map, proxy and forwarding rule belong with the networking material in Load Balancing and Cloud Armor; here only the link between the group and the service is shown.

See Backend services overview and Set up an external Application Load Balancer.

VM Manager is the set of tools in the OS Config service for managing fleets of VMs: OS patch management (schedule and apply updates), OS inventory management (installed packages and OS version, collected per VM), and OS configuration management (policies, written as OS policy assignments, that keep files, packages and repositories in a desired state). It requires the osconfig.googleapis.com API and the OS Config agent, which is preinstalled on current Google public images and is enabled per VM or project with the metadata key enable-osconfig=TRUE.

The deployment file holds the targets, schedule and rollout settings:

See VM Manager overview, Create patch jobs and deployments and gcloud compute os-config patch-deployments create. In the console, open Compute Engine, then VM Manager, and choose Patch to see compliance and to create a deployment. For MIGs the better practice is not to patch in place at all: bake a new image, create a new template, and run a rolling update.

A snapshot is an incremental copy of a disk, stored outside the zone, and the building block for backups and for copying data to another region. Standard snapshots are the default, archive snapshots cost less for long retention, and instant snapshots are taken in seconds and stay in the same location for quick local restores. The disk types and the restore procedures are on Block and File Storage on Google Cloud; this section shows scheduling.

See Create scheduled snapshots and About disk snapshots.

For application-consistent backups of whole VMs, centralised retention and protection from deletion, use the Backup and DR Service. It stores backups in a backup vault (an immutable, access-controlled store) governed by a backup plan that sets the schedule and retention, and it restores a VM, a disk, or individual files. The service has its own pricing, charged for protected data and backup storage, and its own API, so enable backupdr.googleapis.com and read the Backup and DR concepts before choosing between it and plain snapshot schedules. Snapshot schedules are enough for simple disk recovery; Backup and DR is the choice for compliance-driven retention and ransomware resilience.

Compute Engine bills the following, and the prices are on the Compute Engine pricing page and in the pricing calculator (check them on the day you plan, since they vary by region and series, and this page quotes none):

Right-sizing recommendations (idle and over-provisioned VMs) are shown in the console and by the Recommender. Many labelled development VMs can be stopped overnight with an instance schedule resource policy, which starts and stops VMs on a timetable. The Free Program (Always Free) includes one e2-micro VM per month in a few US regions, with limits on disk and egress, listed on the free features page. See Cost Management and Billing for budgets and alerts.

Compute Engine enforces regional quotas (vCPUs by family, in-use IP addresses, disks and total persistent disk capacity, committed CPUs) and global quotas (networks, firewall rules, instance templates). A new project starts with low limits, and a request such as "Quota 'CPUS' exceeded" is solved by requesting an increase in IAM & Admin, then Quotas & System Limits, or by choosing another region. Some GPU and large-machine quotas are zero until requested. See Resource quotas.

Delete in dependency order so that nothing keeps billing. Resources created on this page are the instances and groups, templates, firewall rules, snapshot schedule, policies, and the service account:

Remove any IAM bindings you added for OS Login and IAP with gcloud projects remove-iam-policy-binding, and disable the project metadata flags (gcloud compute project-info remove-metadata --keys=enable-osconfig) if you do not want them in the project. Backups taken by Backup and DR stay in the backup vault until their retention expires and cannot be removed earlier while a vault enforces a minimum retention, so delete the plan first and expect the vault to remain for a while. Deleting a throwaway project removes all of it after a 30-day recovery window; see Shutting down projects.