【トラブル対策】AWSとAzureをSite-to-Site VPNで接続する際の3つの注意点
はじめに
こんにちは！ エデュケーショナルサービス課の三角（みすみ）です。
AWS運用において、他クラウドとの連携は避けて通れないテーマになってきました。特に、AWSのVPCを仮想プライベートゲートウェイ（VGW）で、Azureの仮想ネットワーク（VPN Gateway）とSite-to-Site VPNでつなぐマルチクラウド構成の要件は増えています。
両者はどちらも標準的なIPsecをサポートしているため簡単に繋がりそうに思えますが、「クラウドごとのデフォルト設定の違い」や「コンソール画面上の表記の差異」によって、一筋縄ではいかない落とし穴が潜んでいます。
本記事では、私が実際の構築・検証時に遭遇した「3つの接続トラブル」と、AWSエンジニア視点からの解決策（Azure側をどう設定して合わせるべきか）を解説します。
構成
今回はAWSのVPC2つが1つのAzure環境に接続する構成としています。
AWS側でSite to Site VPNを作成する際、「IPsec トンネル」が必ず2つ作成されるのですが
Azure側のインスタンスのBGP APIPA アドレスが2つまでである為、「IPsec トンネル #2」は利用しないトンネルとして存在しています。
落とし穴1：BGPのAS番号重複による経路ループ検知
事象
AWS側に「アカウントA」と「アカウントB」の2つのVPCがあり、それぞれ同じAS番号（例：65098）のVGWを作成していました。それらを同一のAzure VPN Gatewayに対してBGPで接続したところ、ステータスは一瞬UPになるものの、すぐにBGPがDownしてしまいました。
AWS側のVPNログを確認すると、以下のエラーが出力されていました。
DENIED due to: as-path contains our own AS
原因
BGPのループ防止メカニズムが発動したことが原因です。
AWS（AS: 65098）からAzureへ送られた経路情報が、Azureを経由してもう一方のAWS環境（AS: 65098）へ伝播しようとした際、AWS側が「自分が発信したAS番号が戻ってきた（経路がループしている）」と判定し、ルートを破棄していました。
AWSのVGWは自身のAS番号の受信を許可する allowas-in をサポートしていないため、この構成ではBGPが成立しません。
解決策
- ベストプラクティス: Azureに接続するAWSアカウント間で、VGWのAS番号を重複しないように分ける。
- 回避策（今回の対応）: 既存のAS番号を変更できない場合は、BGP（動的ルーティング）を利用せず、「静的ルーティング（Static）」に切り替えます。静的ルートであればAS番号の制約を受けずに通信が可能です。
落とし穴2：「1時間後に必ず切れる」IPsec SA Lifetimeの不一致
事象
設定を見直し、Pingの疎通も確認できて一安心……と思いきや、ぴったり1時間（3600秒）経過すると必ず通信が切断される事象が発生しました。
AWS側のログには AWS tunnel is sending DELETE for Phase 2 SA が出力されていました。
原因
暗号鍵（SA）の有効期間（Lifetime）のデフォルト値が、クラウド間で異なっているためです。
* AWSのデフォルト: 3600秒（1時間）
* Azureのデフォルト: 27000秒（7.5時間）
1時間経過したタイミングで、AWS側がPhase 2の鍵交換（Rekey）を要求して古い鍵を破棄しますが、Azure側はまだ交換時期ではないと認識しているため、タイミングが合わずトンネルが落ちてしまいます。
解決策
Azure側のVPN接続設定で「IPsec / IKE ポリシー」を「カスタム」に変更し、AWSの仕様に合わせます。
* IPsec SA の有効期間 (秒): 3600 に明示的に設定する。
* ※有効期間（KB）については、Azure側の仕様に合わせ「0」または最大値で問題ありません（時間による制限が先に到達するため）。
落とし穴3：Phase 2が確立しない！PFSグループの設定名マジック
事象
IPsecポリシーをカスタムに変更したところ、今度はPhase 1（認証）は通るのに、Phase 2（データ暗号化の取り決め）がダウンしたまま上がらなくなりました。
ログには Phase 2 was unable to establish while keeping Phase 1 と記録されています。
原因
IKEv2の暗号化設定、特に PFS（Perfect Forward Secrecy） の設定不一致が原因でした。
AWS側はPhase 2のDHグループ（例：DH Group 14）を要求していますが、Azureのカスタム設定ではデフォルトでPFSが「None（なし）」になっていることが多いです。
さらに厄介なのが「設定画面の表記揺れ」です。AWSが要求する「DH Group 14」に対して、Azureの画面では「PFS14」を選べば良いと思いきや、正解は 「PFS2048」 という名称になっています。
解決策
Azure側の「IPsec / IKE ポリシー」で、PFSグループをAWS側の設定に合わせて正しく指定します。
* AWS側が 「DH Group 14」 の場合、Azure側は 「PFS2048」 を選択します。
* （参考：AWS側が「DH Group 2」の場合は、Azure側は「PFS2」を選択します）
まとめ
AWSとAzureのSite-to-Site VPN接続は、コンソール上の見え方やデフォルト値に違いがあります。トラブルを防ぐためには、「AWSマネジメントコンソールからVPNの汎用設定ファイル（Generic）をダウンロードし、その出力結果に合わせてAzure側のカスタムポリシーをガッチリ合わせに行く」というアプローチが成功の近道です。
また、繋がらない時はAWS側で出力されるCloudWatch LogsのVPNログ（BGPステータスやIKEフェーズのログ）を確認することが、原因究明の強力な武器になります。
マルチクラウド環境のネットワーク構築に挑む皆さまの参考になれば幸いです！
