Reservations of Compute Engine zonal resources

This document explains the behavior, requirements, restrictions, and billing of reservations of Compute Engine zonal resources.

Overview

To make sure that 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. You can use reservations to help ensure that your project has resources for future increases in demand, such as in the following cases:

  • Growth
  • Planned or unplanned spikes
  • Migration of a large number of virtual machine (VM) instances
  • Backup and disaster recovery

With reservations, 95% of VMs start in less than 120 seconds. 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.

How reservations work

This section describes how reservations work.

When you create a reservation, you define the following properties:

  • Provisioning type (on-demand or future)

    • An on-demand reservation (default) is provisioned at the time you request it, if possible.

    • A future reservation allows you to request assurance of important or difficult-to-obtain capacity in advance. Specifically, future reservations consist of two resource types: future reservation requests that, if approved, provide automatically created (auto-created) reservations at your future, specified time. After its requested reservation period, an auto-created reservation is either automatically deleted or behaves similarly to an on-demand reservation.

    Using future reservations can provide an even higher level of assurance in obtaining capacity than on-demand reservations by allowing Google Cloud more time to fulfill your request. If you want to use future reservations, see About future reservation requests instead of this document.

  • 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 in this document.

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

  • Optional: Resource placement policy (compact)

    • A compact placement policy indicates that VMs should be located as close to each other as possible to reduce network latency between the VMs. You can only specify a compact placement policy for specific reservations.

Additionally, you define the reservation's VM properties, which describe the hardware requirements for the VMs that you want to reserve. A VM can consume a reservation only if both the VM's properties and reservation's VM properties match exactly. For more information, see Requirements in this document.

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 are billed 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 can't 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

All reservations have the following requirements:

  • A VM instance can consume a reservation only if all of the following properties for both the VM and the reservation match exactly:

    • Project*
    • Zone
    • Machine type
    • Minimum CPU platform
    • GPU type and count
    • Local SSD type and count
    • Reservation affinity†
    • Compact placement policy‡

    *Project requirements vary based on the reservation's share type.

    †Reservation affinity requirements vary based on the reservation's consumption type.

    ‡Compact placement policy requirements apply only when a reservation specifies a compact placement policy.

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

Additional requirements for reservations attached to commitments

Additionally, reservations that are attached to commitments have the following requirements:

  • You must have sufficient committed use discount quota.

  • To receive committed use discounts for GPUs and/or local SSDs, the reservation for these resources must be created and attached when purchasing the commitment.

To learn more, see Attach reservations to commitments.

Additional requirements for reservations created from an instance template

Additionally, if you create a reservation by specifying an instance template, make sure of the following:

  • You must create your reservation in the same region, zone, and project as the resources within the template. Specifically:

    • Any regional or zonal resources that are specified in an instance template—such as a machine type or a disk—restrict the use of the template to the locations where those resources exist. For example, if your instance template specifies an existing disk in the us-central1-a zone, then you must create your reservation in the same zone.

    • An instance template contains project-specific settings, so you can only access and use an instance template within the same project. For the projects a shared reservation is shared with, you must create similar templates in those projects or create VMs by specifying properties directly.

  • If the instance template specifies a compact placement policy, you must create a specific reservation. Then, when you create the VMs to consume the reservation, you must specifically target the reservation by name. Otherwise, the VMs can't consume the reservation.

Additional requirements for shared reservations

Additionally, there are specific quota implications for the owner and consumer projects of a shared reservation. Specifically:

  • The Owner project must have sufficient quota for twice the resources to reserve. The owner project of a shared reservation is charged for quota as follows:

    • When reserving the resources, the owner project is charged for quota for the resources that it reserves.

    • When any of the reserved resources are consumed, the owner project is charged for quota for the resources that are consumed.

  • The Consumer project is charged for quota only when consuming the reserved resources and only for the resources that it consumes.

For example, let's assume that project A (the owner project) creates a shared reservation for 10 resources and share the reservation with project B and C (the consumer projects). After creating the shared reservation, project A is charged for 10 resources. Then, let's assume that the projects consume the reservation as follows:

  • Project A consumes 2 reserved resources and is charged for 2 resources.

  • Project B consumes 2 reserved resources. Project A and B are both charged for 2 resources.

Additional requirements for reservations with compact placement policies

Additionally, reservations that specify compact placement policies have the following requirements:

  • If a reservation specifies a compact placement policy, a VM must specify the same compact placement policy to consume the reservation.

  • To specify a compact placement policy in a reservation, you must create a specific reservation. Then, when you create the VMs to consume the reservation, you must specifically target the reservation by name. Otherwise, the VMs can't consume the reservation.

  • You must reserve resources in a zone that is within the region of the compact placement policy you specify in a reservation.

Restrictions

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 previously listed, like Cloud SQL

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

Additional restrictions for reservations attached to commitments

Additionally, reservations that are attached to commitments have the following restrictions:

  • You can't delete the reservation until the commitment contract has expired.

  • You can only attach the reservation to one single commitment.

  • You can't resize a reservation that is attached to a commitment. Instead, see how to replace reservations that are attached to commitments.

To learn more, see Attach reservations to commitments.

Additional restrictions for shared reservations

Additionally, shared reservations 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 in the project that created it—you can't list all of the shared reservations in an organization or all of the reservations that are shared with a specific project.

  • If you create a shared reservation by specifying an instance template, only the users within your project can access the same instance template and use it to create VM instances or other reservations.

  • You can't specify a compact placement policy when creating a shared reservation.

  • 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 in this project are deleted, and any reservations from the previous organization that were shared with this project can't be consumed in the new organization. For more information, see How shared reservations work in this document.

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

Additional restrictions for reservations with compact placement policies

Additionally, reservations that specify a compact placement policy have the following restrictions:

  • When creating a compact placement policy to include in a reservation, you can't specify a fixed number of VMs. Otherwise, creating the reservation fails.

  • A VM that specifies a compact placement policy can only consume a reservation that specifies the same compact placement policy.

  • You can only specify compact placement policies for single-project reservations. Shared reservations or reservations attached to committed use discounts aren't supported.

  • You can't share a compact placement policy across reservations. Instead, you must create a new compact placement policy for every new single-project reservation you want to create.

  • You can only reserve up to 150 VM instances per reservation.

  • You can only specify supported machine types for compact placement policies.

  • You can only specify compact placement policies. Any other type of resource policies, such as instance schedules or snapshot schedules, isn't supported.

  • You can only delete a compact placement policy specified in a reservation after you delete the reservation.

Billing

This section describes how reservations are billed.

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 that include 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.

Additionally, you can monitor the consumption trends of your reservations to reduce unnecessary costs from wasted or unused resources. For more information, see Monitor reservations consumption.

Additional billing information for shared reservations

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