こんにちは、SCSK林です！
昨今のエンタープライズシステムにおいて、単一のクラウドプロバイダーで全てのワークロードが完結するケースはかなり稀だと思います。
とある案件では、「AWS上の業務データを閉域網経由でGoogle Cloudへ転送し、BigQueryで分析する」という要件に加え、オンプレミスの基幹システムとも連携が必要な「3地点接続」のネットワーク構築が必要でした。
本記事では、AWSの実装そのものではなく、全体アーキテクトの視点から、「AWS Direct Connect を他クラウドやオンプレミスと接続する際に、ハマりやすいポイントと設計の勘所」について共有します。
細かい実装の話ではないので、マルチクラウド接続を実際に設計/構築する時にはここら辺考えないといけないよな～的な目線で見ていただけると幸いです。
アーキテクチャ概要：SCNXをハブとしたハブ＆スポーク構成
今回の要件において、最大の課題は「AWS、Google Cloud、オンプレミスの3地点を、いかにシンプルかつセキュアに接続するか」でした。 各拠点をフルメッシュで接続（AWS⇔Google Cloud、AWS⇔On-Prem、Google Cloud⇔On-Prem）すると、管理コストとルーティングの複雑さが指数関数的に増大します。
そこで今回は、SCSKのクラウド接続サービス「SCNX」をハブとして採用し、物理的な複雑さを抽象化しました。
- AWS: AWS Direct Connect (DX)
- GCP: Cloud Interconnect
- On-Premises: 閉域網接続
- Hub: SCNX (Virtual Router)
※SCNXの紹介はコチラ：https://www.scsk.jp/sp/netxdc/lp1/
設計ポイント
BGPルーティング設計
例えばActive/Standby構成を実現するためには、物理的に線を繋ぐだけでなく、BGP（Border Gateway Protocol）を用いて「どちらの道を優先するか」を論理的に制御する必要があります。
AWS Direct Connectにおいて、経路制御を行いActive/Standbyを正しく機能させるには、以下の設計が必要となります。
AWSへの流入制御
Google CloudやオンプレミスからAWSへデータを送る際、AWS側で受け取る経路をPrimaryに固定する必要があります。
ここで重要になるのがAS_PATH Prepend です。AWS側（Direct Connect Gateway）の設定において、Standby回線側のAS Path（自律システム経路）を意図的に長く見せる（Prependする）ことで、対向ルーター（SCNX/Google Cloud）に対して「こちらの道は遠回りだ」と判断させ、自然とPrimary回線が選択されるよう設計しました。
AWSからの流出制御
逆に、AWSからGoogle Cloudへデータを送る際は、AWS側で Local Preference 値を調整し、Primary回線の優先度を高く設定する必要があります。
※参考URL：https://aws.amazon.com/jp/blogs/news/dx-trafficcontrol-osaka/
他クラウドと接続する場合、AWSのBGP仕様（Prependの反映挙動など）を理解し、対向システム側とパラメータの整合性を取らなければ、頻繁に経路が切り替わる「フラッピング」の原因となります。
データ転送の最適化：MTUとMSSの調整
複数拠点を接続する際に考慮すべきなのがパケットサイズ（MTU）です。
AWS Direct Connectはジャンボフレーム（MTU 9001）をサポートしていますが、経路上にあるSCNXやGoogle Cloud Interconnect、あるいは途中の仮想アプライアンスでMTUが1500に制限されている場合があります。
この不一致を放置すると、ハンドシェイク（小さなパケット）は成功するのに、いざ大量のデータを転送し始めるとパケットがドロップされるという厄介な現象が発生します。
それの予防策、安全策として、TCP MSS Clamping（最大セグメントサイズの調整）を導入し、経路上の最小MTUに合わせてパケットサイズを最適化することで、安定した通信を確立することができます。
IPアドレス設計：AWS Security Groupはじめファイアウォール設定
構築・テストフェーズでありがちなのが、通信がタイムアウトする系のエラーです。
マルチクラウド環境では、IPアドレス設計が非常に重要です。AWS、Google Cloud、オンプレミスでCIDRが重複しないことはもちろん、「どの範囲のIPが、どのポートで通信してくるか」を厳密に管理し、SGのルールへ反映させるプロセスを徹底する必要があります。
また、アプリの追加要件で当初想定より広いIPレンジが後から必要になることもありがちです。
インフラ担当の皆さんは、特にクラウドサービスだと余裕を持ったIPレンジの確保をしておくことが心の余裕につながります。笑
さいごに
単一のクラウドに閉じていれば難しくないことも他クラウド、他拠点が出てくると技術的難易度が上がってしまいます。
また、往々にして担当者・担当チームがクラウドごとにわかれていて全体設計が蔑ろにされ、問題が後から噴出することもままあると思います。
そのためにも、AWSだけでなく、Google Cloudだけでなく、複数のクラウドに関する知識、知見を持っておくことが重要だと感じました。
この記事がどなたかのお役に立つと幸いです。