割り当てと上限

このドキュメントでは、Cloud DNS に適用される割り当てとシステムの上限を示します。

• 割り当ては、使用できるカウント可能な共有リソースの量を指定します。割り当ては、 Google Cloud サービス（Cloud DNS など）によって定義されます。
• システムの上限は固定値で、変更できません。

Google Cloud では、割り当てを使用して公平性を確保し、リソースの使用量と可用性の急増を抑えます。割り当ては、 Google Cloud プロジェクトで使用できるGoogle Cloud リソースの量を制限します。割り当ては、ハードウェア、ソフトウェア、ネットワーク コンポーネントなど、さまざまなリソースタイプに適用されます。たとえば、割り当てによって、サービスへの API 呼び出しの数、プロジェクトで同時に使用されるロードバランサの数、作成可能なプロジェクトの数を制限できます。割り当てを適用することで、サービスの過負荷を防ぎ、Google Cloud ユーザーのコミュニティを保護します。割り当ては、自組織で使用している Google Cloud リソースの管理にも役立ちます。

Cloud Quotas システムは次のことを行います。

• Google Cloud のプロダクトとサービスの使用量をモニタリングする
• これらのリソースの消費量を制限する
• 割り当て値の変更をリクエストする方法を提供する

ほとんどの場合、割り当ての許容量を超えるリソースを消費しようとすると、システムによってリソースへのアクセスがブロックされ、実行しようとしているタスクは失敗します。

割り当ては通常、 Google Cloud プロジェクト レベルで適用されます。あるプロジェクトでリソースを使用しても、別のプロジェクトで使用可能な割り当てに影響することはありません。 Google Cloud プロジェクト内では、すべてのアプリケーションと IP アドレスで割り当てが共有されます。

Cloud DNS リソースにはシステムの上限もあります。システムの上限は変更できません。

割り当て

割り当てを変更するには、追加の割り当てをリクエストするをご覧ください。

次の表は、各プロジェクトの Cloud DNS リソースで重要なグローバル割り当てを示しています。その他の割り当てについては、 Google Cloud コンソールの [割り当て] ページをご覧ください。

項目	説明
リージョンの 1 分あたりの読み取り上限	100 秒間に IAM ユーザーが Cloud DNS API に発行できる API リクエストの最大数。この割り当ては API 呼び出しにのみ適用されます。DNS クエリを処理する際に、割り当ては適用されません。
マネージド ゾーンあたりの DNSSEC キー	マネージド ゾーンあたりの DNSSEC 鍵の最大数。
プロジェクトあたりのマネージド ゾーン	プロジェクト内の管理対象ゾーンの最大許容数。
VPC ネットワークあたりのマネージド ゾーン	VPC ネットワークにアタッチできるマネージド ゾーンの最大許容数。
プロジェクトあたりのポリシー リソース	プロジェクトあたりの DNS サーバー ポリシーの最大数。
レスポンス ポリシーあたりのネットワーク	レスポンス ポリシーあたりに許可される VPC ネットワークの最大数。
ルーティング ポリシーあたりのアイテム数	ルーティング ポリシーあたりに許可されるアイテムの最大数。
マネージド ゾーンあたりの GKE クラスタ	限定公開スコープのゾーンを接続できる Google Kubernetes Engine（GKE）クラスタの最大数。
ポリシーあたりの GKE クラスタ	ポリシーごとに許可される GKE クラスタの最大数。
GKE クラスタあたりのマネージド ゾーン	GKE クラスタに接続できるマネージド ゾーンの最大許容数。
変更あたりのリソース レコードの追加数	ChangesCreateRequest ごとに追加できる ResourceRecordSets の最大数。
変更あたりのリソース レコードの削除	ChangesCreateRequest ごとに削除できる ResourceRecordSets の最大数。
マネージド ゾーンあたりのリソース レコードセット	プロジェクト内のゾーンあたりの ResourceRecordSets の最大許容数。
リソース レコードセットあたりのリソース レコード	ResourceRecordSet あたりに許可される ResourceRecords の最大数。各委任（種類 NS のリソース レコードのセット）には最大 8 個のネームサーバーを含めることができます。
プロジェクトごとのレスポンス ポリシー	プロジェクトあたりに許可されるレスポンス ポリシーの最大数。
リージョンの 1 分あたりのレスポンス ポリシー ルールの書き込み上限	1 リージョンで 1 分間に書き込めるレスポンス ポリシー ルールの最大数。
バッチ アクションあたりのレスポンス ポリシー ルール	1 分あたりのバッチあたりのレスポンス ポリシー管理アクションの最大数。
ポリシーあたりのレスポンス ポリシー ルール	ポリシーに作成できるレスポンス ポリシー ルールの最大数。
転送ポリシーあたりのターゲット ネームサーバー	転送ポリシーごとに許可されるターゲット ネームサーバーの最大数。
マネージド ゾーンあたりのターゲット ネームサーバー	管理対象転送ゾーンあたりのターゲット ネームサーバーの最大許容数。
変更あたりのリソース レコードセット データの合計サイズ（バイト）	1 つの ChangesCreateRequest 内の合計 rrdata の最大許容サイズ（バイト単位）。
マネージド ゾーンあたりの VPC ネットワーク	限定公開スコープのゾーンをアタッチできる VPC ネットワークの最大許容数。
ポリシーあたりの VPC ネットワーク	Cloud DNS サーバー ポリシーごとに許可される VPC ネットワークの最大数。
リージョンの 1 分あたりの書き込み上限	1 リージョンあたり 1 分あたりの DNS 書き込みの最大数。この割り当ては、DNS レコードの作成、変更、削除を行う書き込みオペレーションに使用されます。

上限

割り当ては追加をリクエストできますが、上限の引き上げについては、特に明記のない限りできないのが一般的です。

API の使用

1 日あたりの API リクエスト（クエリ）数は、プロジェクト レベルで管理されます。Google Cloud CLI と Google Cloud コンソールから行われたものも含め、すべての API リクエストがこの上限の計算対象になります。

リソースの上限

項目	上限
これらの上限の更新をリクエストするには、Cloud カスタマーケアにお問い合わせください。
ネットワークあたりのピアリング ゾーンの数	1,000
委任あたりのネームサーバー数	8
変更あたりの追加	1,000
変更あたりの削除	1,000
変更あたりのリソース レコード データ サイズ	100,000 バイト
ラベルの組み合わせの数	1,000
レスポンス ポリシーごとのルール数	10,000
ルーティング ポリシーあたりのアイテム数	100
VPC ネットワークにバインドされるマネージド ゾーン数	10,000
DNS レスポンスの最大サイズ（UDP）	1,440 バイト
DNS レスポンスの最大サイズ（TCP）	65,533 バイト
この上限を引き上げることはできません。
VPC ネットワーク、ゾーンあたりの最大クエリレート	Google Cloud ゾーン（us-central1-a など）で 10 秒（10 秒）間に 10 万件のクエリ
VPC ネットワークあたりのレスポンス ポリシーの数	1
マネージド ゾーンあたりのラベル数	キーまたは値あたりラベル 64 個および 128 バイト
転送ゾーン内の転送ターゲット数	50
代替ネームサーバー内の転送ターゲット数	50

ネームサーバーの上限

Cloud DNS では、各一般公開マネージド ゾーンを 5 つのネームサーバー シャードのいずれかに割り当てます。シャードとは、権威ネームサーバー名の中で番号の前に記述されている文字です。たとえば、ns-cloud-e1 から ns-cloud-e4 は E シャードです。

以下のいずれかが同じシャードにすでに存在する場合、ドメインの新しいマネージド ゾーン（domain.example.tld など）は、シャードに割り当てられません。

• 同じ DNS 名（domain.example.tld など）のマネージド ゾーン
• DNS 名のサブドメイン（sub.domain.example.tld など）
• DNS 名の親ドメイン（example.tld など）

これらの制限があるため、一般公開マネージド ゾーンには次の制限が適用されます。

• まったく同じ DNS 名のゾーンを最大で 5 つ作成できます。
• 親ドメインの場合、最大 5 つのサブドメインを作成できます。

これらの制限は、 Google Cloudのすべてのプロジェクトとユーザーに適用されます。委任されていないサブドメインと、他の DNS サービス上でホストされている委任は、この上限の計算対象には含まれません。使用可能な最後のネームサーバー シャードを占有するゾーンを Cloud DNS が作成する前に、TXT レコードでゾーン ドメインの所有権を確認する必要があります。

同じ親ドメインの複数のサブドメイン（domain.example.tld や otherdomain.example.tld など）を、同じシャードに割り当てることができます。ただし、Cloud DNS は、制限を考慮した後、使用可能なシャードを選択する場合があります。各シャードにこのようなサブドメインを作成する場合、親ドメイン example.tld のゾーンは作成できません。

これらの制限を回避するには、サブドメインにゾーンを作成する前に、必ずその親ドメインにマネージド ゾーンを作成します。

子ドメインがすでにすべてのシャードをブロックしている場合は、次の手順に沿って、親ドメインのシャードを解放します。

1. 各サブドメインのゾーンのネームサーバーを確認して、そのゾーンのシャードを特定します。
2. マネージド ゾーンが最も少ない（重要度が最も低い）シャード（X）を探します。
3. シャード X にあるゾーンを他の DNS サービスにエクスポートします（さらに、そのゾーンの委任を変更します）。
4. 元の委任の TTL が経過した後、シャード X のサブドメインのマネージド ゾーンを削除します。
5. 親ドメインのマネージド ゾーンを作成すると、そのゾーンがシャード X に割り当てられます。
6. サブドメインの削除したマネージド ゾーンを復元します。その場合、サブドメインを復元してから、そのサブサブドメインを復元します。これらは新しいシャードに存在することになるので、そのすべてで更新した委任が必要です。

注: Google Domains でドメインを登録すると、シャードに専用ゾーンが作成されます。シャードの制限や上限はこれらのプロダクトに一律に適用されるため、Google Domains での登録には Cloud DNS でドメインとサブドメインのゾーンに使用できるシャードが割り当てられます。逆にいうと、すべてのネームサーバー シャードで同じ DNS 名かサブドメイン DNS 名を使用している Cloud DNS ゾーンを持つドメインがある場合、前の手順でシャードを開放しない限り、そのドメインを Google Domains に登録できません。

上限を確認する

次のコマンドを実行して、プロジェクトでの上限を検索できます。次の例では、my-project プロジェクト内の各種オブジェクトの合計の上限を示しています。totalRrdataSizePerChange 割り当てはバイト単位で測定され、変更の追加と削除の両方を合計したものです。

gcloud dns project-info describe my-project

これらは上限ですが、 Google Cloud は内部で割り当てとして追跡するため、出力では割り当てとしてラベル付けされます。

id: my-project,
kind: "dns#project",
number: "123456789012",
quota:
    kind: dns#quota,
    managedZones: 10000,
    resourceRecordsPerRrset: 10000,
    rrsetAdditionsPerChange: 3000,
    rrsetDeletionsPerChange: 3000,
    rrsetsPerManagedZone: 10000,
    totalRrdataSizePerChange: 100000,
    labelSets: 1000

デフォルトのプロジェクトとその他のプロジェクトの名前は、 Google Cloud consoleの [ホーム] ページの上部で確認できます。

Manage quotas

Cloud DNS enforces quotas on resource usage for various reasons. For example, quotas protect the community of Google Cloud users by preventing unforeseen spikes in usage. Quotas also help users who are exploring Google Cloud with the free tier to stay within their trial.

All projects start with the same quotas, which you can change by requesting additional quota. Some quotas might increase automatically based on your use of a product.

Permissions

To view quotas or request quota increases, Identity and Access Management (IAM) principals need one of the following roles.

Task	Required role
Check quotas for a project	One of the following: Project Owner (roles/owner) Project Editor (roles/editor) Quota Viewer (roles/servicemanagement.quotaViewer)
Modify quotas, request additional quota	One of the following: Project Owner (roles/owner) Project Editor (roles/editor) Quota Administrator (roles/servicemanagement.quotaAdmin) A custom role with the serviceusage.quotas.update permission

Check your quota

Console

1. In the Google Cloud console, go to the Quotas page.

   Go to Quotas

2. To search for the quota that you want to update, use the Filter table. If you don't know the name of the quota, use the links on this page instead.

gcloud

Using the Google Cloud CLI, run the following command to check your quotas.

Replace PROJECT_ID with your own project ID.

    gcloud dns project-info describe PROJECT_ID
    

Errors when exceeding your quota

If you exceed a quota with a gcloud command, gcloud outputs a quota exceeded error message and returns with the exit code 1.

If you exceed a quota with an API request, Google Cloud returns the following HTTP status code: 413 Request Entity Too Large.

Request additional quota

To adjust most quotas, use the Google Cloud console. For more information, see Request a quota adjustment.

Console

1. In the Google Cloud console, go to the Quotas page.

   Go to Quotas

2. On the Quotas page, select the quotas that you want to change.
3. At the top of the page, click Edit quotas.
4. For Name, enter your name.
5. Optional: For Phone, enter a valid phone number.
6. Submit your request. Quota requests take 24 to 48 hours to process.

Resource availability

Each quota represents a maximum number for a particular type of resource that you can create, if that resource is available. It's important to note that quotas do not guarantee resource availability. Even if you have available quota, you can't create a new resource if it is not available.

For example, you might have sufficient quota to create a new regional, external IP address in the us-central1 region. However, that is not possible if there are no available external IP addresses in that region. Zonal resource availability can also affect your ability to create a new resource.

Situations where resources are unavailable in an entire region are rare. However, resources within a zone can be depleted from time to time, typically without impact to the service level agreement (SLA) for the type of resource. For more information, review the relevant SLA for the resource.