お客様所有 IP の使用

お客様所有 IP アドレス(BYOIP)を用意すると、Google Cloud リソースに独自のパブリック IPv4 アドレスをプロビジョニングして使用できます。インポートされた IP アドレスは、Google Cloud により、Google 提供の IP アドレスと同じ方法で管理されます。ただし、次の点が異なります。

  • 自社所有の IP アドレスは、取り込んだユーザーだけが利用できます。

  • アイドル状態と使用中の IP アドレスについては課金されません。

ライブ マイグレーションを使用すると、Google がプレフィックスのルート アドバタイジングを開始するタイミングを制御できます。デフォルトでは、ライブ マイグレーションは利用できません。アクセスをリクエストする場合は、Google Cloud の担当者までお問い合わせください。

概要

お客様所有 IP アドレスを使用するには、パブリック アドバタイズド プレフィックス(PAP)を作成します。ROA とリバース DNS 検証を使用して、このパブリック アドバタイズド プレフィックスの所有権を検証します。検証が完了したら、このプレフィックスのインターネットへのアナウンスを構成しますが、プレフィックスはプロビジョニングされるまでアドバタイズされません。パブリック アドバタイズド プレフィックスがプロビジョニングされるまで最大で 4 週間かかります。

パブリック アドバタイズド プレフィックスがプロビジョニングされるのを待つ間、プレフィックスをパブリック委任プレフィックス(PDP)に分割し、リージョン スコープまたはグローバル スコープを使用するように構成します。これにより、パブリック委任プレフィックスをさらに分割することも、割り当て可能な IP アドレスの作成に使用することもできます。パブリック委任プレフィックスがプロビジョニングされるまで最大で 4 週間かかります。

パブリック委任プレフィックスのプロビジョニングが完了すると、パブリック アドバタイズド プレフィックスがインターネットにアドバタイズされます。ライブ マイグレーションを使用する場合は、ライブ マイグレーションの使用の追加の手順をご覧ください。

図 1. パブリック アドバタイズド プレフィックスとパブリック委任プレフィックスを作成するワークフロー。

パブリック アドバタイズド プレフィックス

パブリック アドバタイズド プレフィックス(PAP)は、Google Cloud に取り込んだ IP プレフィックスを集約した、Compute Engine のリソースです。これにより、自社独自のプレフィックスから IP アドレスを Google Cloud リソースに割り振ることができます。この IP プレフィックスは、ルート アドバタイズの単一ユニットであり、インターネットに対してグローバルにアナウンスされます。IP プレフィックスは Network Service Tiers のプレミアム ティアでのみ利用でき、スコープはグローバルです。

新しいパブリック アドバタイズド プレフィックスを作成する際には、最小サイズ/24の CIDR 範囲を持つ、IPv4 IP 範囲が必要です。たとえば、より小さな CIDR 範囲(/25 など)は、新しいパブリック アドバタイズド プレフィックスとして作成できません。ただし、作成後、/24/23 などのパブリック アドバタイズド プレフィックスをより小さなパブリック デリゲート プレフィックスに分割できます。

パブリック デリゲート プレフィックス

パブリック デリゲート プレフィックス(PDP)は、単一のスコープ(特定のリージョンまたはグローバル)内で構成されたパブリック アドバタイズド プレフィックス内の IP ブロックです。IP ブロックは、プロジェクトまたは組織に IP アドレスを割り振る前に、委任してスコープに割り当てる必要があります。

パブリック アドバタイズド プレフィックスを複数のパブリック委任プレフィックスに分割し、その 1 つ 1 つを Google Cloud プロジェクトで必要なスコープを使用して構成できます。単一のパブリック デリゲート プレフィックスを複数のより小さなブロックに分割することもできます。この場合、分割したブロックのスコープは親ブロックと同じでなければなりません。特定のスコープ内に、連続していない複数のパブリック デリゲート プレフィックスを構成できます。こうしたより小さなブロックもパブリック委任プレフィックスですが、サブプレフィックスとも呼ばれます。

IP アドレス

パブリック委任プレフィックスから作成した IP アドレスは、その IP アドレスに割り当てられたプロジェクトとスコープ内でのみ使用できます。この IP アドレスを使用するには、プロジェクトで次の IAM 権限が必要です。

  • compute.addresses.*(リージョン IP アドレスの場合)

  • compute.globalAddresses.*(グローバル IP アドレスの場合)

パブリック IP 管理者のロール

Compute パブリック IP 管理者のロールroles/compute.publicIpAdmin)を割り当てると、BYOIP プレフィックスとアドレスの管理者を指定できます。このロールを持つ管理者は、組織内で公開ルーティングが可能な IP を管理できます。

パブリック IP 管理者は次の操作を行えます。

  • 所有するプロジェクトでパブリック アドバタイズド プレフィックスを構成する。
  • パブリック アドバタイズド プレフィックスを、所有するプロジェクトのパブリック デリゲート プレフィックスに構成する。
  • パブリック デリゲート プレフィックスから、組織内の特定のプロジェクトにサブプレフィックスを委任する。
  • 以前パブリック デリゲート プレフィックスから組織内の特定のプロジェクトに委任されたサブプレフィックスを取り消す。
  • パブリック デリゲート プレフィックスを削除する。

デプロイの計画

プロビジョニングと削除のプロセスが完了するまでには数週間かかるため、デプロイを計画しておくことが重要です。プロビジョニングのタイムラインと許可されるプレフィックス サイズの詳細については、制限事項をご覧ください。

デプロイの計画時に考慮すべき事項は次のとおりです。

  • BYOIP アドレス管理の責任者。通常、個々のプロジェクトを管理するユーザーではない管理者またはグループが担当します。IAM のロールと権限を使用して、プロビジョニングするパブリック アドバタイズド プレフィックスとパブリック デリゲート プレフィックスの権限を持つユーザーを区別します。

  • プレフィックスの管理方法。複数のプロジェクトの BYOIP アドレスの使用が必要になる場合があります。IP アドレスの最終的な宛先とは異なるプロジェクト内でプレフィックスを一元的に管理できます。パブリック IP 管理者権限を持つ独自のユーザーとグループを持つ独自のプロジェクトを作成し、プレフィックス管理を分離することをおすすめします。そうすることで、プレフィックス管理における混乱や、プレフィックスの意図されていない使用、不正使用を防げます。詳細については、プロジェクト アーキテクチャをご覧ください。

  • プレフィックスの命名方法。すべての BYOIP リソース(パブリック アドバタイズド プレフィックス、パブリック デリゲート プレフィックス、サブプレフィックス)には名前が必要です。名前は各リソースの管理に使用されます。名前はリソース作成時に割り当てます。この名前は、リソースを削除して再作成しない限り変更できません。そのため、管理しやすい名前で作成することをおすすめします。たとえば、pap-203-0-113-0-24pdp-203-0-113-0-25sub-203-0-113-0-28 では、文字がリソースの種類を表し、数字は特定のプレフィックスとプレフィックスの長さを示しています。

  • IP アドレスがプロビジョニングされる場所。プロビジョニング プロセスは、リージョン(またはグローバル スコープ)に IP を「ストック」するものと考えることができます。IP アドレスをストックするプロビジョニング プロセスが完了するまでには数週間かかります。そのため、パブリック デリゲート プレフィックスは、必要になる前に十分な余裕を持って計画し、デプロイすることが大切です。

    パブリック デリゲート プレフィックスのすべての IP をすぐに使用する必要はありません。どこで必要になるかが不明な場合は、確実に使用するパブリック デリゲート プレフィックスのみをプロビジョニングします。パブリック デリゲート プレフィックスを移動するには、完全に削除して再作成する必要があり、最長 8 週間かかることがあります。

    パブリック デリゲート プレフィックスのプロビジョニングが完了したら、プロジェクトにサブプレフィックスを委任し、リソースで使用するアドレスを作成できます。あるリージョンで BYOIP アドレスが必要になると予測している場合、事前にパブリック デリゲート プレフィックスのプロビジョニング プロセスを完了しておくことで、後は必要になったときにアドレスの指定を行うだけで済みます。

    たとえば、パブリック アドバンスド プレフィックス /24 があるとします。us-central1 に IP アドレスがいくつか必要で、グローバル ロードバランサ用にも IP アドレスがいくつか必要です。また、今後のためのストックも用意したいと考えています。次のように計画を作成することができます。

    プレフィックスの種類 プレフィックス スコープ
    パブリック アドバタイズド プレフィックス 203.0.113.0/24
    パブリック デリゲート プレフィックス 203.0.113.0/28 us-central1
    パブリック デリゲート プレフィックス 203.0.113.16/28 グローバル
    今後のためのストックにする IP アドレス

ライブ マイグレーション

ライブ マイグレーションは、詳細な計画と実行を必要とする強力な機能です。

プレフィックスの一部がすでにアドバタイズされている場合は、ライブ マイグレーションを使用して BYOIP プレフィックスをインポートします。ライブ マイグレーションを使用せずにアドバタイズド プレフィックスをインポートすると、予期しないルーティングやパケットロスが発生する可能性があります。

ライブ マイグレーションは限定的に利用可能です。ライブ マイグレーションを有効にしてパブリック デリゲート プレフィックスを作成する前に、Google Cloud の担当者に問い合わせてアクセス権を取得してください。

ライブ マイグレーションは、パブリック デリゲート プレフィックスの作成時に有効にします。パブリック アドバタイズド プレフィックスが Google によってピアにアドバタイズされないようにするには、次の点を確認する必要があります。

  • パブリック アドバタイズド プレフィックス内のパブリック デリゲート プレフィックスはすべて、グローバル スコープではなく、リージョン スコープで構成されている。詳しくは、ライブ マイグレーションの推奨事項をご覧ください。

  • パブリック アドバタイズド プレフィックスの範囲内の IP アドレスはリソースに割り振られていない。

図 2 に、構成が異なる同じプロジェクトを表示します。1 つの構成ではプレフィックスがアドバタイズされませんが、2 つの構成ではパブリック アドバタイズド プレフィックスがアドバタイズされます。

図 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 アドレスを委任できます。

図 3. 組織とプロジェクトを使用して BYOIP アドレスを管理できます。

共有 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 アドレスの作成はサポートされていません。

図 4. 共有 VPC ホスト プロジェクトに BYOIP アドレスを委任することはできますが、共有 VPC サービス プロジェクトに委任することはできません。ただし、サービス プロジェクトはホスト プロジェクトに委任された BYOIP アドレスを使用できます。

組織を使用しない BYOIP アドレス管理

組織に帰属しないプロジェクトを使用する場合、BYOIP アドレス管理用に個別のプロジェクトを作成することはできません。BYOIP アドレスが必要な 1 つのプロジェクトにパブリック アドバタイズド プレフィックスとパブリック デリゲート プレフィックスを作成します。

次のステップ