Reservations for Compute Engine zonal resources

Reservations provide a very high level of assurance in obtaining capacity for Compute Engine zonal resources. For example, use reservations to help ensure that your project has resources for future increases in demand, including: planned or unplanned spikes, migrating a large number of virtual machine (VM) instances, backup and disaster recovery, or planned growth and buffer.

Each reservation provides assurance for one or more VMs with the same properties, such as zone, machine type, CPU platforms, GPUs, and disks. You can create a reservation for a single project (default) or you can create a shared reservation for multiple projects (preview).

After you create a reservation, you begin paying for the reserved resources immediately, and they remain available for your project to use until the reservation is deleted. When you no longer need a reservation, delete the reservation to stop incurring charges for it. Because reservations consume resources just like normal VMs, each reservation is charged based on existing on-demand rates, which include sustained-use discounts, and are eligible for committed-use discounts.

This document describes the benefits, limitations, behavior, and billing of reservations for Compute Engine zonal resources. To learn how to create, consume, and manage reservations, see the following:

Benefits

Reservations provide the following benefits:

  • Machines are available when you need them, even if you don't use them immediately.
  • No time constraints. Create a reservation at any time and delete it at any time to stop paying for it.

  • Discounts. Because we bill for reservations in the same way and at the same rate as the resources that they are reserving, reserved resources qualify for committed- and sustained-use discounts.

Benefits of shared reservations

By default, a reservation can only be used by a single project: the project that was used to create it. However, if your organization has many projects, that need the same types of instances reserved, you should consider using shared reservations: reservations that can be used by, not only the project that created it, but also any projects it is shared with.

Shared reservations provide the following benefits over single-project reservations:

  • Improve the utilization of your reservations. Shared reservations can be consumed by multiple projects simultaneously, which can help prevent underutilized reservations
  • Reduce the number of reservations that you need to create and manage. If you have single-project reservations for identical instance properties across multiple projects in the same organization, you can consolidate them into a single shared reservation instead.

Limitations

Reservations have the following limitations:

  • Reservations apply only to Compute Engine, Dataproc, and Google Kubernetes Engine VM usage.
  • Reservations don't apply to the following resources:
    • f1-micro and g1-small machine types
    • Preemptible VMs
    • Sole-tenant nodes
    • Other services not listed above, like Cloud SQL and Dataflow
  • You can reserve up to 1,000 VM instances per reservation.
  • You must have sufficient quota in your project for the resources you are reserving. If the reservation is created successfully, quota for that resource is charged accordingly.
  • Compute Engine attempts to allocate on-demand resources when you create a reservation. If there aren't enough resources in the zone at the time of the request, the reservation fails with an resource availability error due to insufficient capacity. If the reservation is created successfully, the resources are available for you to use, even if you don't use them immediately.
  • When combined with a committed-use discount, the following limitations apply:
    • You must have sufficient committed-use-discount quota.
    • For committed-use discounted pricing for GPUs and local SSDs, the reservation must be created when purchasing the commitment.
    • If the reservation is attached to a commitment, the reservation cannot be deleted.
    • You can only buy a 1-year commitment on K80 GPUs.
  • Reservations that aren't attached to a committed-use discount can be held for any duration, but the same minimum charge of 1 minute applies as for regular instances.
  • When consuming instances from your reservations, you have limited options for prioritizing the order in which your reservations are consumed. For more information, see consumption order.

Additional limitations for shared reservations

Shared reservations also have the following limitations:

  • You can only share reservations with projects in the same organization as the project that creates the reservation.
  • Each shared reservation can be shared with 1 to 100 consumer projects.
  • You must have sufficient quota for the resources you are reserving in both the project that creates the reservation and any projects that consume the reservation. Thus, shared reservations require twice as much quota per resource as reservations that are not shared with other projects. Quota is charged twice for each resource of a shared reservation even if the same project creates and consumes the reservation.
  • For each organization, you can create up to 100 shared reservations for each unique combination of instance properties.
  • You can only list the reservations created by a specific project. This means that each shared reservation is only listed under the project that created it—you cannot list all of the shared reservations in an organization or all of the reservations that are shared with a specific project.
  • If you move a project that is using shared reservations to a new organization, its shared reservations do not migrate to the new organization and any shared reservations that were created using this project are deleted. For more information, see How shared reservations work.

You can mitigate the effects of some of these limitations by following the best practices for shared reservations.

How reservations work

Reservations help to ensure that the VM instances you need are available when you need them. When you create a reservation, you can choose how your project uses the reserved resources. For example, you can choose for a reservation to be automatically applied to any new or existing instances that match the reservation's instance properties (the default behavior), or specify that only a specific VM instance can consume a reservation.

In all cases, a VM instance can only use a reservation if its properties exactly match the reservation's instance properties:

  • Zone
  • Machine type (machine family, vCPUs, and memory)
  • Minimum CPU platform
  • GPU type
  • GPU count
  • Local SSD interface
  • Local SSD count

If a VM instance does match a reservation's instance properties, the default behavior is for all existing and new VM instances to consume the reservation automatically unless otherwise specified. For example, by default, if you create a reservation for 10 custom-8-10240 instances, and you already have 5 matching custom-8-10240 instances, then those 5 instances consume 5 of the reservations. If you create an additional 3 matching instances, then another 3 reservations are consumed.

You can override this default behaviour by specifying certain options when creating reservations and instances.

  • To create a reservation that you don't want to be consumed automatically, specify that instances are required to target the specific reservation. These reservations can only be used if you explicitly specify the reservation during instance creation.
  • To specify that you want an instance to consume a reservation, use the reservationAffinity option when creating the instance or in the instance template. You can specify that an instance automatically consumes from any matching reservation, doesn't automatically consume from matching reservations, or only consumes from a specific reservation.

If you stop, suspend, or delete an instance that is using a reservation, the instance no longer counts against the reservation and the reserved resources are available again.

If you delete a reservation but don't delete the instances that are using the reserved resources, the instances persist and you pay for them as usual.

How shared reservations work

Resources in a single-project reservation (default) can only be consumed by the project that created the reservation. But, resources in shared reservation can be consumed by, not only the project that created the reservation (the owner project), but also any projects the reservation is shared with (consumer projects).

Each resource in a shared reservation can only be consumed by one project at a time. But, multiple projects can consume different resources from the same shared reservation simultaneously. When a project stops consuming a resource in a shared reservation, the resource can be consumed by another project.

By default, projects cannot create and modify shared reservations. To create and modify a shared reservation with a project, the project must be added to the allowlist of the Shared Reservations Owner Projects (compute.sharedReservationsOwnerProjects) organizational policy constraint. If you share a reservation, it is affected by additional limitations and has slightly different consumption behavior than reservations that are not shared.

Consumption order

To consume instances from a reservation, you can specify for an instance to either automatically consume any matching reservation, consume a specific reservation, or not consume any reservations. When consuming instances from any matching reservation (default), if a project can consume an instance from multiple reservations, reservations are consumed in the following order:

  1. Single-project reservations that only this project has access to.
  2. Shared reservations that this project has created or has access to.

Each category has no particular consumption order within it. If one of these categories has multiple reservations, then the consumption order within that category is unpredictable. For example, if a project only has access to one single-project reservation and two shared reservations, then the single-project reservation is consumed first, but you cannot accurately predict which of the shared reservations is consumed next.

This order helps improve the utilization and availability of your reservations by ensuring that your projects consume single-project reservations before consuming more widely available shared reservations.

Reservation billing

Compute Engine reservations are billed at the same rate as the resources that they are reserving. Sustained-use discounts, committed-use discounts, and custom pricing apply as they would for regular VMs.

Take the following example:

  • You have a 3-vCPU commitment in us-central1
  • You are running 5 vCPUs in us-central1-a
  • You have a 10-vCPU reservation in us-central1-a

Reservations with some committed-use discounts.

You will be billed as follows:

Covered by # of vCPUs
Committed-use discount price 3
On-demand price (2 vCPU used reservations + 5 vCPU unused reservations) 7

Shared reservation billing

There are no additional charges for using shared reservations—they are billed at the same price as single-project Compute Engine reservations. But, the project that is billed for shared reservations changes with consumption as different projects might qualify for different committed-use discounts.

The billing project and price for shared reservations are handled as follows:

  • Billing project: By default, the owner project is billed for the shared reservation. But, when a resource from a shared reservation is being consumed by a consumer project, the consumer project is billed for the reservation instead.
  • Billing discounts: By default, billing uses the on-demand price. But, if committed-use discounts have been purchased for either the project that is being billed or the billing account associated with that project, the committed-use discount price is used instead.

What's next