Google Cloud for Azure Professionals: Compute

Updated Dec 10, 2020

Compute services are typically offered under four service models:

  • Infrastructure as a service (IaaS), in which users have direct, on-demand access to virtual machines, as well as a suite of related services to automate common tasks.
  • Platform as a service (PaaS), in which the machine layer is abstracted away completely, and users interact with resources by way of high-level services and APIs.
  • Containers as a service (CaaS), an IaaS/PaaS hybrid that abstracts away the machine layer but retains much of the flexibility of the IaaS model.
  • Functions as a service (FaaS), in which users can create serverless PaaS-style microservices without having to build out full applications.

This article focuses on the IaaS services offered by Google and Microsoft.

IaaS comparison

For IaaS, Microsoft Azure offers Azure virtual machines (VMs), and Google Cloud offers Compute Engine. Google and Microsoft take similar approaches to their IaaS services: both are fundamental to their respective cloud environment, and almost every type of customer workload runs on them.

At a high level, Azure's IaaS terminology and concepts map to those of Google Compute Engine as follows:

Feature Azure Compute Engine
Virtual machines Virtual machines Virtual machine instances
Virtual machine groups Virtual machine scale sets Instance groups
Images Image (both boot-disk-only and full machine) Image (boot-disk-only)
Custom images Generalized Azure VMs Custom images
VM templates Resource Manager templates Instance templates
Automatic instance scaling Azure Autoscale Compute Engine autoscaler
Supported VM import formats VHD RAW, OVA, VMDK, and VHD
Deployment locality Regional or zonal Zonal
Preemptible VMs Yes Yes
Incremental snapshots Yes Yes

Virtual machines

Compute Engine VM instances and Azure VMs share many of the same features. On both services, you can:

  • Create instances from boot disk images.
  • Launch and terminate instances on demand.
  • Manage your instances without restrictions.
  • Tag your instances.
  • Install a variety of available operating systems on your instance.

Machine access

On both Compute Engine and Azure, you can access your Windows machines through standard methods like the Windows Remote Management service and Remote Desktop Protocol (RDP).

For Linux machines, Compute Engine and Azure approach SSH-based machine access in slightly different ways. With Azure, you must include your own SSH key if you want SSH-based access to your VM. In contrast, on Compute Engine, you can create the key when you need it, even if your VM instance is already running.

Compute Engine also provides SSH from the Browser, which provides a browser-based SSH terminal for a given VM instance. In contrast to Azure Cloud Console and Cloud Shell, which provide an ephemeral command-line interface to their respective platforms, SSH from the Browser provides direct access to a specific VM instance from your browser. If you choose to use this feature, which is available in the Google Cloud Console, you can avoid storing keys on your local machine.

Machine types

Azure and Compute Engine both offer a variety of predefined virtual machine configurations with specific amounts of virtual CPU, RAM, and network capacity.

Like Azure, Compute Engine groups VMs into the following families:

  • Basic instances
  • General-purpose instances
  • Compute-optimized instances
  • Memory-optimized instances
  • GPU instances
  • Shared-core instances

In addition, Compute Engine allows you to depart from the predefined configurations. You can customize your VM instance's CPU and RAM resources to fit your workload.


Azure provides OS images, which are boot-disk-only, and Azure VM images, which also include the VM's swap disks or data disks. Compute Engine machine images are boot-disk-only.

Azure and Compute Engine both provide a variety of platform- or community-supported images for commonly used operating systems such as Windows, Ubuntu, or Red Hat Enterprise Linux, as well as images that have various common server applications preinstalled, such as SQL Server. On both platforms, if you choose an image that uses a premium operating system that requires a license, you must pay a license fee in addition to normal VM costs.

Both platforms also have marketplaces which feature a variety of preconfigured end-to-end solutions. Azure has the Azure Marketplace, and Google Cloud has the Cloud Launcher. These channels allow you to launch common applications on one or more VMs with minimal configuration.

Custom image import

Azure and Compute Engine both provide methods for importing existing machine images to their respective environments:

  • On Azure, your uploaded machine image must be a VHD that is compatible with Azure's version of Hyper-V. VHDs are usually converted into Azure Managed Disks.
  • The Compute Engine import tool supports RAW, OVA, VMDK, and VHD machine images. You upload your image to Cloud Storage and then use the gcloud command line tool or Cloud Console to import the image into Compute Engine. For more details about importing images and other virtual assets into Compute Engine, see Choosing an import method.

If you build your own custom operating systems and plan to run them on Compute Engine, ensure that they meet the hardware support and kernel requirements for custom images.

Preemptible VMs

Azure offers spot VMs for individual VMs or scale sets. These VMs run on unused capacity in an Azure datacenter and are cheaper than standard VMs, but can be reclaimed by their respective compute services with little notice. Due to their ephemeral nature, these VMs are most useful when applications have tasks that can be interrupted or that can use, but don't need, increased compute power.

Similarly, Compute Engine offers preemptible VM instances, which serve the same purpose as Azure's spot VMs. In contrast to spot VMs, preemptible VM instances are not tied to a specific service, giving them slightly more flexibility. Preemptible VM instances last a maximum of 24 hours. For more information, see Preemptible VM Instances.



Both Compute Engine and Azure support autoscaling, in which instances are created and removed according to a user-defined policy. Autoscaling can be used to maintain a specific number of instances at any given point, or to adjust capacity in response to certain conditions. Autoscaled instances can be created from a user-defined template.

Compute Engine and Azure implement autoscaling in similar ways:

  • Azure Autoscale scales instances within a VM scale set. The VM scale set creates and removes instances according to your chosen autoscaling policy.
  • Compute Engine's autoscaler scales instances within a managed instance group. The autoscaler creates and removes instances according to your chosen autoscaling policy.

Azure Autoscale allows for two types of autoscaling: scheduled and dynamic. With scheduled autoscaling, you configure VM scale sets to scale up or down at scheduled times. With dynamic autoscaling, you configure the VM to scale up and down according to a metric threshold such as CPU utilization or message queue length.

Compute Engine's autoscaler uses a dynamic scaling policy that you define based on metrics like average CPU utilization, HTTP load balancing serving capacity, or Stackdriver Monitoring metrics. Like in Azure, you can also configure the Compute Engine autoscaler to autoscale based on schedules.

Post-deployment configuration

Both Compute Engine and Azure provide methods by which you can perform additional configuration automatically after an instance has been deployed. On Azure, you can add Azure VM Extensions to help facilitate VM configuration after deployment. On Compute Engine, you can add startup scripts to perform automated tasks each time your instance boots up, such as installing software, performing updates, or turning on services.

Internal networks

Compute Engine and Azure both automatically connect new VMs to an internal virtual network. In addition, you can create additional networks and launch instances into those networks in both services. For a full comparison of Google Cloud networking and Azure networking, see the Networking article.

Block storage

Azure and Compute Engine both support networked and locally attached block storage. For a detailed comparison of their block storage services, see Block storage.


This section compares the pricing models for Compute Engine and Azure VMs.

On-demand pricing

Compute Engine and Azure have similar on-demand pricing models for running VMs. Each service charges by the minute. Compute Engine has a minimum charge of ten minutes of usage. Both services allow you to run your VM indefinitely.

Discount pricing

Compute Engine and Azure approach discount pricing in different ways.

Microsoft offers its most substantial VM discounts through Microsoft Enterprise Agreements. These agreements allow you to get discounted pricing by committing to a base-wide installation of one or more Microsoft Server and Cloud technologies with full Software Assurance coverage. If you don't have a Microsoft Enterprise Agreement, you might also be able to get discounted rates through a reseller.

In contrast, Compute Engine provides both a sustained-use discount model and a committed-use discount model.

  • Sustained-use discounts: Compute Engine automatically applies discounts to your instances depending on how long the VM instances are active in a given month. The longer you use an instance in a given month, the greater the discount. Sustained-use discounts can save you as much as 30% of the standard on-demand rate.
  • Committed-use discounts: You commit to reserving some number of virtual CPUs for either a one-year or a three-year period, and are billed for usage whether or not the CPUs are fully utilized. This model is appropriate for predictable and steady state usage where you will use a specific amount of cores and memory for future workloads. Committed-use discounts can save you as much as 57% of the standard on-demand rate.

For more details about Compute Engine pricing, see Compute Engine Pricing.

What's next?

Next: Networking