【Catoクラウド】Cloud InterConnect × vSocket で冗長化はできるのか？を徹底考察！

本記事は夏休みクラウド自由研究2025 8/10付の記事です。

こんにちは　SCSK中山です。

今回は夏休みの自由研究ということで、自由研究チックな内容にしたいと思いまして、AWS上でCloud InterConnect × vSocketで冗長構成を組めるかを試してみようかと思います。

通常、Cato Networksを利用してAWSなどのクラウドサービスと接続する場合、「Cloud InterConnect」または「vSocket」のどちらかを選択します。冗長化を組む際も、Cloud InterConnectであればDirect Connect回線を2本に、vSocketであればvSocketインスタンスを2台に、といった形で同一の接続方式で構成するのが標準的です。

これら2つの異なる接続方式を組み合わせて冗長化に利用することは、Catoの推奨構成ではありません。

しかし、「技術的には本当に不可能なのか？」という純粋な好奇心から、今回はその実現可能性を考察し、記事にまとめてみることにしました。

先に申し上げますと、本記事は現時点では机上考察です。検証はこれからとなりますので、あらかじめご了承ください。

考慮すべきポイント
1. 案①BGPを使った方法
2. 案②Catoのルーティングを無理やり変更する方法
まとめ

考慮すべきポイント

：動的なルーティング切り替え

この構成を実現する上での鍵は、「どのようにしてルーティングを動的に切り替えるか」です。

Catoでは、Cloud InterConnectとvSocketを利用する場合、それぞれ別の「Site」として登録・管理します。今回の構成では、通常時はCloud InterConnectを利用するSite（以下、Site A）をメイン経路とし、Site Aの障害時にのみvSocketを利用するSite（以下、Site B）へルーティングを自動で切り替える必要があります。この自動切り替えをどう実現するかが、最大のポイントとなります。

案①BGPを使った方法

ネットワークの経路を動的に切り替えるといえば、まず思い浮かぶのがBGP (Border Gateway Protocol) です。

CatoはBGPをサポートしているため、AWS側との連携が焦点となります。

1. Cloud InterConnect (Site A) 側

こちらは比較的シンプルです。AWS Direct ConnectおよびTransit GatewayはBGPによるルート伝播に標準で対応しているため、Site AとAWS間の経路交換(青色矢印)はBGPで問題なく実現できるでしょう。

参考: BGP for AWS（クラスメソッド）

TransitGWを通してDirectConnectが生きているときは通信を可能としてくれるはずです。

2. vSocket (Site B) 側

ここが難関です。vSocketはVPC内に配置される仮想アプライアンスであり、それ自体がBGPスピーカーとして機能するわけではありません。そのため、AWSからCatoのSite BへBGPで経路情報を広報するには、何らかの仕組みをVPC内に別途構築する必要があります。

考えられる方法は以下の通りです。

BGPソフトウェアを搭載したEC2インスタンスを立てる VPC内にBGPルーティングソフトウェアをインストールしたEC2インスタンスを別途用意し、AWSのネットワークとCato Site Bの間でBGPピアを確立させる方法です。
Amazon VPC Route Serverを利用する AWSのマネージドサービスである「Amazon VPC Route Server」を利用する方法も考えられます。これは、VPC内のネットワーク仮想アプライアンス（NVA）とBGPで動的にルーティング情報を交換するためのサービスです。私も詳細は分からないので、以下記事などを見て貰えればと思います。

参考：VPC Route Server の設定を一通りやってみた（サーバワークス）

…と、これでCatoへのルート伝播はできたとして、話は終わりませんでした。。

実はもう一つ、大きな課題があります。それは「AWS内でのvSocketへの経路」です。AWS上のEC2などからCato側へ通信するとき、通常はDirectConnectへ、障害時にはvSocketへ向かうように経路を切り替える必要があります。この切り替えをTransit Gatewayにお願いしたいのですが、vSocket側の経路をTransit Gatewayに動的に伝えるのが、だーいぶ厳しそうです。

この課題を解決する方法を、2つほどを考えてみました。

BGPだけで頑張る方法（GREトンネル活用）

1つ思いついたのが、BGPを話せるインスタンスを立てる方法の応用です。

Transit Gatewayは、実は「Transit Gateway Connect」という機能を使うと、GREトンネル経由でVPC内のインスタンスとBGPを話すことができます。

これを利用して、

1. VPC内にBGPとGREに対応したインスタンス（NVA）を立てる
2. このNVAとTransit Gatewayの間でBGPピアを張る
3. NVAからvSocketへの経路を広報するときに、ASパスプリペンド（ASパスを長くして経路の優先度を下げる技術）を設定する

こうすれば、通常時はASパスが短いDirectConnect側が優先され、障害時にだけvSocket側の経路が使われる、という自動切り替えが実現できる(？)気がします。。

BGPは諦めて、障害検知で静的ルートを操作する方法

BGPだけで全部やろうとすると複雑すぎるのでBGPに固執せず、別の方法を組み合わせる手もあります。これは案②にも通じる話ですが、「DirectConnectがダメになったことをCloudWatchなどで検知して、Lambdaを動かし、Transit GatewayのルートテーブルにvSocket向けの静的ルートをAPIで追加/削除する」というやり方です。これなら、複雑なBGP設定を回避しつつ、やりたいことは実現できそうですね。

CatoのSource NATを活用する方法

こちらの方法はかなり条件付きになりますが、AWS側の複雑な設定を回避できる面白い案なので紹介してみます。

AWSをCatoで利用する場合って、多くはAWS上にいるサーバーにWAN側からアクセスしたい、というケースかと思います。この「外から中への通信」がメインなら、使えるかもしれない技です。

どうやるかというと、vSocketが持っている「Source NAT」機能を使います。 CatoのSocket（vSocket含む）は、通過する通信の送信元IPアドレスを、Socket自身のIPアドレスに変換するNAT機能を持っています。

これを利用して、

1. WAN側から来た通信がvSocketを通過するときに、送信元IPをvSocketのIPアドレスにNATで書き換えてしまいます。
2. AWSのサーバーから見ると、通信は「vSocketから来た」ように見えます。
3. サーバーからの応答（戻りの通信）は、当然vSocketに向かいます。Transit GatewayもvSocketのいるVPCへの経路は知っているので、問題なくルーティングできます。
4. 応答を受け取ったvSocketは、元の送信元IPアドレスにちゃんと戻してからWAN側に返してくれます。

こうすれば、Transit GatewayでBGPや静的ルートをごちゃごちゃ設定しなくても、戻りの経路をvSocketに強制的に向けることができる、というわけです。Catoの機能をうまく使った裏技的な感じですね。

ただ、最初に「条件付き」と言った通り、大きな制約があります。この方法は、AWS側から自発的にWAN側へ通信を始める場合には使えません。 (Transit Gatewayのルートテーブルには他拠点宛のルーティング情報がないため)

あくまで「外から中」へのアクセスがメインで、「中から外」への自発的な通信がない、という環境であれば、かなりシンプルな解決策になるかもしれませんね。

色々書いてきましたが、正直なところ調べながら書いたので、実現度はだいぶ低いのかなと思ってます。
# @Amazon Q ファクトチェックして

案②Catoのルーティングを無理やり変更する方法

BGPを使わない方法も一応、思いつきました。

最初に述べた通り、この構成のポイントはルーティングを切り替えることになります。

CatoではSiteへのルーティングは各Siteの設定よりできるので、手動でもそこの設定を切り替えることでSite AからSite Bへルーティングを切り替えることができます。

ただ、それでは芸がないので、何とか自動化する方法がないかを考えてみました。

このアプローチのポイントは、「障害検知」と「ルーティング変更の実行」を自動化することです。

1.障害の検知方法

まず、Cloud InterConnectがダメになった時を検知する方法はないかを考えてみます。

Cloud InterConnect（Site A）の障害を検知する方法として、以下の2つが考えられます。

Cato側での検知: Catoの「Link Health Rule」機能を利用します。Siteのダウンといったイベントを検知し、指定したWebhook宛に通知を送信できます。
AWS側での検知: Amazon CloudWatchを利用します。Direct Connectのメトリクス「ConnectionState」（0=down, 1=up）を監視し、CloudWatch Alarmを発報させます。
- 参考: Monitoring with Amazon CloudWatch – AWS Direct Connect

2. ルーティング変更の実行方法

続いてSiteのルーティングの変更の自動化方法について考えてみます。

こちらはCatoのAPIを使えばいけそうです。

参考: Cato API Documentation

障害を検知したら、Cato APIを呼び出し、以下の通りルーティング設定を書き換えるLambdaを作成します。

障害発生時: Site Aから対象VPC/SubnetへのルートをAPIで削除し、Site Bへ同じルートを追加する。
障害復旧時: 上記とは逆の処理（Site Bのルートを削除し、Site Aのルートを再追加）を実行する。

これだけだと「案①」でも触れたAWSからCatoへの戻りの通信経路が切り替わりませんので、LambdaでAWSのAPIも叩いてもらい、Transit Gatewayのルートテーブルを書き換えてもらいます。

具体的には、Lambdaのプログラムの中で、

障害発生時: Transit Gatewayのルートテーブルに、Catoのネットワーク宛てのネクストホップをvSocket側に向ける静的ルートを追加する。
障害復旧時: 追加した静的ルートを削除する。という処理を追加します。

全体像としては、以下のようになるかと思います。

障害検知: CloudWatch Alarm (Direct Connect) または Cato Link Health Rule (Webhook)
トリガー: CloudWatch Alarm Action または Amazon API Gateway
実行: AWS Lambda
処理内容:
1. Lambda関数が Cato API をコールし、Cato側のルート情報を書き換え
2. Lambda関数が AWS API をコールし、Transit Gatewayのルートテーブルを書き換え