Summary

  • Google Cloud's 8 September update makes conversion between single-project and shared Compute Engine reservations generally available. It changes access to existing reserved capacity, not its quantity.
  • Sharing can improve utilisation, but it does not eliminate idle charges. Reverting a specifically targeted shared reservation also carries conditions for consumer instances and their restart.

A reservation can change its audience

A capacity buffer bought for one project may be useful to another before its original workload arrives. Google Cloud now gives administrators a way to change that reservation's audience. Its 8 September Compute Engine release notes make share-type conversion generally available: eligible single-project reservations can become shared reservations, and shared reservations can become single-project ones.

This is not the invention of shared reservations. The new step is changing between the two types. Nor is it a marketplace for selling capacity to another organisation. Google's modification guide limits sharing to up to 100 projects in the same organisation. A shared reservation is modified from the project where it was created; ownership does not move to whichever team uses the resources.

For a central cloud team, the commercial attraction is straightforward. Compatible demand elsewhere in the organisation may use capacity that would otherwise sit idle. But the change neither creates additional reserved resources nor overrides the permissions and quota requirements that govern sharing.

The bill follows use, with a residual owner

Google's reservation overview explains why unused capacity matters: reserved resources incur charges while the reservation exists, whether they are being used or not. Consuming them does not create duplicate charges for the same reserved resources.

Sharing itself adds no separate charge. By default, the owner project is billed; when a consumer project uses resources from the shared reservation, that consumer project is billed for those resources instead. Applicable committed-use discounts and other pricing arrangements can affect the rate. An access change is therefore not a promise of an identical bill across projects, and it is not a new discount.

Imagine one team holding a buffer for an upcoming workload while another has compatible demand today. This is a hypothetical example, not a customer result reported by Google. Sharing may turn some idle capacity into useful work. If both teams subsequently need it at once, however, the organisation still has a finite pool. The setting cannot settle their business priorities.

Returning the pool is not just reversing a choice

The less obvious part of the update concerns withdrawal. For a shared reservation that consumer instances specifically target, Google's guide requires those consuming instances in consumer projects to be stopped, suspended or deleted before conversion to single-project use. That requirement does not apply to instances in the owner project.

The guide adds a restart condition. Consumer instances that were stopped or suspended and target the shared reservation cannot restart or resume until a replacement reservation exists in the same owner project and zone, with the original name and matching properties. This is a documented dependency, not a report of an outage or a recommendation to delete workloads. It must not be generalised to every instance that automatically consumes shared capacity.

The modification guide also sends reservations attached to commitments to a separate replacement procedure; automatically created future reservations have their own limits. The announcement does not make every reservation type or commercial commitment freely editable.

The new flexibility is real. So is the distinction between changing an access policy and unwinding work that has come to rely on it.