AWSの単一トンネル通知：本当に重要になるのはどんなときか

片方のトンネルがダウンしているというAWS Healthの通知は、何も壊れていないように見えるときに届くことが多い。だからこそ軽視される。この通知は障害を説明しているのではなく、AWSの監視ウィンドウを超えて続いている冗長性の状態を説明している。対応すべきかどうかは、ダッシュボードの見え方ではなく、設計が何に耐えられるかで決まる。

通知が実際に測っていたもの

各Site-to-Site接続には二本のトンネルがあり、それぞれ別のAWSエンドポイントで終端する。AWSの監視ドキュメントは両方を冗長化のために設定することを勧めており、片方が定められた期間ダウンし続けると通知を出す。この期間が重要なのは、短い揺らぎと恒久的な喪失が一つのグラフでは同じに見えるからだ。

接続全体の状態ではなく、トンネルごとのテレメトリを読む。aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' はトンネルごとに状態とメッセージを返し、それが通知の根拠となる証拠だ。

対応を決める三つの条件

これがチケットなのか肩をすくめる話なのかを決める前に、三つを順に見ていく。

第一に、生き残ったトンネルは負荷を運べるか。帯域の上限や広告しているプレフィックスも含めて考える。第二に、作成時からダウンしている二本目のトンネルが上がったことが一度も確認されていないなかで、フェイルオーバーは実際に起きるのか。第三に、次に計画している変更が両方のトンネルを同時に落とすなら、見た目だけの警告が保守ウィンドウの問題に変わる。どれか一つの答えが「いいえ」か「不明」なら、その通知は本物の所見だ。

三つとも問題ないと示せるなら、なぜ許容できるのかを書き留めて先へ進む。そのメモは来四半期の議論より価値がある。

待機ピアが証明しないこと

バックアップピアを設定したカスタマーゲートウェイは、AWSが健全なトンネルを二本見ている証拠にはならない。顧客側は新しいネゴシエーションを必要とするコールドピアを保持できるし、それは正当な設計でもある。それでも二本の稼働中のトンネルと同じ観測ではない。

物理ルータを二台置いても逆のケースは直らない。両方のトンネルが一台の機器で終端したり、一本のアップリンクから出ていたりすれば、冗長性は紙の上にしかない。

変更をその影響範囲に合わせる

AWSの エンドポイント置き換えのドキュメント はケースを分けているが、その区別は見落としやすい。AWSが管理する更新は一度に一本のトンネルに適用される。顧客が開始するターゲットゲートウェイ、カスタマーゲートウェイ、接続オプションへの変更は、代替エンドポイントが用意される間、両方のトンネルを使えなくする。

単一トンネルのオプション変更は三つ目のケースで、独自の影響が明示されている。そのトンネルは自身の更新中は利用できず、もう片方は動き続ける。

必要になる前に代替を証明する

出来事を待つのではなく、テストを予定する。健全なトンネルを保守ウィンドウの中で落とし、代替がネゴシエーションすることを確認し、実際のトラフィックが双方向に通ることを確認する。トンネルの状態だけでなく戻り経路も確認する。第二フェーズの不一致はトンネルを上げたままワークロードを死なせるからだ。そこにいる間に切り替えの時間も測る。

通知、テレメトリの出力、変更計画を一つの記録にまとめる。その記録があれば、来四半期の通知は、バックアップを誰かが試したことがあるかという議論ではなく、二分のレビューになる。