CloudWatch Log Alarm で FSx for ONTAP 監査ログから直接アラートする — メトリクスフィルター不要の新しい監視パターン - 運び屋 (A carrier(forwarder) changed his career to an engineer)

この記事は、DEV Community で公開している「Serverless Observability for Amazon FSx for NetApp ONTAP」シリーズを、日本語読者向けに再構成したものです。

単純な翻訳ではなく、AWS 上での検証結果、設計判断、日本のエンタープライズ環境での読みどころを補足し、最新情報を加えながら整理しています。

はじめに

FSx for ONTAP の監査ログを CloudWatch Logs に集めたあと、「特定のファイルにアクセスされたら通知したい」と思ったことはないでしょうか。従来はメトリクスフィルターを挟む必要がありましたが、2026 年 7 月にリリースされた CloudWatch Log Alarm を使えば、ログクエリから直接アラームを作れるようになりました。

CloudWatch Log Alarm (2026-07-01 GA): ログクエリから直接アラーム。メトリクスフィルター不要
仕組み: Logs Insights で文字列にマッチしたイベントを数え、その件数が閾値を超えたら発火
検知プリセット 5 種: 機密パスアクセス / 認証失敗 / 大量削除 / 特権操作 / カスタム
1 コマンドデプロイ: bash shared/scripts/deploy-log-alarm.sh（15 分で動作確認可能）
コスト: ~$6.6/月（100MB/日）。メトリクスフィルター方式より少し高いが、ログ行付き通知と遡及クエリという利点がある
E2E 検証済み: 東京リージョンで CloudFormation デプロイから状態遷移まで確認

GitHub: Yoshiki0705/fsxn-observability-integrations

何が変わったのか

ログの内容に基づいてアラートを出す、というのは監視の基本的な要求です。ところが CloudWatch でこれをやろうとすると、これまでは少し遠回りが必要でした。まずメトリクスフィルターを作り、そこからカスタムメトリクスを生成し、最後にそのメトリクスにアラームを設定する、という 3 段構えです。ログを見て「これを検知したい」と思ってから実際にアラートが飛ぶまで、15〜30 分の設定作業がかかっていました。

2026 年 7 月 1 日にリリースされた Log Alarm は、この中間ステップをまるごと省きます。Logs Insights のクエリに閾値を指定するだけで、ログから直接アラームが作れます。

aws.amazon.com

観点	従来（メトリクスフィルター）	Log Alarm (NEW)
設定ステップ	3（フィルター → メトリクス → アラーム）	1（Log Alarm のみ）
クエリ柔軟性	パターン構文のみ	Logs Insights フル構文
通知にログ行含む	❌	✅ (最大 50 行)
既存ログに遡及	❌	✅
IaC	2 リソース	1 リソース (`AWS::CloudWatch::LogAlarm`)

個人的にありがたいのは、通知メールにマッチしたログ行そのものを含められる点です。アラートを受け取った瞬間に「誰が、どのファイルに、何をしたのか」が見えるので、コンソールを開く前に初動の見立てが立てられます。

FSx for ONTAP 監査ログ × Log Alarm

前回の記事で構築した Syslog VPC Endpoint により、FSx for ONTAP の管理監査ログはすでに CloudWatch Logs に届いています。つまり、Log Alarm を載せる土台はもう出来上がっているわけです。あとはその上でクエリを書くだけで、ストレージ層のセキュリティ検知が動き出します。

対象ログ

一点だけ整理しておきたいのが、FSx for ONTAP のログ / イベントは大きく 3 系統に分かれるという点です。管理監査ログ・ファイルアクセス監査ログという 2 種類の「監査ログ」に加えて、システム側の出来事を通知する EMS（Event Management System） があります。本記事の主役は管理監査ログですが、EMS も前回記事で構築した CloudWatch Logs の Syslog VPC エンドポイントにそのまま流せば（EC2 の Syslog サーバーは不要）、Log Alarm の対象にできます。

ログ種別	記録される操作	配信経路	Log Alarm 対象
管理監査ログ	ONTAP の管理操作（CLI / REST API）	Syslog VPCE → CloudWatch Logs	✅ 本記事
ファイルアクセス監査ログ	NAS 上のファイル / フォルダ操作（NFS / SMB）	FSx for ONTAP S3 AP → Lambda	別パイプライン
EMS イベント	ONTAP システムイベント（容量 / HA / ARP 等）	Syslog VPCE → CloudWatch Logs（EC2 不要）、または EMS Webhook → Lambda	✅ Syslog VPCE 配信時

管理監査ログは「誰が管理者として何をしたか」の記録です。具体的には次のような操作が 1 行ずつ残ります。

SSH / HTTP(S) / コンソールでのログイン成功・失敗
security login によるアカウント作成・パスワード変更・ロール変更
volume create / volume offline / volume delete などのボリューム操作
vserver 構成変更、エクスポートポリシーや共有（CIFS share）の変更
system node systemshell や set -privilege diagnostic といった診断・特権操作

ONTAP の 2 つの設定を混同しない: 「何を記録するか」は security audit（例: 参照系/GET を捕捉する security audit modify -cliget on -httpget on -ontapiget on — デフォルト無効。有効化しないと sensitive-file-access が空振り）、「どこへ送るか」は cluster log-forwarding が決めます。正確なコマンドは Syslog VPCE セットアップガイドを参照。cluster log-forwarding は複数宛先をサポートするため、既存のオンプレ SIEM を維持したまま CloudWatch を追加できます。

ファイルアクセス監査ログは「どのユーザーが、どのファイルに、どんな操作をしたか」の記録です。vserver audit create で有効化し、Windows セキュリティイベント形式（EVTX / XML）で出力されます。主なイベントは次の通りです。

EventID	意味	典型的なユースケース
4656	ハンドル要求（オープン試行）	ファイルを開こうとした
4663	オブジェクトへのアクセス	read / write / delete などの実操作
4660	オブジェクト削除	ファイル削除
4670	アクセス許可（ACL）変更	セキュリティ記述子の変更

各レコードには実行ユーザー・対象パス・クライアント IP・成否が含まれます（本プロジェクトのサンプルログより抜粋）。

EventID 4663  user=CORP\user-finance-01    path=/share/finance/quarterly-reports/Q2-2026-revenue.xlsx  client=10.0.x.x  Audit Success
EventID 4660  user=CORP\contractor-ext-03  path=/share/engineering/designs/prototype-v3.dwg            client=10.0.x.x  Audit Failure（削除失敗）

機密フォルダへのアクセスや大量削除の検知には、このファイルアクセス監査ログが向いています。ただし本記事の Log Alarm で直接扱うには、EVTX / XML を CloudWatch Logs へ転送する別パイプラインが必要です（本プロジェクトでは FSx for ONTAP S3 AP 経由で Lambda が読み取り、各ベンダーへ配信しています）。

⚠️ 重要なスコープ（プリセット名を鵜呑みにしない）: 本記事のプリセットは管理監査ログ（/syslog/fsxn-admin-audit）を対象とします。このログには管理プレーンの操作しか含まれず、NFS/SMB 経由のエンドユーザーファイル I/O は見えません。したがってこのロググループでは: - bulk-delete-operations は管理プレーンの破壊操作（Snapshot 削除、volume offline/delete）を検知します — SMB でユーザーファイルを暗号化するランサムウェアは検知しません。 - sensitive-file-access は管理コマンドがそのパスを参照したときだけマッチします — ユーザーがそのファイルを開いたときではありません。

ユーザーファイルのランサムウェア/大量削除/機密アクセス検知には、ONTAP ARP（記事2）と FPolicy / ファイルアクセス監査（記事2で解説）を使います。同じプリセットはファイルアクセス監査ログを CloudWatch Logs に取り込めば動作しますが、/syslog/fsxn-admin-audit に対しては管理プレーンしか見えません。

EMS イベント（システムイベント）

3 つ目の情報源が EMS（Event Management System） です。EMS は ONTAP が内部で発行するシステムイベント通知の仕組みで、「誰が操作したか」を記録する監査ログとは対照的に、「システム側で何が起きたか」を伝えます。重要度は emergency / alert / error / warning / notice / informational / debug の 7 段階です。

本プロジェクトが正規化対応している代表的な EMS イベントを挙げます。

イベント名	重要度	意味
`arw.volume.state` / `arw.vserver.state`	alert	ARP（ランサムウェア自動防御）の状態遷移（enabled / disabled / dry-run / paused）
`monitor.volume.full` / `wafl.vol.full`	alert	ボリューム容量の枯渇
`wafl.quota.hardlimit.exceeded`	error	quota ハードリミット超過
`sms.vol.full`	error	SnapMirror 先ボリュームの逼迫
`cf.fsm.takeoverStarted`	alert	HA テイクオーバー開始
`net.linkDown`	alert	ネットワークリンクダウン
`passwd.changed`	notice	管理ユーザーのパスワード変更

EMS の扱いには 2 つの経路があります。

本プロジェクトの実装（EMS Webhook）: ONTAP の EMS Webhook（HTTPS）→ API Gateway → Lambda で受け、ems-parser が messageName / severity / source_node とイベント固有パラメータを正規化して各ベンダー / OTLP へ配信します。ARP の状態遷移のようなセキュリティ・運用イベントを、そのまま Datadog などのダッシュボードに載せられます。
Syslog VPCE 経由で CloudWatch Logs へ: ONTAP 9.x では event notification destination create -syslog ... により、EMS イベントを管理監査ログと同じ CloudWatch Logs の Syslog VPC エンドポイントへ送れます。前回記事で作った VPCE をそのまま宛先に指定するだけで、EC2 の Syslog サーバーを別途立てる必要はありません。こうして CloudWatch Logs に届いた EMS は、そのまま Log Alarm の対象になります。ログは次のような 1 行で届き、app = "kernel"（または notifyd）で絞り込めます。

<pri>1 2026-06-25T03:33:31+00:00 FsxId...-01 kernel - monitor.volume.full - Volume "<volume>" is full (using or reserving 100% of space ...)

「容量枯渇や ARP の状態変化に即アラートしたい」なら、EMS を Syslog 経由で CloudWatch Logs に流し込み、本記事の Log Alarm で拾うのが最短です。管理監査ログと EMS の両方を Syslog VPCE 経由で CloudWatch Logs へ配信する手順は、クラスメソッド DevelopersIO の検証記事（管理アクティビティの監査ログを Syslog の VPC エンドポイントで CloudWatch Logs に配信してみた）でも確認されています。

アーキテクチャ

全体像は次の通りです。監査ログが CloudWatch Logs に入るところまでは前回の構成、そこから下が今回追加する部分です。

FSx for ONTAP (ONTAP log-forwarding)
    │ Syslog TCP
    ▼
VPC Endpoint → CloudWatch Logs (/syslog/fsxn-admin-audit)
    │ Scheduled Query (5 min)
    ▼
CloudWatch Log Alarm
    │ count(*) > threshold → ALARM
    ▼
SNS → Email / Slack / PagerDuty (ログ行付き)

実際のログフォーマット

Log Alarm のクエリを書くには、対象のログがどんな形をしているかを知っておくと話が早いです。実際に CloudWatch Logs に届く 1 行はこうなっています。

<190>Jul  2 03:17:37 FsxId...-02: [kern_audit:info:6392]
...:: FsxId...:ssh :: <source-ip>:unknown ::
FsxId...:fsx-control-plane:admin ::
system node systemshell -node * -command "top -d 1 -s 1"
:: Success

一見すると呪文のようですが、この 1 行には「いつ・どのプロトコル（ssh/http）で・どこ（ソース IP）から・誰が（実行ユーザー）・何を（コマンド）実行し・どうなったか（Success/Failure）」がすべて詰まっています。クエリで拾いたいのは、たいていこのうちのどれかです。

「文字列でアラート」の仕組み

ここで一つ、CloudWatch Alarm の性質を思い出しておく必要があります。CloudWatch Alarm は本来、数値に対して閾値を比較する仕組みであって、「このログ文字列が出たら鳴らす」という文字列ベースの発火装置ではありません。

では Log Alarm はどうやってログの内容でアラートを出しているのか。答えは、文字列を一度「数」に変換しているからです。Logs Insights のクエリでマッチするイベントを絞り込み、それを count(*) で件数に変換します。この件数が閾値を超えたときに発火する、という流れです。「文字列 → 数値化 → 閾値比較」と読み替えると腑に落ちるはずです。

たとえば機密フォルダへのアクセスを検知したいなら、次のようなクエリになります。

fields @timestamp, @message
| filter @message like /\/vol\/data\/confidential/

集約式に count(*)、閾値に > 0 を設定すれば、5 分間のウィンドウで 1 件でもアクセスがあれば ALARM に遷移します。「誰かが機密フォルダに触れたら即座に知らせる」という要件が、これだけで実現できます。

デプロイ

前置きが長くなりましたが、実際に動かしてみましょう。リポジトリにはデプロイスクリプトを用意してあるので、環境変数をいくつか渡すだけで一通りのリソースが立ち上がります。

デプロイスクリプト（推奨）

# 機密ファイルアクセス検知（SNS トピック自動作成）
DETECTION_TYPE=sensitive-file-access \
TARGET_PATTERN="/vol/data/confidential" \
CREATE_SNS_TOPIC=true \
SNS_TOPIC_NAME=fsxn-security-alerts \
  bash shared/scripts/deploy-log-alarm.sh

このスクリプトは、SNS トピックの作成から CloudFormation のデプロイ、最後にアラーム名とコンソール URL の出力までを一気に済ませてくれます。

CloudFormation テンプレート

# shared/templates/cloudwatch-log-alarm.yaml (抜粋)
Resources:
  SensitiveFileAccessAlarm:
    Type: AWS::CloudWatch::LogAlarm
    Properties:
      AlarmName: fsxn-sensitive-file-access
      ComparisonOperator: GreaterThanThreshold
      Threshold: 0
      QueryResultsToEvaluate: 3
      QueryResultsToAlarm: 1
      TreatMissingData: notBreaching
      ScheduledQueryConfiguration:
        QueryString: |
          fields @timestamp, @message
          | filter @message like /\/vol\/data\/confidential/
        LogGroupIdentifiers:
          - /syslog/fsxn-admin-audit
        ScheduledQueryRoleARN: !GetAtt ScheduledQueryRole.Arn
        AggregationExpression: "count(*)"
        ScheduleConfiguration:
          ScheduleExpression: "rate(5 minutes)"
          StartTimeOffset: 300
      AlarmActions:
        - !Ref AlarmSNSTopic
      ActionLogLineCount: 5
      ActionLogLineRoleArn: !GetAtt LogLineRole.Arn

検知プリセット

テンプレートには、よく使う検知パターンを 5 種類のプリセットとして用意しました。DetectionType を切り替えるだけで、それぞれに適したクエリと閾値が設定されます。

DetectionType	用途	デフォルト閾値
`sensitive-file-access`	特定パスへのアクセス検知	> 0
`failed-access-attempts`	認証/認可失敗	> 10
`bulk-delete-operations`	大量削除（ランサムウェア兆候）	> 50
`specific-user-activity`	特権ユーザー操作監視	> 0
`custom`	任意の Logs Insights クエリ	任意

ユースケース

プリセットが実際の運用でどう効いてくるのか、代表的な 3 つのシナリオで見ていきます。

1. 管理プレーンの破壊操作検知（多層防御）

スコープを正確に言うと、管理監査ログに対するこのプリセットは管理プレーンの破壊操作 — Snapshot 削除の連発、volume offline、volume delete — を捉えます。窃取した管理者認証情報を持つ攻撃者（または誤操作した運用者）が、復旧ポイントを消すために取る類の操作です。SMB 経由のユーザーファイル暗号化は見えません。それはストレージ層の ONTAP ARP（記事2）の担当で、ファイル単位の操作は FPolicy（記事2で解説）が担います。3 つを重ねます — 暗号化は ARP、ファイル操作は FPolicy、そしてこの Log Alarm は管理プレーンの改ざん（復旧に使う Snapshot を誰かが削除する等）を検知します。

DETECTION_TYPE=bulk-delete-operations \
ALARM_THRESHOLD=50 \
QUERY_RESULTS_TO_ALARM=2 \
SNS_TOPIC_ARN=<YOUR_SNS_ARN> \
  bash shared/scripts/deploy-log-alarm.sh

検知層	捕捉対象	手法	レイテンシ
ストレージ層 (ARP)	ユーザーファイル暗号化	ML ベースエントロピー分析	リアルタイム
ファイル操作 (FPolicy)	NFS/SMB のファイル作成/書込/削除/リネーム	プロトコルレベル傍受	~6 秒（記事2 で検証）
管理プレーン (Log Alarm)	管理者による Snapshot/ボリューム破壊操作	管理監査ログのカウント閾値	~5 分

同じ攻撃を 3 つの視点から見ます — ARP は暗号化を、FPolicy はファイル操作を、この Log Alarm は復旧に使う Snapshot を管理者が削除する行為を捉えます。重ねることで、片方をすり抜けた異常をもう片方が拾う多層防御になります。

ATT&CK で言えば、この管理プレーンの視点は T1490 Inhibit System Recovery — 攻撃者が復旧ポイントを削除し、ARP が検知する暗号化（T1486）をロールバックできなくする行為です。2 つのテクニック、2 つのコントロール: ここで Snapshot 削除を検知し、SnapLock（期限前は削除不可の WORM Snapshot）で予防することで、復旧ポイントがその試みを生き延びます。完全な ATT&CK マッピング、改ざん耐性（誰がアラームを削除できるか、どう守るか）、経営説明用の1枚カバレッジ表はセットアップガイドにあります。

運用注意（まずベースライン）: 夜間バックアップ・バッチ ETL・アーカイブ削除などの定期大量処理は、「5 分で 50 削除」の閾値を正当に超えてオンコールを無駄に呼び出すことがあります。本番投入前に通常の削除量をベースライン化し（数日間はアラームアクションなしでクエリだけ動かす）、平常時のピークより上に閾値を設定するか、既知のサービスアカウント/メンテナンス時間帯をクエリで除外してください。記事2の ARP 学習期間の注意点と同じ考え方です。

2. コンプライアンス: 規制データへのアクセス通知

金融や医療のように「この領域のデータに触れたら必ず記録・通知する」ことが求められる場面では、特定パスを対象にしたシンプルな検知が効きます。

DETECTION_TYPE=sensitive-file-access \
TARGET_PATTERN="/vol/finance/" \
ALARM_THRESHOLD=0 \
SNS_TOPIC_ARN=<YOUR_SNS_ARN> \
  bash shared/scripts/deploy-log-alarm.sh

アラート疲れ注意: 常時アクセスされるパスに > 0 を設定すると、アクセスのたびに発報してノイズになります。> 0 は本当に制限されたパス（ブレークグラス用ディレクトリ、隔離データ）に限定してください。正当な定期アクセスがあるパスでは、レート閾値（想定外プリンシパルからのアクセス、ベースライン超過など）を使い、ページャーではなくチケット/Slack へルーティングするのが適切です。

3. 特権ユーザー操作の監視

管理者アカウントの操作をすべて記録に残しておきたい、という要件も同じ仕組みで実現できます。

DETECTION_TYPE=specific-user-activity \
TARGET_PATTERN="fsxadmin" \
ALARM_THRESHOLD=0 \
SNS_TOPIC_ARN=<YOUR_SNS_ARN> \
  bash shared/scripts/deploy-log-alarm.sh

E2E 検証（東京リージョン）

新機能だけに、ドキュメント通りに動くのか半信半疑なところもありました。そこで東京リージョンの実環境でテンプレートをデプロイし、アラームが状態遷移するところまで一通り確認しました。結果は次の通りです。

項目	結果
CloudFormation デプロイ	✅ 成功
IAM ロール自動作成	✅ ScheduledQueryRole + LogLineRole
Scheduled Query 実行	✅ INSUFFICIENT_DATA → OK 遷移確認
コンソール表示	✅「Log alarm」タイプ表示
Logs Insights クエリ	✅ マッチ確認（`/volume/` で 12 件 / 3,482 レコード scan、`ssh` で 472 件）

コンソール上では、既存のメトリクスアラームとは別に「Log alarm」という新しいタイプとして表示されました。

CloudWatch Alarms — Log alarm タイプ表示（Type 列が「Log alarm」）

アラームを開くと Log Alarm の詳細が確認できます。クエリ設定（Logs Insights クエリ文字列・対象ロググループ /syslog/fsxn-admin-audit・5 分間隔スケジュール）と、CloudFormation が自動作成した 2 つの IAM ロール — ScheduledQueryRole（クエリ実行）と LogLineRole（マッチしたログ行を通知に添付）— が確認できます。

Log alarm 詳細 — クエリ設定・対象ロググループ・スケジュール・ScheduledQueryRole / LogLineRole

Logs Insights でクエリを実行すると、監査ログが実データとしてヒットします（下は /volume/ フィルタで 12 件マッチ、3,482 レコードをスキャンした例）。棒グラフに件数が出ているのが分かります。

Logs Insights — 監査ログのクエリ結果（`/volume/` フィルタで 12 件マッチ、3,482 レコード scan）

アラーム自体は、該当アクセスが無い間は「OK」を保ちます（INSUFFICIENT_DATA → OK への遷移を確認）。閾値 > 0 なので、機密パスへのアクセスが 1 件でも出た瞬間に ALARM へ切り替わる想定です。

Log alarm — 状態 OK（INSUFFICIENT_DATA → OK 遷移を確認）

注意点

一方で、検証中にいくつか気をつけるべき点も見えてきました。

注意点	対処
AWS CLI 未対応 (`put-log-alarm` なし)	CloudFormation を使用
cfn-lint E3006	無視可（デプロイは成功する）
初回評価に 5〜10 分	待機するだけ
通知にログ行が含まれる (PII リスク)	機密環境では `ActionLogLineCount=0`

特に「AWS CLI にまだ put-log-alarm が来ていない」のは GA 直後ならではで、当面は CloudFormation かコンソールが唯一の作成手段になります。

コスト

気になるコストも見ておきましょう。5 分間隔で 1 アラームを動かした場合の概算です。

ログ量/日	Log Alarm 方式	メトリクスフィルター方式
100 MB	~$6.6/月	~$3/月
500 MB	~$33/月	~$3/月
1 GB	~$66/月	~$3/月

正直に言うと、Log Alarm はメトリクスフィルター方式より割高です。Scheduled Query が実行のたびにログをスキャンする分、費用が上乗せされるためです。ただ、この差額は運用の別のところで回収できると考えています。通知にログ行が含まれるので調査時間が縮み、既存ログにも遡って適用でき、設定も 1 ステップで済む。月数ドルの差より、インシデント対応が速くなる価値の方が大きい場面は少なくないはずです。

ログ量が多くて費用が気になる場合は、評価頻度を 15 分に変えるだけで 1/3 に、さらにクエリに limit を足せばスキャン量を抑えられます。

使い分けガイド

ここまで Log Alarm の利点を並べてきましたが、あらゆる監視をこれで置き換えるべきだ、という話ではありません。用途によってはメトリクスフィルターや OTel Collector の方が適しています。本プロジェクトが提供する 3 つの配信パスの中で、Log Alarm は最もシンプルな入り口に位置します。

パス	適用場面	追加インフラ
Log Alarm (本記事)	シンプルな閾値アラート	なし（CloudWatch 内で完結）
Lambda → ベンダー	ダッシュボード、SIEM	転送 Lambda
OTel Collector	マルチバックエンド、PII 除去	転送 Lambda + Collector（ECS Fargate）

OTel Collector パスの「追加インフラ」を本プロジェクトの実装で具体的に言うと、2 層構成になります。

転送 Lambda ×3: 監査ログ shipper（FSx for ONTAP S3 AP → EventBridge → Lambda）、EMS handler（API Gateway → Lambda）、FPolicy handler（SQS / EventBridge → Lambda）。それぞれログを正規化し、OTLP/HTTP で Collector へ送ります（環境変数 OTLP_ENDPOINT）。
OTel Collector 本体: otel/opentelemetry-collector-contrib コンテナを ECS Fargate タスクとして VPC 内に常駐させます（OTLP 受信ポート 4318 / ヘルスチェック 13133）。外部バックエンドへの egress 用に NAT Gateway、タスク IP 解決に AWS Cloud Map（Service Discovery）、負荷に応じて ALB とオートスケールを組み合わせます。

Grafana・Honeycomb・Datadog へのファンアウトや PII 除去（redaction / transform プロセッサ）は、この Collector の設定 YAML 1 箇所で切り替えられます。Log Alarm が「CloudWatch だけで完結する最小構成」なのに対し、OTel Collector は「常駐プロセスを 1 つ抱える代わりに、配信先とデータ加工を自在にできる構成」という位置づけです。

Log Alarm はあくまでセキュリティ検知の第一報です。「まず気づく」ところを Log Alarm が担い、そこから先の深掘りは Datadog や Splunk などのベンダーツールに委ねる。この役割分担が現実的だと考えています。

クリーンアップ

試し終わったら、作成したスタックはまとめて削除できます。

# 全 Log Alarm スタック削除
bash shared/scripts/cleanup-log-alarm.sh --all -y

おわりに

CloudWatch Log Alarm は、派手な機能ではありません。けれども「ログを見て気づいたことを、そのままアラートにできる」という体験は、監視設定のハードルを確実に下げてくれます。メトリクスフィルターを作り、メトリクスを眺め、アラームを設定する——この一連の作業を思い出す前に、クエリ 1 つで済んでしまうからです。

FSx for ONTAP の監査ログとの相性も良く、機密ファイルへのアクセスや大量削除といったストレージセキュリティの「まず気づきたい」ニーズに、追加のインフラなしで応えられます。GA 直後で AWS CLI が追いついていないなどの粗さはありますが、CloudFormation で問題なく使えることは実環境で確認済みです。気になった方は、ぜひ手元の環境で試してみてください。

シリーズ

本シリーズでは以下を解説しています。

サーバーレスアーキテクチャ — Lambda + S3 AP による EC2 不要のログ配信
ランサムウェア検知 — ARP + FPolicy + EMS による多層検知
9 ベンダー比較と OTel Collector — ベンダーロックイン回避
GUI 管理と管理操作監査 — System Manager + Syslog VPCE
CloudWatch Log Alarm（本記事）— メトリクスフィルター不要のネイティブ監視

すべてのコード・テンプレートは GitHub で公開しています: Yoshiki0705/fsxn-observability-integrations

運び屋 (A carrier(forwarder) changed his career to an engineer)

AWS / Storage / Community / Cloud Native / Kubernetes / コンテナ / SRE / DevOps

CloudWatch Log Alarm で FSx for ONTAP 監査ログから直接アラートする — メトリクスフィルター不要の新しい監視パターン