はじめに

　ネットワークは機器筐体やリンクなどの障害でルートが切り替わる設計にも関わらず、ハードエラーやソフトエラーなどによる不安定事象やサイレント障害を検知できないため、ルートが切り替わらないケースがしばしばあります。

　ハイブリッド接続も例外ではないですが、2023年12月22日に検知の一助となるNetwork Monitor機能が公開されましたので、本機能を用いてどのような検知や対処が可能なのか、やってみた気付きなどをまとめてみました。

aws.amazon.com

はじめに
不安定事象やサイレント障害の問題
Network Monitorによる検知および対処
やってみた
まとめ
おわりに

不安定事象やサイレント障害の問題

　AWS DirectConnectやAWS Site-to-Site VPN上で利用されるBGPは、再送やタイムアウト機能により一時的な通信断が発生しても回復を試みる仕様になっています。
　一時的な通信断が頻発した場合、業務通信影響は生じているものの、BGPはエラーと認識しない程度であれば、ルート切り替わりどころか検知すらされない可能性があります。

　AWS DirectConnectやAWS Site-to-Site VPNのメトリクスであるスループット(BPS/PPS)などは正常な状態でも増減しうるため、一時的な通信断頻発といった異常な状態かどうかの判断が難しいです。
　静的な閾値のほか動的な異常検出機能を用いる選択肢もありますが、不規則なトラフィックの場合は誤検知が増えてしまい、異常検知のメリットより運用負担のデメリットの方が高まります。

docs.aws.amazon.com

Network Monitorによる検知および対処

　Network MonitorはAWSからオンプレミスへのICMP/TCPポーリングを行って、パケット損失やRTTのメトリクスを提供します。閾値超過が異常状態へ直結するため、検知のうえで有効なメトリクスです。
　このようなメトリクスを用いて、CloudWatchアラームで異常を検知し、EventBridgeで中継のうえ、LambdaでDirectConnectのBGPフェイルオーバーをトリガーする対処が考えられます。

やってみた

　公式blogおよびgithubにて、検知および自動対処の手順や資材が紹介されてましたので試しました。原則は手順通りですが、今回は単一DX構成のため一部修正してますのでご了承下さい。

aws.amazon.com github.com

Network Monitor作成

　CloudWatch > ネットワークモニタリング > Network Monitorへアクセスし、モニターを作成します。

モニター名は、任意の文字列を記入します。
集計期間は、30秒もしくは60秒を選択します。

サブネットは、送信元のサブネットを選択します(ENIやSGは自動生成されます)。
IPアドレスは、送信先のIPアドレスを記入します。
プロトコルは、ICMPもしくはTCPを選択します(TCPの場合はポート番号も記入します)。
パケットサイズは、56～8500(byte)を記入します。

パケット損失、RTTなどが取得・表示できていたらOKです。
監視機能だけでもお手軽に使えますので、テストなどで重宝しそうです。

SNS作成

　SNS >トピックへアクセスし、トピック・サブスクリプションを作成します。

タイプは、スタンダードを選択します。
トピック名は、任意の文字列を記入します。
プロトコルは、Eメールを選択します。
エンドポイントは、任意のEメールアドレスを記入します。
確認メールのConfirm subscriptionをクリックするまで有効化されません。

CloudWatchアラーム作成

　Cloudwatch > アラーム > すべてのアラームへアクセスし、アラームを作成します。

メトリクスは、AWS/NetworkMonitor > Monitor,Prove > PacketLossもしくはRTTを選択します。
条件は、任意の演算子と閾値、データポイントを選択・記入します。
アクションは、アラームをトリガーとして作成済みトピックへの通知を選択します。
アラーム名は、BGPフェイルオーバーしたいVIF IDを記入します。
前述の資材を用いる場合、上記以外のアラーム名は正しく動かない可能性があります。

Lambda作成

　Lambda > 関数へアクセスし、関数を作成します。

関数名は、任意の文字列を記入します。
ランタイムは、Python3.9を選択します。
コードは、前述の資材(aws-dx-failover/python/dx-failover.py)より転記します。
今回は単一DX構成のため、110～112行目の残VIF数のチェックをコメントアウトします。
設定 > アクセス権限 > 実行ロールは、インラインポリシを追加します。
インラインポリシは、前述の資材(aws-dx-failover/json/lambda-iam-policy.json)より転記します。
resourcesオブジェクト内のVIF IDおよび作成済みトピックのARNを更新します。
設定 > アクセス権限 > リソースベースのステートメントは、アクセス権限を追加します。
アクセス権限は、以下の内容で作成します。※あらかじめEventBridge設定が必要。
- サービスは、EventBridge (CloudWatch Events)を選択します。
- ステートメントIDは、任意の文字列を記入します。
- プリンシパルは、events.amazonaws.comを記入します。
- ソースARNは、作成済みルールのARNを記入します。
- アクションは、lambda:InvokeFunctionを記入します。
設定 > 環境変数は、以下の内容で編集します。
- EMAILは、任意のEメールアドレスを記入します。
- FAILOVERは、BGPフェイルオーバーしたい時間(分)を記入します。
- MINVIFSは、VIF最小値を記入します。今回は単一DX構成のため、0を記入します。
- SNSARNは、作成済みトピックのARNを記入します。
- VIFLISTは、BGPフェイルオーバーしたいVIF IDを記入します。

EventBridge作成

　EventBridge > バス > ルールへアクセスし、ルールを作成します。

ルール名は、任意の文字列を記入します。
ルールタイプは、イベントパターンを持つルールを選択します。
イベントパターンは、前述の資材(aws-dx-failover/json/event-rule.json)より転記します。
resourcesオブジェクト内の作成済みアラームのARNを更新します。
ターゲットは、AWSのサービス、Lambda関数、作成済みLambda関数名を選択します。