AWS Site-to-Site VPN トンネルを監視するためにメンテナンスの特性を調べて見た
2025.07.16こんにちは！コンサル部のinomasoです。
ある案件でAWS Site-to-Site VPN(以下VPNと略)をCloudWatchアラームで監視するためにトンネルのメトリクスを確認したところ、数週間の間隔でダウンしていることがわかりました。
トンネルは定期的に片方ずつダウンしていたので、その原因について詳しく調べてみることにしました。
結論から
- VPNはAWS側の定期メンテナンスで2つのトンネルエンドポイントのいずれか一つのみで置き換えが発生する。
- メンテナンスの間隔について公式ドキュメント上に明記はなく、AWSアカウントによってバラツキがあった。
- VGW(TGW)で片方のトンネルメンテナンス時にもう一方のトンネルのMEDを低く設定するので通信に影響を与えないようになっている。
- ただしCGWで両方のトンネルに対して同じ重みおよびローカル優先設定の値が設定されていない場合は通信に影響がでる可能性があるので注意が必要です。
VPNメンテナンスイベント
今回のVPNメンテナンスイベントは、AWS Health Dashboardのイベントログで「VPN redundancy loss」から確認することができました。
イベントの説明を確認したところ、「This replacement was AWS Initiated.」と記載があったので、AWS側によるメンテナンスだとわかりました。
調べていてわかったのですが、デフォルトだとAWS側のメンテナンスに起因するVPNトンネルの置き換えについて事前通知はされません。
トンネルエンドポイントのライフサイクル制御を有効化することで事前通知は可能ですが、以下の公式ドキュメントに記載されているように1つのトンネルのみ利用するケースでの利用が想定されています。
ちなみにライフサイクル制御を有効化することで、事前通知だけではなくユーザー側が決めた任意のタイミングでメンテナンスを実行できますので、特定時間帯のメンテナンスを避けるといったことも可能です。
VPNトンネルエンドポイントの置き換えによる通信影響
VPNのトンネルが2つあれば、VGW(TGW)側で以下のように設定されるため通信の影響はございません。
一方の VPN トンネルで更新を実行する場合、もう一方のトンネルでアウトバウンド multi-exit discriminator (MED) の値を低く設定します。両方のトンネルを使用するようにカスタマーゲートウェイデバイスを設定している場合、VPN 接続はトンネルエンドポイント更新プロセス中にもう一方の (アップ) トンネルを使用します。
ただし、以下の条件を満たす必要があります。
MED の低いアップトンネルが優先されるようにするには、カスタマーゲートウェイデバイスで、両方のトンネルに対して同じ重みおよびローカル優先設定の値が使用されていることを確認します (重みおよびローカル優先設定は MED よりも優先度が高くなります)。
トンネルエンドポイントの置き換えにおけるルーティング変更について具体的な処理を知りたい方は、ライフサイクル制御機能でのメンテナンステストの結果をまとめてくださったブログがあるため、そちらを参考にするのが良いと思います。
結局CloudWatchアラームによる監視をどうしたのか？
VPNのトンネルが2つありCGW側で条件を満たしていれば、メンテナンスにより片方のトンネルがダウンしても通信に影響が出ないようルーティングされるため、基本的に問題ないことがわかりました。
そのため、メンテナンス時に想定外の動作でトンネルが同時にダウンすることがあれば通知するようにしました。
CloudWatchアラームで複数のメトリクスを監視する方法は、数式や複合アラームといった方法が考えられますが、今回のケースですとTunnelStateメトリクスを2つ監視するだけですので、数式を選択しています。
以下はCloudWatchアラームの設定例となります。
まとめ
VPNトンネルのメンテナンスについてこれまで意識することがなかったため、今回の調査で要点を理解することができました。
この記事が、どなたかのお役に立てば幸いです。それでは！
