Compute EngineAuthorCloudBrum editorial teamLast reviewed21 Oct 2026Reading time~12 minLevelBeginner to advanced

• Many machine familiesGeneral-purpose, compute-optimised, memory-optimised and storage-optimised families, plus accelerator types for GPUs.
• Custom machine typesOn supported families you choose the exact number of vCPUs and amount of memory rather than a preset size.
• Images and image familiesBoot from public images, Marketplace images or your own, and use a family name to always get the newest version.
• Block storage choicesPersistent Disk and Hyperdisk for durable data, and Local SSD for very fast scratch space.
• Managed instance groupsRun a fleet of identical VMs that autoscale, heal themselves and update in rolling fashion behind Cloud Load Balancing.
• Live migrationWhen Google services a host, most VMs are moved to another one while they keep running, so planned maintenance seldom causes a restart.
• Shielded and Confidential VMsSecure boot, a virtual TPM and integrity monitoring, with Confidential VMs to keep data encrypted while it is processed.
• Per-second pricingBilling runs by the second after a one-minute minimum, with sustained and committed use discounts on top.

Instance (VM)

A single virtual machine, billed for its vCPU and memory while it runs.

Machine type

The CPU and memory shape of a VM, such as e2-medium or n2-standard-4. Some families also accept a custom shape.

Image and image family

An image holds an operating system for a boot disk. A family is a pointer that always resolves to the latest image in a series.

Project

The unit that owns resources, billing and permissions. Every VM, disk and network sits inside exactly one project.

Region and zone

Regions are named geographies such as asia-south1; each one holds several zones, which are separate failure domains. A single VM is placed in exactly one zone.

VPC network and subnet

Your private network. A VPC network spans the world, while each subnet belongs to one region and defines the IP range for VMs there.

Firewall rule

A stateful allow or deny rule with a priority, applied to VMs through network tags or service accounts.

Persistent Disk and Hyperdisk

Durable network-attached storage that outlives the VM. The boot disk is created with the VM; data disks are optional extras.

Service account

The identity a VM uses when it calls Google Cloud APIs, which removes the need to store keys on the machine.

Metadata and startup script

Key-value settings attached to a VM, including a startup-script that runs on every boot. Both are visible to code running on the VM, so credentials belong in neither.

Metadata server

A local address (metadata.google.internal) from which a VM reads details about itself and obtains access tokens.

Launch a VM from the Google Cloud console

1. Open Compute Engine and pick the projectIn the Google Cloud console choose the project from the top bar, then open Compute Engine → VM instances. Enable the Compute Engine API if prompted.
2. Name the instance and add labelsUse a descriptive name plus labels such as env and owner; they feed cost reports and organisation policies later.
3. Choose region and zoneSelect the region nearest your users and then a zone. For production, plan on running VMs in more than one zone.
4. Choose the machine configurationStart with something modest like e2-medium, or define a custom machine type; you can resize once real metrics exist.
5. Configure the boot diskPick an image such as Debian 12 or Ubuntu 24.04 LTS, a Balanced persistent disk and a size like 20 GB. Disks are encrypted at rest without any extra step.
6. Set the identityCreate or select a dedicated service account that holds only the roles the VM needs, instead of the default Compute Engine service account.
7. Configure networkingChoose the VPC and subnet, leave the HTTP and HTTPS boxes cleared unless you need them, and set the external IPv4 address to None for a private VM (add Cloud NAT for outbound access).
8. Review the Security settingsTurn on Secure Boot, vTPM and Integrity monitoring, and add the metadata enable-oslogin = TRUE so that SSH access follows IAM.
9. Create the VM and connectWhen the green tick appears, connect with browser SSH or gcloud compute ssh --tunnel-through-iap, which works without a public IP.

• Measure first. Cloud Monitoring metrics and Recommender suggestions show which VMs are over- or under-sized.
• Choose current families such as C4 or N4, and try Arm-based types (Axion C4A, Tau T2A) when your software supports Arm.
• Shape the machine. A custom machine type avoids paying for memory or vCPUs you never use.
• Pick the disk by the bottleneck. Hyperdisk Balanced separates capacity from IOPS and throughput, SSD or Extreme tiers serve heavy database I/O, and Local SSD takes the scratch data.
• Switch on gVNIC and Tier_1 networking where the machine type supports them for higher network bandwidth.
• Use compact placement policies to keep latency-sensitive VMs physically close.
• Know the shared-core limits. Types such as e2-micro and e2-small burst; move sustained, heavy load to standard machine types.
• Add machines, not only size. A managed instance group behind Cloud Load Balancing spreads the load, and Cloud CDN keeps static content near users.

FinOps is the habit of managing cloud spend together with engineering. These are the FinOps checks that matter most for Compute Engine.

• Commit to the steady baseline. Committed use discounts reward a 1 or 3-year promise (Google advertises roughly 55% to 70%, depending on machine type and term); leave the spiky part on-demand.
• Spot VMs for anything restartable: batch jobs, CI runners and stateless workers. Google quotes discounts of up to about 91% against on-demand.
• Benefit from sustained use discounts. Eligible families that run for much of the month are discounted automatically.
• Act on Recommender. Its idle and oversized VM suggestions show where a smaller machine type would do.
• Attach instance schedules to dev and test VMs so they power off in the evening and at weekends.
• Remember the disks. A stopped VM stops vCPU and memory charges, but its disks keep billing until deleted.
• Tidy up regularly: unattached disks, old snapshots, reserved external IPs that nothing uses, and idle Cloud NAT gateways (external IPv4 addresses are billed hourly).
• Match disk type to need. Balanced Persistent Disk suits most workloads; pay for SSD or Hyperdisk performance only where it matters.
• Keep an eye on egress. Traffic to the internet and between regions adds up, so co-locate chatty services.
• Label and budget. Use labels with Cloud Billing budgets and alerts.

• Give each workload a dedicated least-privilege service account and avoid the default Compute Engine one.
• Connect with IAP TCP forwarding and OS Login instead of public SSH or RDP, and leave private VMs without an external IP.
• Let private VMs reach the internet through Cloud NAT.
• Write tight firewall rules that target a service account or secure tag rather than wide IP ranges.
• Keep Shielded VM protections on (secure boot, vTPM, integrity monitoring) and consider Confidential VMs for data that must stay encrypted while in use.
• Add customer-managed encryption keys in Cloud KMS if your rules call for them; disks are already encrypted by default.
• Patch through VM Manager and review vulnerability findings in Security Command Center.
• Gather logs with the Ops Agent, and keep Cloud Audit Logs and VPC Flow Logs enabled.
• Hold secrets in Secret Manager, not in metadata or startup scripts.
• Boot only from images your team approved, restricted by the trusted image projects constraint, and rebuild them on a schedule.
• Block project-wide SSH keys and serial port access unless you have a specific need.

For audit trails use Cloud Audit Logs; for retention use Backup and DR Service or snapshot schedules; and for evidence download reports from Compliance Reports Manager. Compute Engine sits inside Google’s SOC, ISO 27001, PCI DSS and HIPAA-eligibility scope, which speaks for the platform. Whether your own workload complies turns on the guest OS, access rules and data handling that you set up.

• Right-size, then stop what is idle. A VM that is not running emits nothing of its own.
• Try Arm. Axion and Tau T2A are Google’s Arm machine types, and Arm cores often draw less power for the same job.
• Favour cleaner regions where latency and data rules allow; Google publishes carbon-free energy figures for each region.
• Let managed instance groups scale in overnight and at weekends instead of holding the peak size.
• Run flexible jobs on Spot VMs to put spare capacity to use.
• Move spiky work off VMs. Cloud Run and Cloud Run functions scale to zero between bursts, so nothing sits idle.
• Read the report. Carbon Footprint in the console breaks your estimated emissions down by project, product and region.

Purchase options

What you actually pay for

• vCPU and memory, which depend on machine type, region and purchase option
• Disk capacity, any extra provisioned IOPS or throughput, and stored snapshots
• Outbound traffic that leaves Google’s network, and traffic that crosses regions
• Reserved or in-use external IPs, Cloud Load Balancing and Cloud NAT gateways
• Per-hour licence charges on premium operating system and database images

Create a small Debian VM with Shielded VM, OS Login, a dedicated service account and no external IP. Replace the placeholder names with your own.

# Create one VM (no external IP)
gcloud compute instances create vm-demo-01 \
  --project=my-project-id \
  --zone=asia-south1-a \
  --machine-type=e2-medium \
  --image-family=debian-12 --image-project=debian-cloud \
  --boot-disk-size=20GB --boot-disk-type=pd-balanced \
  --subnet=snet-app --no-address \
  --service-account=vm-demo-sa@my-project-id.iam.gserviceaccount.com --scopes=cloud-platform \
  --shielded-secure-boot --shielded-vtpm --shielded-integrity-monitoring \
  --metadata=enable-oslogin=TRUE \
  --labels=env=dev,owner=platform-team

# List the VMs with their state
gcloud compute instances list --filter="labels.env=dev" \
  --format="table(name,zone.basename(),machineType.basename(),status,networkInterfaces[0].networkIP)"

# Connect without a public IP, through Identity-Aware Proxy
gcloud compute ssh vm-demo-01 --zone=asia-south1-a --tunnel-through-iap

# Stop vCPU and memory charges (disks still bill)
gcloud compute instances stop vm-demo-01 --zone=asia-south1-a

# Assumes the subnet and the service account are defined elsewhere
resource "google_compute_instance" "demo" {
  name         = "vm-demo-01"
  machine_type = "e2-medium"
  zone         = "asia-south1-a"

  labels = {
    env   = "dev"
    owner = "platform-team"
  }

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-12"
      size  = 20
      type  = "pd-balanced"
    }
  }

  network_interface {
    subnetwork = "snet-app"
    # no access_config block = no external IP
  }

  service_account {
    email  = google_service_account.vm.email
    scopes = ["cloud-platform"]
  }

  shielded_instance_config {
    enable_secure_boot          = true
    enable_vtpm                 = true
    enable_integrity_monitoring = true
  }

  metadata = {
    enable-oslogin = "TRUE"
  }
}

# pip install google-cloud-compute
from google.cloud import compute_v1

project, zone, region = "my-project-id", "asia-south1-a", "asia-south1"

instance = compute_v1.Instance(
    name="vm-demo-01",
    machine_type=f"zones/{zone}/machineTypes/e2-medium",
    disks=[compute_v1.AttachedDisk(
        boot=True,
        auto_delete=True,
        initialize_params=compute_v1.AttachedDiskInitializeParams(
            source_image="projects/debian-cloud/global/images/family/debian-12",
            disk_size_gb=20,
            disk_type=f"zones/{zone}/diskTypes/pd-balanced",
        ),
    )],
    network_interfaces=[compute_v1.NetworkInterface(
        subnetwork=f"projects/{project}/regions/{region}/subnetworks/snet-app",
    )],  # no access_configs = no external IP
    service_accounts=[compute_v1.ServiceAccount(
        email=f"vm-demo-sa@{project}.iam.gserviceaccount.com",
        scopes=["https://www.googleapis.com/auth/cloud-platform"],
    )],
    shielded_instance_config=compute_v1.ShieldedInstanceConfig(
        enable_secure_boot=True, enable_vtpm=True, enable_integrity_monitoring=True,
    ),
    metadata=compute_v1.Metadata(items=[compute_v1.Items(key="enable-oslogin", value="TRUE")]),
    labels={"env": "dev"},
)

operation = compute_v1.InstancesClient().insert(project=project, zone=zone, instance_resource=instance)
operation.result()
print("created", instance.name)

// dotnet add package Google.Cloud.Compute.V1
using Google.Cloud.Compute.V1;

const string project = "my-project-id", zone = "asia-south1-a", region = "asia-south1";

var instance = new Instance
{
    Name = "vm-demo-01",
    MachineType = $"zones/{zone}/machineTypes/e2-medium",
    Disks =
    {
        new AttachedDisk
        {
            Boot = true,
            AutoDelete = true,
            InitializeParams = new AttachedDiskInitializeParams
            {
                SourceImage = "projects/debian-cloud/global/images/family/debian-12",
                DiskSizeGb = 20,
                DiskType = $"zones/{zone}/diskTypes/pd-balanced"
            }
        }
    },
    NetworkInterfaces = { new NetworkInterface { Subnetwork = $"projects/{project}/regions/{region}/subnetworks/snet-app" } },  // no AccessConfigs = no external IP
    ServiceAccounts =
    {
        new ServiceAccount
        {
            Email = $"vm-demo-sa@{project}.iam.gserviceaccount.com",
            Scopes = { "https://www.googleapis.com/auth/cloud-platform" }
        }
    },
    ShieldedInstanceConfig = new ShieldedInstanceConfig { EnableSecureBoot = true, EnableVtpm = true, EnableIntegrityMonitoring = true },
    Metadata = new Metadata { Items = { new Items { Key = "enable-oslogin", Value = "TRUE" } } },
    Labels = { ["env"] = "dev" }
};

InstancesClient client = await InstancesClient.CreateAsync();
var operation = await client.InsertAsync(project, zone, instance);
await operation.PollUntilCompletedAsync();
Console.WriteLine("created " + instance.Name);

Short walkthrough videos for this service are being prepared. They will appear here and load only when you press play. Until then, follow CloudBrum on YouTube for new videos.

Not sure virtual machines are the right level? Compare with Cloud Run (containers and web apps), Cloud Run functions (serverless functions), Google Kubernetes Engine (Kubernetes) and App Engine (managed app platform).