こんにちは。自称ネットワーク技術者の貝塚です。SCSKでAWSの内製化支援『テクニカルエスコートサービス』を担当しています。
多くのAWSサービスを使う上で、ログ管理や監視・通知は欠かせませんが、通常これらの機能を目的のサービス自身が持っていることはなく、どうしても他サービス(例えばCloudWatch)との連携が出てきてしまいます。しかも連携パターンも1パターンではなく、運用上の要件・制約などによって複数の連携パターンが考えられるので、この部分を設計するだけでも一苦労なのではないでしょうか。
本記事執筆の動機
今回は、AWSのネットワーク系サービス(の中で私になじみのあるもの)がどこにログを出力できて、どのように監視や通知ができて、ログの分析をどうすればよいのか、自分の中で整理したいと考えたのが本記事の執筆動機です。
先行する記事として以下の記事があります。本稿の執筆にあたっても参考にさせて頂きました。
私がこの記事を書く必要はないのでは……と思うくらいよくまとまっているのですが、以下のモチベーションのため自分でも記事としてまとめることにしました。
- ネットワーク系サービス(Transit Gateway, Network Firewall)の情報を充実させたかった
- 通知まで含めて明示したかった
なおシステムを監視するにあたっては、各サービスの出力するメトリクス(パフォーマンス等に関する定量的な時系列データ)や各サービスが発生させるイベント(たとえばEC2の停止)も重要な情報になりますが、本稿ではあえてログの取り扱いのみをターゲットにしています。
ネットワーク系サービスのロギング・監視・通知・分析
まずは一枚の図にまとめてみましたのでこちらをご覧ください。(文字が小さいので拡大して見ることをお勧めします)
左側に主なネットワーク系サービスを並べ、それがどのサービスにログを出力できるのかを矢印で結んでいます。さらにそのログ出力先からどのサービスに連携すると監視・通知・分析につなげられるのかも矢印で示しました。
GuardDutyは通常ネットワーク系サービスに分類されませんが、ネットワーク系のログ(VPCフローログやRoute 53クエリログ)をインプットにして脅威検出をしてくれるため、あえてこの図に含めています。
ログ出力先
出力先候補の選択肢は基本的に3つ。CloudWatch Logs、S3、Kinesis Firehoseです。この3つのいずれかから選択可能なサービスが多いですが、中にはそうではないサービスもあります。
CloudWatch Logs
CloudWatch Logsに出力しておけば、その後の監視・通知や分析もしやすいですが、ログの取り込みや分析で料金が高額になることもあるようです。
今回調査対象にしたサービスの多くはCloudWatch Logsへのログ出力に対応しており、Route 53についてはCloudWatch Logsのみとなっています
S3
S3はログの保管だけに限ればおそらく最適ですが、監視・通知や分析をしようとするとひと手間かかります。
ALBやCloudFrontは、S3のみの出力となっています。
また、今回あえて対象範囲にしたGuardDutyで検出した脅威は、GuardDuty自体が決まった件数の検出結果を保持してくれますが、長期間保管するのであればS3への出力となります。
Kinesis Firehose
Kinesis Firehoseはリアルタイムの分析やETLが必要な場合の出力先です。ストリーミングデータをリアルタイムで配信するためのサービスであり、Firehose自体はログのストレージではありません。具体的なログ活用のユースケースがあった上での選択肢と言えます。
まとめ
ロギング・監視・通知・分析と銘打ちましたが、この記事では説明はロギングの部分までにとどめ、以降の説明は別記事としてまとめることにしました。（きっちり書こうとすると調査や検証がかなり大変と気づいたので……)
よろしければ続編をお待ちくださいませ。
参考資料
CloudWatchの料金に関するAWSの記事です。
