About future reservation requests

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

Use future reservations to request assurance of important or difficult-to-obtain capacity in advance.

Overview

Compared to on-demand reservations, future reservations provide you with an even higher level of assurance in obtaining capacity for Compute Engine zonal resources. With future reservations, you can request to reserve capacity starting on a specific date up to 1 year in the future. After you create a future reservation, Google Cloud reviews your request and, if approved, Compute Engine provisions the requested capacity on the date and time you specified. This process helps ensure that the requested resources are available and reserved for your projects when you need them, and prevents you from not obtaining the requested resources due to resource availability errors. For example, future reservations can be useful to do the following:

  • Migrate a large number of virtual machine (VM) instances.

  • Obtain highly-demanded resources.

  • Secure capacity for peak scale events.

Each future reservation provides a very high-level of assurance for one or more VMs with the same properties in a specific zone. If Google Cloud approves a future reservation request, then, on the date you requested to have the reserved capacity available, Compute Engine subtracts any matching, existing reservations and running VMs, and it automatically creates reservations to reach the requested capacity specified in the future reservation. The new automatically created reservations can then be consumed just like on-demand reservations, and they prevent anyone else from using your reserved resources until they're deleted.

There are no additional costs for creating future reservation requests. You only start to pay when Compute Engine provisions the reserved resources, and you're charged at the same cost as on-demand reservations.

How future reservations work

The details of how future reservations work are outlined in the following sections.

Future reservations properties

When you create a future reservation request, you must define the following properties:

  • Name prefix

    The name prefix specifies a string to include at the start of the name of each automatically created (auto-created) reservations provisioned for this request. You can then filter by one or more name prefixes to identify the auto-created reservations when you view a list of reservations.

  • Share type (single-project or shared)

    • A single-project future reservation is useful if you want to consume your reserved VMs only in a single project. For more information, see single-project reservations.

    • A shared future reservation is useful if you want the project that hosts the future reservation (the owner project) and any other project that the future reservation is shared with (the consumer projects) to consume your reserved VMs. You can only share a shared future reservation with up to 100 consumer projects that belong to the same organization. For more information, see shared reservations.

  • Reservation period (start time and end time)

    • The start time specifies the start of your reservation period, which is the date and time when Compute Engine has finished provisioning the auto-created reservations. You can then create VMs to consume the auto-created reservations. Make sure to specify a start time that accounts for the time you need to create the VMs to consume the auto-created reservations. The start time can only be within 1 year from the date and time you submit a future reservation request for review.

    • The end time specifies the end of your reservation period, which is the date and time when the future reservation request can be deleted, and the auto-created reservations with your reserved resources can be deleted or modified. The end time must be at least 24 hours after the start time and has no maximum; however, the end time should last as long as a recommended minimum reservation period to increase the likelihood that Google Cloud approves a future reservation request.

  • Total count

    The total count specifies the total number of VMs with the specified zone and VM properties that you want a very high-level of assurance for at the start time. After Google Cloud approves a future reservation request, Compute Engine provisions the auto-created reservations by accounting for any existing, matching reservations that can only be consumed by (some or all of) the projects specified in the future reservation request. For more information, see how Compute Engine counts and provisions reserved resources in this document.

  • VM properties

    The VM properties define 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 future reservation request, you can specify these properties directly, specify the properties based on an existing VM, or specify the properties by using an instance template. A VM can consume an auto-created reservation only if both the VM's properties and the auto-created reservation's VM properties match exactly. With future reservations, you can only specify an automatic consumption type and you can't specify a compact placement policy.

  • Zone

    The zone where you want to request capacity. The combination of zone and machine type (see VM properties) that you specify for your reserved resources affects the likelihood that Google Cloud approves a future reservation request or not. For more information, see Future reservations review process in this document.

Additionally, you can define the following properties:

  • Auto-delete

    The auto-delete option specifies whether or not you want Compute Engine to automatically delete (auto-delete) any auto-created reservations provisioned for this request, regardless if they're fully consumed or not. Compute Engine deletes the auto-created reservations within 2 hours after the specified deletion time. Automatically deleting auto-created reservations can be useful to avoid unnecessary charges for the auto-created reservations that aren't consumed for some time.

  • Description

    The description specifies an optional text to describe the properties of your future reservation request.

  • Planning status

    The planning status specifies if a future reservation request was submitted for review to Google Cloud or not. For more information, see Future reservations status in this document.

Future reservations status

This section specifies the possible states that a future reservation request can be set to. A future reservation request contains the following status fields:

  • Planning status

    This section explains the planning status, which you specify when creating a future reservation request. The planning status specifies if a future reservation request is in a draft state or was submitted to Google Cloud for review.

  • Procurement status

    This section explains the procurement status, which is set by Compute Engine after you create a future reservation request. At first, the procurement status field displays the approval status of a future reservation request. After Google Cloud approves a future reservation request and the request enters its lock time, this field displays the procurement status of the requested resources.

Future reservations planning status

When creating a future reservation request, you can set its planning status (planningStatus) to one of the following values:

  • Draft (DRAFT): By default, you create a draft future reservation request. You can modify the draft of a future reservation request as needed and, when you're satisfied with your changes, you can submit it to Google Cloud for review. Google recommends creating a draft request first as this lets you determine the number of VMs that Compute Engine will provision for the request instead of manually estimating this number, and optionally modify the number of reserved VMs in the request before submitting it for review.

  • Submitted (SUBMITTED): The future reservation request was submitted for review to Google Cloud. After you submit a future reservation request for review, you can't change its planning status back to DRAFT. Optionally, you can immediately submit a future reservation request for review when creating it.

Future reservations procurement status

After creating a future reservation request, Compute Engine sets its procurement status (procurementStatus) to one of the following values:

  • Drafting (DRAFTING): The future reservation request is in its draft state.

  • Pending approval (PENDING_APPROVAL): The future reservation request is submitted for approval to Google Cloud. While the request is in review, the procurement status of a future reservation request can be set to one of the following:

    • Declined (DECLINED): Google Cloud has declined the future reservation request. You can still modify the future reservation request and, after you've finalized your changes, submit it again for approval.

    • Approved (APPROVED): Google Cloud has approved the future reservation request and Compute Engine plans to provision the auto-created reservations with the requested capacity at the start time of the reservation period. If Google Cloud approves the future reservation request within 56 days (8 weeks) from its start time, then the future reservation enters its lock time within a few minutes.

    • Canceled (CANCELED): A user canceled the future reservation request during review, or after Google Cloud approved or declined it.

    After a future reservation request is approved or declined, you can modify one or more properties of the future reservation request and submit it again to Google Cloud for review. This action sets the status of the future reservation back to pending approval.

  • Procuring (PROCURING): 56 days (8 weeks) from the start time of its reservation period, a future reservation enters its lock time. After the future reservation enters this state:

    • You can't cancel the future reservation anymore.

    • You can only delete the future reservation after its end time.

    • If you want to modify the reservation period, the share settings, the total count, or the VM properties of the future reservation, you must request approval from Google Cloud. After then, Google Cloud approves or declines your request by changing its update status. If Google Cloud declines a request and you don't submit new ones, Compute Engine provisions the reserved resources using the previously-specified properties.

    If a future reservation specifies a reservation period that is less than 56 days from the date and time you submit a future reservation request, then the future reservation enters its lock time within a few minutes after approval.

  • Provisioning (PROVISIONING): 24 hours before the start time specified in a future reservation, Compute Engine starts to provision the requested resources by automatically creating reservations. Then, Compute Engine sets the procurement status of the future reservation to one of the following:

    • Fulfilled (FULFILLED): Compute Engine has provisioned all the resources required to reach the total count specified in the future reservation.

    • Partially fulfilled (FAILED_PARTIALLY_FULFILLED): Compute Engine has only provisioned part of the resources required to reach the total count specified in the future reservation because of insufficient quota.

    • Failed (FAILED): Compute Engine has failed to provision the reserved resources.

    The auto-created reservations can be consumed at the start time. To make sure you have the total capacity requested, identify any unconsumed auto-created reservations and create VMs to consume them. You can only modify or delete an auto-created reservation after the end time specified in the future reservation. For more information, see How Compute Engine provisions resources in this document.

Future reservations updates

After creating a future reservation request, you can optionally update it—cancel it, delete it, modify it, or request to modify it. However, you can only update future reservation requests during certain time frames, as explained in the following sections.

Future reservation lock time

After you submit a future reservation request, you can cancel or delete it any time before Google Cloud starts procuring (PROCURING) its resources, at which point the future reservation enters its lock time. During the lock time for a future reservation, you can no longer cancel it and can't delete it until after its end time.

Additionally, the lock time affects when you can request modifications. The lock time for a future reservation request begins at one of the following times:

  • If the future reservation request specifies a start time that is less than 56 days (8 weeks) away from when its submitted, the future reservation request enters the lock time shortly after it's approved.

  • Otherwise, the lock time for the future reservation request begins 56 days from its start time.

Future reservation modification

If a future reservation request isn't canceled or pending approval, then you can modify the request at any time before it reaches a procurement status of Provisioning (PROVISIONING).

After a future reservation request is approved, you can modify the following properties only if you request a modification from Google Cloud:

  • GPUs and GPU type

  • Local SSD disks and the disks interface type

  • Machine series and machine type

  • Minimum CPU platform

  • Share settings

  • Start and end time of the reservation period

  • Total count (Number of VMs)

You can only request one modification (of one or more properties) for an approved future reservation at a time. Additionally, if you submit the following types of modification requests, Google Cloud is likely to decline them:

  • Any requests made within 72 hours of the start time.

  • Any requests to modify VM properties made within 14 days of the start time.

  • Any requests to significantly increase or decrease the total count made within 14 days of the start time.

Submitting a modification request creates the update status (AmendmentStatus) field in the future reservation. After Google Cloud reviews the request, Compute Engine sets the update status to one of the following values:

  • Update pending approval (AMENDMENT_PENDING_APPROVAL): Google Cloud is reviewing your request.

  • Update approved (AMENDMENT_APPROVED): Google Cloud has approved your request. Compute Engine will provision the reserved resources using the approved properties.

  • Update declined (AMENDMENT_DECLINED): Google Cloud has declined your request. Unless you submit a new request and the request is approved, Compute Engine provisions the reserved resources using previously-approved properties.

To learn more about how to modify future reservation requests and the properties that you can modify, see Modify future reservation requests.

Future reservations review process

To provision the requested capacity, any future reservation request must be submitted to Google Cloud for review. After you submit a request, Google Cloud can take up to five business days to review your request. If Google Cloud needs more than five business days to review your request or has questions, your assigned Technical Account Manager or the Sales Team will contact you.

If a future reservation request or modification request is approved, then Google Cloud uses commercially reasonable efforts to make your requested capacity available at the start time of the future reservation's reservation period. Google Cloud prioritizes the delivery of your reserved capacity over other customers without approved future reservations with the same properties. For more information, see Service Specific Terms.

To increase the likelihood that Google Cloud approves a future reservation request, make sure to specify the following when creating or modifying a future reservation request:

56 days (8 weeks) from the start time of its reservation period, any approved future reservation request enters a lock time. If the start time specified in an approved future reservation is less than 56 days from the date and time you submit a future reservation request for review, then the future reservation request enters its lock time within a few minutes from approval.

To have enough time to cancel or delete a future reservation request, as well as submit a modification request, specifying a start time that is more than 56 days from the date and time you submit a future reservation request for review is recommended.

As long as the reservation period of a future reservation lasts more than 24 hours, there are no restrictions to the length a reservation period can be. However, depending on the machine type and zone you specify in a future reservation request, Google Cloud is more likely to approve a future reservation request if its reservation period specifies one of the following recommended minimum reservation periods:

  • 14 days. Specify a minimum reservation period of 14 days when your future reservation request specifies both of the following:

    • An N1, N2, or N2D machine series

    • A zone in one of the following regions:

      America Asia Europe
      Iowa (us-central1) Singapore (asia-southeast1) Belgium (europe-west1)
      Oregon (us-west1) Germany (europe-west3)
      South Carolina (us-east1) Netherlands (europe-west4)
      Virginia (us-east4)

  • 365 days. Specify a minimum reservation period of 365 days when your future reservation request specifies any other combination of available regions for Compute Engine and supported machine series.

If you specify a different reservation period than a recommended one, then Google Cloud is less likely to approve a future reservation request or modification request.

How Compute Engine provisions reserved resources

This section explains how Compute Engine provisions the reserved resources:

  • Count and provision reserved resources

    This section explains how Compute Engine accounts for existing future reservations, reservations, and VMs that match your request when provisioning the total count of resources for an approved future reservation.

  • Auto-created reservations

    This section explains the type of reservations that Compute Engine creates for an approved future reservation at its start time.

Count and provision reserved resources

To reach the total count of an approved future reservation request, Compute Engine does the following:

  1. Compute Engine subtracts any matching existing (consumed and unconsumed) reservations that are only shared with (some or all of) the projects specified in the future reservation.

  2. Compute Engine automatically creates reservations for the remaining amount. This means the following:

    • Any existing matching VMs start consuming the auto-created reservations.

    • You'll need to create matching VMs for any auto-created reservation that wasn't consumed.

For example, assume that you create a shared future reservation request in zone us-central1-a. This future reservation request specifies a total count of 10 VMs with n2-standard-2 machine type, project A as the owner project, and project B and C as the consumer projects. After this future reservation request is approved and Compute Engine starts creating reservations at the start time of the reservation period, assume that these projects contain the following resources with VM properties that match the future reservation:

  • In project A, 1 running VM that is not consuming a reservation.

  • In project B, 1 unconsumed shared reservation with project C for 2 VMs.

  • In project C, 1 unconsumed single-project reservation for 1 VM.

In this scenario, Compute Engine automatically creates a shared reservation for 7 VMs to reach a total count of 10 VMs at the start time.

To learn how to determine the number of VMs that Compute Engine plans to provision for an existing future reservation request, see Determine the number of provisioned VMs.

Auto-created reservations

24 hours before the start time specified in a future reservation, Compute Engine starts provisioning the requested capacity in an approved future reservation by automatically creating reservations, but you're only charged for the auto-created reservations at the start time. Each auto-created reservation has the following properties:

  • It can be automatically consumed by creating VMs with matching properties.

  • It has matching VM properties as the ones specified in its future reservation request.

  • It matches the share settings of its future reservation request. Specifically:

    • If you created a single-project future reservation request, each auto-created reservation is a single-project reservation.

    • If you created a shared future reservation request, each auto-created reservation is a shared reservation that specifies the same owner project and consumer projects.

  • Its name starts with the name prefix specified in its future reservation request.

  • If you enabled the auto-delete option when creating or modifying a future reservation request, each auto-created reservation specifies a deleteAtTime field set to the time when Compute Engine automatically deletes the auto-created reservation.

Auto-created reservations can't be modified or deleted until the end time of the future reservation request. Otherwise, you can consume, modify, and delete auto-created reservations the same as on-demand reservations.

Restrictions

The restrictions for reservations are outlined in the following sections.

Restrictions on creation

When creating a future reservation request, the following restrictions apply:

  • If you have existing reservations with matching properties, read the following:

    • If your project already contains auto-created or on-demand reservations, or these reservations are shared with your project, you can only create future reservation requests shared across all the projects specified in the existing reservations.

    • If your project already contains a single-project future reservation request, you can create single-project future reservation requests only.

    • If your project already contains a shared future reservation request, or a future reservation request is shared with your project, you can only create shared future reservation requests across the same projects. For example, a shared future reservation request in project A (the owner project) that is shared with project B and C (the consumer projects), means that you can do the following:

      • Create another shared future reservation request in project A and share it with projects B and C.

      • Create a shared future reservation request in project B and share it with projects A and C.

      • Create a shared future reservation request in project C and share it with projects A and B.

  • You can only specify to provision the requested resources using automatically consumed reservations.

  • You can't specify A3 or E2 machine types.

  • You can't specify a reservation period shorter than 24 hours.

  • You can't specify a reservation period that overlaps with the reservation period of another existing future reservation request with matching VM properties and zone. The existing future reservation request can be either located in the same project where you're creating the future reservation request, or in a project you want to share your future reservation request with.

  • You can't specify a start time that is after 1 year from the date and time you submit a future reservation request for review.

  • You can't specify placement policies.

Restrictions after creation

After creating a future reservation request, the following restrictions apply:

  • If you move a project that created a future reservation request to a different organization and the future reservation hasn't entered its lock time yet, the future reservation request is deleted.

  • After a future reservation request is approved and enters its lock time, the following restrictions apply:

    • You can't cancel the future reservation anymore.

    • If you want to attach auto-created reservations to a commitment, the following restrictions apply:

      • You can purchase the commitment only during the last 24 hours before the start time of the reservation period.

      • You can attach only the auto-created reservations that have the auto-delete option disabled. If you enabled the auto-delete option when creating or modifying a future reservation request, you must disable the option.

    • You can only delete the future reservation after its end time.

  • After a future reservation enters its start time, you can only modify or delete the auto-created reservations provisioned for the future reservation after the end time.

Billing

There are no additional costs for creating future reservation requests.

After a future reservation request is approved and enters its lock time, you commit to pay for the total provisioned capacity for the entire reservation period, unless you request Google Cloud to modify the number or the VM properties of the resources you're reserving before the start time of the reservation period. If Google Cloud approves the request, you then commit to pay for the updated requested capacity.

At the start time of a future reservation's reservation period, Google Cloud charges you only for the auto-created reservations to reach the total count specified in the future reservation. If Compute Engine can only partially deliver the requested capacity, you're only charged for the provisioned resources.

Any auto-created reservation incurs charges as follows:

  • At the same rate of on-demand reservations.

  • While the reservation exists, regardless if you use the reserved resources or not.

What's next