![[アップデート] Amazon CloudWatch Pipelines で条件付きプロセッシングと Drop Events プロセッサーがサポートされ、ログ変換をより柔軟に制御できるようになりました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-d6a3bc85cad6419960fbda152152cd8c/ba5841cea06b96f4933878762028b090/amazon-cloudwatch?w=3840&fm=webp)
[アップデート] Amazon CloudWatch Pipelines で条件付きプロセッシングと Drop Events プロセッサーがサポートされ、ログ変換をより柔軟に制御できるようになりました
いわさです。
CloudWatch Pipelines はログデータの取り込み・変換・ルーティングをフルマネージドで行えるサービスです。
サードパーティアプリケーションや AWS サービスからのログを CloudWatch に集約する際に、インフラを管理することなくプロセッサーを使ってログの加工が出来ます。
これまで CloudWatch Pipelines のプロセッサーはパイプラインを通過するすべてのログエントリに対して一律に適用されていました。
特定の条件に合致するログだけ変換したい場合でも、プロセッサー側で条件を指定する手段がなく、すべてのログに同じ変換が適用されてしまう状態でした。
今回のアップデートで、プロセッサーに条件式（when）を指定できる「条件付きプロセッシング」と、条件に一致するログエントリを除外できる「Drop Events（イベントをドロップ）プロセッサー」が追加されました。
条件付きプロセッシングは多くのプロセッサーで利用可能みたいです。
また、Drop Events プロセッサーはサードパーティコネクターからの不要なログエントリをフィルタリングするために使えるプロセッサーです。
いずれも追加コストなしで利用出来ます。
今回こちらを確認してみたので紹介します。
条件付きプロセッシングを使ってみる
では早速 CloudWatch コンソールからパイプラインを作成して条件付きプロセッシングを試してみましょう。
今回はデータソースに AWS WAF ログを使います。
CloudWatch Pipelines は東京リージョンでも利用可能ですが、今回は Amplify Hosting（CloudFront）に関連付けした AWS WAF のログを処理してみるので、WAF ログの出力先であるバージニア北部リージョンでパイプラインを作成しています。
Run when 条件の設定
プロセッサーを追加すると「Run when」というセクションが表示されています。
これが今回のアップデートで追加された、プロセッサーレベルの条件付きプロセッシングに対応する設定です。
「Add a condition」にチェックを入れると条件式の入力欄が表示されます。
条件付きプロセッシングの式構文については以下のドキュメントに記載されています。
今回は action == "BLOCK" を設定し、WAF でブロックされたリクエストのログだけ小文字変換が適用されるようにしてみます。
変換対象のキーには httpRequest.country と terminatingRuleId の 2 つを指定しました。
キーは複数指定出来るので、条件に合致した場合にどのフィールドが変換されるか確認しやすいようにしています。
なお、条件式の文字列リテラルにはダブルクォートを使う必要がありました。
シングルクォート（action == 'BLOCK'）で試したところ Invalid expression エラーになったので注意が必要です。
条件式では以下の演算子や関数が使えるみたいです。
- 等値比較:
==,!= - 関係演算子:
<,<=,>,>= - 論理演算:
and,or,not - セットメンバーシップ:
in,not in - 正規表現マッチ:
=~,!~ - 関数:
length(),contains(),startsWith()
条件付きプロセッシングの対応プロセッサー
条件付きプロセッシングには「プロセッサーレベル」と「エントリレベル」の 2 段階があります。
Processor-level
when(outer level)
Awhenplaced at the top level of the processor configuration. If the expression evaluates to false, the entire processor is skipped and no operations within it execute.
プロセッサーレベルは条件が false の場合にプロセッサー全体がスキップされます。
エントリレベルは entries 配列を持つプロセッサーで使え、各エントリごとに独立して条件を評価出来ます。
add_entries、copy_values、rename_keys、move_keys、extract_value、substitute_string がエントリレベルに対応しているみたいです。
また、when_else というフォールバック機能もあり、他の when 条件がすべて false だった場合にのみ実行されるエントリを定義出来るようです。
An entry with
when_elseacts as a fallback — it executes only when none of the otherwhenconditions in the same processor matched.
パーサー系プロセッサー（Grok を除く JSON、CSV、KeyValue、WAF 等）は条件付きプロセッシングに対応していないみたいですね。
Parser processors (except Grok) do not support conditional processing. This includes JSON, CSV, KeyValue, WAF, Postgres, CloudFront, VPC, Route53, and OCSF parsers.
変換結果の確認
パイプラインを作成して実際に WAF ログを流してみました。
WAF を設定したエンドポイントに通常のリクエスト（ALLOW）と XSS パターンのリクエスト（BLOCK）を送信しています。
変換後のログを確認してみます。
まず BLOCK のログです。
action が "BLOCK" なので Run when 条件に合致し、lowercase_string プロセッサーが適用されています。
httpRequest.country が "JP" → "jp" に、terminatingRuleId も小文字に変換されていることがわかります。
次に ALLOW のログです。
action が "ALLOW" なので Run when 条件に合致せず、プロセッサーがスキップされています。
httpRequest.country は "JP" のまま大文字で残っていることが確認できます。
条件付きプロセッシングが期待どおりに動作していますね。良いですね！
Drop Events プロセッサーについて
Drop Events プロセッサーはサードパーティコネクターからの不要なログエントリを条件に基づいてドロップするプロセッサーです。
when パラメータが必須で、条件に一致したログエントリがパイプラインから除外されます。
handle_expression_failure(optional): Behavior when thewhenexpression evaluation fails. Allowed values:"skip"(default) keeps the event, or"apply"drops the event regardless of the failure.
なお、Drop Events プロセッサーは CloudWatch Logs ソースのパイプラインでは選択出来ませんでした。
サードパーティソース（今回は Microsoft Entra ID ログ）でパイプラインを作成したところ、プロセッサーの一覧に「イベントをドロップ」（drop_events）が表示されることを確認出来ました。
さいごに
本日は Amazon CloudWatch Pipelines に条件付きプロセッシングと Drop Events プロセッサーが追加されたので確認してみました。
これまでプロセッサーがすべてのログに一律適用されていたのが、when 条件で柔軟に制御出来るようになったのは良いですね。
WAF ログで試してみましたが、BLOCK のログだけ変換を適用して ALLOW のログはスキップするといった使い分けが簡単に出来ました。
Drop Events プロセッサーはサードパーティコネクター向けの機能のようなので、サードパーティログの取り込み時にノイズ削減を考えている方は試してみてください。
なお、アナウンスでは「reduce noise and lower costs」と謳われていますが、CloudWatch Logs ソースの場合はパイプライン処理前にメータリングされるので、Drop Events でログを落としてもコストは変わらないはずです。
一方でサードパーティソースの場合は処理後にメータリングされるので、Drop Events で不要なログを落とせばストレージコストの削減につながる可能性がありそうです。
