稼働中のトンネルで AWS VPN トンネルログを有効にすべきか？

Site-to-Site VPN のトンネルアクティビティログを有効にするのは小さな変更ですが、計測対象のトンネルを落とすことがあります。AWS は、既存のトンネルでログを有効にすると数分間中断される可能性があると警告しています—したがって本当の問いは、フラグをどう切り替えるかではなく、どのトンネルで、いつ切り替えるかです。順序を決めるのは三つの条件です—もう一方のトンネルが本当にルートを運んでいるか、サービスイベントと BGP イベントのどちらが必要か、変更をコンソールとトンネルオプション API のどちらで行うか。ここを間違えると、停止か、中身のないロググループのどちらかになります。

順序を決める三つの条件

変える対象の同一性から始めます。VPN 接続 ID、リージョン、そのトンネルの外部 IP アドレスが必要です—この機能のログ設定は接続単位ではなくトンネル単位だからです。誤った外部アドレスに適用した変更は、誰もデバッグしていないトンネルへの変更です。

送信先は同じリージョンの CloudWatch ロググループで、実際に必要な保持期間とアクセスポリシーを設定します。AWS はこれらのグループに /aws/vendedlogs/ というプレフィックスを推奨しています—単純な名前では当たりうるリソースポリシーのサイズ上限を避けられるからです。/aws/vendedlogs/vpn/branch-a-activity のような名前はあくまで例で、重要なのはグループが存在すること、配信ロールがそこに書き込めること、そして両方を VPN 設定の所有者が管理することです。名前は権限を与えず、配信ポリシーなしで作られたグループはエラーではなく沈黙を生みます。

条件一：実際にトラフィックを運ぶ冗長トンネル

これがチームが見落とす条件です。トンネルが二本設定されていることは、アプリケーションに使える代替経路がある証拠ではありません。

一方のトンネルに触る前に、もう一方が重要なルートを運んでいることを確認します—カスタマーゲートウェイ側のルーティングテーブルを確認し、アプリケーションが実際にフェイルオーバーできることを確かめてください。AWS の中断時間は秒ではなく分単位で、紙の上にしか存在しないトンネルは診断のための変更を障害に変えます。冗長経路が証明されていないなら、ログを後回しの作業とみなさず、他のルーティング変更と同じ慎重さで計画してください。動作を説明したいトンネルを計装し、到達しやすいほうを選ばないでください。

条件二：アクティビティログか BGP ログか

どちらを読めるかがこれで決まります。アクティビティレコードは IKE と IPsec の状態遷移や DPD メッセージなどのサービスイベントを扱い、トンネルが上がらない、あるいは鍵を更新し続けるときに欲しい情報です。BGP レコードは独自の制御を持つ別のストリームで、別の問いに答えます—ルートが期待どおり交換され、撤回されたかどうかです。

アクティビティフラグを有効にしても、サービスが出力できるすべてのストリームを要求したことにはなりません。疑いがルーティングなら両方を有効にし、疑いがフェーズ 1 かフェーズ 2 のネゴシエーションなら、アクティビティストリームがそれを示します。

どちらのストリームもパケットキャプチャではなく、この区別は本来より多くのチケットを解決します。アクティビティと BGP のレコードは、サービスがトンネルとセッションに対して何をしたかを示すもので、アプリケーションがそこを通じて何を送ったかではありません。アプリケーションのタイムアウトをデバッグするためにトンネルログに手を伸ばすのはカテゴリーエラーで、誰かが気づく前に中断の時間枠を消費します。まず問いを選び、次にそれに答えられるストリームを選んでください。

条件三：コンソールでの変更か、トンネルオプション API か

人が一度だけ変更するならコンソール経路で構いません—VPC console、Site-to-Site VPN connections、接続を選択、Actions、Modify VPN tunnel options、外部 IP を選択、Tunnel activity log を有効化、グループと出力形式を選択し、時間枠の中で保存します。VPN をコードとして管理しているなら、同じクリックは後で解消すべきドリフトです。

自動化では、トンネルオプションのアクティビティログ部分は固定の形をしています—LogOptions が CloudWatchLogOptions を持ち、そこに LogEnabled、LogGroupArn、LogOutputFormat が入ります。このブロックは断片であり、要求ではありません—modify-vpn-tunnel-options には引き続き接続 ID とトンネルの外部 IP が必要で、残りのトンネル設定はテンプレートの所有者が保持しなければなりません。BGP ログは同じ構造の中で独自の BgpLogEnabled、BgpLogGroupArn、BgpLogOutputFormat キーを使います。呼び出しが適用されたと信じるのではなく、describe-vpn-connections で変更を読み返してください。

レコードが教えてくれること、教えてくれないこと

最初のトンネルが終わり、意図した経路が利用できるようになったら、二本目のログも必要なら同じ制御された手順を繰り返します。一度に一本ずつというのが要点です。

レコードは接続とトンネルの外部アドレスで識別されるストリームに届くので、履歴が遡って現れることを期待せず、その同一性で相関させてください。変更より前のものは存在せず、どれだけ待っても空白は埋まりません。基準が必要なら、比較できるように変更前に現在のトンネル状態とルーティングテーブルを記録してください。

ロググループ、その保持期間、配信権限、トンネルオプションブロックは、VPN 本体と同じ台帳で管理してください—四か所に散らばった一つの設定だからです。AWS のログ有効化手順はトンネルごとの作業手順と中断の警告を文書化しており、変更の後ではなく前に読む価値があります。次に順番に確認します—トンネルが戻ったか、レコードが期待したストリームに現れているか、そのレコードがチケットを開いた問いに答えているか。三番目が失敗するなら、問題はログではなくストリームの選択でした。