お客様所有 IP アドレスの使用
お客様所有 IP アドレス（BYOIP）を使用すると、Google Cloud リソースに独自のパブリック IPv4 アドレスをプロビジョニングして使用できます。インポートされた IP アドレスは、Google Cloud により、Google 提供の IP アドレスと同じ方法で管理されます。ただし、次の点が異なります。
自社所有の IP アドレスは、取り込んだユーザーだけが利用できます。
アイドル状態と使用中の IP アドレスについては課金されません。
ライブ マイグレーションを使用すると、Google がプレフィックスのルート アドバタイジングを開始するタイミングを制御できます。デフォルトでは、ライブ マイグレーションは利用できません。アクセス権をリクエストするには、Google Cloud カスタマー エンジニアにお問い合わせください。
概要
お客様所有 IP アドレスを使用するには、パブリック アドバタイズド プレフィックス（PAP）を作成します。ROA とリバース DNS 検証を使用して、このパブリック アドバタイズド プレフィックスの所有権を検証します。検証が完了したら、このプレフィックスのインターネットへのアナウンスを構成しますが、プレフィックスはプロビジョニングされるまでアドバタイズされません。パブリック アドバタイズド プレフィックスがプロビジョニングされるまで最大で 4 週間かかります。
パブリック アドバタイズド プレフィックスがプロビジョニングされるのを待つ間、プレフィックスをパブリック委任プレフィックス（PDP）に分割します。これにより、パブリック委任プレフィックスをさらに分割することも、割り当て可能な IP アドレスの作成に使用することもできます。パブリック委任プレフィックスがプロビジョニングされるまで最大で 4 週間かかります。
パブリック委任プレフィックスのプロビジョニングが完了すると、パブリック アドバタイズド プレフィックスがインターネットにアドバタイズされます。ライブ マイグレーションを使用する場合は、ライブ マイグレーションを使用するの追加の手順をご覧ください。
パブリック アドバタイズド プレフィックス
パブリック アドバタイズド プレフィックス（PAP）は、Google Cloud に取り込んだ IP プレフィックスを表す Compute Engine のリソースです。これにより、自社独自のプレフィックスから IP アドレスを Google Cloud リソースに割り振ることができます。パブリック アドバタイズド プレフィックスは、ルート アドバタイズの単一ユニットです。Google のグローバル バックボーンは、すべての接続拠点からパブリック アドバタイズド プレフィックスをアドバタイズします。パブリック アドバタイズド プレフィックスの IP アドレスは常に、Network Service Tiers のプレミアム ティアを使用します。
パブリック アドバタイズド プレフィックスは、グローバル パブリック委任プレフィックスまたはリージョン パブリック委任プレフィックスのいずれかに使用できますが、両方には使用できません。
パブリック アドバタイズド プレフィックスが 2023 年 7 月 10 日より前に作成された場合は、BYOIP の動作変更をご覧ください。
新しいパブリック アドバタイズド プレフィックスを作成する際には、最小サイズ/24の CIDR 範囲を持つ、IPv4 IP 範囲が必要です。たとえば、より小さな CIDR 範囲（/25 など）は、新しいパブリック アドバタイズド プレフィックスとして作成できません。ただし、作成後、/24 や /23 などのパブリック アドバタイズド プレフィックスをより小さなパブリック デリゲート プレフィックスに分割できます。
パブリック委任プレフィックス
パブリック委任プレフィックス（PDP）は、単一のスコープ（特定のリージョンまたはグローバル）内で構成されたパブリック アドバタイズド プレフィックス内の IP ブロックです。IP ブロックは、プロジェクトまたは組織に IP アドレスを割り振る前に、委任してスコープに割り当てる必要があります。
グローバル パブリック委任プレフィックスの作成は制限されています。詳細については、グローバル パブリック委任プレフィックスをご覧ください。
単一のパブリック デリゲート プレフィックスを複数のより小さなブロックに分割することもできます。この場合、分割したブロックのスコープは親ブロックと同じでなければなりません。特定のスコープ内に、連続していない複数のパブリック委任プレフィックスを構成できます。こうしたより小さなブロックもパブリック委任プレフィックスですが、サブプレフィックスとも呼ばれます。
グローバル パブリック委任プレフィックス
グローバル パブリック委任プレフィックスを作成するには、グローバル パブリック委任プレフィックスの作成のみに使用されるパブリック アドバタイズド プレフィックスを使用する必要があります。グローバル プレフィックスを作成するアクセス権が付与されたプロジェクトでは、パブリック委任プレフィックスを作成する必要があります。
アクセス権をリクエストするには、サポートケースを送信して、プロジェクトがグローバル パブリック委任プレフィックスの作成のための許可リストに登録されるようにリクエストします。
IP アドレス
パブリック委任プレフィックスまたはサブプレフィックスから IP アドレスを作成する場合、その IP アドレスは、割り振られたプロジェクトとスコープ内でのみ使用できます。パブリック委任プレフィックスまたはサブプレフィックス内の IP アドレスは、すべて使用できます。予約済みのネットワーク アドレスやブロードキャスト アドレスはありません。たとえば、/28 パブリック委任プレフィックスまたはサブプレフィックスを使用して IP アドレスを作成すると、16 個の IP アドレス リソースが作成されます。
この IP アドレスを使用するには、プロジェクトで次の IAM 権限が必要です。
compute.addresses.*（リージョン IP アドレスの場合）compute.globalAddresses.*（グローバル IP アドレスの場合）
BYOIP の動作変更
以下の動作変更が 2023 年 7 月 10 日に適用されます。
- パブリック アドバタイズド プレフィックスは、グローバル パブリック委任プレフィックスまたはリージョン パブリック委任プレフィックスのいずれかに使用できますが、両方には使用できません。
- 2023 年 7 月 10 日より前に作成されたパブリック アドバタイズド プレフィックスは、リージョン パブリック委任プレフィックスの作成にのみ使用できます。
- グローバル パブリック委任プレフィックスを作成するには、アクセスをリクエストする必要があります。
既存のグローバル パブリック委任プレフィックス構成は影響を受けません。
BYOIP アドレスでポートを開く
BYOIP アドレスにポートスキャンを実行すると、予期しない結果が返されることがあります。グローバル BYOIP アドレスは、Google Front End（GFE）と呼ばれるインフラストラクチャ サービスによって実装されます。BYOIP アドレスでは、未使用の場合でもオープンポートがあるように見えることがあります。これらのポートが GFE を共有する他の Google サービスで使用されているためです。これらのポートへのトラフィックは破棄され、ログに記録されません。
グローバル IP アドレスは、サポートされているロードバランサのみで使用されます。ロードバランサのオープンポートの詳細については、以下をご覧ください。
パブリック IP 管理者のロール
Compute パブリック IP 管理者のロール（roles/compute.publicIpAdmin）を割り当てると、BYOIP プレフィックスとアドレスの管理者を指定できます。このロールを持つ管理者は、組織内で公開ルーティングが可能な IP を管理できます。
パブリック IP 管理者は次の操作を行えます。
- 所有するプロジェクトでパブリック アドバタイズド プレフィックスを構成する。
- パブリック アドバタイズド プレフィックスを、所有するプロジェクトのパブリック デリゲート プレフィックスに構成する。
- パブリック デリゲート プレフィックスから、組織内の特定のプロジェクトにサブプレフィックスを委任する。
- 以前パブリック デリゲート プレフィックスから組織内の特定のプロジェクトに委任されたサブプレフィックスを取り消す。
- パブリック デリゲート プレフィックスを削除する。
デプロイの計画
プロビジョニングと削除のプロセスが完了するまでには数週間かかるため、デプロイを計画しておくことが重要です。プロビジョニングのタイムラインと許可されるプレフィックス サイズの詳細については、制限事項をご覧ください。
デプロイの計画時に考慮すべき事項は次のとおりです。
BYOIP アドレス管理の責任者。通常、個々のプロジェクトを管理するユーザーではない管理者またはグループが担当します。IAM のロールと権限を使用して、プロビジョニングするパブリック アドバタイズド プレフィックスとパブリック デリゲート プレフィックスの権限を持つユーザーを区別します。
プレフィックスの管理方法。複数のプロジェクトの BYOIP アドレスの使用が必要になる場合があります。IP アドレスの最終的な宛先とは異なるプロジェクト内でプレフィックスを一元的に管理できます。パブリック IP 管理者権限を持つ独自のユーザーとグループを持つ独自のプロジェクトを作成し、プレフィックス管理を分離することをおすすめします。そうすることで、プレフィックス管理における混乱や、プレフィックスの意図されていない使用、不正使用を防げます。詳細については、プロジェクト アーキテクチャをご覧ください。
プレフィックスの命名方法。すべての BYOIP リソース（パブリック アドバタイズド プレフィックス、パブリック デリゲート プレフィックス、サブプレフィックス）には名前が必要です。名前は各リソースの管理に使用されます。名前はリソース作成時に割り当てます。この名前は、リソースを削除して再作成しない限り変更できません。そのため、管理しやすい名前で作成することをおすすめします。たとえば、
pap-203-0-113-0-24、pdp-203-0-113-0-25、sub-203-0-113-0-28では、文字がリソースの種類を表し、数字は特定のプレフィックスとプレフィックスの長さを示しています。IP アドレスがプロビジョニングされる場所。プロビジョニング プロセスは、リージョン（またはグローバル スコープ）に IP を「ストック」するものと考えることができます。IP アドレスをストックするプロビジョニング プロセスが完了するまでには数週間かかります。そのため、パブリック デリゲート プレフィックスは、必要になる前に十分な余裕を持って計画し、デプロイすることが大切です。
パブリック デリゲート プレフィックスのすべての IP をすぐに使用する必要はありません。どこで必要になるかが不明な場合は、確実に使用するパブリック デリゲート プレフィックスのみをプロビジョニングします。パブリック デリゲート プレフィックスを移動するには、完全に削除して再作成する必要があり、最長 8 週間かかることがあります。
パブリック デリゲート プレフィックスのプロビジョニングが完了したら、プロジェクトにサブプレフィックスを委任し、リソースで使用するアドレスを作成できます。あるリージョンで BYOIP アドレスが必要になると予測している場合、事前にパブリック委任プレフィックスのプロビジョニング プロセスを完了しておくことで、後は必要になったときにアドレスの指定を行うだけで済みます。
たとえば、
us-central1に IP アドレスが必要で、グローバル ロードバランサにも IP アドレスがいくつか必要で、さらに、将来のためにいくつかの IP アドレスを予約する場合は、次のプランを作成する必要があります。プレフィックスの種類 プレフィックス スコープ パブリック アドバタイズド プレフィックス 203.0.113.0/24 グローバル ロードバランサのパブリック アドバタイズド プレフィックス 192.0.2.0/24 パブリック委任プレフィックス 203.0.113.0/28 us-central1 パブリック委任プレフィックス 203.0.113.16/28 us-east-4 パブリック委任プレフィックス 192.0.2.0/28 グローバル 残りの IP アドレスは、将来の使用のために予約されます。
ライブ マイグレーション
ライブ マイグレーションは、詳細な計画と実行を必要とする強力な機能です。
プレフィックスの一部がすでにアドバタイズされている場合は、ライブ マイグレーションを使用して BYOIP プレフィックスをインポートします。ライブ マイグレーションを使用せずにアドバタイズド プレフィックスをインポートすると、予期しないルーティングやパケットロスが発生する可能性があります。
ライブ マイグレーションは限定的に利用可能です。ライブ マイグレーションを有効にしてパブリック デリゲート プレフィックスを作成する前に、Google Cloud のカスタマー エンジニアに問い合わせてアクセス権を取得してください。
ライブ マイグレーションは、パブリック デリゲート プレフィックスの作成時に有効にします。パブリック アドバタイズド プレフィックスが Google によってピアにアドバタイズされないようにするには、次の点を確認する必要があります。
パブリック アドバタイズド プレフィックス内のパブリック デリゲート プレフィックスはすべて、グローバル スコープではなく、リージョン スコープで構成されている。詳しくは、ライブ マイグレーションの推奨事項をご覧ください。
パブリック アドバタイズド プレフィックスの範囲内の IP アドレスはリソースに割り振られていない。
図 2 に、構成が異なる同じプロジェクトを表示します。1 つの構成ではプレフィックスがアドバタイズされませんが、2 つの構成ではパブリック アドバタイズド プレフィックスがアドバタイズされます。
図 2 は次のシナリオを示しています。
最初のプロジェクトの例では、パブリック アドバタイズド プレフィックスのすべてのパブリック委任プレフィックスでライブ マイグレーションが有効になっています。このプレフィックスの IP アドレスは VM に構成されていません。
結果: パブリック アドバタイズド プレフィックスはアドバタイズされません。
2 番目のプロジェクトの例では、パブリック アドバタイズド プレフィックスのすべてのパブリック委任プレフィックスでライブ マイグレーションが有効になっています。このプレフィックスの IP アドレスを使用して 1 つの VM が構成されています。
結果: パブリック アドバタイズド プレフィックスはアドバタイズされます。
3 番目のプロジェクトの例では、パブリック アドバタイズド プレフィックスの 1 つのパブリック デリゲート プレフィックスでライブ マイグレーションが有効になっていません。このプレフィックスの IP アドレスは VM に構成されていません。
結果: パブリック アドバタイズド プレフィックスはアドバタイズされます。
パブリック デリゲート プレフィックスから IP アドレスを Google Cloud リソースに割り当てることで、アドバタイズメントが開始されるタイミングを制御できます。詳細については、ライブ マイグレーションを使用するをご覧ください。
ライブ マイグレーションが完了したら、Google Cloud カスタマー エンジニアに連絡して、プレフィックスのライブ マイグレーションを無効にするよう依頼してください。デフォルトでは、パブリック アドバタイズド プレフィックスのアドバタイズを開始してから 30 日後にライブ マイグレーションが無効になります。30 日を超えるライブ マイグレーション オプションが必要な場合は、Google Cloud のカスタマー エンジニアにお問い合わせください。
ライブ マイグレーションの制限
ライブ マイグレーションを計画する場合は、次の要件と制限事項を理解しておくことが重要です。
スコープがグローバルに設定されている場合、ライブ マイグレーションを有効にしたパブリック デリゲート プレフィックスの作成はサポートされません。グローバル リソースのライブ マイグレーションの管理については、ライブ マイグレーションの推奨事項をご覧ください。
/24はインターネットでルーティング可能なプレフィックスの最長の長さであるため、移行できる最長プレフィックスは/24です。すべての Google のピアが、2 つのサイト間で最長のプレフィックスを使用できるとは限りません。一部のピアにはルーティング テーブルがない場合があります。そのため、Google がピアにアドバタイズする短いプレフィックスは、ピアに表示される唯一の（したがって最長の）プレフィックスになります。その結果、オンプレミスのロケーションからより限定されたルートをアドバタイジングする場合でも、Google からのプレフィックスの存在が優先されます。
例:
お客様は、オンプレミスのロケーションからアクティブにルーティングされる
/23を持っています。お客様が、/23を 2 つの/24プレフィックスに分解し、オンプレミスのロケーションからより限定したルートをアナウンスします。分解後に、BYOIP に/23パブリック アドバタイズド プレフィックスを構成します。お客様は、短い BYOIP プレフィックスよりもオンプレミスのロケーションからのより限定されたルートのほうが優先され、引き続きトラフィックは限定されたオンプレミス プレフィックスにルーティングされるものと想定しています。残念ながら、この手法は部分的にのみ機能します。
フル ルーティング テーブルを持つ Google の類似アプリは、より具体的な
/24オンプレミス プレフィックスを優先します。フル ルーティング テーブルを持たない Google の類似アプリは、ルーティング テーブルにより具体的なプレフィックスが含まれていないため、Google がアナウンスするパブリック アドバタイズド プレフィックスを使用することが推奨されます。
プレフィックス用のアクティブなオンプレミス アドバタイズメントがある場合でも、サービスをプロビジョニングしていない有効なパブリック アドバタイズド プレフィックスのトラフィックを Google が受信した場合、トラフィックは配信されません。
例:
お客様は 2 つの
/24プレフィックスで構成されるオンプレミス ネットワークを持っています。そのパブリック アドバタイズド プレフィックスは/23を集約したものです。お客様は 1 つの
/24を Google に移行し、オンプレミス プレフィックスを取り消しますが、他の/24はオンプレミスのロケーションでアクティブのままにします。この構成では、オンプレミスのロケーションからより具体的な
/24プレフィックスがアナウンスされているにもかかわらず、/23プレフィックス全体では、一部に Google へのトラフィック ルーティングが発生します。さまざまな自律システムがオンプレミスのロケーションにトラフィックを配信する一方、その他のシステムからは Google に配信され、トラフィックがドロップされるため、このシナリオの診断は困難です。
ライブ マイグレーションの推奨事項
ライブ マイグレーションを使用する際のベスト プラクティスとして、次の推奨事項を実施してください。
移行中にプレフィックスをアドバタイズする方法を考慮して、すべてのライブ マイグレーション プレフィックスを最長のプレフィックスに分割します。先の例では、パブリック アドバタイズド プレフィックスを作成する前に
/23を 2 つの/24プレフィックスに分割し、オンプレミスのロケーションからそのようにアナウンスするのが適切な手法です。正確なプレフィックス長の ROA リクエストを作成し、最長パラメータが常に適用されるとは考えないようにします。
オンプレミスの発信元 ASN と Google の発信元 ASN の両方に RPKI ROA リクエストがあることを確認します。オンプレミス プレフィックスの ROA がない状態で Google の発信元 ROA を作成すると、第三者 ISP が自動 RPKI フィルタリングが使用している場合には、そのオンプレミス プレフィックスが除外される可能性があります。
ライブ マイグレーションを使用する必要がある場合は、グローバル リソースおよびリージョン リソース用のパブリック アドバタイズド プレフィックスを個別に作成します。パブリック デリゲート プレフィックスでライブ マイグレーションを有効にするときは、スコープのリージョンを指定する必要があります。ライブ マイグレーションが有効なパブリック デリゲート プレフィックスでのグローバル スコープの指定はサポートされていません。ライブ マイグレーションが有効なグローバル スコープのパブリック デリゲート プレフィックスを作成すると、プレフィックスは直ちにアドバタイズされます。
1 つのパブリック アドバタイズド プレフィックスにリージョン プレフィックスを、別のパブリック アドバタイズド プレフィックスにグローバル プレフィックスを含めると、それらを個別に管理できます。リージョン リソースのライブ マイグレーションはお客様側で管理できます。グローバル リソースのライブ マイグレーションを管理するには、Google Cloud のカスタマー エンジニアに問い合わせてください。
プロジェクト アーキテクチャ
組織を利用して、組織レベルでの IAM 権限や共有 VPC などの有用な機能を活用することをおすすめします。組織の利用の詳細については、組織の作成と管理をご覧ください。
組織内の BYOIP アドレス管理
この例のように、組織に属するプロジェクトには、BYOIP アドレスの管理に使用される専用のプロジェクト Public IP Project があります。組織のパブリック IP 管理者は、Public IP Project にパブリック アドバタイズド プレフィックスとパブリック デリゲート プレフィックスを事前に作成します。
VPC Project でパブリック IP アドレスが必要な場合は、組織のパブリック IP 管理者が VPC Project に IP アドレスを作成します。
組織に複数のプロジェクトを含めることができ、パブリック IP 管理者は Public IP Project からすべてのプロジェクトに IP アドレスを委任できます。
共有 VPC を使用した BYOIP アドレス管理
この例のように、共有 VPC を持つ組織には、BYOIP アドレスの管理に使用される専用のプロジェクト Public IP Project があります。組織のパブリック IP 管理者は Public IP Project にパブリック アドバタイズド プレフィックスとパブリック デリゲート プレフィックスを事前に作成します。
Shared VPC Host Project または関連サービス プロジェクトでパブリック IP アドレスが必要な場合は、組織のパブリック IP 管理者が Shared VPC Host Project に IP アドレスを作成します。ホスト プロジェクトとサービス プロジェクトは、ホスト プロジェクトから BYOIP アドレスにアクセスできます。
共有 VPC サービス プロジェクトでの IP アドレスの作成はサポートされていません。
組織を使用しない BYOIP アドレス管理
組織に帰属しないプロジェクトを使用する場合、BYOIP アドレス管理用に個別のプロジェクトを作成することはできません。BYOIP アドレスが必要な 1 つのプロジェクトにパブリック アドバタイズド プレフィックスとパブリック委任プレフィックスを作成します。
割り当てと上限
パブリック委任プレフィックス（PDP）とパブリック アドバタイズド プレフィックス（PAP）には、割り当てと上限があります。詳細については、VPC の割り当てと上限をご覧ください。