This document gives you an overview of reservations. To learn more about thedifferent types of reservations, seeChoose a reservation type.

When you create a reservation, Compute Engine verifies that therequested capacity is available in the specified zone. If so, thenCompute Engine reserves resources, creates the reservation, and thefollowing is enabled:

• You can consume the reserved resources to create virtual machine (VM)instances, and the reserved resources remain available until you delete thereservation.

• You're charged for the reserved resources at the same on-demand rate asrunning VMs, including any applicable discounts, as long as the reservationexists.

Reservations are useful for growth, migrations, or disaster recovery.

How reservations work

A reservation provides a high level of assurance of capacity for one or more VMswith the configuration the user specifies.You might also use a reservation withCompute Engine commitmentsorother products that use VMs.

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

• Auto-delete

  Theauto-delete option specifies to automatically delete the reservation, regardless if it's fully consumed or not. If you enable the auto-delete option, the reservation is deleted within two hours from your specified date and time by default, or at custom date and time. Automatically deleting reservations can be useful to avoid unnecessary charges for the reservations that aren't consumed for some time.

• Consumption type (automatic or specific)
  • Anautomatically consumed reservation (default) can be consumed by VMs with a reservation affinity property that allows them to automatically consume any of these reservations. This consumption type is useful if you create and delete lots of VMs, and you want to consume your reservations whenever possible.Note: If a project has VMs that can automatically consume multiple reservations, all single-project reservations are consumed before any shared reservations. Otherwise, the reservation that a VM automatically consumes is random.
    
    This order helps improve the utilization and availability of your reservations by ensuring that your projects consume their designated single-project reservations before consuming any widely available shared reservations.
  • Aspecifically targeted reservation can only be consumed by VMs with a reservation affinity property that targets that specific reservation. This consumption type makes it easier to track and control which VMs consume which reservations.
• Share type (single-project or shared)
  • Asingle-project reservation (default) can only be consumed by VMs that are located in the same project as the reservation.
  • Ashared 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, seeHow shared reservations work in this document.
• Sharing policy

  Thesharing policy specifies if a reservation of GPU VMs can be consumed bycustom training jobs orprediction jobs in Vertex AI. By default, custom training jobs or prediction jobs aren't allowed to consume reservations of GPU VMs. To change this, see how tocreate or update reservations to be consumed in Vertex AI.

• VM count

  TheVM count is the number of VMs with matching properties and zone that you want to reserve when creating a reservation. After you create the reservation, you can modify the VM count.

• VM properties

  TheVM properties describe the hardware requirements (memory and CPUs) and optional resources (Local SSD disks and GPUs) for the VMs that you want to reserve. When creating a reservation, you can specify these properties directly, specify the properties based on an existing VM, or specify the properties by using aninstance template. A VM can consume a reservation only if both the VM's properties and reservation's VM propertiesexactly match. For more information, seeRequirements in this document.

• Optional:Resource placement policy (compact)

  Acompact placement policy indicates that the reserved VMs should be located as close to each other as possible to reduce network latency between them.

When you stop, suspend, or delete a VM that consumes a reservation, the VM nolonger counts toward the reservation. The reserved capacity becomes availableagain.

If you want to delete a reservation to release the reserved capacity, but keepany VMs that consume the reservation, then consider the following:

• You can delete an automatically consumed reservation without stopping orsuspending VMs. After you delete the reservation, any VMs that wereconsuming it keep running. You keep incurring charges for them.

• You can only delete a specifically targeted reservation if no VMs consumeit. If you stop or suspend VMs, then, after you delete the reservation, youcan only restart or resume the VMs if you create a new specifically targetedreservation with a name, zone, and properties that match the deletedreservation.

How shared reservations work

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

By default, projects can't create and modify shared reservations. To create andmodify a shared reservation in a project, the project must be added to theallowlist of theShared Reservations Owner Projects (compute.sharedReservationsOwnerProjects) organizational policy constraint.If you share a reservation, then it is affected byadditional quota requirements and hasdifferentconsumption behavior than single-projectreservations.

Caution: If you migrate a project that created or consumed sharedreservations to a different organization, its shared reservations experience thefollowing effects:

• Any shared reservations created in the migrated project (any shared reservations where the migrated project is specified as the owner project) are deleted. Running VMs are not affected. The project is not automatically removed from theShared Reservations Owner Projects (compute.sharedReservationsOwnerProjects) organizational policy constraint, but you can optionally remove it.
• The migrated project stops consuming resources from any reservations in the previous organization that were shared with it (any shared reservations where the migrated project is specified as a consumer project). The shared reservation attempts to hold on to the capacity for these resources. If the reservation cannot hold on to the capacity immediately due to capacity constraints, Compute Engine continues to attempt to replenish this capacity. Until all of the capacity is replenished, you are only billed for the reserved capacity.

Requirements

All reservations have the following requirements:

• A VM can consume a reservation only if all of the following properties forboth the VM and the reservationexactly match:

  • Project

    • Project requirements vary based on the reservation'sshare type.

  • Zone

  • Machine type

  • Minimum CPU platform

  • GPU type and count (if any)

  • Local SSD disk type and count (if any)

  • Reservation affinity

    • Reservation affinity requirements vary based on the reservation'sconsumption type.

  • Compact placement policy (if any)

    • A reservation can optionally include acompact placement policyto indicate that its reserved VMs should be located as close to eachother as possible to reduce network latency among them. If areservation specifies a compact placement policy, then it can onlybe consumed by VMs that specify the same compact placement policy.

  • Location hint (if any)

    • A reservation can optionally include thelocationHint field, whichyou can only specify when creating reservations or VMs usingREST. Google doesn't recommend specifying thelocationHintfield when creating reservations.

• You must have unusedquota available in your project forthe resources that you're reserving. If the reservation is createdsuccessfully, then quota for those resources is consumed immediately.

Additional requirements for reservations attached to commitments

Additionally, reservations that are attached to commitments have the followingrequirements:

• The reservations must be for the same project and region as the commitment.

• The reservations must be for the same machine family series as the commitment.However, you can choose any machine type within that machine family series.

• The reservations must have the auto-delete option disabled.

• If the commitment specifies any GPUs, Local SSD disks, or both, then theattached reservation (or combination of attached reservations) must specifyexactly the same numbers and types of those resources as the commitment.

  Note: This requirement doesn't apply to local Titanium SSD disks for usewith C4A, C4D, H4D, or Z3 machine types. You can purchasecommitments for these disks without attaching reservations.

To learn more, seeAttach reservations to resource-based commitments.

Additional requirements for reservations created from an instance template

Additionally, if you create a reservation by specifying aninstance template, make sure of thefollowing:

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

  • Anyregionalorzonal resourcesthat are specified in an instance template—such as a machine type or adisk—restrict the use of the template to the locations where thoseresources exist. For example, if your instance template specifies anexisting disk in theus-central1-a zone, then you must create yourreservation in the same zone.

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

• If the instance template specifies a compact placement policy, you must createaspecific reservation. Then, when you create the VMs toconsume the reservation, you mustspecifically targetthe reservation by name. Otherwise, the VMs can't consume the reservation.

Additional quota requirements for shared reservations

Additionally, there are the following quota implications for the owner andconsumer projects of a shared reservation:

• Owner project: The owner project consumes quota as follows:

  • When creating the shared reservation, the owner project consumes quota forthe total reserved resources.

  • When consuming reserved resources, the owner project consumes quota for theresources that it consumes.

• Consumer projects: The consumer projects consume quota only when consumingthe reserved resources and only for the resources that they consume.

For example, assume that project A (the owner project) creates a sharedreservation for 10 resources and shares the reservation with project B and C(the consumer projects). Upon creating the shared reservation, project Aconsumes quota for 10 resources. Then, if project A and B consume 2 reservedresources each, project A and B each consume quota for 2 resources. In total,project A consumes quota for 12 resources, project B consumes quota for 2resources, and project C consumes quota for 0 resources (as it didn't consumethe reservation).

Additional requirements for reservations with compact placement policies

Additionally, to specify a compact placement policyfor a reservation, make sure of the following requirements:

• The compact placement policy must support reservations:

  • The compact placement policy can't specify a maximum distance value of1.

  • The compact placement policy can't be specified by more than one reservationat a time.

• The reservation must support compact placement policies:

  • You can only specify a compact placement policy for an on-demand,single-project, specifically targeted reservation that is not attached to acommitment.

  • The VMs reserved by the reservation must be supported by the compactplacement policy:

    • The reservation's zone must be within the region of the compactplacement policy.

    • The reservation's number of VMs can't exceed the maximum number of VMsthat the compact placement policy supports.

    • The reservation's machine type must be supported by compact placementpolicies.

Restrictions

All reservations have the following restrictions:

• You can only use reservations with the following Google Cloudproducts:

  • Batch
  • Compute Engine
  • Dataflow
  • Dataproc
  • Google Kubernetes Engine
  • Vertex AI

• You can reserve up to 1,000 VMs per reservation.

• You can't reserve A4X, A4, A3 Ultra, or A3 High (with less than 8 GPUs) VMs.

• You can only reserve A3 Mega, A3 High (8 GPUs), or A3 Edge VMs throughspecifically targeted reservations.

  Note: This restriction doesn't affect reservations of A3 Mega, A3 High, orA3 Edge VMs that were created before July 11, 2024. You can continue to usethose reservations as configured.

• You can't use reservations with the following Compute Engineresources:

  • f1-micro andg1-small machine types

  • Spot VMs or preemptible VMs

  • Sole-tenant nodes

• You can only update thereservation affinity property ofVMs to automatically consume any matching reservation (ANY_RESERVATION) orno reservations (NO_RESERVATION).

Additional restrictions for reservations attached to commitments

Additionally, reservations that are attached to commitments have the followingrestrictions:

• You can attach reservations only to resource-based commitments.

• You can attach reservations only while you're purchasing your commitment.

• You can attach a specific reservation to only one single commitment.

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

To learn more, seeAttach reservations to resource-based commitments.

Additional restrictions for shared reservations

Additionally, shared reservations have the following restrictions:

• You can only share reservations with projects in the same organizationas 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 eachunique combination ofVM properties.

• You can onlylist the reservations created by a specific project.This means that each shared reservation is only listed in the project thatcreated it—you can't list all of the shared reservations inan organization or all of the reservations that are shared with a specificproject.

• If you create a shared reservation byspecifying an instance template,only the users within your project can access the same instance template anduse it to create VMs or other reservations.

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

• If you move a project that was using shared reservations to a neworganization, its shared reservations don't migrate to the new organization.Any shared reservations that were created in this project are deleted, and anyreservations from the previous organization that were shared with this projectcan't be consumed in the new organization. For more information, seeHow shared reservations work in thisdocument.

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

Additional restrictions for reservations with compact placement policies

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

• You can't share a compact placement policy across reservations. Instead, youmust use a separate compact placement policy for each reservation that youwant to apply a compact placement policy to.

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

Billing

Reservations are billed at the same rate as their reserved resources, includingthe same on-demand prices and1-minute minimum chargesas unreserved, running VMs.Sustained use discounts (SUDs),CUDs, and custom pricing alsoapply as they would for running VMs.

Note: When you use reservations with Google Cloud Serverless for Apache Spark, you can'treceive resource-based CUDs for those resources. If you use reservations withDataflow, then you can receive CUDs only forspecificallytargeted reservations that specify accelerators. For more information, seeUseCompute Engine reservations withDataflow.

For example, suppose that you have the following scenario:

• You have a 3-vCPU commitment inus-central1.
• You're running 5 vCPUs inus-central1-a.
• You have a 10-vCPU reservation inus-central1-a.

In this scenario, Google Cloud bills you as follows:

Covered by	Number 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 thereservation exists, regardless of whether or not its resources are being used.While consuming a reservation, a VM does not incur duplicate resources chargessince the reservation is already billed for the cost of the reserved resources.For details, seeVMs pricing.

Additionally, you can monitor the consumption trends of your reservations toreduce unnecessary costs from wasted or unused resources. For more information,seeMonitor reservations consumption.

Additional billing information for shared reservations

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

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

• Billing project: By default, the owner project is billed for the sharedreservation. But, when a resource from a shared reservation is being consumedby a consumer project, the consumer project is billed for the reservationinstead.
• Billing discounts: By default, billing uses the on-demand price. But, ifyou are eligible to receive CUDs for either the project that is being billedor the Cloud Billing account associated with that project, then thediscounted price is used instead.

What's next

• Learn how to create reservations:
  • Create a reservation for a single project.
  • Create a shared reservation.