何を学ぶか
実務では 何がこの仕組みの入口になるか？ を先に確認する。設定値だけでなく、入力と出力の境界を明確にする。
CloudWatch LogsからFirehoseで監査ログを配送する
CloudWatch LogsのサブスクリプションからFirehoseを経由してS3へ永続化するデータ経路を理解する。
TL;DR — この章で学ぶこと
- サブスクリプションが配送を開始する
- FirehoseがバッファしてS3へ書く
- 変換と失敗時の保管を設計する
01サブスクリプションが配送を開始する
何がこの仕組みの入口になるか？ — サブスクリプションが配送を開始するを、構成図の矢印から読み解く。
02FirehoseがバッファしてS3へ書く
どのサービスが責任を持つか？ — FirehoseがバッファしてS3へ書くを、構成図の矢印から読み解く。
何を学ぶか
実務では どのサービスが責任を持つか？ を先に確認する。設定値だけでなく、入力と出力の境界を明確にする。
03変換と失敗時の保管を設計する
失敗時にはどこへ戻る／進むか？ — 変換と失敗時の保管を設計するを、構成図の矢印から読み解く。
何を学ぶか
実務では 失敗時にはどこへ戻る／進むか？ を先に確認する。設定値だけでなく、入力と出力の境界を明確にする。
結論
- CloudWatch Logsのsubscription filterは一致するログイベントをFirehoseへ渡す。フィルタ条件と対象ロググループを明確にする。
- Firehoseはレコードをバッファし、設定した条件でS3に書く。低遅延と小さなファイル数は両立しないため、バッファ設定は用途に合わせる。
- Lambda変換を挟めるが、変換失敗の扱いを決める。S3のprefixやエラー出力先を分け、後で原因を追えるようにする。