AWS SOA 無料サンプル

EC2インスタンスのCloudWatchメトリクス（CPUUtilization、NetworkIn/Out、DiskReadOps 等のハイパーバイザーレベルの指標）は、 デフォルトでは基本監視（basic monitoring）＝5分間隔で収集され、追加料金は発生しない。

• これを1分間隔の詳細監視（detailed monitoring）に切り替えるには、インスタンス起動時またはインスタンス設定変更で 「CloudWatch詳細モニタリングを有効化」するだけでよく、エージェント導入もアプリケーション改修も不要である。
• 詳細監視は基本監視より追加費用がかかる（インスタンスごとの課金）が、実装コストは最小で障害検知のラグを大きく短縮できる。
• 一方、メモリ使用率やディスク使用率のようなOS内部の指標は、詳細監視を有効にしても収集されない（別途CloudWatch Agentが必要）点は区別すること。

AWSの標準サービスが提供しない独自の指標は、CloudWatchカスタムメトリクスとしてアプリケーション側から PutMetricData APIで送信する。

• 1回の PutMetricData 呼び出しには、名前空間（Namespace）・メトリクス名（MetricName）・値（Value）に加えて、 ディメンション（Dimensions）をキー・バリューのペアとして複数付与できる（1メトリクスあたり最大30ディメンション）。
• 本問のように環境とキュー名の両方で絞り込みたい場合は、Environment と QueueName という 2つのディメンションを同じメトリクスデータポイントに付与すればよい。CloudWatchコンソールでは、 ディメンションの組み合わせごとに個別の時系列として自動的に集計・表示され、アラームも特定のディメンションの組み合わせに対して設定できる。
• デフォルトの解像度（標準解像度）は60秒単位で、より高頻度（1秒単位）が必要な場合は StorageResolution: 1 を指定した高解像度カスタムメトリクスにできる。

CloudWatchの名前空間（Namespace）は、メトリクスを分離するための最上位のコンテナである。 AWSの各サービスは AWS/EC2、AWS/RDS のように固有の名前空間を使っており、 カスタムメトリクスでは AWS/ で始まらない任意の名前空間を自分で定義できる （例：MyCompany/OrderService、MyCompany/InventoryService）。

• 名前空間をアプリケーション単位で分けることで、CloudWatchコンソールのメトリクス一覧・ダッシュボード・アラームの検索性が大きく向上し、 誤って他アプリのメトリクスと混同するリスクも避けられる。
• ディメンションはあくまで同一名前空間内でのメトリクスの絞り込み軸であり、名前空間そのものの代替にはならない。 アプリケーションという大きな括りの分離には名前空間、環境やインスタンスIDのような細かい絞り込みにはディメンション、という役割分担が基本設計になる。

CloudWatchのディメンションは値の組み合わせごとに個別の時系列（メトリクスストリーム）を作る。 一意性の高い値（リクエストID、セッションIDなど）をディメンションに使うと、組み合わせ数（カーディナリティ）が実質無限に近い形で増殖する。

• コスト：カスタムメトリクスは一意なメトリクス（名前空間＋メトリクス名＋ディメンションの組み合わせ）の数に応じて課金される。 高カーディナリティなディメンションはこのユニークメトリクス数を爆発的に増やし、想定外の高額請求につながる。
• 集計・可視化の劣化：本来見たいのは「エンドポイントごと」「環境ごと」など意味のある集約軸での傾向であり、 リクエストIDのような一意値でディメンションを切ると、1つ1つが個別の系列になってしまい、ダッシュボードやアラームで有用な集計（平均・パーセンタイル等）ができなくなる。
• 推奨される設計は、エンドポイント名・HTTPメソッド・環境名のような低〜中カーディナリティで意味のある軸をディメンションに選び、 リクエストID等の一意な識別子はCloudWatch Logsの構造化ログ側に残す、という役割分担である。

EC2の標準メトリクス（基本監視・詳細監視いずれも）はハイパーバイザーが観測できる範囲（CPU使用率、ネットワークI/O、EBSディスクI/Oなど）に限られる。 メモリ使用率やOSファイルシステム単位のディスク使用率は、ゲストOS内部の状態であり、ハイパーバイザーからは見えないため 標準では収集されない。

• これらの指標を取得するには、インスタンス内にCloudWatch Agent（統合エージェント）をインストールし、 設定ファイルで mem_used_percent、disk_used_percent 等のメトリクスを収集対象として指定する必要がある。
• CloudWatch Agentが収集したメトリクスは、デフォルトでは CWAgent（設定変更可）という名前空間にカスタムメトリクスとして送信され、 通常のカスタムメトリクスと同様にアラーム・ダッシュボードで利用できる。
• エージェントの実行にはインスタンスにIAMロール（CloudWatchAgentServerPolicy 等）をアタッチする必要がある（別設問で扱う）。

CloudWatch Agentは、収集したメトリクス・ログをCloudWatchへ送信する際、あるいは設定をSSM Parameter Storeから取得する際に、 インスタンスにアタッチされたIAMロールの認証情報を使ってAWS APIを呼び出す。IAMロールが無ければ、 cloudwatch:PutMetricData や logs:PutLogEvents 等の呼び出しがすべてAccessDeniedになる。

• 最小限の対応は、AWS管理ポリシー CloudWatchAgentServerPolicy（メトリクス・ログの送信や、SSMパラメータ・EC2タグの読み取りを許可） をアタッチしたIAMロールを作成し、対象インスタンスに割り当てることである。
• 加えて、エージェント設定をSSM Parameter Store経由で一元管理・配布したい場合は CloudWatchAgentAdminPolicy（設定の書き込み権限を含む）を 設定側の管理者に付与する（エージェントを実行するだけのインスタンス側には不要）。
• IAMユーザーのアクセスキーをインスタンス内に埋め込む方式は、長期認証情報の漏えいリスクがあるためベストプラクティスに反する。

CloudWatch Agentは、設定ウィザード（amazon-cloudwatch-agent-config-wizard）で生成したJSON設定を、 Systems Manager Parameter Storeにパラメータとして保存し、各インスタンスは起動時に amazon-cloudwatch-agent-ctl の -c ssm:<parameter-name> オプションでその設定を取得・適用する運用に対応している。

• この方式であれば、設定を1箇所（Parameter Store）で更新するだけで、以後起動するインスタンス（Auto Scaling起動時など）は 起動スクリプト（ユーザーデータ）経由でSSMパラメータを参照し常に最新の設定を取得できる。
• 設定変更時も、Parameter Store側を更新して既存インスタンス群にエージェント再起動（設定の再取得）をSSM Run Command等で一括実行すれば足り、 個々のインスタンスへ手動でファイルをコピーする必要がない。
• 設定をParameter Storeへ書き込む側（管理者・CI/CDパイプライン）には CloudWatchAgentAdminPolicy が必要（前問の CloudWatchAgentServerPolicy は実行側インスタンスに付与するロール）。

EC2標準メトリクス（AWS/EC2名前空間）はハイパーバイザーが観測できる範囲に限られ、CPUUtilization、 NetworkIn/NetworkOut、EBSの DiskReadOps/DiskWriteOps はこれだけで取得できる。

• メモリ使用率（mem_used_percent）とファイルシステム単位のディスク使用率（disk_used_percent）は、 ゲストOS内部でしか把握できない指標であり、CloudWatch Agentの導入が必須である。
• CPU使用率・ネットワークI/Oは標準メトリクスに含まれ、Agent導入は不要（基本/詳細監視の範囲）。

CloudWatch Agentには、procstatプラグインがあり、プロセス名（pattern）・PIDファイル・ systemdユニット名などを指定して、特定のプロセスに限定したCPU使用率・メモリ使用量・スレッド数・ファイルディスクリプタ数 などをメトリクスとして収集できる。

• 設定ファイルの metrics.metrics_collected.procstat セクションに対象プロセスの識別方法とメトリクス項目を指定する。
• プロセスが停止・クラッシュした場合、procstatのメトリクス自体が送信されなくなる（データ欠落）ため、 アラームの欠落データの扱い（treatMissingData）を breaching に設定しておけば、 プロセス停止＝メトリクス途絶をアラームの発報条件として扱える（別設問で詳述）。
• これに対しEC2標準メトリクスは、インスタンス全体のCPU・ネットワーク等は分かってもプロセス単位の内訳は分からない。

CloudWatch Agentは、StatsDプロトコル（デフォルトUDPポート8125）とcollectdを使ったメトリクス受信に対応しており、 アプリケーション側の実装をPutMetricData の直接呼び出しに書き換えなくても、 既存のStatsDクライアントからの送信をCloudWatch Agentが受け取り、CloudWatchカスタムメトリクスへ変換して転送できる。

• CloudWatch Agentの設定ファイルの metrics.metrics_collected.statsd セクションで、待受ポートや集計間隔（metrics_collection_interval）を指定するだけでよい。
• アプリケーションは引き続きローカルのStatsDエンドポイントへメトリクスを送るだけで済み、AWS SDKやAPI呼び出しコードの追加実装が不要になる。
• これにより、オンプレミス時代からある監視スタック（Graphite/StatsD等）の資産を活かしつつ、宛先をCloudWatchへ集約する移行がしやすくなる。

複合アラームは、複数の子アラーム（メトリクスアラーム、または他の複合アラーム）の状態を ALARM()／OK()／INSUFFICIENT_DATA() 関数と論理演算子（AND／OR／NOT）で 組み合わせたAlarmRuleという式で評価する。

• 「両方ともALARM状態のときだけ発報」はAND条件で表現する： ALARM(HighCPUAlarm) AND ALARM(HighLatencyAlarm)。
• 複合アラームを使う目的は、相関する複数の子アラームをまとめて評価し、単独の一時的なスパイクだけでは発報させない（アラート疲れの軽減）こと。 本問のように「CPUだけ高い」「レイテンシだけ高い」は個別の一過性ノイズの可能性があるが、両方同時に閾値超過している場合は本当に深刻な障害である可能性が高い、という運用判断を式に落とし込める。
• 逆に「どちらか一方でも」という要件であれば OR を使う。

複合アラームは複数の子アラームの状態を論理式で束ねて、より意味のある単位で通知を発生させる仕組みである。

• アラート疲れの軽減：単独では一時的なノイズになりがちな複数の子アラームをANDで束ねることで、 「複数の兆候が同時に発生した本当に深刻な状況」の時だけ通知するよう絞り込め、通知の総量を減らせる。
• アラームの依存関係・階層のモデリング：例えば「あるサービスがメンテナンス中を示すアラームがOKの間だけ、 個々のメトリクスアラームの通知を有効にする」といった親子関係・条件付き抑制を式として表現できる。

一方、複合アラーム自体が個々のメトリクスの評価間隔（period）を変えたり、メトリクス収集コストを直接削減したりするものではない点は区別すること。

CloudWatchの異常検知（Anomaly Detection）は、対象メトリクスの過去の履歴データに機械学習モデルを適用し、 曜日・時間帯による周期性を織り込んだ「予測される正常範囲（バンド）」を自動的に算出する機能である。

• 異常検知を有効にすると、CloudWatchは対象メトリクスに対して上限・下限の帯（バンド）を表す特殊なメトリクス （ANOMALY_DETECTION_BAND関数の結果）を生成する。
• 異常検知アラームは、実測値がこのバンドから指定した標準偏差の係数（例：2）を超えて外れた場合にALARM状態になる。 固定の単一しきい値では「平日昼は正常でも深夜なら異常」といった時間帯依存の判定ができないが、異常検知はこれを自動的に扱える。
• これにより、曜日・時間帯ごとに手動でしきい値を作り込む運用を避けつつ、季節性のあるメトリクスに対して精度の高い異常検知ができる。

異常検知アラームは静的しきい値アラームと同じメトリクスアラームの一種だが、しきい値の決め方が根本的に異なる。

• 異常検知モデルは継続的に学習を更新する。メトリクスの傾向（トラフィックの緩やかな増加トレンド等）が変化すれば、 時間とともに正常範囲（バンド）も追従して変化していく。
• アラームの発報条件は「予測バンドから指定した標準偏差の幅を超えて逸脱したか」で判定され、 固定の絶対値しきい値を運用者があらかじめ決め打ちする必要がない。
• 一方、異常検知は十分な履歴データ（一般的に数日〜2週間程度の学習期間）が無いと精度が安定しないため、 新規に作られたばかりのメトリクスにいきなり適用しても最初は誤判定が出やすい。また、静的しきい値アラームを完全に置き換える万能の仕組みでもなく、 明確な絶対的な安全限界（例：ディスク使用率100%目前）を守りたい場面では静的しきい値の方が適する場合もある。

CloudWatchアラームには、評価期間内にデータポイントが届かなかった場合の扱いを制御する treatMissingData パラメータがあり、次の4種類から選べる。

• missing（デフォルト）：欠落したデータポイントは評価に含めず、アラームの状態遷移の判断材料にしない。
• notBreaching：欠落したデータポイントを「しきい値を超えていない（正常）」とみなす。
• breaching：欠落したデータポイントを「しきい値を超えている（異常）」とみなす。
• ignore：欠落があった評価期間については現在のアラーム状態を維持し、状態を変化させない。

本問のような「メトリクスが送られてくること自体が正常性の証（ハートビート）」というユースケースでは、 データの欠落こそが最も検知したい異常であるため、treatMissingData をbreaching に設定する。 これにより、ハートビートが止まった瞬間に（欠落したデータポイントがしきい値超過とみなされ）アラームがALARM状態に遷移する。

CloudWatchアラームには、「直近何回中、何回しきい値を超えたらALARMにするか」を指定する 「データポイント数（Datapoints to Alarm）＝M out of N」という設定がある。

• 例えば「評価期間（Evaluation Periods）5回のうち3回」（3 out of 5）と設定すると、 直近5つのデータポイントのうち3つ以上がしきい値を超えて初めてALARMになり、単発の1回だけのスパイクでは発報しなくなる。
• これは、しきい値そのものを変えずに「継続性・頻度」でノイズを抑制する手法であり、 本問のように「一時的な揺らぎは無視し、持続的な異常だけを検知したい」という要件に直接対応する。
• これに対し、しきい値自体を緩める対応は、本来検知したい持続的な異常の検知感度まで一律に下げてしまう副作用があり、根本対応として適切でない。

CloudWatchアラームのEC2向けアクションには再起動（Reboot）・復旧（Recover）・停止（Stop）・終了（Terminate）があるが、 それぞれ用途が異なる。

• 復旧（Recover）アクションは、StatusCheckFailed_System（AWS側の物理ハードウェア・ネットワーク・電源等の基盤障害）を契機に設定するのに適しており、 同じインスタンスID・プライベートIPアドレス・Elastic IP・EBSボリュームのアタッチ状態などのメタデータを保持したまま、 正常な新しい物理ハードウェアへ自動的に移行させる。
• これに対しStatusCheckFailed_Instance（ゲストOS内部の問題：カーネルパニック、ネットワーク設定誤りなど）は 物理ホストの問題ではないため、Recoverでは解決せずRebootアクションで対応するのが一般的である。
• Recoverが使えるのは一部のインスタンスタイプ・EBSバックドインスタンスに限られる制約がある点も実務上押さえておく。

EC2向けのCloudWatchアラームアクション（Reboot / Recover / Stop / Terminate）は、それぞれ想定するトラブルシューティングの状況が異なる。

• Stopアクションは、コスト最適化目的（例：開発環境で日中のみ稼働させ夜間はアイドル状態のインスタンスを自動停止する）や、 インスタンスストア以外（EBSルート）の障害時に一時停止して調査する目的で使われる。EBSバックドインスタンスにのみ利用できる。
• Recoverアクションは、システムステータスチェック失敗（物理ハードウェア基盤側の問題）を契機に、 構成（インスタンスID・プライベートIP等）を維持したまま正常な物理ホストへ自動的に切り替える。
• これに対しTerminateは不可逆な操作でインスタンス自体を削除するため、Auto Scaling配下で新しいインスタンスに置き換わる前提の設計でなければ、 構成の喪失というリスクを伴う。

複数アカウント・複数リージョンにまたがるメトリクスを1つのダッシュボードへ集約するには、 CloudWatchのクロスアカウント・クロスリージョン監視機能（Observability Access Manager／Oam）を使う。

• 各事業部のアカウントを「ソースアカウント（monitoring source account）」として、 メトリクス・ログ・トレースの共有を許可するリンク（Oam Link）を作成する。
• 集約先のアカウントを「モニタリングアカウント（monitoring account）」として設定し、 そのアカウントのCloudWatchコンソールから、リンクされた全ソースアカウントのメトリクスをまたいでダッシュボード・アラームを作成できる。
• この仕組みにより、各アカウントへ個別にスイッチロールしてログインし直す必要なく、単一のモニタリングアカウントの単一ダッシュボードで 全社横断の監視が可能になる。リージョンについても、ダッシュボードのウィジェットごとにリージョンを指定できるため、複数リージョンのメトリクスを1画面に混在させられる。

CloudWatchダッシュボードはJSON形式の「ダッシュボードボディ（dashboard body）」に複数のウィジェットを定義して構成する。 本問の2つの要件は、いずれも追加の実装（Lambda・カスタムメトリクス送信）なしに標準ウィジェットだけで実現できる。

• メトリクス数式（Metric Math）を使ったウィジェットでは、既存の HTTPCode_Target_5XX_Count と RequestCount のメトリクスを m1・m2 のような変数として参照し、(m1 / m2) * 100 のような式を定義してグラフの1系列として表示できる。 これは表示上の計算であり、新たなカスタムメトリクスをCloudWatchへ書き込むわけではない。 なおAWS/ApplicationELB名前空間の5xx系メトリクスには、ロードバランサー自身が生成したエラーを表すHTTPCode_ELB_5XX_Countと、 ターゲット（バックエンド）が返したエラーを表すHTTPCode_Target_5XX_Countの2種類があり、単純な「5XXCount」という名前のメトリクスは存在しない点に注意。
• テキストウィジェットは、Markdown形式で任意の説明文・リンクをダッシュボード上に表示できるウィジェットであり、 グラフとは独立して「オーナーチーム」「Runbookへのリンク」のような運用メモを埋め込むのに使う。

CloudWatch Logsのサブスクリプションフィルタ（subscription filter）は、ロググループに新しいログイベントが到着するたびに、 指定パターンに一致するイベントをほぼリアルタイムでストリーミング配信する機能である。

• 配信先には Lambda・Kinesis Data Streams・Kinesis Data Firehose を指定できる。
• Amazon OpenSearch Serviceへ継続的に流し込みたい場合は、サブスクリプションフィルタの配信先をKinesis Data Firehoseに設定し、 Firehose側でOpenSearch Serviceへの配信先を構成するのが標準パターン（Firehoseがバッファリング・リトライ・変換を担う）。
• これに対しCreateExportTaskによるS3エクスポートはポイントインタイムのバッチ処理であり、リアルタイム性が無い。

このため「エラーパターンをリアルタイムで下流サービスへ転送」という要件には、エクスポートタスクではなくサブスクリプションフィルタ＋Firehoseの組み合わせが最適となる。

CloudWatch Logs Insightsは、CloudWatch Logsに保存済みのロググループへ事前のエクスポートや外部インフラ構築なしに、 その場でクエリ言語（fields/filter/stats/parse 等）を使ってアドホックに検索・集計できる機能である。

• 複数ロググループを横断して同時にクエリでき、時間範囲を指定して直近24時間分などに絞り込める。
• statsコマンドでレイテンシの平均・パーセンタイル・分布集計も1クエリ内で完結できる。
• これに対しAmazon Athenaでの分析は、ログが事前にS3へエクスポートされ、かつテーブル/パーティションが定義済みであることが前提となり、 障害対応中の即時調査には向かない（構築の時間的余裕が無い今回の状況と合わない）。

CloudWatch Logsのロググループは、デフォルトでは「失効しない（無期限保持）」であり、明示的に保持期間（PutRetentionPolicy）を 設定しない限りコストが積み上がり続ける。既存分の是正だけでなく今後の新規作成分にも継続的に規約を適用するには、単発のスクリプト実行では不十分である。

• AWS Configのカスタムルール（Guardで書くカスタムポリシールール、またはLambdaのカスタムルール）で 「保持期間が90日でないロググループ」＝「失効しない（Never Expire）」のものも含めて非準拠と判定させると、 今後作成される分も含めて継続的に検出できる。
• さらに自動修復（remediation）としてSSM Automationランブック（logs:PutRetentionPolicyを呼び出す）を紐づければ、 非準拠を検知するたびに自動で保持期間90日へ是正され、新規作成分にも継続的に効く運用が実現する。
• ⚠️ここでAWS Configの管理ルール cw-loggroup-retention-period-check は使えない。 このルールは「保持期間が MinRetentionTime（既定365日）未満なら非準拠」という 最低保持期間を保証する向きの判定であり、公式ドキュメントに 「保持設定が『失効しない（Never expire）』のロググループはCOMPLIANTと判定される」と明記されている。 つまり本問の非準拠（Never Expire群）を1件も検出できない。
• 単発のCLIスクリプトによる一括設定は既存分の是正にはなるが、継続的なガバナンス（今後作られるロググループへの適用）を担保できない。

ログファイル検証を有効化すると、CloudTrailは配信先S3バケットへログファイルを配信するたびに、 そのログファイルのSHA-256ハッシュを記録した「ダイジェストファイル」を1時間ごとに生成する。

• 各ダイジェストファイルには直前のダイジェストファイルのハッシュ値も含まれ、ハッシュチェーンを形成する。 これにより、ログファイルまたはダイジェストファイル自体が削除・改ざん・置換された場合に検知可能になる。
• 検証は aws cloudtrail validate-logs --trail-arn <ARN> --start-time <time> のようにCLIで実行し、 指定期間のログファイル群が改ざんされていないかを機械的に確認できる。

なお、ログファイル検証はあくまで「改ざん・削除の検知」の仕組みであり、ログの暗号化はSSE-S3/SSE-KMSという別機能で提供される点、 また証跡自体の削除・無効化を防ぐものではない点に注意する。

AWS Organizationsの組織証跡（organization trail）を使うと、管理アカウント（またはCloudTrail用の委任管理者アカウント）から 「組織内の全アカウントに証跡を適用する」オプションを有効にして証跡を作成できる。

• これにより各メンバーアカウントに自動的に同じ証跡が作成され、すべてのログが管理アカウント側の指定S3バケットへ集約される。
• メンバーアカウントの管理者は、その組織証跡を無効化・削除・変更できない（参照のみ可能）。組織証跡の管理権限は管理アカウント（または委任管理者）に限定される。
• これに対し、各アカウントに個別の証跡を手動作成する方式では、各アカウントの管理者がその証跡自体を無効化・削除できてしまうため、 「管理者であっても無効化できない」という要件を満たさない。

VPC Flow Logsは、ENI単位で発生する通信のACCEPT/REJECTの記録（送信元/宛先IP・ポート・プロトコル・パケット数等）を出力する機能である。 配信先をCloudWatch Logsに設定しておけば、CloudWatch Logs Insightsで filter action = "REJECT" のようなクエリを即座に実行し、直近数分間の拒否パターンを素早く洗い出せる。

• REJECTの記録から、どのセキュリティグループ／ネットワークACLの設定変更が影響したかを絞り込む手がかりが得られる （Flow Logs自体はどのルールが拒否したかまでは明示しないが、拒否された通信の特定には直結する）。
• 配信先をS3にした場合はAthenaでの分析が定石だが、Athenaはテーブル定義・パーティション設定が前提となり、 「今すぐ数分単位で確認したい」という即時性の要件には、CloudWatch Logs Insightsの方が適している。

CloudTrailのイベントには管理イベント（management events）とデータイベント（data events）の2種類があり、 証跡はデフォルトで管理イベントのみを記録する。

• 管理イベントは、バケットの作成・削除・バケットポリシー変更などコントロールプレーン操作が中心で、 個々のオブジェクトに対するGetObject/PutObjectのようなデータプレーン操作は含まれない。
• オブジェクトレベルの操作を監査するには、証跡の高度なイベントセレクタ（advanced event selectors）でS3データイベントを明示的に有効化し、 対象バケット（または「すべてのS3バケット」）を指定する必要がある。
• データイベントは記録量が多くなりがちで管理イベントとは別料金が発生するため、対象を必要なバケットに絞ることがコスト最適化の観点でも推奨される。

統合CloudWatchエージェント（unified CloudWatch agent）は、旧来のCloudWatch Logsエージェント（awslogs、ログ収集専用でレガシー扱い）を置き換える 形で提供されており、1つのエージェントでログファイルの収集とOSレベルのカスタムメトリクス（メモリ使用率・ディスク使用率など、EC2のデフォルトメトリクスに含まれない項目） の両方を1つの設定ファイルで扱える。

• EC2インスタンスにCloudWatchエージェント用のIAMロール（CloudWatchAgentServerPolicy等の権限）を付与する。
• エージェントの設定ファイル（JSON）で、収集するログファイルパスとロググループ名、収集するメトリクス項目（mem_used_percent等）を1箇所に記述する。
• 結果として、ログはCloudWatch Logsへ、メトリクスはCloudWatchカスタムメトリクスへ、それぞれ同じエージェントプロセスから送信される。

CloudTrail Insightsは、証跡に記録されるAPI呼び出しのパターンについて、 通常時のベースラインから統計的に逸脱した異常（例：リソースのプロビジョニング数の急増、エラー率の急上昇）を自動検出する機能である。 検出できる種類は呼び出し量（API call rate）とエラー率（API error rate）の2つで、必要な記録設定はこの2つで異なる。

• 呼び出し量（API call rate）は書き込み（write）系イベントの記録が必要だが、 エラー率（API error rate）は読み取り（read）または書き込み（write）のいずれかを記録していればよい。 「Insightsは書き込み専用イベントでしか動かない」というのは呼び出し量側の条件であり、エラー率には当てはまらない。
• 対象は長らく管理イベントのみだったが、2025年11月20日にデータイベント向けのInsightsが提供開始され、管理イベント専用ではなくなった （データイベントのInsightsは証跡でのみ対応し、イベントデータストアでは利用できない）。
• Insightsは証跡ごとに明示的に有効化する必要があり、有効化していない証跡では動作しない（分析されたイベント数に応じた追加課金が発生する）。
• 検出された異常はInsightイベントとして証跡の配信先S3バケットに書き込まれ、CloudTrailコンソールの「Insights」タブでも確認できる。
• Insightsは正常時の呼び出しパターンを継続的に学習してベースラインを構築し、そこから外れた挙動を検知する仕組みであり、 特定のAPIコールを事前にルールとして登録する必要はない（あらかじめ閾値を手動設定する仕組みではない）。

CloudWatch Logsのクロスアカウントサブスクリプションを使うと、複数アカウントのロググループから単一の中央アカウントの配信先へリアルタイムに集約できる。

• まず中央（監視）アカウント側で PutDestination によりCloudWatch Logsの「送信先（destination）」リソースを作成し、 対象のKinesis Data Streamを紐づける。この送信先にはCloudWatch LogsサービスがKinesisへ書き込むためのIAMロール（信頼ポリシーでlogs.amazonaws.comを許可）を関連付ける。
• 次にPutDestinationPolicyで、この送信先に対して各メンバーアカウントのプリンシパルからのlogs:PutSubscriptionFilterを許可するアクセスポリシーをアタッチする。
• 最後に各メンバーアカウント側で、対象ロググループにサブスクリプションフィルタを作成し、配信先ARNとして中央アカウントの送信先ARNを指定する。

この3ステップにより、10アカウント分のログをそれぞれ個別にエクスポート・転送するスクリプトを書かずに、リアルタイムのクロスアカウント集約が実現できる。