Our website relies on funding from our readers, and we may receive a commission when you make a purchase through the links on our site.

Google Compute Engine Fundamentals & Basics

The Fundamentals of Google Compute Engine (GCE)

by DAVID VARNUM, CCIE, VCP, MCSE+ - Last Updated: July 27, 2023

Google Compute Engine (GCE) is part of Google’s Infrastructure-as-a-Service (IaaS) offering, where you can build high-performance, fault-tolerant, massively scalable compute nodes to handle your application’s needs.

Virtual Machine instances are provisioned in GCE and can be pre-packed or fully customized.

In this article, we’ll cover some of the fundamentals of VM Instances within GCE.

Virtual Machine (VM) Instances

The terms Virtual Machine and Instance are synonymous in GCP. VM Instances are comprised of on Operating System and infrastructure resources such as CPU, Memory, Disk, and Networking.

Creating VM instances can be done using the GCP console (console.google.com), using the command line via Cloudshell or SDK, or via the REST API.

When creating a VM instance, you have the option of choosing a predefined machine type or a custom machine type.


Machine Types

Machines types are templates of virtualized hardware that will be available to the VM instance. These resources include the CPU, Memory, Disk capabilities, and so on.

Predefined machine types are managed by Google, and are categorized by 4 types:

  • Standard machine type
    • Ideal for typical balanced instances with respect to RAM and CPU
    • Have 3.75GB of RAM per virtual CPU
  • High-memory machine types
    • Ideal for applications that require more memory
    • Have 6.5GB of RAM per virtual CPU
  • Shared-core machine types
    • These machines have one virtual CPU on a single hyper-thread of a single host CPU that is running the instance. Ideal for non-resource intensive applications.
    • Very cost effective
  • Large machine types
    • Ideal for resource-intensive workloads
    • Up to 1TB of memory


Custom machine types

Say that none of these predefined machine types match your requirements. No worries, you can completely customize the machine type to fit your vCPU and Memory needs.

This is ideal if you have a workload that maybe requires more processing power or memory than what is offered by the Google-provided types, or if you need GPUs.

You may pay a small premium to use custom machine types.



After choosing a machine type which covers CPU and Memory, it’s time to choose a disk option.

You have a few options when choosing a disk type for your VM instance.

The disk you choose will be your single root disk in which your image is loaded during the boot process.

Do you choose a persistent disk or a local disk?


Persistent Disks

Persistent disks are network-based “disks” abstracted to appear as a block device. Data is durable, meaning the data will remain as you left it after reboots and shutdowns.

Available as either a standard hard disk drive or as a solid state drive (SSD), persistent disks are located independently of the VM instances, which means they can be detached and reattached to other instances.

You have the option to keep your disk when deleting your instance, or having it terminated along with the instance.

  • Standard persistent disks
    • Ideal for efficient and reliable block storage
    • Max 64TB per instance
    • Only available within a single zone
  • SSD persistent disks
    • Ideal for fast and reliable block storage
    • Max 64TB per instance
    • Only available within a single zone

Other key features:

  • Redundancy is built-in, protecting your data from unforeseen failures.
  • GCE automatically encrypts all data on the persistent disk, protecting integrity with cipher keys
  • You can resize disks and migrate instances with zero downtime
  • Disks scale in performance as capacity increases
  • Supports snapshots

Local SSD

Local SSD disks are physically attached to VM instances. These will offer the highest possible IOPS and are used for seriously intensive workloads.

  • Local SSD
    • Ideal for very high-performance local block storage
    • Available as SCSI or NVMe
    • Max 3TB (which is a total of eight 375GB disks)
    • Available only to a single Instance, meaning it cannot be reattached elsewhere
    • Only Persistent if you do not stop or terminate your instance.
    • Does not support snapshots

More often than not, you’ll be choosing a Standard persistent disk for your VMs.  So, what’s next?


Images contain a bootloader, Operating System, file system structure, and any software customizations needed for your deployment.

The image describes what actually gets loaded onto the root disk.

Tons of public images are available from Google and other authorized third-party vendors.

Google Compute Engine (GCE) uses the selected image to create a persistent boot disk for each instance.

Some public images include:

  • CentOS
  • Container-Optimized OS from Google
  • CoreOS
  • Debian
  • RHEL
  • SLES
  • Ubuntu
  • FreeBSD
  • Windows Server 2008, 2012, 2016
  • SQL Server on Windows Server


Alternatively, you can create your own custom images! Custom images can be created from a VM in your environment that has all the necessary settings and additional software configured.

You can even import custom images from on-prem environments, or another cloud provider such as AWS.


You actually choose the zone in the very beginning of creating a new instance.

We talk more about Regions and Zones in another article, but what is important to know here is the different CPU architectures in each zone which could be a deciding factor where you run your applications.

The processor families include Broadwell, Sandy Bridge, Skylake, Ivy Bridge, and Haswell.

If you have a specific requirement for a specific processor, just visit documentation to validate zone availability.

Otherwise, just pick the zone that is closest to you or your customers.


What if I choose a zone and want it changed afterward?

You can absolutely move VM instances to another zone, but it will require a short outage.

To do this manually, you’ll snapshot the disk on the instance you wish to move.

Next, create a new disk in the desired zone from the snapshot.

Create a new VM instance in the new zone and attach the new disk. Update any IPs and references for a clean migration.

Alternatively, you can do this automatically with the gcloud compute instances move command.

Networking & Firewall

Each VM will have a single interface by default. This interface can be placed in a particular subnet of a particular network with respect to the zone that you choose.

You can add multiple interfaces if desired, but that is more of an advanced topic.

By default, the primary internal IP will be set to Automatic (DHCP) and the External IP set to Ephemeral (DHCP).


A couple of easy checkboxes can get your VM setup with the proper firewall rules for HTTP and HTTPS traffic as well.


Availability Policy

There are three categories under the Availability Policy when creating a new VM — Preemptibility, Automatic Restart, and On host maintenance.


Off by default, a preemptible VM is an affordable, short-lived instance ideal for batch jobs or fault-tolerant workloads.

They’re up to 80% cheaper than regular instances, so if your application can handle random the termination of VMs at any time, then give this a look.

Some common applications that use preemptible VMs are modeling or simulations, rendering, media transcending, big data, continuous integration, and web crawling.

Automatic Restart

On by default, this feature of GCE can automatically restart VM instances if they are terminated due to a non-preemption, non-user-initiated reason.

Some examples are due to maintenance events or hardware/software failures.

On host maintenance

On by default, this feature of GCE can automatically migrate your VM instances to other hardware during infrastructure maintenance periods to ensure your VMs operate with no downtime.

This is called Live Migration and is a key differentiator of GCP.  Alternatively, you can set this to turn off the VM.


Other Options

There are various other options you can choose from, such as automation with startup scripts, metadata tags, SSH key, and so on, but these are beyond the scope of fundamentals.

Accessing the VM

After creating the VM, you’ll certainly want to access it someway – but how?

Well, if your VM is running Linux, you can access it via the console through SSH, from another VM running CloudShell via the Cloud SDK, or from your computer via SSH.

If your VM is running Windows, you can use an RDP client or Powershell terminal.



Lastly, let’s look at some GCE fundamentals when it comes to pricing. Google handles charges and discounts differently than AWS and Azure.

With GCP you’re always billed for the first 10 minutes and then for each minute afterward for the life of the machine, rounded up to the nearest minute.

The console will summarize this into costs per month so you don’t have to do the per-minute math.

Discounts are extended for sustained use, meaning if you commit to keeping instances alive for some period of time, a discount will be applied.

Another neat discount is what Google refers to as Inferred instance discounts.

If you have multiple VMs of the same machine type in the same zone, they are combined as if they were a single machine, giving you the maximum available discount.


A sustained usage discount applies to custom machine types as well. Google Compute Engine will perform calculations to match the best qualifying discount for usage in the month.

In the example given in their documentation, two custom machine type instances are split to provide discounts on vCPU and Memory when stretched across the whole month instead of just 15 days.


In this article, we looked at some of the fundamental concepts of Google Cloud Platform’s (GCP) Compute Engine (GCE). You should have a basic understanding of VM instances in GCE, with enough knowledge to be dangerous in your own lab.

That said, if you haven’t already, head over to https://console.cloud.google.com/ to create yourself a free account and get started with GCP!

Google Compute Engine (GCE) FAQs

What operating systems can I run on Google Compute Engine?

You can run a variety of operating systems on Google Compute Engine, including Linux, Windows Server, and custom images.

How do I create a VM on Google Compute Engine?

You can create a VM on Google Compute Engine using the Google Cloud Console, the gcloud command-line tool, or the API.

What are some best practices for creating VMs on Google Compute Engine?

Best practices for creating VMs on Google Compute Engine include selecting the appropriate machine type and configuration for your workload, securing access to VMs using SSH keys and firewall rules, and regularly monitoring and optimizing VM performance.

How do I access and manage VMs on Google Compute Engine?

You can access and manage VMs on Google Compute Engine using the Google Cloud Console, SSH, or remote desktop tools for Windows Server VMs.

What are some use cases for Google Compute Engine?

Google Compute Engine is commonly used for running web applications, batch processing workloads, data analytics, and machine learning tasks.

How does Google Compute Engine ensure security and compliance?

Google Compute Engine uses a variety of security and compliance measures, including network encryption, access controls, and compliance with industry standards and regulations.

How can I optimize performance on Google Compute Engine?

To optimize performance on Google Compute Engine, you can use features such as preemptible VMs, managed instance groups, and automatic scaling and load balancing.

How does Google Compute Engine handle data storage and management?

Google Compute Engine provides a variety of data storage and management options, including persistent disks, local SSDs, and Google Cloud Storage.

What are some best practices for data backup and recovery on Google Compute Engine?

Best practices for data backup and recovery on Google Compute Engine include using snapshot backups, replicating data across multiple zones, and testing disaster recovery scenarios.