Merge and split commitments

To help you manage the resource requirements for your projects, Compute Engine lets you merge or split your existing commitments and redistribute your resources to match the granularity that your projects require.

This document describes the benefits and process of merging and splitting commitments, including their limitations and requirements.

Before you begin

If you haven't already, set up authentication . Authentication verifies your identity for access to Google Cloud services and APIs. To run code or samples from a local development environment, you can authenticate to Compute Engine by selecting one of the following options:
Select the tab for how you plan to use the samples on this page:
Console

When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.
gcloud
1. Install the Google Cloud CLI. After installation, initialize the Google Cloud CLI by running the following command:
  gcloud init
  If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity .
  
  Note:If you installed the gcloud CLI previously, make sure you have the latest version by running gcloud components update .
2. Set a default region and zone .
REST

To use the REST API samples on this page in a local development environment, you use the credentials you provide to the gcloud CLI.
For more information, see Authenticate for using REST in the Google Cloud authentication documentation.

Merge commitments

You can merge multiple compatible commitments to create a new larger commitment. By merging commitments, you can track and manage them as a single entity. Merging commitments helps you avoid staggered commitment end dates by co-terming the individual commitments to expire at the same time. Merging also lets you gradually ramp up your workloads. For example, you can purchase newer, smaller commitments when the need arises and choose to merge them together or with an existing commitment.

How merging works

When you merge individual commitments (source commitments), you create a new commitment (merged commitment) that combines resources from all source commitments. At 12 AM US and Canadian Pacific Time (UTC-8, or UTC-7 during daylight saving time) on the following day, the merged commitment becomes active and the source commitments are canceled. This activation date becomes the merged commitment's start date, and the merge operation concludes.

The merged commitment inherits the following properties, regardless of whether the source commitments have a preset or custom term duration:

The end date that is furthest in the future among the source commitments.
The term extension eligibility window that ends the earliest among the source commitments.

Because the merged commitment can be created only after your source commitments are active, the merged commitment might have a custom term duration instead of the preset term duration of 1 or 3 years. However, the merged commitment retains the 1- or 3-year commitment plan of the source commitments.

For example, consider two source commitments starting on January 1, 2020, and December 1, 2020. Their end dates are January 1, 2023, and December 1, 2023, respectively. The term extension eligibility window for the first commitment remains open until May 1, 2020, and for the second commitment until April 1, 2021. If you merge these commitments on March 1, 2022, then your merged commitment is a custom term commitment with a start date of March 2, 2022, and an end date of December 1, 2023. The term extension eligibility window for the merged commitment would have already ended by May 1, 2020.

If any source commitments have reservations attached, then the reservations are preserved during the merge and are attached to the merged commitment after its creation. For more information about commitments with attached reservations, see Attach reservations to resource-based commitments .

Example of a merged commitment

The following table shows the properties of source and merged commitments when you merge two commitments ( source-commitment-1 and source-commitment-2 ) into a single commitment ( merged-commitment ) on March 1, 2022:

First source commitment

Second source commitment

Merged commitment

Name

source-commitment-1

source-commitment-2

merged-commitment

Type

Region

us-central1

Resources

vCPUs: 100
Memory: 100 GB

vCPUs: 200
Memory: 300 GB

vCPUs: 300
Memory: 400 GB

Term

3 years

Start date ^*

January 1, 2020

December 1, 2020

March 2, 2022
(the day after the merge)

End date ^†

January 1, 2023

December 1, 2023

Term extension eligibility window open until

May 1, 2020

April 1, 2021

May 1, 2020

^* All commitments start at 12 AM US and Canadian Pacific Time (UTC-8 or UTC-7) on the specified start date.
^† All commitments expire at 12 AM US and Canadian Pacific Time (UTC-8 or UTC-7) on the specified end date.

Pricing implications

Your commitment fee is the sum of the discounted prices of all your committed resources. When you merge your commitments, the discounted prices of the merged commitment's resources might change on the day the merged commitment becomes active. This new discounted price for each resource remains the same until the end of your merged commitment's term, even if on-demand prices change. However, if you merge or split this commitment again, then the discounted prices of the resources might change again.

Limitations

You can't merge license commitments.
The merged commitment automatically includes any reservations already attached to source commitments. You can't attach any additional reservations (new or existing) to the merged commitment.
You can't merge commitments that have expired or are canceled.
By default, when you create merged commitments, the auto-renewal setting is disabled on the new commitments, even if all source commitments were set to renew automatically. If you want your merged commitments to renew automatically, then you must manually enable the auto-renewal setting on those commitments. You can do so either at the time of their creation or after their creation .

Requirements

When you merge individual source commitments to create a new merged commitment, your source and merged commitments must meet the following requirements:

The source commitments must have the same project, region, commitment plan, commitment type, and commitment category.
The merged commitment must have the same project, region, commitment plan, commitment type, and commitment category as the source commitments. However, you can choose a new name for your merged commitment.
The resource types you specify for your merged commitment must exactly match the resource types in the source commitments. Additionally, the quantity for each resource type in your merged commitment must be the sum of the quantities for that resource type in all source commitments. For example, if the first source commitment has 100 vCPUs and 100 GB memory, and the second source commitment has 200 vCPUs and 300 GB memory, then you must create your merged commitment with 300 vCPUs and 400 GB memory.
The source and merged commitments must be for hardware resources (vCPUs, memory, GPUs, and Local SSD disks).

Create merged commitments

Create a merged commitment by using the gcloud CLI or REST. Before you merge commitments, review the limitations for merging .

Permissions required for this task

To perform this task, you must have the following permissions :

compute.commitments.create on the project or organization.

Console

In the Google Cloud console, select the project where you want to merge commitments. Then, go to the Committed use discountspage.

Go to Committed use discounts
To initiate the merge operation for a set of commitments, in the Hardware commitmentstab of the Commitment listpage, click Merge.

Alternatively, you can also select the commitments that you want to merge from the list and then click Merge.
On the Choose commitmenttab of the Mergepage that opens, do the following:
1. Under Choose commitments to merge, select the commitments that you want to merge from the list. If you already selected these commitments on the Commitment listpage, then verify your selected commitments on this tab.
  
  Optional: To filter the commitment list, specify the Plan, Region, and Commitment typevalues for your merged commitment before you select any commitments.
2. Click Next. The Reviewtab opens.
On the Reviewtab of the Mergepage, do the following:
1. Review and confirm the details of the merged commitment. To modify the list of individual commitments, select the Choose commitmenttab on the left side of the window and repeat step 3.
2. In the New commitment namefield, enter a name for your merged commitment.
3. Optional: To enable auto-renewal on your merged commitment, select the Enable auto renewcheckbox.
4. Read the Terms and conditions.
5. To finish creating your merged commitment and return to the Commitment listpage, click Merge.

gcloud

To merge existing commitments into a single commitment, use the gcloud compute commitments create command with the --merge-source-commitment flag.

gcloud compute commitments create COMMITMENT_NAME 
\
    --region= REGION 
\
    --project= PROJECT_ID 
\
    --plan= COMMITMENT_PLAN 
\
    --type= COMMITMENT_TYPE 
\
    --resources=vcpu= NUMBER_VCPUS 
,memory= MEMORY 
\
    --merge-source-commitments= SOURCE_COMMITMENT_URLS

Replace the following:

COMMITMENT_NAME : the name of your new merged commitment.
NUMBER_VCPUS : the sum of the numbers of vCPUs in the source commitments.
COMMITMENT_TYPE : the same commitment type as your source commitments, one of the following:
- For A2 machine types, use accelerator-optimized
- For A3 Edge and A3 High machine types, use accelerator-optimized-a3
- For A3 Mega machine types, use accelerator-optimized-a3-mega
  Note: For A4X Max, A4X, A4, or A3 Ultra machine types, you must purchase your commitments by using the future reservations in AI Hypercomputer consumption option. For more information, see Reserve capacity through your account team .
- For G2 machine types, use graphics-optimized
- For G4 machine types, use graphics-optimized-g4
- For C2 machine types, use compute-optimized
- For C2D machine types, use compute-optimized-c2d
- For C3 machine types, use compute-optimized-c3
- For C3D machine types, use compute-optimized-c3d
  Caution : For C3 and C3D commitment types, the machine family that is specified by the commitment type changes depending on the interface:
  - In the gcloud CLI and REST, the commitment type values use Compute-optimized as the machine family, even though C3 and C3D are part of the general-purpose machine family.
  - In the Google Cloud console, the commitment type values use the correct machine series: General-Purpose .
  Make sure to select the correct commitment type value that corresponds to the interface that you're using.
- For H3 machine types, use compute-optimized-h3
- For H4D machine types, use compute-optimized-h4d
- For N1 machine types, use general-purpose
- For C4 machine types, use general-purpose-c4
- For C4A machine types, use general-purpose-c4a
- For C4D machine types, use general-purpose-c4d
- For E2 machine types, use general-purpose-e2
- For N2 machine types, use general-purpose-n2
- For N2D machine types, use general-purpose-n2d
- For N4 machine types, use general-purpose-n4
- For N4D machine types, use general-purpose-n4d
- For N4A machine types, use general-purpose-n4a
- For Tau T2D machine types, use general-purpose-t2d
- For M1 or M2 machine types, use memory-optimized
- For M3 machine types, use memory-optimized-m3
- For M4 machine types, use memory-optimized-m4
- For M4 machine types with 6 TB of memory, use memory-optimized-m4-6tb
- For X4 machine types with 6 TB of memory, use memory-optimized-x4-6t
- For X4 machine types with 8 TB of memory, use memory-optimized-x4-8t
- For X4 machine types with 12 TB of memory, use memory-optimized-x4-12t
- For X4 machine types with 16 TB of memory, use memory-optimized-x4-960-16t
- For X4 machine types with 24 TB of memory, use memory-optimized-x4-1440-24t
- For X4 machine types with 32 TB of memory, use memory-optimized-x4-1920-32t
- For Z3 machine types, use storage-optimized-z3
REGION : the same region as your source commitments.
PROJECT_ID : the project ID of the project for which you want to merge commitments.
COMMITMENT_PLAN : the commitment plan ('12-month' or '36-month'), which must be the same as your source commitments.
MEMORY : the sum of the amounts of memory, in MB or GB, in the source commitments. For example, 1000 MB. If you don't specify a unit, then the default unit is GB.
SOURCE_COMMITMENT_URLS : a comma-separated list of at least two distinct source commitment URLs. Don't add spaces between the URLs.

For example, consider two source commitments in the us-east1 region with resources specified as four N2 vCPUs and 2048 MB, and three N2 vCPUs and 2048 MB, respectively. The commitment plan for each source commitment is 12-month . The following gcloud CLI command merges the two commitments and creates a new commitment called merged-commitment . The merged commitment specifies its resources as seven N2 vCPUs and 4096 MB, and its commitment plan is 12-month :

gcloud compute commitments create merged-commitment \
    --plan=12-month \
    --project=myproject \
    --region=us-east1 \
    --type=general-purpose-n2 \
    --resources=vcpu=7,memory=4096MB \
    --merge-source-commitments=projects/myproject/regions/us-east1/commitments/source-commitment-1,projects/myproject/regions/us-east1/commitments/source-commitment-2

REST

To merge existing commitments into a single commitment, use the regionCommitments.insert method .

POST https://compute.googleapis.com/compute/v1/projects/ PROJECT_ID 
/regions/ REGION 
/commitments
{
  "name": COMMITMENT_NAME 
,
  "plan": COMMITMENT_PLAN 
,
  "type": COMMITMENT_TYPE 
,
  "region": REGION 
,
  "resources": [
    {
      "type": "vCPUs",
      "amount": NUMBER_VCPUS 
}
    {
      "type": "MEMORY",
      "amount": MEMORY 
}
  ],
  "mergeSourceCommitments": [ SOURCE_COMMITMENT_URL 
...]
}

Replace the following:

PROJECT_ID : the project ID of the project for which you want to merge commitments.
REGION : the same region as your source commitments.
COMMITMENT_TYPE : the same commitment type as your source commitments, one of the following:
- For A2 machine types, use ACCELERATOR_OPTIMIZED
- For A3 Edge and A3 High machine types, use ACCELERATOR_OPTIMIZED_A3
- For A3 Mega machine types, use ACCELERATOR_OPTIMIZED_A3_MEGA
  Note: For A4X Max, A4X, A4, or A3 Ultra machine types, you must purchase your commitments by using the future reservations in AI Hypercomputer consumption option. For more information, see Reserve capacity through your account team .
- For G2 machine types, use GRAPHICS_OPTIMIZED
- For G4 machine types, use GRAPHICS_OPTIMIZED_G4
- For C2 machine types, use COMPUTE_OPTIMIZED
- For C2D machine types, use COMPUTE_OPTIMIZED_C2D
- For C3 machine types, use COMPUTE_OPTIMIZED_C3
- For C3D machine types, use COMPUTE_OPTIMIZED_C3D
  Caution : For C3 and C3D commitment types, the machine family that is specified by the commitment type changes depending on the interface:
  - In the gcloud CLI and REST, the commitment type values use Compute-optimized as the machine family, even though C3 and C3D are part of the general-purpose machine family.
  - In the Google Cloud console, the commitment type values use the correct machine series: General-Purpose .
  Make sure to select the correct commitment type value that corresponds to the interface that you're using.
- For H3 machine types, use COMPUTE_OPTIMIZED_H3
- For H4D machine types, use COMPUTE_OPTIMIZED_H4D
- For N1 machine types, use GENERAL_PURPOSE
- For C4 machine types, use GENERAL_PURPOSE_C4
- For C4A machine types, use GENERAL_PURPOSE_C4A
- For C4D machine types, use GENERAL_PURPOSE_C4D
- For E2 machine types, use GENERAL_PURPOSE_E2
- For N2 machine types, use GENERAL_PURPOSE_N2
- For N2D machine types, use GENERAL_PURPOSE_N2D
- For N4 machine types, use GENERAL_PURPOSE_N4
- For N4D machine types, use GENERAL_PURPOSE_N4D
- For N4A machine types, use GENERAL_PURPOSE_N4A
- For Tau T2D machine types, use GENERAL_PURPOSE_T2D
- For M1 or M2 machine types, use MEMORY_OPTIMIZED
- For M3 machine types, use MEMORY_OPTIMIZED_M3
- For M4 machine types, use MEMORY_OPTIMIZED_M4
- For M4 machine types with 6 TB of memory, use MEMORY_OPTIMIZED_M4_6TB
- For X4 machine types with 6 TB of memory, use MEMORY_OPTIMIZED_X4_480_6T
- For X4 machine types with 8 TB of memory, use MEMORY_OPTIMIZED_X4_480_8T
- For X4 machine types with 12 TB of memory, use MEMORY_OPTIMIZED_X4_960_12T
- For X4 machine types with 16 TB of memory, use MEMORY_OPTIMIZED_X4_960_16T
- For X4 machine types with 24 TB of memory, use MEMORY_OPTIMIZED_X4_1440_24T
- For X4 machine types with 32 TB of memory, use MEMORY_OPTIMIZED_X4_1920_32T
- For Z3 machine types, use STORAGE_OPTIMIZED_Z3
COMMITMENT_PLAN : the commitment plan ('TWELVE_MONTH' or 'THIRTY_SIX_MONTH'), which must be the same as your source commitments.
COMMITMENT_NAME : the name of your new merged commitment.
NUMBER_VCPUS : the total number of vCPUs in the source commitments.
MEMORY : the sum of the amounts of memory, in MB, in the source commitments. For example, 1000 MB. If you don't specify a unit, then the default unit is MB.
SOURCE_COMMITMENT_URL : the URL of the source commitment that you want to merge. You must specify a comma-separated list of distinct source commitment URLs.

For example, consider two source commitments ( source-commitment-1 and source-commitment-2 ) in the us-east1 region with their resources specified as (four N2 vCPUs and 2048 MB) and (three N2 vCPUs and 2048 MB) respectively. The commitment plan for each source commitment is TWELVE_MONTH . The following POST request merges the source commitments and creates a new commitment called merged-commitment . The merged commitment specifies its resources as seven N2 vCPUs and 4096 MB, and its commitment plan is TWELVE_MONTH .

POST https://compute.googleapis.com/compute/v1/projects/myproject/regions/us-east1/commitments
{
  "name": "merged-commitment",
  "plan": "TWELVE_MONTH",
  "type": "GENERAL_PURPOSE_N2",
  "region": "us-east1",
  "resources": [
    {
      "type": "VCPU",
      "amount": "7"
    }
    {
      "type": "MEMORY",
      "amount": "4096"
    }
  ],
  "mergeSourceCommitments": [
    "projects/myproject/regions/us-east1/commitments/source-commitment-1",
    "projects/myproject/regions/us-east1/commitments/source-commitment-2",
    ...
  ]
}

Split commitments

You can transfer resources out of an existing commitment and split the commitment into smaller commitments. Splitting lets you closely monitor and manage portions of a large commitment as smaller individual commitments. For example, you can set only a portion of a commitment to renew automatically by splitting it and enabling automatic renewal for only one of the child commitments. With splitting, you can also distribute your committed use discounts at a more granular level by using prioritized attribution for the split commitments.

How splitting works

When you split an existing commitment (source commitment), you transfer resources out of your source commitment, create one or more new commitments (split commitments), and redistribute the transferred resources among the new split commitments. Both the activation of split commitments and the resizing of the source commitment take place at 12 AM US and Canadian Pacific Time (UTC-8, or UTC-7 during daylight saving time) on the following day. Compute Engine sets this activation date as the start date for the split commitments. After the split operation concludes, you have the following commitments:

The resized source commitment with the resources that remain after the split.
The split commitments with the redistributed resources.

The source commitment, although resized, retains all its other attributes, including its start and end dates, and continues to operate normally. The split commitments retain the same end date and term extension eligibility window as the source commitment.

Because split commitments can be created only after your source commitment is already active, the split commitments might have a custom term duration instead of the preset term duration of 1 or 3 years. However, the split commitments retain the 1- or 3-year commitment plan of the source commitment.

You can create only one new split commitment at a time using REST and the gcloud CLI. You can create multiple new split commitments in a single operation by using the Google Cloud console.

You can't split a commitment that has attached reservations. For more information about commitments with attached reservations, see Combining reservations with committed use discounts .

Example of a split commitment

The following table shows commitment properties when you split an existing commitment ( source-commitment ) into two distinct commitments (a resized source-commitment and a split-commitment ) on March 1, 2022:

Source commitment
(before split)

Split commitment

Source commitment
(after split)

Name

source-commitment

split-commitment

source-commitment

Type

Region

us-central1

Resources

vCPUs: 200
Memory: 200 GB

vCPUs: 50
Memory: 100 GB

vCPUs: 150
Memory: 100 GB

Term

3 years

Start date ^*

January 1, 2020

March 2, 2022
(the day after the split)

January 1, 2020

End date ^†

January 1, 2023

Term extension eligibility window open until

January 1, 2021

Pricing implications

Your commitment fee is the sum of the discounted prices of all your committed resources. Splitting a commitment affects your resource costs in the following ways:

Resized source commitment: The discounted prices of resources from your resized source commitment remain the same.
Split commitment: The discounted prices of your split commitment's resources might change on the day the split commitment becomes active. This new discounted price for each resource remains the same until the end of your new split commitment's term, even if on-demand prices change.

However, if you merge or split either of these commitments again, then the discounted prices might change again.

Limitations

You can't split license commitments.
You can't split commitments that have attached reservations . Consequently, you can't split commitments that have GPUs, Local SSD disks, or both, because commitments with these resources always have attached reservations.
You can't attach any reservations (new or existing) to the split commitments.
You can't split commitments that have expired or are canceled.
By default, when you split your commitments, the auto-renewal setting is disabled on the split commitments, even if all source commitments were set to renew automatically. If you want your split commitments to renew automatically, then you must manually enable the auto-renewal setting on those commitments. You can do so either at the time of their creation or after their creation .
You can create only one new split commitment at a time using REST or the gcloud CLI. As a result, you can split your source commitment into a maximum of two commitments in a single operation when using these interfaces. To split your source commitment into three or more commitments in a single operation, use the Google Cloud console.
In the Google Cloud console, you can specify memory only in increments of 0.25 GB. To specify a custom memory value for your commitment, use gcloud CLI or REST instead.

Requirements

When you split a source commitment and create one or more split commitments, your source and split commitments must meet the following requirements:

The split commitments must have the same project, commitment type, region, and commitment plan as the source commitment. However, you must choose new names for your split commitments.
The resource types you specify for split commitments must match some or all resource types in the source commitment. Additionally, the combined amount of resources that you specify for split commitments must be a portion of the resources in the source commitment. You must retain a portion of the resources in your source commitment. For example, if your source commitment is for 200 vCPUs and 300 GB memory, then the following resize and redistribution scenarios apply:
- You can redistribute a portion of the 200 vCPUs and a portion of the 300 GB memory among the split commitments.
- You can redistribute all of the 200 vCPUs, but you must retain a portion of the memory in your source commitment.
- You can redistribute all of the 300 GB memory, but you must retain a portion of the vCPUs in your source commitment.
- You can't redistribute all of the 200 vCPUs and all of the 300 GB memory among your split commitments.
The source and split commitments must specify only the following hardware resources: vCPUs, memory, or a combination of both.

Additionally, to split a source commitment by using the Google Cloud CLI, update the Google Cloud CLI to version 423.0.0 or later. If you use an earlier version, then the split operation fails and Compute Engine throws an error.

Create split commitments

Create one new split commitment at a time by using the gcloud CLI or the Compute Engine API. Create multiple new split commitments at a time by using the Google Cloud console. Before you split a commitment, review the limitations for splitting .

Permissions required for this task

To perform this task, you must have the following permissions :

compute.commitments.create on the project or organization.

Console

In the Google Cloud console, select the project where you want to split a commitment. Then, go to the Committed use discountspage.

Go to Committed use discounts
To initiate the split operation for a commitment, do one of the following on the Hardware commitmentstab of the Commitment listpage:
- Select the commitment that you want to split from the list and click Split.
- In the Namecolumn, click the name of the commitment that you want to split. On the Hardware commitment detailspage that opens, click Split.
On the Resizetab of the Split commitmentpage that opens, do the following:
1. In the vCPUsand Memoryfields, specify the number of vCPUs and memory that you want to retain in your original commitment. The remaining resources are available for redistribution to your split commitment. The source commitment can't be empty after you resize it.
2. Click Next. The Redistributetab opens.
On the Redistributetab of the Split commitmentpage, do the following:
1. In the Namefield, specify a name for your split commitment.
2. In the vCPUsand Memoryfields, specify the number of vCPUs and memory for your split commitment. You can specify memory only in increments of 0.25 GB. To specify a custom memory value for your commitment, use gcloud CLI or REST instead.
  
  If you want to create a single split commitment, then specify all of the resources that you want to redistribute from the source commitment. If you want to create multiple split commitments, then specify only the portion of the redistributed resources that you want for this split commitment.
3. Optional: To enable auto-renewal on your split commitment, select the Enable auto renewcheckbox.
4. Click Done.
5. Optional: To create additional split commitments, click Add an itemand repeat the preceding steps.
6. Click Next. The Reviewtab opens.
On the Reviewtab of the Split commitmentpage, do the following:
1. Review and confirm the details of the resized commitment and the split commitments.
  - To modify the resource allocation from your original commitment, select the Resizetab on the left side of the window and repeat step 3.
  - To modify your resource redistribution among your split commitments, select the Redistributetab on the left side of the window and repeat step 4.
2. Read the Terms and conditions.
3. To finish creating your split commitments and return to the Commitment listpage, click Submit.

gcloud

To split an existing commitment into two commitments, use the gcloud compute commitments create command with the --split-source-commitment flag.

gcloud compute commitments create COMMITMENT_NAME 
\
    --region= REGION 
\
    --project= PROJECT_ID 
\
    --plan= COMMITMENT_PLAN 
\
    --type= COMMITMENT_TYPE 
\
    --resources=vcpu= NUMBER_VCPUS 
,memory= MEMORY 
\
    --split-source-commitment= SOURCE_COMMITMENT_URL

Replace the following:

COMMITMENT_NAME : the name of your new split commitment.
COMMITMENT_TYPE : the same commitment type as your source commitment, one of the following:
- For A2 machine types, use accelerator-optimized
- For A3 Edge and A3 High machine types, use accelerator-optimized-a3
- For A3 Mega machine types, use accelerator-optimized-a3-mega
  Note: For A4X Max, A4X, A4, or A3 Ultra machine types, you must purchase your commitments by using the future reservations in AI Hypercomputer consumption option. For more information, see Reserve capacity through your account team .
- For G2 machine types, use graphics-optimized
- For G4 machine types, use graphics-optimized-g4
- For C2 machine types, use compute-optimized
- For C2D machine types, use compute-optimized-c2d
- For C3 machine types, use compute-optimized-c3
- For C3D machine types, use compute-optimized-c3d
  Caution : For C3 and C3D commitment types, the machine family that is specified by the commitment type changes depending on the interface:
  - In the gcloud CLI and REST, the commitment type values use Compute-optimized as the machine family, even though C3 and C3D are part of the general-purpose machine family.
  - In the Google Cloud console, the commitment type values use the correct machine series: General-Purpose .
  Make sure to select the correct commitment type value that corresponds to the interface that you're using.
- For H3 machine types, use compute-optimized-h3
- For H4D machine types, use compute-optimized-h4d
- For N1 machine types, use general-purpose
- For C4 machine types, use general-purpose-c4
- For C4A machine types, use general-purpose-c4a
- For C4D machine types, use general-purpose-c4d
- For E2 machine types, use general-purpose-e2
- For N2 machine types, use general-purpose-n2
- For N2D machine types, use general-purpose-n2d
- For N4 machine types, use general-purpose-n4
- For N4D machine types, use general-purpose-n4d
- For N4A machine types, use general-purpose-n4a
- For Tau T2D machine types, use general-purpose-t2d
- For M1 or M2 machine types, use memory-optimized
- For M3 machine types, use memory-optimized-m3
- For M4 machine types, use memory-optimized-m4
- For M4 machine types with 6 TB of memory, use memory-optimized-m4-6tb
- For X4 machine types with 6 TB of memory, use memory-optimized-x4-6t
- For X4 machine types with 8 TB of memory, use memory-optimized-x4-8t
- For X4 machine types with 12 TB of memory, use memory-optimized-x4-12t
- For X4 machine types with 16 TB of memory, use memory-optimized-x4-960-16t
- For X4 machine types with 24 TB of memory, use memory-optimized-x4-1440-24t
- For X4 machine types with 32 TB of memory, use memory-optimized-x4-1920-32t
- For Z3 machine types, use storage-optimized-z3
REGION : the same region as your source commitment.
PROJECT_ID : the project ID of the project for which you want to split the source commitment.
COMMITMENT_PLAN : the commitment plan ('12-month' or '36-month'), which must be the same as your source commitment.
NUMBER_VCPUS : The number of vCPUs that you want to transfer from your source commitment to create your new split commitment. This number must be an integer that is less than the number of vCPUs in the source commitment.
MEMORY : the amount of memory, in MB or GB, that you want to transfer from your source commitment to create your new split commitment. This amount must be less than the amount of memory in the source commitment. For example, 10000 MB. If you don't specify a unit, then the default unit is GB.
SOURCE_COMMITMENT_URL : the URL of the source commitment from which you want to carve out resources.

For example, consider a source commitment ( source-commitment ) in the us-east1 region with resources specified as three N2 vCPUs and 2048 MB memory. The commitment plan for the source commitment is 12-month . The following gcloud CLI command splits the commitment into two separate commitments:

gcloud compute commitments create split-commitment \
    --plan=12-month \
    --type=general-purpose-n2 \
    --region=us-east1 \
    --project=myproject \
    --resources vcpu=1,memory=1024MB \
    --split-source-commitment=projects/myproject/regions/us-east1/commitments/source-commitment

When splitting source-commitment , Compute Engine does the following:

Takes resources from source-commitment and creates a new commitment split-commitment with one N2 vCPU and 1024 MB memory.
Resizes source-commitment to the remaining resources.

REST

To split an existing commitment into two commitments, use the regionCommitments.insert method .

POST https://compute.googleapis.com/compute/v1/projects/ PROJECT_ID 
/regions/ REGION 
/commitments
{
  "name": COMMITMENT_NAME 
,
  "plan": COMMITMENT_PLAN 
,
  "type": COMMITMENT_TYPE 
,
  "region": REGION 
,
  "resources": [
    {
      "type": "vCPUs",
      "amount": NUMBER_VCPUS 
}
    {
      "type": "MEMORY",
      "amount": MEMORY 
}
  ],
  "splitSourceCommitment": SOURCE_COMMITMENT_URL 
}

Replace the following:

PROJECT_ID : the project ID of the project for which you want to split the source commitment.
REGION : the same region as your source commitment.
COMMITMENT_NAME : the name of your new split commitment.
COMMITMENT_TYPE : the same commitment type as your source commitment, one of the following:
- For A2 machine types, use ACCELERATOR_OPTIMIZED
- For A3 Edge and A3 High machine types, use ACCELERATOR_OPTIMIZED_A3
- For A3 Mega machine types, use ACCELERATOR_OPTIMIZED_A3_MEGA
  Note: For A4X Max, A4X, A4, or A3 Ultra machine types, you must purchase your commitments by using the future reservations in AI Hypercomputer consumption option. For more information, see Reserve capacity through your account team .
- For G2 machine types, use GRAPHICS_OPTIMIZED
- For G4 machine types, use GRAPHICS_OPTIMIZED_G4
- For C2 machine types, use COMPUTE_OPTIMIZED
- For C2D machine types, use COMPUTE_OPTIMIZED_C2D
- For C3 machine types, use COMPUTE_OPTIMIZED_C3
- For C3D machine types, use COMPUTE_OPTIMIZED_C3D
  Caution : For C3 and C3D commitment types, the machine family that is specified by the commitment type changes depending on the interface:
  - In the gcloud CLI and REST, the commitment type values use Compute-optimized as the machine family, even though C3 and C3D are part of the general-purpose machine family.
  - In the Google Cloud console, the commitment type values use the correct machine series: General-Purpose .
  Make sure to select the correct commitment type value that corresponds to the interface that you're using.
- For H3 machine types, use COMPUTE_OPTIMIZED_H3
- For H4D machine types, use COMPUTE_OPTIMIZED_H4D
- For N1 machine types, use GENERAL_PURPOSE
- For C4 machine types, use GENERAL_PURPOSE_C4
- For C4A machine types, use GENERAL_PURPOSE_C4A
- For C4D machine types, use GENERAL_PURPOSE_C4D
- For E2 machine types, use GENERAL_PURPOSE_E2
- For N2 machine types, use GENERAL_PURPOSE_N2
- For N2D machine types, use GENERAL_PURPOSE_N2D
- For N4 machine types, use GENERAL_PURPOSE_N4
- For N4D machine types, use GENERAL_PURPOSE_N4D
- For N4A machine types, use GENERAL_PURPOSE_N4A
- For Tau T2D machine types, use GENERAL_PURPOSE_T2D
- For M1 or M2 machine types, use MEMORY_OPTIMIZED
- For M3 machine types, use MEMORY_OPTIMIZED_M3
- For M4 machine types, use MEMORY_OPTIMIZED_M4
- For M4 machine types with 6 TB of memory, use MEMORY_OPTIMIZED_M4_6TB
- For X4 machine types with 6 TB of memory, use MEMORY_OPTIMIZED_X4_480_6T
- For X4 machine types with 8 TB of memory, use MEMORY_OPTIMIZED_X4_480_8T
- For X4 machine types with 12 TB of memory, use MEMORY_OPTIMIZED_X4_960_12T
- For X4 machine types with 16 TB of memory, use MEMORY_OPTIMIZED_X4_960_16T
- For X4 machine types with 24 TB of memory, use MEMORY_OPTIMIZED_X4_1440_24T
- For X4 machine types with 32 TB of memory, use MEMORY_OPTIMIZED_X4_1920_32T
- For Z3 machine types, use STORAGE_OPTIMIZED_Z3
COMMITMENT_PLAN : the commitment plan ('TWELVE_MONTH' or 'THIRTY_SIX_MONTH'), which must be the same as your source commitment.
NUMBER_VCPUS : the number of vCPUs that you want to transfer from your source commitment to create your new split commitment. This number must be an integer that is less than the number of vCPUs in the source commitment.
MEMORY : the amount of memory, in MB, that you want to transfer from your source commitment to create your new split commitment. This amount must be less than the amount of memory in the source commitment. For example, 1000 MB. If you don't specify a unit, then the default unit is MB.
SOURCE_COMMITMENT_URL : the URL of the source commitment from which you want to transfer resources.

For example, consider a source commitment ( source-commitment ) in the us-east1 region with resources specified as three N2 vCPUs and 2048 MB memory. The commitment plan for the source commitment is TWELVE_MONTH . The following POST request splits the commitment into two separate commitments:

POST https://compute.googleapis.com/compute/v1/projects/myproject/regions/us-east1/commitments
{
  "name": "split-commitment",
  "plan": "TWELVE_MONTH",
  "type": "GENERAL_PURPOSE_N2",
  "region": "us-east1",
  "resources": [
    {
      "type": "VCPU",
      "amount": "1"
    }
    {
      "type": "MEMORY",
      "amount": "1024"
    }
  ],
  "splitSourceCommitment": "projects/myproject/regions/us-east1/commitments/source-commitment"
}

When splitting source-commitment , Compute Engine does the following:

Takes resources from source-commitment and creates a new commitment split-commitment with one N2 vCPU and 1024 MB memory.
Resizes source-commitment to the remaining resources.

What's next

Learn how to renew resource-based commitments automatically .
Learn how to extend the term of resource-based commitments .
Learn how to upgrade resource-based commitments .
Learn how to analyze the effectiveness of your CUDs .

Merge and split commitments Stay organized with collections Save and categorize content based on your preferences.

Before you begin

Console

gcloud

REST

Merge commitments

How merging works

Example of a merged commitment

Pricing implications

Limitations

Requirements

Create merged commitments

Permissions required for this task

Console

gcloud

REST

Split commitments

How splitting works

Example of a split commitment

Pricing implications

Limitations

Requirements

Create split commitments

Permissions required for this task

Console

gcloud

REST

What's next

Merge and split commitments