To maximize resource usage and reduce management overhead, you can sharereservations of Compute Engine resources across multiple projects in yourGoogle Cloud organization. A shared reservation allows up to 100 projects in thesame organization to create Compute Engine instances by using the samereserved capacity.

Shared reservations offer the following benefits:

• You maximize the use of reserved capacity.

• You lower costs by minimizing idle resources.

• You manage a single, shared reservation rather than many.

This document explains the best practices for creating and managing sharedreservations. For more information about the different methods to reserveCompute Engine resources, seeChoose a reservation type.

Best practices for shared reservations

When you create a shared reservation, or Compute Engine creates one tofulfill a future reservation request, we recommend the following best practicesto help you manage and use the reservation:

• Have the owner project create the shared reservation but not consume it.

  • To distribute costs among projects, we recommend that onlyconsumer projects, the projects you share a reservation with, consume the reservation. Only use theowner project, the project in which the reservation exists, to create shared reservations.
  • When you create a shared on-demand reservation or future reservation, the owner project must have sufficient quota for the total resources to reserve. Then, after Compute Engine creates the reservation, the owner project must have quota for any reserved resources that it wants to consume. For more information, see Additional quota requirements for shared reservations.

• Minimize the number of projects in your organization that can create shared reservations.

  • You can view only the reservations that exist in your project. Thus, you can only view a shared reservation in its owner project. Having only a few owner projects in your organization helps you monitor and manage your shared reservations. To control which projects can create shared reservations, see Manage shared reservation creation.
  • Share a reservation only with a few projects to better manage the quota of your reserved resources.

• Minimize the number of separate shared reservations with identical compute instance properties.

  • An organization can have up to 100 shared reservations for each unique combination of compute instance properties. As a result, if you minimize the number of shared reservations with identical compute instance properties, you mitigate this limit.
  • Having fewer shared reservations improves manageability.

• Only share reservations between projects with the same Cloud Billing account.

  • Limit each shared reservation to consumer projects that have the same Cloud Billing account as the owner project. This approach helps you track reservation consumption and associated billing.Caution: If you have a shared reservation and also have CUD sharing enabled for your commitment's Cloud Billing account, then we recommend that you share your reservationonly with projects that are linked to the commitment's Cloud Billing account. Otherwise, when projects outside the Cloud Billing account consume that shared reservation, their usage won't be eligible for this Cloud Billing account's shared resource-based CUDs and will incur charges at on-demand rates.
• For future reservation requests, carefully review the total count of compute instances that you request.
  • If you are creating a future reservation request, then verify that you request atotal count of compute instances that includes all of the following:
    • All matching reserved compute instances that will already exist at the future date.
    • All matching unreserved compute instances that will already exist at the future date.
    • Any matching, unused on-demand reservations that will already exist at the future date.
    • The increase in usage that you want to reserve at the future date.

    For example, suppose that you need 10 additional compute instances at a future date and you'll already have the following resources at that future date:

    • 40 matching reserved compute instances
    • 50 matching unreserved compute instances

    or

    • 40 matching reserved compute instances
    • 50 matching unused on-demand reservations

    Because your existing usage at the future date already adds up to 90 matching compute instances and reservations, and you need an additional ten compute instances, you must specify a total count of100 in your future reservation request.

    Note: If you create additional on-demand reservations after you submit the future reservation request and before the future date, then those reservations are counted toward your total count.
    
    If you add more on-demand reservations after the future date, then those reservations are added to the previous total. For example, if after the future date, you reserve another ten compute instances, then you end up with 110 compute instances as your total reserved resources.

    For more information, see Count and provision reserved resources.

What's next

• Manage shared reservation creation