Reservations of Compute Engine zonal resources

Stay organized with collections Save and categorize content based on your preferences.

To make sure Compute Engine resources are available when you need them, use reservations. Reservations provide a very high level of assurance in obtaining capacity for Compute Engine zonal resources. With reservations, 95% of VMs start in less than 120 seconds. For example, you can use reservations to help ensure that your project has resources for future increases in demand like growth, planned or unplanned spikes, migration of a large number of virtual machine (VM) instances, or backup and disaster recovery.

Each reservation provides assurance for one or more VMs with the same properties. After you create a reservation, the reserved resources are available immediately and remain available until you delete the reservation. Similarly, you begin paying for the reserved resources immediately, and, when you no longer need a reservation, you can delete the reservation to stop incurring charges for it. While a VM is consuming a reservation, it does not incur separate charges.

Regardless of how much you use your reserved resources, the reservation prevents anyone else from using your reserved resources. Because a reservation occupies resources as much as unreserved running VMs, reserved resources are charged at the same on-demand rates as running VMs, including any applicable discounts.

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

How reservations work

This section describes how all reservations work. For additional information about how reservations that are shared with multiple projects work, also see How shared reservations work.

A VM can only consume a reservation if all the following properties for both the VM and reservation are exactly matching:

  • Project
  • Zone
  • Machine type
  • Minimum CPU platform
  • GPU type and count
  • Local SSD type and count

Additionally, you can use the following properties to control which VMs can consume a reservation:

  • share type (single-project or shared)
    • A single-project reservation (default) can only be consumed by VMs that are located in the same project as the reservation.
    • A shared reservation can be consumed by VMs in the project where the reservation is located and any other project that the reservation is shared with. Using shared reservations can help improve the utilization of your reservations and reduce the number of reservations that you need to create and manage. For more information, see How shared reservations work.
  • consumption type (automatic or specific)

    • An automatically consumed reservation (default) can be consumed by VMs with a reservation affinity property that allows them to automatically consume any of these reservations (default).

    • A specifically targeted reservation can only be consumed by VMs with a reservation affinity property that targets that specific reservation for consumption. Using specifically targeted reservations can make it easier to track and control which VMs are consuming which reservations.

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

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

How shared reservations work

Each VM in a shared reservation can be consumed by a VM in either the project that created the reservation (owner project) or any of the projects the reservation is shared with (consumer projects). When a VM stops consuming a shared reservation, the shared reservation can be consumed by a different VM in any of the projects that the reservation is shared with. If a shared reservation reserves multiple VMs, VMs from multiple projects can consume the same shared reservation simultaneously.

By default, projects cannot create and modify shared reservations. To create and modify a shared reservation in 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 requirements and has slightly different consumption behavior than reservations that are not shared.

Requirements and restrictions

All reservations have the following requirements:

  • 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.
  • If a reservation is combined with a committed-use discount, the following requirements also 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.

Additionally, all reservations have the following restrictions:

  • You can reserve up to 1,000 VM instances per reservation.
  • 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
  • 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 a

    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.

  • If a reservation is combined with a committed-use discount, the following restrictions also apply:

    • If the reservation is attached to a commitment, the reservation cannot be deleted until the commitment contract has expired.
    • You can only buy a 1-year commitment on K80 GPUs.

Additional requirements and restrictions for shared reservations

In addition to the previous requirements, shared reservations also have the following requirements:

  • 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.

Furthermore, in addition to the previous restrictions, shared reservations also have the following restrictions:

  • 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.
  • 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 was using shared reservations to a new organization, its shared reservations do not migrate to the new organization. Any shared reservations that were created using this project are deleted, and any reservations from the previous organization that were shared with this project cannot be consumed in the new organization. For more information, see How shared reservations work.

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

Reservation billing

This section describes how all reservations are billed. For additional information, see Shared reservation billing.

Compute Engine reservations are billed at the same rate as their reserved resources, including the same on-demand prices and 1-minute minimum charges as unreserved, running VMs. Sustained-use discounts, committed-use discounts, and custom pricing also apply as they would for running VMs.

For example, suppose the following:

  • 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.

Then, you are billed as follows:

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

A reservation incurs charges for its reserved resources for as long as the reservation exists, regardless of whether or not its resources are being used. While consuming a reservation, a VM does not incur duplicate resources charges since the reservation is already billed for the cost of the reserved resources.

For details, see VM instances pricing.

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 managed 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