Cloud Interconnect に関するよくある質問

このドキュメントでは、Cloud Interconnect の機能とアーキテクチャに関するよくある質問について説明します。質問と回答は、以下のセクションにまとめています。

Cloud Interconnect を経由するトラフィック
Cloud Interconnect のアーキテクチャ
VLAN アタッチメント
MPLS
Cloud Interconnect 接続の管理
Cloud Interconnect エッジアベイラビリティゾーン

Cloud Interconnect を経由するトラフィック

このセクションでは、Cloud Interconnect を経由するトラフィックの種類、帯域幅、暗号化に関する質問に回答します。

Cloud Interconnect 経由で伝送されるのはどのような種類のパケットですか？

Cloud Interconnect の回線では、ペイロードに IPv4 パケットが含まれる 802.1q イーサネットフレームが伝送されます。これらのフレームは、VLAN タグ付きイーサネットフレームとも呼ばれます。

802.1q ヘッダーの 12 ビット VLAN ID（VID）フィールドの値は、VLAN アタッチメントの作成時に Google Cloud によって割り当てられる VLAN ID の値と同じです。詳細については、次のドキュメントをご覧ください。

Cloud Interconnect 経由のトラフィックを暗号化するにはどうすればよいですか？

Cloud Interconnect を使用してアクセスされるサービスによっては、特別な処理をしなくてもトラフィックがすでに暗号化されている場合があります。たとえば、Cloud Interconnect 経由で到達可能な Google Cloud APIs のいずれかにアクセスする場合、そのトラフィックは、公共のインターネット経由で API にアクセスするのと同じ方法で、TLS を使って暗号化されています。

Compute Engine インスタンスや HTTPS プロトコルをサポートする Google Kubernetes Engine Pod 上で提供するサービスなど、作成したサービスに TLS ソリューションを使用することもできます。

オンプレミスルーターと Google のエッジルーターの間でのみ暗号化が必要な場合は、Cloud Interconnect の MACsec をおすすめします。

IP レイヤで暗号化が必要な場合は、Cloud Interconnect を介した HA VPN をデプロイすることをおすすめします。

なんらかの理由で Cloud Interconnect を介した HA VPN をデプロイできない場合は、Virtual Private Cloud（VPC）ネットワークにセルフマネージド（Google Cloud 以外の）VPN ゲートウェイを作成し、各ゲートウェイにプライベート IP アドレスを割り振ることもできます。たとえば、Compute Engine インスタンスで strongSwan VPN を実行します。この場合は、オンプレミスから Cloud Interconnect を通過してそれらの VPN ゲートウェイで終端する IPsec トンネルを確立できます。

詳細については、転送データの暗号化をご覧ください。

Dedicated Interconnect 経由の 100 Gbps 接続を作成できますか？

はい、必要に応じて Google との接続をスケーリングできます。

Cloud Interconnect 接続は、イーサネットポートチャネルリンク（LAG）グループとしてデプロイされた 1 つ以上の回線で構成されます。接続内の回線は 10 Gbps または 100 Gbps のいずれかです。両方を使用することはできません。

接続には、次の最大容量のいずれかを選択できます。

8 x 10 Gbps 回線（合計 80 Gbps）
2 x 100 Gbps 回線（合計 200 Gbps）

Dedicated Interconnect または Partner Interconnect では、50 Mbps～50 Gbps の VLAN アタッチメント容量がサポートされています。Partner Interconnect でサポートされる最大アタッチメントサイズは 50 Gbps ですが、選択したロケーションで選択したサービスプロバイダから提供されるサービスによっては、使用できないサイズがあります。

Cloud Router の Border Gateway Protocol（BGP）ルーティング機能を使用すると、複数の接続を注文して、それらをアクティブ / アクティブで使用できます。

容量、割り当て、上限の詳細なリストについては、Cloud Interconnect の料金と割り当てと上限をご覧ください。

Cloud Interconnect 経由で IPv6 を使用してインスタンスにアクセスできますか？

Dedicated Interconnect は、IPv4 と IPv6（デュアルスタック）の VLAN アタッチメントを使用して、オンプレミスネットワークとの IPv6 接続をサポートします。

デュアルスタック VLAN アタッチメントで IPv6 ルート交換を有効にするには、IPv6 BGP セッションを構成するか、IPv4 BGP セッションで IPv6 ルート交換を有効にします。デュアルスタック VLAN アタッチメントの作成方法については、VLAN アタッチメントを作成するをご覧ください。

IPv4 BGP セッションで IPv6 ルート交換を有効にする方法については、IPv4 または IPv6 BGP セッションでマルチプロトコル BGP を構成するをご覧ください。

BGP ピアリング IP アドレスを指定できますか？

Partner Interconnect の場合はできません。Google によってピアリング IP アドレスが選択されます。
Dedicated Interconnect の場合、VLAN アタッチメントの作成時に Google が選択する IPv4 アドレス範囲（CIDR ブロック）の候補を指定できます。この CIDR ブロックは、IPv4 リンクローカルアドレス範囲 169.254.0.0/16 内に存在する必要があります。IPv6 アドレス範囲の候補は指定できません。Google が所有するグローバルユニキャストアドレス（GUA）の範囲 2600:2d00:0:1::/64 から選択されます。

オンプレミスから Cloud Interconnect を介して Google API にアクセスできますか？また、どのようなサービスや API を使用できますか？

次のオプションが用意されています。

Cloud Interconnect をプライベートチャネルとして使用して、すべての Google Workspace サービスにブラウザからアクセスできますか？

Cloud Interconnect 経由では Google Workspace アプリケーションに到達できません。

一定の時間が経過すると BGP セッションが継続的にフラップするのはなぜですか？

オンプレミスの BGP IP 範囲のサブネットマスクが正しいかどうか確認してください。たとえば、169.254.10.0/29 と構成すべきところを、169.254.10.0/30 と構成しているかもしれません。

L3 Partner Interconnect 接続を介して MED 値を送信し学習できますか？

レイヤ 3 サービスプロバイダが BGP を処理する Partner Interconnect 接続を使用している場合、Cloud Router がオンプレミスルーターから MED 値を学習することや、そのルーターに MED 値を送信することはできません。これは、MED 値が自律システムを通過できないためです。このタイプの接続では、Cloud Router からアドバタイズされたルートのルート優先度をオンプレミスルーターに設定することはできません。また、オンプレミスルーターによってアドバタイズされるルートの優先順位を VPC ネットワークに設定することはできません。

Cloud Interconnect のアーキテクチャ

このセクションでは、Cloud Interconnect のアーキテクチャを設計または使用する際のよくある質問に回答します。

Dedicated Interconnect 接続の名前の変更や、別のプロジェクトへの移動はできますか？

いいえ。Dedicated Interconnect 接続に名前を付けた後は、名前の変更や、別の Google Cloud プロジェクトへの移動はできません。その場合、接続を削除して、新しい名前または別のプロジェクトで再作成する必要があります。

Cloud Interconnect を使用して公共のインターネットに接続できますか？

インターネットルートは Cloud Interconnect 経由でアドバタイズされません。

コロケーション施設のロケーションのリストにない PoP ロケーションにいる場合、Google Cloud に接続するにはどうすればよいですか？

2 つの方法があります。いずれかを行った後、Dedicated Interconnect の通常の発注とプロビジョニングの処理を進めることができます。

オプション 1: 通信事業者に専用回線を注文し、拠点（PoP）のロケーションから Google の Cloud Interconnect コロケーション施設のいずれかに接続できます。通常は、契約しているコロケーション施設プロバイダに問い合わせ、「オンネット」プロバイダのリストを入手することをおすすめします。オンネットプロバイダとは、お客様の所在地である建物の中にすでにインフラストラクチャを構築しているプロバイダを指します。オンネットプロバイダを使用することによって、既存の PoP ロケーションに到達するためのインフラストラクチャのビルドを必要とする別のプロバイダを使用する場合と比較して、コストの低減と高速化を実現できます。
オプション 2: お客様の拠点に到達するための「ラストワンマイル回線」を提供できるサービスプロバイダをパートナーとして、Partner Interconnect を使用できます。通常、コロケーションプロバイダはこのタイプのサービスを提供できません。コロケーションプロバイダのロケーションは固定されており、お客様がすでにそのロケーションに存在している必要があるためです。

Partner Interconnect を使用する場合、VLAN アタッチメントを作成したプロジェクトの接続は確認できますか？

Partner Interconnect サービスを使用する場合、接続のオブジェクトがサービスプロバイダプロジェクトに作成されますが、プロジェクトには表示されません。VLAN アタッチメント（interconnectAttachment）は、Cloud Interconnect の場合と同様にプロジェクト内に表示されます。

Cloud Interconnect を使用する冗長アーキテクチャを作成するにはどうすればよいですか？

希望する SLA に応じて、Dedicated Interconnect、Partner Interconnect の両方について、特定のアーキテクチャを実装する必要があります。

詳細については、本番環境レベルアプリケーション用のトポロジの概要と、クリティカルでないアプリケーション用のトポロジの概要をご覧ください。

これらの SLA レベルは、Cloud Interconnect 接続の可用性（オンプレミスロケーションと VPC ネットワークの間でルーティングされる接続の可用性）を示しています。たとえば、Cloud Interconnect を介して到達可能な Compute Engine インスタンスにサービスを作成する場合、このサービスの可用性は、Cloud Interconnect サービスと Compute Engine サービスの両方の可用性の組み合わせによって左右されます。

Dedicated Interconnect の場合、単一の接続（LACP バンドル）に稼働時間のない SLA があります。
Partner Interconnect の場合は、単一の VLAN アタッチメントに稼働時間のない SLA があります。

単一の接続 / バンドルの障害に関する問題は、「P3: 中程度の影響 – サービスの使用が部分的に損なわれている」より低いサポートケースの優先度で処理されます。そのため、迅速な解決やさらなる根本原因の分析は期待できません。

定期または臨時メンテナンスが原因で、単一のリンクやバンドルが数時間または数日などの長期間にわたってもドレインされる可能性があります。

オンプレミスのアプリケーションと内部ロードバランサのバックエンドの間で、Cloud Interconnect 経由のトラフィックを転送できますか？

このシナリオでは、2 つの階層で構成されるアプリケーションをデプロイ済みです。Google Cloud にまだ移行されていないオンプレミス階層（レガシー階層）と、Google Cloud の内部ロードバランサのバックエンドでもある VPC インスタンス上で実行されているクラウド階層です。

Cloud Router とオンプレミスルーターの間に必要なルートを実装すれば、Cloud Interconnect を使用してこれら 2 つのアプリケーション階層の間でトラフィックを転送できます。次の 2 つのケースについて考えてみましょう。

ケース 1: Cloud Router とロードバランサのバックエンドが同じリージョンにある。

このアプリケーションのトラフィックを処理する VLAN アタッチメントの Cloud Router は、ロードバランサのバックエンドを含むサブネットと同じリージョンにあるため、追加の設定なしでトラフィックを転送できます。

ケース 2: 異なるリージョンに配置された Cloud Router とロードバランサのバックエンド。

このシナリオでは、Cloud Router とロードバランサのバックエンドが異なるリージョンに配置されているため、次のように構成する必要があります。

VPC でグローバル動的ルーティングモードを有効にします。
ロードバランサでグローバルアクセスモードを有効にします。

詳しくは以下をご覧ください。

Google Cloud のプロジェクトや組織間で、1 つ以上の Cloud Interconnect のインスタンスを移動できますか？

プロジェクトを新しい Google Cloud 組織に移行する必要がある場合は、サポートケースを登録していただくと、Google Cloud サポートで移行を迅速に処理できます。

組織を変更しても、プロジェクトが同じである限り、Dedicated Interconnect と VLAN アタッチメントに影響はありません。

プロジェクトを変更するにあたって、Cloud Interconnect のアクティベーションを実行していて LOA を所有しているが、まだアクティベーションを完了していない場合は、現在のアクティベーションをキャンセルして目的のプロジェクトに新しいインスタンスを作成します。Google が新しい LOA を発行し、お客様はそれを Cloud Interconnect 接続プロバイダに提供できます。手順については、接続を注文すると LOA-CFA を取得するをご覧ください。

アクティブな Cloud Interconnect 接続はプロジェクト間で移動することはできません。アクティブな Interconnect はプロジェクトの子オブジェクトであり、プロジェクト間でオブジェクトを自動的に移行する機能がないためです。可能であれば、新しい Cloud Interconnect のリクエストを最初から行ってください。

同じ Google Cloud 組織内の複数のプロジェクトで、同じ Cloud Interconnect 接続を使用して複数の VPC ネットワークに接続するにはどうすればよいですか？

Dedicated Interconnect または Partner Interconnect の場合は、共有 VPC または VPC ネットワークピアリングを使用して、複数の VPC ネットワーク間で単一のアタッチメントを共有できます。手順については、複数の VPC ネットワークに接続するための選択肢をご覧ください。

Partner Interconnect の場合

たとえば、VPC ネットワークを分離した状態で維持する必要があるなどの理由で、共有 VPC または VPC ネットワークピアリングを使用できない場合は、追加の VLAN アタッチメントを作成する必要があります。アタッチメントを追加作成すると、余分な費用が発生する可能性があります。

他のプロジェクトのものも含めて、複数の VLAN アタッチメントが存在する場合は、それらを同じサービスプロバイダの Partner Interconnect 接続、または異なるサービスプロバイダの Partner Interconnect 接続とペアリングできます。

Dedicated Interconnect の場合

接続するプロジェクトまたは VPC ネットワークごとに、複数のアタッチメントを作成できます。

プロジェクトが多数ある場合は、各プロジェクトに独自の VLAN アタッチメントと独自の Cloud Router を設定し、指定されたプロジェクトで同じ物理的な Dedicated Interconnect 接続を使用するようにすべてのアタッチメントを構成できます。

VLAN アタッチメントは、802.1q ID を持つ VLAN であるだけでなく、プロジェクト内に存在する Cloud Interconnect 接続の子オブジェクトでもあります。

このモデルでは、VPC ネットワークごとに独自のルーティング構成を持つことになります。ルーティングポリシーを一元管理する場合は、共有 VPC モデルと共有 VPC の考慮事項をご覧ください。その後、共有 VPC ホストプロジェクトの VPC ネットワーク内で VLAN アタッチメントを終端させることができます。ホストプロジェクトには、接続あたりの VLAN アタッチメントの最大数があります。詳細については、Cloud Interconnect の割り当てと上限をご覧ください。

1 つの Cloud Interconnect 接続を使用して、複数のオンプレミスサイトを VPC ネットワークに接続できますか？

これは簡単に実現できます。たとえば、複数のサイトが MPLS VPN ネットワークの一部である場合（セルフマネージド型、携帯通信会社による管理型のいずれであっても）、Inter-AS MPLS VPN Option A（詳細については、RFC 4364 のパラグラフ 10 を参照）と同様の方法で、VPC ネットワークを追加サイトとして論理的に追加できます。

このソリューションは、パートナーの MPLS VPN サービス内に VPC ネットワークが含まれるようにする方法に関する回答で説明されています。Cloud Router の BGP 機能を活用すると、インターネットルートのインポートに使用するのと同様のテクニックとアーキテクチャを使用して、既存の IP コアファブリック内に VPC ルートを挿入できます。

Google Cloud を他のクラウドサービスプロバイダに接続するにはどうすればよいですか？

Cross-Cloud Interconnect を使用すると、Google Cloud とサポートされている次のクラウドサービスプロバイダの間に専用接続を確立できます。

アマゾンウェブサービス（AWS）
Microsoft Azure
Oracle Cloud Infrastructure（OCI）
Alibaba Cloud

詳細については、Cross-Cloud Interconnect の概要をご覧ください。

Cross-Cloud Interconnect でサポートされていない別のクラウドプロバイダを使用している場合、2 つの接続に物理的にパッチを適用するというクラウドプロバイダ間の合意構成はありません。ただし、他のクラウドプロバイダがネットワーク相互接続サービスを提供する場合は、VPC ネットワークのプライベートアドレス空間と別のクラウドプロバイダのネットワークとの間でルーティングを行うことができます。

他のクラウドプロバイダのサービス接続ポイントが Cloud Interconnect と同じロケーションにある場合は、そのロケーションに独自のルーターをプロビジョニングして、2 つの接続サービスを終端させることができます。この場合、そのルーターは、VPC ネットワークと別のクラウドプロバイダのネットワークの間をルーティングします。この構成を使用すると、遅延を最小限に抑えながら、2 つのクラウドネットワークからオンプレミスネットワークに直接ルーティングできます。

Partner Interconnect の一部の通信事業者は、この構成を仮想ルーターに基づくマネージドサービスとして提供できます。Google Cloud と他のクラウドプロバイダが異なるロケーションで接続サービスを終端させる場合は、2 つのロケーションを接続する回線を用意する必要があります。

Google が Dedicated Interconnect サービスを提供しているロケーションについては、すべてのコロケーション施設をご覧ください。
Google が Partner Interconnect サービスを提供しているロケーションについては、サポートされているサービスプロバイダをご覧ください。

Google のエッジ近くのコロケーション施設に機器を設置せずに Google Cloud に接続するにはどうすればよいですか？

一部のネットワークサービスプロバイダは、Google エッジの近くにハードウェアを配置することを望まない Google Cloud のお客様向けに、独自の Cloud Router ソリューションと Partner Interconnect ベースのソリューションを提供しています。

Google Cloud で Equinix ソリューションを設定する方法については、Equinix の構成手順をご覧ください。

Google Cloud で Megaport を設定する方法については、Megaport の構成手順をご覧ください。

Google Cloud で Console Connect を設定する方法については、Console Connect の構成手順をご覧ください。

VLAN アタッチメント

このセクションでは、VLAN アタッチメントに関する質問に回答します。

VLAN アタッチメントに使用する VLAN ID を選択するにはどうすればよいですか？

Partner Interconnect を使用して作成された VLAN アタッチメントの場合、サービスプロバイダはアタッチメントの作成プロセス中に VLAN ID を選択しますが、ユーザーによる選択が可能な場合もあります。VLAN アタッチメントの VLAN ID を選択できるかどうかは、サービスプロバイダにご確認ください。

Dedicated Interconnect で作成される VLAN アタッチメントの場合、--vlan フラグをオンにして gcloud compute interconnects attachments create コマンドを使用するか、Google Cloud コンソールの手順を完了します。

次の例は、gcloud コマンドを使用して、VLAN ID を 5 に変更する方法を示しています。

gcloud compute interconnects attachments dedicated create my-attachment \
  --router my-router \
  --interconnect my-interconnect \
  --vlan 5 \
  --region us-central1

完全な手順については、以下のいずれかのドキュメントをご覧ください。

Cloud Router を複数の VLAN アタッチメントと併用できますか？

はい、この構成はサポートされています。

帯域幅の合計が Cloud Interconnect 接続の帯域幅を超過するように構成することはできますか？

はい。ただし、Cloud Interconnect 接続よりも大きな帯域幅を持つアタッチメントを作成しても、接続でサポートされる最大帯域幅を超えることはありません。

IPv6 トラフィックを伝送するように既存の Partner Interconnect アタッチメントの設定を更新するにはどうすればよいですか？

レイヤ 3 サービスプロバイダを使用している場合は、Partner Interconnect プロバイダに連絡して設定更新のサポートを依頼してください。

MPLS

このセクションでは、Cloud Interconnect とマルチプロトコルラベルスイッチング（MPLS）に関する質問について回答します。

Cloud Interconnect を使用して VPC ネットワーク内の MPLS LSP を終端させることができますか？

VPC には、MPLS LSP を終端させる Google Cloud の組み込み機能はありません。

セルフマネージドの MPLS VPN サービスで VPC ネットワークを追加サイトとして含めることはできますか？

管理している MPLS VPN サービスがある場合は、セルフマネージド VPN で構成される追加サイトとして VPC ネットワークを含めることができます。

このシナリオでは、プロバイダから MPLS VPN サービスを購入していないことが前提となります。つまり、お客様が所有している MPLS VPN 環境において、MPLS ネットワークの P ルーターおよび PE ルーターをお客様が管理、構成している必要があります。

セルフマネージド型 MPLS VPN サービス内に追加サイトとして VPC ネットワークを含めるには、次の手順を行います。

いずれかの MPLS VPN PE エッジデバイスを、Dedicated Interconnect のピアリングエッジデバイスに接続します。これには、Inter-AS MPLS VPN Option A（RFC 4364 のパラグラフ 10 を参照）と同様のモデルを使用します。つまり、必要な MPLS-VPN VPN（VRF_A など）を PE エッジデバイス内で終端させ、VLAN から VRF へのマッピングを使用して Google Cloud VLAN アタッチメントをこの VPN に「参加」させることができます。実質的には、PE エッジデバイスで VLAN を VRF_A にマッピングすることになります。
PE ルーターと Cloud Router の間に標準的な IPv4 BGP セッションを作成し、それらの間でルートが確実に交換されるようにします。Cloud Router によって送信されたルートは、VPN のルーティングテーブル（VRF_A 内）のみに設定され、PE エッジデバイスのグローバルルーティングテーブルには設定されません。

複数の独立した VPN を作成することで、重なり合う IP 範囲を管理できます。たとえば、VRF_A と VRF_B があり、それぞれに特定の VPC ネットワーク（たとえば VPC_A と VPC_B）内の Cloud Router への BGP セッションが存在するとします。この場合、お客様の PE エッジデバイスと Dedicated Interconnect のピアリングエッジデバイスの間に MPLS カプセル化は必要ありません。

Partner Interconnect のサービスプロバイダである通信事業者の MPLS VPN 内に、VPC ネットワークを追加サイトとして含めることはできますか？

Partner Interconnect の正式なサービスプロバイダである通信事業者から MPLS VPN サービスを購入した場合は、MPLS VPN 内に VPC ネットワークを追加サイトとして含めることができます。

この場合は、通信事業者が MPLS ネットワークの P ルーターと PE ルーターを管理、構成します。Partner Interconnect は Dedicated Interconnect とまったく同じ接続モデルを使用するため、通信事業者は Inter-AS MPLS VPN Option A（RFC 4364 のパラグラフ 10 を参照）と同様のモデルを利用できます。

実質的には、通信事業者はレイヤ 3 Partner Interconnect サービスをお客様に提供し、VLAN アタッチメントを通信事業者のエッジデバイス上の適切な MPLS VPN に「バインド」します。これはレイヤ 3 サービスモデルであるため、Cloud Router と通信事業者のエッジデバイス内の VRF の間に BGP セッションが確立されます。詳細については、Partner Interconnect の概要をご覧ください。

インフラストラクチャメンテナンスイベント

詳細については、インフラストラクチャメンテナンスイベントをご覧ください。

Cloud Interconnect 接続の管理

Cloud Interconnect の接続を一時的に切断したり、無効にしたりするにはどうすればよいですか？

Dedicated Interconnect または Partner Interconnect の接続を一時的に（フェイルオーバーテストやアラームテストなどで）シャットダウンする場合は、次のコマンドを使用します。

  gcloud compute interconnects update my-interconnect --no-admin-enabled

接続を再度有効にするには、次のコマンドを使用します。

  gcloud compute interconnects update my-interconnect --admin-enabled

接続を物理的に切断する必要がある場合は、プロバイダと協力して、コロケーション施設内の MMR で相互接続のプラグを外してください。提供されたオリジナルの LOA をプロバイダに提供して、接続解除をリクエストできます。

LOA にアクセスできなくなった場合は、cloud-interconnect-sd@google.com までメールでご連絡ください。

Cloud Interconnect エッジアベイラビリティドメイン

Dedicated Interconnect: 相互接続が異なるエッジアベイラビリティドメインにあることを確認するにはどうすればよいですか？

相互接続が異なるエッジアベイラビリティドメインにあることを確認するには、次のコマンドを使用します。大都市圏のアベイラビリティゾーンとエッジアベイラビリティドメインという用語は同じ意味で使用しています。詳細については、Cloud Interconnect のロケーションをご覧ください。

gcloud compute interconnects describe INTERCONNECT_NAME

出力で、location フィールドを確認します。ここには https://www.googleapis.com/compute/...<example>.../sin-zone1-388. などの URL が表示されます。URL の最後の部分はロケーションの名前（sin-zone1-38）です。

次に、LOCATION_NAME の説明を取得して、配置されているエッジアベイラビリティドメインを確認します。

gcloud compute interconnects locations describe LOCATION_NAME

このコマンドの出力には、相互接続がどのエッジアベイラビリティドメインにあるかを示す行が含まれています。

availabilityZone: zone1

特定の大都市圏のすべてのエッジアベイラビリティドメインを確認するには、ロケーションの表をご覧ください。

Partner Interconnect: 2 つのリンクが異なるエッジアベイラビリティドメインにあることを確認するにはどうすればよいですか？

2 つのリンクが異なるエッジアベイラビリティドメインにあることを確認するには、次のコマンドを使用します。

gcloud compute interconnects attachments describe VLAN_ATTACHMENT_NAME /
    --region REGION

このコマンドの出力には、次のような行が含まれています。

edgeAvailabilityDomain: AVAILABILITY_DOMAIN_1

両方のアタッチメントに対してコマンドを実行して、エッジアベイラビリティドメインが異なることを確認します。