🐯

AWS ⇔ Google Cloud 間で Cross-Cloud Interconnect 構成してみた

2023/07/03に公開

AWS

はじめに

こんにちは、クラウドエースでSREディビジョンに所属している Shanks と申します。

2023/06/01 に Cross-Cloud Interconnect（以降、CCIと呼ぶ。）という Cloud Interconnect の派生機能が新たに追加されました。
CCI のまとめ記事については、下記で公開していますので、この記事を読む前にご一読ください。

とはいえ、ドキュメントを読むだけでは得られない注意点があると思います。
そこで、本記事では手順に加えて実際に AWS - Google Cloud 間で CCI を構築してみて気づいた点などを解説をします。

概要

実際にそれぞれの環境を構築したことで得られたポイントをまとめ、実際の流れを把握することを目的としています。

方針

検証の方針は以下の通りとします。

AWS - Google Cloud 間で CCI を構成する
- 構成は HA 構成とする
- 東京リージョンを利用する
- 契約する帯域幅は 10 Gbps とする

確認点

確認点は以下の通りとします。

公式ドキュメントの手順に従って構成手順を確認する
公式ドキュメントにない点や不足点を補足する

アーキテクチャ

検証環境として以下の構成図のとおり環境を構成します。
architecture
CCI 構成図

クラウドプロバイダ	リソース種別	リソース数
Google Cloud	VPC	1
Google Cloud	Cloud Router	1
Google Cloud	VLAN アタッチメント	2
Google Cloud	Interconnect 接続	2
AWS	VPC	1
AWS	Direct Connect ゲートウェイ	1
AWS	LAG	2
AWS	接続	2
AWS	仮想インターフェイス	2
AWS	仮想ゲートウェイ	1

構成手順

構成手順は大きく4つの STEP に分かれます。
最後の STEP5 は接続確認ですが、これに加え ping 等を用いて疎通確認まで行うと良いでしょう。

STEP1 Cross-Cloud Interconnect 接続を注文する

まず最初に、Google Cloud の CCI 接続を注文します。
Cloud Console より相互接続 > 物理接続を設定と進むと、Cloud Interconnect の接続タイプを聞かれますので、「Cross-Cloud Interconnect 接続」を選択します。
gcp-connection-create-1

続いて、接続の詳細を入力する画面になりますので、値を入力します。
今回は Amazon Web Services を選択し、それぞれのロケーションを東京（Equinix Tokyo）で選択します。
gcp-connection-create-2

後続の冗長構成や LOA-CFA に必要な技術責任者の連絡先等を記入し、注文ボタンを押下すれば完了です。
gcp-connection-create-3

最後に、注文が完了し以下のようになっていることを確認してください。
request-port

注文が正常に完了するとメールが届きます。
get-email

STEP2 AWS ポートを注文する

続いて、AWS ポートを注文します。AWS のコンソールから AWS Direct Connect > LAG と進み、CCIの物理接続と同じ数だけ LAG を作成します。つまり、 LAG を2つ作成します。

後述の注意点にも記載しますが、今回の手順で LAG に設定する接続数は 1 です。
誤解しやすいですが、 CCI の物理接続が2つである場合に、 LAG を1つで接続数を2に設定して進めると CCI の結線作業に失敗します。
ですので、 CCI で冗長構成を組む場合は、 CCI の物理接続の数と、 AWS LAG の数を一致させるよう、 LAG の作成作業を繰り返してください。
aws-lag-create

次に、接続タブの中のIDをクリックして、各接続で LOA-CFA ファイルを取得します。
Optional Field は "Google Cloud" と入力し、 LOA-CFA ファイルをダウンロードします。
この LOA-CFA ファイルを Google Interconnect Team から送信された LOA-CFA リクエストメールに対して返信する形で送付します。
(今回は冗長構成のため、LAG 毎に合計2回実施する)
get-loa-aws

メールで送付して数日後、物理接続が完了した旨を知らせるメールが Google Interconnect Team から届きます。
CCI の物理接続と、AWS の LAG の双方が正しくリンクアップしていることが確認できます。

LOA-CFA ファイル送付から物理接続の開通まで、おおよそ1週間程度のリードタイムが発生しましたので、構築される際に考慮するとよいでしょう。
なお、このリードタイムはあくまで今回の検証でかかった期間であり、SLA等で保証されているわけではございません。

STEP3 Google Cloud リソースを構成する

お互いにリンクアップしていることが確認できたら、BGPセッションを構成するために Google Cloud 側からリソースを作成します。
Google Cloud 側のリソースについては割愛しますが、Cloud Router の BGP IP と BGP ピア IP はAWS側のリソース作成で必要になりますのでメモを取ってください。

VPC ネットワーク
サブネットワーク（任意）
Cloud Router
VLAN アタッチメント

Cloud Router の補足情報

複数の経路を意図的に設けたい場合、構築できる Cloud Router の個数がクォータに触れてしまうことがあります。
例えば、正副系統で Cloud Router をx2個用意するとこの制限に触れる可能性が高くなります。
99.99% の可用性のための冗長接続

その場合は、異なる Edge Availability Domain の値を VLAN アタッチメントに設定し、1つの Cloud Router に複数の VLAN アタッチメントを接続することで回避できます。

これは、Cloud Router が VLAN アタッチメントの Edge Availability Domain の値によって正副系統として Cloud Router 内部プロセスを完全に分離するためです。
Cloud Router の個数を節約したい場合はぜひご活用ください。

STEP4 AWS リソースを構成する

Direct Connect ゲートウェイの作成

まず、Direct Connect ゲートウェイを作成します。
このとき、Amazon 側の ASN には Cloud Router で指定したピア ASN を指定します。
（Cloud Routerから見たピア ASN は Amazon 側の ASN となります）
aws-direct-connect-gateway-create

仮想プライベートインターフェースの作成

次に、仮想プライベートインターフェースを作成します。
設定する値の多くは、Direct Connect ゲートウェイと同様、Cloud Router で指定したピア情報です。
ここで VLAN ID は Google Cloud の VLAN アタッチメントで指定したものと同じIDを使用します。
aws-vpi-create

仮想プライベートゲートウェイの作成

次に、仮想プライベートゲートウェイを作成します。
ここで指定する Amazon ASN は Direct Connect ゲートウェイと同様に Cloud Router で指定したピア ASN を指定します。
aws-vpg-create

AWS VPC へのアタッチ

仮想プライベートゲートウェイが作成できたら AWS VPC に接続します。

アクションからVPCにアタッチを選択	AttachedとなっていればOK

Direct Connect ゲートウェイへのアタッチ

仮想プライベートゲートウェイを Direct Connect ゲートウェイに関連付ければリソース作成は完了です。

ゲートウェイを関連付けるを選択	AttachedとなっていればOK

STEP5 接続を確認する

最後に、接続状況を確認します。
Google Cloud Console より相互接続 > 物理接続タブ > 該当の接続名 > 相互接続の詳細ページを確認します。

構成したVLANアタッチメントが正しければVLANアタッチメントのステータスが稼働中となります。
gcp-check-signal-for-aws-vlan

そして一番重要な点は、ページ下部にある「リンク回路の情報」です。
構成したリソースが AWS 共に正常でどちらもリンクアップしていればステータスがOKとなります。
これによりL2レベルでのリンクアップが確認できます。
このとき、光信号の送受信強度を確認することができ、この数値が -10 を下回っていなければ信号が十分送受信できる状態です。
gcp-check-signal-for-aws

おまけ

実際にやってみたことで気づいた注意点をまとめます。
なお、検証を行ったメンバは AWS の初学者で知識が少なく、筆者に至っては AWS をほぼ初めて触ったレベルです。
そのため、AWS に精通している方からみたら初歩的なつまづきがあるかもしれません。
AWS を知らない人はここで躓く、Google Cloud では異なる設計思想である、という気づきを得るものとして読んでいただければ幸いです。

注意点

検証環境を構成していて得られた注意点として、AWS と Google Cloud で専用線に関する設計思想の違いが挙げられます。
AWS では LAG と呼ばれる論理インターフェイスが存在します。

Link Aggregation Group (LAG) は、Link Aggregation Control Protocol (LACP) を使用して、1 つの AWS Direct Connect エンドポイントに複数の接続を集約し、それらを 1 つのマネージド型接続として扱うことを可能にする論理インターフェイスです。

CCI では AWS 側でこのリンクアグリゲーションの技術を使用したリソース（LAG）を作成する必要があるのですが、最初に構成した際に誤った構成をしてしまいました。
miss-architecture
誤った構成

まず、AWS の LAG は名前に Group と付いているものの、単一の接続構成が可能です。
Google Cloud の Interconnect 接続と Cloud Router のように、別のリソースにアタッチするものと認識していましたが誤りでした。
AWS には Cloud Router のようなものがなく、LAG に内蔵されているようなイメージで、それぞれの CCI 物理接続には対応する LAG が必要でした。
architecture
正しい構成

これらのつまづき(特に LAG の設定誤り)により、検証環境の片系で CCI の物理接続が失敗し、冗長構成が組めない状態になりました。
サポート問い合わせを行い、 LAG を再作成した後に再度 LOA-CFA して復旧しましたが、検証を開始できるまで追加で1週間程度費やしました。
公式ドキュメントでは、AWS の LAG と CCI の物理接続の対応について詳細に説明されていないため、ご注意ください。

まとめ

本記事では、新たに Cloud Interconnect へ追加された Cross-Cloud Interconnect の具体的な構築手順についてまとめました。
本記事がマルチクラウド構成を検討されている方にとって一助となれば幸いです。

最後に、特に重要なポイントをまとめます。
CCI を含め Cloud Interconnect は高額なサービスかつ構成にリードタイムを多く要します。
構築の際はポイントを確認しながら慎重に進めましょう。

Cloud Console から構成する場合は「Cross-Cloud Interconnect 接続」を選択する
AWS のリソースのうち、LAG の注文時は1つずつ注文する
- 冗長構成の場合は複数回に分けて行う
AWS VPC:仮想ゲートウェイ:Direct Connect ゲートウェイは 1:1:1 の関係で接続する
AWS / Google Cloud 双方の LOA-CFA を Google Interconnect Team に送付する
- ※ AWS には送付不要
接続までのリードタイムは検証では1週間ほどだったが、意図しない設定ミス等があるため十分に余裕を持ったスケジュールで開始する

また、付録として、実際にパフォーマンステストを行った結果を公開しています。
検討資料としてぜひお役立てください。