割り当てと上限

このページでは、Cloud Storage の割り当てとリクエストの上限について説明します。割り当ての増加をリクエストできますが、上限を変更することはできません。

割り当てと上限は変更されることがあります。

バケット

上限	値	注
バケット名の最大サイズ	63 文字	名前にドット（.）が含まれる場合、上限は 222 文字です。
プロジェクトあたりのバケットの作成と削除のレート上限	2 秒ごとに約 1 件のリクエスト	ほとんどの場合、より少ないバケットでより多くのオブジェクトを使用するように計画します。たとえば、一般的な設計では、プロジェクトのユーザーごとに 1 つのバケットを使用します。1 秒間に多数のユーザーを追加するシステムを設計する場合は、1 つのバケットを多数のユーザーで使用するように設計し（適切な権限を与えて）、バケット作成のレート上限がボトルネックにならないようにします。可用性の高いアプリケーションは、アプリケーションのクリティカルパスでバケットの作成や削除に依存しないようにしてください。バケット名は、一元化されたグローバル名前空間の一部になっています。この名前空間に依存すると、アプリケーションで単一障害点が生じます。これとバケットの作成 / 削除制限があるため、Cloud Storage で可用性の高いサービスを作成する場合には、必要なバケットをすべて事前に作成することをおすすめします。
プロジェクトあたりのバケット復元レートの上限	2 秒ごとに約 1 件のリクエスト
バケットあたりのバケットメタデータの更新レートの上限	1 秒あたり 1 回の更新	1 つのバケットを頻繁に更新（たとえば、CORS 構成の変更など）すると、スロットリングエラーが発生する可能性があります。
バケットごとに IAM ロールを付与できるプリンシパルの最大数	1,500 個のプリンシパル（すべての IAM ロール） 100 個のプリンシパル（以前の IAM ロール）	詳細については、プリンシパルのタイプをご覧ください。
バケットあたりの Pub/Sub 通知構成の最大数	100 個の通知構成
プロジェクト内の同じロケーションからサポートされる、バケットの同時再配置の最大数	5 つのバケット	詳細については、バケットの再配置をご覧ください。
特定のイベントでトリガーされるように設定される Pub/Sub 通知構成の最大数	10 個の通知構成
Pub/Sub 通知構成のカスタム属性の最大数	10 個のカスタム属性
バケットロックに設定できる最大保持期間	3,155,760,000 秒（100 年）
削除（復元可能）の最大保持期間	90 日

オブジェクト

上限	値	注
オブジェクトの最大サイズ	5 TiB	この上限は、オブジェクトの作成、再開可能なアップロード、マルチパートアップロードなどの書き込み方法に関係なく適用されます。
オブジェクトあたりのすべてのカスタムメタデータのキーと値の合計サイズ	8 KiB
フラットな名前空間バケット内のオブジェクトのオブジェクト名の最大サイズ	1,024 バイト（UTF-8 エンコード）
階層型名前空間が有効にされているバケット内のオブジェクトのオブジェクト名の最大サイズ	フォルダ名: 512 バイト（UTF-8 エンコード）ベース名: 512 バイト（UTF-8 エンコード）
同じオブジェクト名に対する書き込みの最大速度	1 秒あたり 1 回の書き込み	同じオブジェクト名に上限を超える速度で書き込むと、スロットリングエラーが発生する可能性があります。詳細については、オブジェクトの不変性をご覧ください。
1 つのオブジェクトに対するオブジェクトメタデータの更新頻度	1 秒あたり 1 回の更新	この上限を超える頻度でオブジェクトのメタデータを更新すると、スロットリングエラーが発生する可能性があります。
バケットでのオブジェクト書き込みの最大レート	無制限	オブジェクトのアップロード、更新、削除が含まれます。バケットは最初 1 秒あたり約 1,000 回の書き込みをサポートします。その後、必要に応じてスケールします。
バケットでのオブジェクト読み取りの最大レート	無制限	オブジェクトデータの読み取り、オブジェクトメタデータの読み取り、オブジェクトの一覧表示を含みます。バケットは最初 1 秒あたり約 5,000 回の読み取りをサポートします。その後、必要に応じてスケールします。ただし、帯域幅の上限に注意してください。
アクセス制御リスト（ACL）のエントリの最大数	オブジェクトあたり 100 個の ACL	詳細については、ACL スコープをご覧ください。
オブジェクト作成のソースオブジェクトの最大数	1 回の作成リクエストで 32 個のオブジェクト
複合オブジェクトを構成するコンポーネントの最大数	無制限	複合オブジェクトを構成するコンポーネントの数に上限はありませんが、複合オブジェクトに関連付けられる `componentCount` メタデータは 2,147,483,647 個が上限となります。最終的な複合オブジェクトは、Cloud Storage のすべてのオブジェクトに適用される 5 TiB のサイズ制限を遵守する必要があります。
オブジェクト保持ロックに設定できる最大保持時間	現在の日時から 3,155,760,000 秒（100 年）
階層型名前空間が有効になっているバケット内のオブジェクトの読み取りと書き込みの初期秒間クエリ数（QPS）の上限。	階層型名前空間が有効になっていないバケットと比較して、QPS が最大 8 倍に向上します。	フォルダ操作時のパフォーマンスの最適化については、フォルダ管理をご覧ください。

Anywhere Cache

上限値メモ

上限	値	メモ
Anywhere Cache の最大キャッシュサイズ	1 PiB	キャッシュサイズは、キャッシュに保存されるデータの量に応じて自動的にスケールされます。キャッシュサイズは、キャッシュに取り込まれたデータ量から強制排除されたデータ量を引いたものと同じです。たとえば、ワークロードが 100 GiB のデータを取り込むと、キャッシュサイズは 100 GiB に増加します。その後 50 GiB のデータが強制排除されると、キャッシュサイズは 50 GiB に縮小されます。キャッシュサイズの上限は、プロジェクトの請求先アカウントの履歴によっては、これより少なくなる場合があります。リソースが限られている場合、キャッシュの作成が停止されるか、既存のキャッシュの増加が停止し、最も長く使用されていない（LRU）アルゴリズムに基づいてデータが強制排除され、新しいデータのためのスペースが確保されます。
プロジェクトごと、ゾーンごとの Anywhere Cache データ使用量の最大帯域幅の上限	20 Tbps	キャッシュ帯域幅の上限は、キャッシュに保存されているデータの量に応じて自動的にスケーリングされます。データ 1 TiB あたり 20 Gbps で、ベース値は 100 Gbps です。キャッシュ帯域幅の上限はプロジェクトごと、ゾーンごとに適用されるため、キャッシュが異なるバケット用に作成されている場合でも、同じプロジェクトとゾーン内のキャッシュからのトラフィックは、共通のキャッシュ帯域幅の上限にカウントされます。たとえば、プロジェクト `my-project` にあるバケット `example-bucket-1` のゾーン `us-east1-a` にキャッシュ A が作成されているとします。キャッシュ B は `example-bucket-2` の `us-east1-a` に作成されているとします。`example-bucket-2` も `my-project` にあります。キャッシュ A とキャッシュ B はどちらも `us-east1-a` と `my-project` にあるため、両方のキャッシュのトラフィックは同じキャッシュ帯域幅の上限にカウントされます。注: 異なるロケーションタイプのバケットに作成されたキャッシュは、同じゾーンに作成された場合でも、同じキャッシュ帯域幅の上限にカウントされません。たとえば、キャッシュ A とキャッシュ B の両方が `us-east1-a` ゾーンに作成されているが、キャッシュ A は `us-east1` リージョンのバケットに属し、キャッシュ B は `US` マルチリージョンのバケットに属しているとします。1 つはリージョンに保存され、もう 1 つはマルチリージョンに保存されており、関連付けられたバケットのロケーションタイプが異なるため、キャッシュには個別のキャッシュ帯域幅の上限があります。キャッシュに保存されるデータの量を増やすか、キャッシュをより多くのゾーンに配置してキャッシュの数を増やすことで、キャッシュ帯域幅の合計量を増やすことができます。キャッシュ帯域幅の上限は、プロジェクトの最大帯域幅割り当てとは別です。キャッシュからのデータの読み取りは、上限に達するまでキャッシュ帯域幅の上限にカウントされます。上限に達すると、データの読み取りはプロジェクトの帯域幅割り当てにカウントされます。キャッシュミスは、キャッシュ帯域幅の上限にはカウントされません。

Anywhere Cache の最大キャッシュサイズ

1 PiB

キャッシュサイズは、キャッシュに保存されるデータの量に応じて自動的にスケールされます。キャッシュサイズは、キャッシュに取り込まれたデータ量から強制排除されたデータ量を引いたものと同じです。たとえば、ワークロードが 100 GiB のデータを取り込むと、キャッシュサイズは 100 GiB に増加します。その後 50 GiB のデータが強制排除されると、キャッシュサイズは 50 GiB に縮小されます。

キャッシュサイズの上限は、プロジェクトの請求先アカウントの履歴によっては、これより少なくなる場合があります。リソースが限られている場合、キャッシュの作成が停止されるか、既存のキャッシュの増加が停止し、最も長く使用されていない（LRU）アルゴリズムに基づいてデータが強制排除され、新しいデータのためのスペースが確保されます。

プロジェクトごと、ゾーンごとの Anywhere Cache データ使用量の最大帯域幅の上限

20 Tbps

キャッシュ帯域幅の上限は、キャッシュに保存されているデータの量に応じて自動的にスケーリングされます。データ 1 TiB あたり 20 Gbps で、ベース値は 100 Gbps です。

キャッシュ帯域幅の上限はプロジェクトごと、ゾーンごとに適用されるため、キャッシュが異なるバケット用に作成されている場合でも、同じプロジェクトとゾーン内のキャッシュからのトラフィックは、共通のキャッシュ帯域幅の上限にカウントされます。たとえば、プロジェクト my-project にあるバケット example-bucket-1 のゾーン us-east1-a にキャッシュ A が作成されているとします。キャッシュ B は example-bucket-2 の us-east1-a に作成されているとします。example-bucket-2 も my-project にあります。キャッシュ A とキャッシュ B はどちらも us-east1-a と my-project にあるため、両方のキャッシュのトラフィックは同じキャッシュ帯域幅の上限にカウントされます。

注: 異なるロケーションタイプのバケットに作成されたキャッシュは、同じゾーンに作成された場合でも、同じキャッシュ帯域幅の上限にカウントされません。たとえば、キャッシュ A とキャッシュ B の両方が us-east1-a ゾーンに作成されているが、キャッシュ A は us-east1 リージョンのバケットに属し、キャッシュ B は US マルチリージョンのバケットに属しているとします。1 つはリージョンに保存され、もう 1 つはマルチリージョンに保存されており、関連付けられたバケットのロケーションタイプが異なるため、キャッシュには個別のキャッシュ帯域幅の上限があります。

キャッシュに保存されるデータの量を増やすか、キャッシュをより多くのゾーンに配置してキャッシュの数を増やすことで、キャッシュ帯域幅の合計量を増やすことができます。

キャッシュ帯域幅の上限は、プロジェクトの最大帯域幅割り当てとは別です。キャッシュからのデータの読み取りは、上限に達するまでキャッシュ帯域幅の上限にカウントされます。上限に達すると、データの読み取りはプロジェクトの帯域幅割り当てにカウントされます。キャッシュミスは、キャッシュ帯域幅の上限にはカウントされません。

マネージドフォルダ

上限	値	注
マネージドフォルダ名の最大サイズ	1,024 バイト（UTF-8 エンコード）
マネージドフォルダの最大ネスト数	15
マネージドフォルダあたりの IAM ポリシー更新の最大レート	1 秒あたり 1 回の更新

JSON API リクエスト

上限	値	注
バッチリクエストのリクエストペイロードの合計の上限	10 MiB 未満	1 回のリクエストに 100 個を超える呼び出しを含めないでください。
オブジェクトリストの glob パターンの最大サイズ	UTF-8 エンコードで 1,024 バイト

XML API リクエスト

上限	値	注
リクエスト URL と HTTP ヘッダーの合計サイズの上限	16 KiB
バケットの一覧表示で返されるバケットの最大数	1,000 バケット	XML API は、名前の辞書順でバケットを返します。
マルチパートアップロードのパートの最大数	10,000 パート	これらのパートで組み立てられたオブジェクトは、Cloud Storage のすべてのオブジェクトに適用される 5 TiB のサイズ制限を遵守する必要があります。
マルチパートアップロードの個々のパートの最大サイズ	5 GiB
マルチパートアップロードの個々のパートの最小サイズ	5 MiB	マルチパートアップロードの最後のパートに最小サイズの上限はありません。そのため、この上限は、パートのアップロード時点では適用されず、アップロードの完了を試みた時点で適用されます。
マルチパートアップロードとそのアップロード済みパートがバケット内で未完了またはアイドル状態のままである状態が許容される最大時間。	無制限
1 つのオブジェクトで同時に実行可能なマルチパートアップロードの最大数	無制限
再開可能なアップロードのセッションが完了するまでの最大時間	7 日	この時間は、再開可能なアップロードの開始から測定されます。

サービスアカウントの HMAC キー

HMAC キーは、サービスアカウントごとに最大 10 個という上限があります。削除されたキーは、この上限にカウントされません。

インベントリレポート

インベントリレポートの構成には、ソースバケットごとに 100 個という上限があります。

ストレージバッチオペレーションジョブ

このセクションでは、ストレージバッチオペレーションジョブの使用に関する現在の API の制限と使用量の割り当てについて説明します。

同時実行ストレージバッチオペレーションジョブ

次の表は、同時に実行できる jobs の上限を示します。

進行中のジョブの最大数	対象
100	プロジェクトごと、バケットのロケーションあたり

レートに基づく割り当て

ストレージバッチオペレーションでは、すべてのリクエストにレート制限が適用されます。

次の表に、各割り当ての指標、API メソッド、デフォルトの上限を示します。

指標	API メソッド	上限（デフォルト）
`storagebatchoperations.googleapis.com/create_requests`	`storagebatchoperations.jobs.create`	1 プロジェクトにつき 1 分あたり 1,200 回のリクエスト
`storagebatchoperations.googleapis.com/read_requests`	`storagebatchoperations.jobs.get` `storagebatchoperations.jobs.list`	1 プロジェクトにつき 1 分あたり 1,200 回のリクエスト
`storagebatchoperations.googleapis.com/cancel_requests`	`storagebatchoperations.jobs.cancel`	1 プロジェクトにつき 1 分あたり 1,200 回のリクエスト
`storagebatchoperations.googleapis.com/delete_requests`	`storagebatchoperations.jobs.delete`	1 プロジェクトにつき 1 分あたり 1,200 回のリクエスト

帯域幅

割り当て	値	注
Cloud Storage から Google サービスへの下り（外向き）データがあるリージョンの最大帯域幅	ほとんどのプロジェクトでは、リージョンごとのデフォルトの割り当ては 200 Gbps ですが、プロジェクトの請求先アカウントの履歴によっては、これより少なくなる場合があります。	Cloud CDN と Media CDN への下り（外向き）はこの割り当てから除外されます。プロジェクトごとに割り当ての増加をリクエストできます。プロジェクトの Google 下り（外向き）の上限を表示する方法については、割り当ての表示と管理をご覧ください。プロジェクトの Google 下り（外向き）の使用量を表示する方法については、帯域幅のモニタリングをご覧ください。
Cloud Storage から Google サービスへの下り（外向き）データがあるデュアルリージョンの最大帯域幅	ほとんどのプロジェクトでは、デュアルリージョン内の各リージョンのデフォルトの割り当ては 200 Gbps ですが、プロジェクトの請求先アカウントの履歴によっては、これより少なくなる場合があります。	Cloud CDN と Media CDN への下り（外向き）はこの割り当てから除外されます。プロジェクトごとに割り当ての増加をリクエストできます。プロジェクトの Google 下り（外向き）の上限を表示する方法については、割り当ての表示と管理をご覧ください。プロジェクトの Google 下り（外向き）の使用量を表示する方法については、帯域幅のモニタリングをご覧ください。
Cloud Storage から Google サービスへの下り（外向き）データがあるマルチリージョンの最大帯域幅	ほとんどのプロジェクトでは、リージョンごとのデフォルトの割り当ては 200 Gbps ですが、プロジェクトの請求先アカウントの履歴によっては、これより少なくなる場合があります。	Cloud CDN と Media CDN への下り（外向き）は、この割り当てから除外されます。特定のマルチリージョン内の各リージョンには個別の割り当てがあります。たとえば、プロジェクト `my-project` で、そのプロジェクト内のすべてのリージョンに対して 200 Gbps のマルチリージョン Google 下り（外向き）帯域幅割り当てがあるとします。このシナリオの場合、`us` マルチリージョンのバケットから Google サービスへの下り（外向き）データに対して、`us-east1` リージョンで 200 Gbps の帯域幅を使用できます。`us` マルチリージョンのバケットから Google サービスへの下り（外向き）データに対して、`us-west1` リージョンで 200 Gbps の帯域幅を使用できます。プロジェクトの Google 下り（外向き）の上限を表示する方法については、割り当ての表示と管理をご覧ください。プロジェクトの Google 下り（外向き）の使用量を表示する方法については、帯域幅のモニタリングをご覧ください。プロジェクトごとに割り当ての増加をリクエストできます。通常、Google サービスへの下り（外向き）料金が高いワークロードには、リージョンまたはデュアルリージョンにあるバケットを使用する必要があります。Google サービスで大規模なワークロードを実行するマルチリージョン内の既存のバケットについては、リージョンまたはデュアルリージョン内のバケットに Storage Transfer Service を使用してデータを移動できます。
リージョンのバケットデータにアクセスするインターネットリクエストの下り（外向き）帯域幅の上限	ほとんどのプロジェクトでは、リージョンごとのデフォルトの割り当ては 200 Gbps ですが、プロジェクトの請求先アカウントの履歴によっては、これより少なくなる場合があります。	この割り当てには、キャッシュミスによる Cloud CDN と Media CDN への下り（外向き）も含まれます。プロジェクトのインターネット下り（外向き）の上限を表示する方法については、割り当ての表示と管理をご覧ください。プロジェクトのインターネット下り（外向き）の使用量を表示する方法については、帯域幅のモニタリングをご覧ください。プロジェクトごとに割り当ての増加をリクエストできます。
デュアルリージョンのバケットデータにアクセスするインターネットリクエストの下り（外向き）帯域幅の上限	ほとんどのプロジェクトでは、デュアルリージョン内の各リージョンのデフォルトの割り当ては 200 Gbps ですが、プロジェクトの請求先アカウントの履歴によっては、これより少なくなる場合があります。	この割り当てには、キャッシュミスによる Cloud CDN と Media CDN への下り（外向き）も含まれます。プロジェクトのインターネット下り（外向き）の上限を表示する方法については、割り当ての表示と管理をご覧ください。プロジェクトのインターネット下り（外向き）の使用量をリージョンごとに表示する方法については、帯域幅のモニタリングをご覧ください。プロジェクトごとに割り当ての増加をリクエストできます。
特定のマルチリージョンのバケットデータにアクセスするインターネットリクエストの下り（外向き）帯域幅の上限	ほとんどのプロジェクトでは、リージョンごとのデフォルトの割り当ては 200 Gbps ですが、プロジェクトの請求先アカウントの履歴によっては、これより少なくなる場合があります。	この割り当てには、キャッシュミスによる Cloud CDN と Media CDN への下り（外向き）も含まれます。マルチリージョン内の各リージョンには、マルチリージョンのインターネット下り（外向き）割り当てが存在します。たとえば、`my-project` が `us` マルチリージョンにあるバケットから世界中の顧客にデータを送信するとします。このシナリオでは、バケットから世界中のさまざまな地域にデータが送信されるため、`us` マルチリージョン内のさまざまなリージョンがそれぞれ独自のインターネット下り（外向き）割り当てを使用します。通常、インターネット下り（外向き）の割り当ては、地理的にデータの宛先に最も近いリージョンに対してカウントされます。プロジェクトのインターネット下り（外向き）の上限を表示する方法については、割り当ての表示と管理をご覧ください。プロジェクトのインターネット下り（外向き）の使用量をリージョンごとに表示する方法については、帯域幅のモニタリングをご覧ください。プロジェクトごとに割り当ての増加をリクエストできます。

プロジェクトの帯域幅が特定の割り当てを超えると、影響を受けるバケットへのリクエストがスロットリングされるか、再試行可能な 429 - rateLimitExceeded エラーで拒否されて、超過した割り当ての詳細が報告される場合があります。帯域幅のモニタリングについては、帯域幅の使用量をご覧ください。

割り当てと上限 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。