AWS の可観測性とガバナンス：CloudWatch、EventBridge、CloudTrail、Config

CloudWatch メトリクスの役割

Amazon CloudWatch は AWS サービス（およびカスタムソース）のメトリクスを収集する。各メトリクスには名前がある（CPUUtilization、NetworkIn など、多くは自明）。メトリクスの傾向はトラブルシューティングとキャパシティ判断に使う。

構造

Namespace — メトリクスをグループ化（例：AWS/EC2、AWS/EBS、サービス固有の名前空間）。
Dimensions — 系列を識別する属性（例：InstanceId、AutoScalingGroupName、環境タグ）。メトリクスあたり最大 30 次元（コースより）。
Timestamp — 各データポイントにタイムスタンプ。

コンソール： CloudWatch → Metrics → All metrics → namespace でブラウズし Region、リソース、dimension でフィルタ。

異常検知

CloudWatch は履歴メトリクスからベースラインを機械学習で学習し、期待帯から外れた値を異常としてフラグできる。

静的しきい値だけでなく異常検知でアラームを作成。
初期データが代表的でない期間（メンテナンス、インシデント）を学習から除外できる。

EC2：基本モニタリングと詳細モニタリング

デフォルト（基本）： EC2 のハイパーバイザメトリクスは 5 分粒度（無料）。
詳細モニタリング（有料オプション）： インスタンスは 1 分粒度。

詳細を有効にする理由： 変化への反応を速く；それらのメトリクスに依存するポリシーでは Auto Scaling グループがスケールアウト/インを早く判断しやすい。

ギャップ： デフォルトの EC2 メトリクスにはメモリ（RAM）は含まれない — カスタムメトリクスとして公開（または CloudWatch エージェント / スクリプト）。

カスタムメトリクス（`PutMetricData`）

PutMetricData API（CLI、SDK、内部的には CloudWatch 統合エージェント）で独自のnamespace、メトリクス名、値、単位、dimensions（例：InstanceId、InstanceType、Environment）を公開する。

解像度（ストレージ解像度）

標準解像度： データポイントは 1 分（60 秒）まで細かく。
高解像度： 1、5、10、30 秒ごとの送信を許可（バーストや細かいワークロード — 現在の API ドキュメントでパラメータ名を確認）。

タイムスタンプ（試験で出やすい）

CloudWatch はメトリクスのタイムスタンプを最大 2 週間過去または最大 2 時間未来まで拒否せず受け付ける。

含意： ホスト時刻（NTP ずれ）がずれているとグラフ上でメトリクスがずれて見える。正確な時系列が要るならインスタンスの時刻同期を保つ。

ワークフローパターン

EC2（または Lambda など）上の処理が RAM、ディスク、ビジネス KPI、ログイン数などを計測。
スケジュール（cron、systemd タイマー、エージェント）で PutMetricData を呼ぶ。
新しいメトリクスは All metrics 上のカスタム namespace にdimensions付きで表示される。

CloudWatch 統合エージェントは PutMetricData（および関連 API）で標準・カスタムメトリクスを定期的にプッシュする。

ダッシュボード

クロスリージョン・クロスアカウント： 1 つのダッシュボードに複数 Region と複数 AWS アカウント由来のメトリクスのウィジェットを載せられる（試験のハイライト）。
タイムゾーン、時間範囲、自動更新を設定；AWS アカウントを持たないユーザーとも共有（共有リンク / 埋め込み — 最新のコンソールオプションに従う）。
料金（コースの枠）： 3 ダッシュボードまで 50 メトリクスまで無料；追加ダッシュボードは月額課金（料金確認）。
自動ダッシュボード： サービス（例：Auto Scaling）のスターターをリソースグループでフィルタして生成。
カスタムダッシュボード： 折れ線、積み上げエリア、数値、テキスト、アラーム状態、Logs Insights 結果テーブルなど。ウィジェットは相関のため同じグローバル時間範囲を共有。
メトリクスウィジェット追加時は Region を明示し、Frankfurt と us-east-1 の系列を並べられる。

CloudWatch Logs

モデル

Log group — 多くはアプリケーションまたは連携ごとに 1 つ。
Log stream — そのアプリのインスタンス：コンテナ、ホスト、Lambda 呼び出し、stdout/stderr ペアなど。
Retention — 無期限、または 1 日～10 年（コンソールでは 120 か月表示も — 同趣旨）。

取り込み元（例）

SDK、Unified Agent（推奨；旧 Logs Agent は非推奨）、Elastic Beanstalk、ECS タスク定義、Lambda（デフォルト）、VPC Flow Logs、API Gateway、CloudTrail（設定経由）、Route 53 クエリログ、RDS / Aurora エクスポートなど。

暗号化

ログはデフォルトで暗号化；ロググループごとに KMS CMK を任意指定。

メトリクスフィルタ

パターンを定義（例：installing や ERROR にマッチする行をカウント）。マッチ時に選択した namespace の CloudWatch メトリクスを増分 → そのメトリクスをグラフ化しアラーム（例：エラー行が多すぎる → SNS）。

サブスクリプションフィルタ（リアルタイム）

マッチしたログイベントを Kinesis Data Streams、Kinesis Data Firehose、または Lambda にストリーム。フィルタパターンでグループから出すイベントを選択。ほぼリアルタイムの分析、Firehose 経由の S3 アーカイブ、OpenSearch 取り込み、カスタム処理。

制限（コース）： ロググループあたり最大 2 つのサブスクリプションフィルタ — 最新クォータを確認。

S3 へのバッチエクスポート

CreateExportTask で時間範囲のログを S3 にエクスポート — バッチ、最大 ~12 時間かかることがある；リアルタイムではない。

クロスアカウントログ集約（パターン）

送信アカウント：ロググループのサブスクリプションフィルタ → 受信ストリームを表す宛先オブジェクト。受信側： 宛先のリソースポリシー + 送信側が引き受け可能な IAM ロール（Kinesis へ PutRecord）。多アカウント/多 Region のログを 1 パイプライン（例：Kinesis → Firehose → S3）に集約。

CloudWatch Logs Insights

履歴ログ向けの専用クエリ言語 — ライブ tail エンジンではない；実行時に走る。
フィールドを自動検出；filter、stats、sort、limit、parse をサポート。
クエリ保存、ダッシュボードへの可視化、結果エクスポート。
複数ロググループを一度にクエリ可能（設定されている場合クロスアカウントも）。

コンソールにサンプルクエリ（例：Lambda 遅延統計、VPC Flow Logs のトップ IP）。

Live Tail

Live Tail はコンソールでマッチイベントをほぼリアルタイムにストリームしデバッグに使う（任意のログストリームフィルタ + パターン）。料金： コースでは 1 日あたりの無料時間に制限 — 課金を避けるためセッション終了時に停止。

ログのデータ保護

ロググループのデータ保護ポリシーが機密データを検出しマスキング（100+ 組み込み識別子：メール、クレジットカード、SSN、認証情報など）— ML；カスタム識別子も可。

logs:Unmask（または同等）がないプリンシパルには Insights、メトリクスフィルタ、サブスクリプション配信でもマスク。
別ロググループ、S3、Firehose への任意監査配信；機密検知時にメトリクス LogEventsWithFindings → アラーム → SNS。

アラーム

状態

OK — 条件未違反。
ALARM — しきい値またはルール発火；アクション実行。
INSUFFICIENT_DATA — 評価に十分なサンプルなし。

評価

Period がウィンドウ；統計（Average、Maximum、SampleCount など）。高解像度カスタムメトリクスと連携（例：10 秒、30 秒、または 60 秒の倍数 — メトリクス解像度に合わせる）。

しきい値タイプ： 静的または異常検知帯。

アクション

EC2： Stop、Terminate、Reboot、Recover。
Auto Scaling： スケールイン / アウト。
SNS → メール、チャット、Lambda 自動化など。

複合アラーム

他のアラームを AND / OR で結合しノイズ削減（例：CPU 高かつネットワーク低のときだけ通知）。

EC2 ステータスチェックアラーム → リカバリ

インスタンスステータス、システムステータス、または接続 EBS の健全性のアラーム。Recovery は新しいハードウェアへインスタンスを移しプライマリ/セカンダリ/elastic IP、インスタンスメタデータ、配置グループ（対応インスタンスタイプのみ）を保持。

ログメトリクスフィルタ → アラーム

チェーン：ログ → メトリクスフィルタ → メトリクス → アラーム → SNS。

アラームのテスト

set-alarm-state（CLI/API）で OK / ALARM / INSUFFICIENT_DATA を強制し、実負荷を待たず SNS や EC2 アクションを検証（コースデモ：強制 ALARM でインスタンス終了）。

CloudWatch Synthetics（Canaries）

ヘッドレススクリプト（Node.js または Python）が顧客ジャーニーを模倣（HTTP/API チェック、ヘッドレス Chrome の UI フロー）。

1 回またはスケジュール実行；遅延、HAR、スクリーンショットを取得。
Blueprints： ハートビート URL、REST API CRUD、リンク切れクローラ、ベースラインとの視覚 diff、Canary Recorder（ブラウザ記録 → 生成スクリプト）、GUI ワークフロービルダー。
失敗時 → アラーム → 自動化（コース例：Lambda が健全な Region へ Route 53 を更新）。

VPC 内の Canaries

プライベートターゲットに当てるには VPC で DNS resolution と DNS hostnames を有効化。Canary 結果は引き続き CloudWatch へ。

パブリック経路： プライベートサブネット + 外向き NAT ゲートウェイで CloudWatch API 呼び出し。
プライベート AWS 経路： CloudWatch の VPC インターフェースエンドポイント（多くは成果物用 S3 ゲートウェイエンドポイントも）でトラフィックを AWS ネットワーク内に。

CloudWatch Container Insights

ECS、Fargate、EKS、ROSA（AWS 上の OpenShift）向けにメトリクスとログを収集。基本有効化にカスタムサイドカーは不要。

デフォルトでクラスタとサービスレベルのメトリクス。
Enhanced 可視性で タスク / pod / コンテナ粒度の CPU、メモリ、ネットワーク、スロットルの深いトラブルシューティング。

アカウントレベルまたはクラスタ作成時に有効化。

CloudWatch Internet Monitor

Internet Monitor は AWS のグローバルネットワークテレメトリを使い、インターネットの状態（都市、ASN、AWS エッジ/PoP の健全性）があなたのワークロードとエンドユーザーにどう影響するかを示すサービス＋ダッシュボード。

グローバルトラフィックパターンとヘルスイベント；可能な範囲で遅延と体験改善の推奨。
テレメトリは CloudWatch Metrics と CloudWatch Logs に現れ；グローバルヘルスイベントは EventBridge へ送りアラートと自動化に使える。

CloudWatch Network Synthetic Monitor

オンプレミスと AWS のハイブリッドリンク（Direct Connect またはサイト間 VPN）向けに、Network Synthetic Monitor が ICMP または TCP で IPv4 パスをプローブ — 側にエージェント設置なし。

パケット損失、遅延、ジッタを表し企業 ↔ クラウド経路の劣化を捕捉。
結果は CloudWatch Metrics に公開しダッシュボードとアラームに利用。

Amazon EventBridge（旧 CloudWatch Events）

EventBridge はかつて CloudWatch Events と呼ばれたものの現名 — 試験や新しいドキュメントでは EventBridge を想定。

コアモデル

ソースがイベント（JSON：detail-type、source、account、time、region、resources、detail など）を発行。
イベントバス上のルールがイベントパターンまたはスケジュール（cron / rate）にマッチ。
マッチしたイベントがターゲットを呼び出す（多くはルールあたり複数、IAM 付き）。

パターン例： EC2 ステート変更（例：shutting-down、terminated）、S3 オブジェクト作成、IAM ルートのコンソールサインイン、Trusted Advisor の所見。

ターゲット例： Lambda、SQS、SNS、Kinesis Data Streams、Step Functions、ECS タスク、AWS Batch ジョブ、CodePipeline / CodeBuild、SSM Automation、EC2 API アクション（start/stop/reboot）、API Gateway、CloudWatch Logs（ログターゲットとして）、その他。

CloudTrail → EventBridge：ほぼ任意の API 呼び出しに反応

CloudTrail が記録する管理（および設定された）API 呼び出しもデフォルトイベントバス上のイベントとして現れるため、特定の API をイベントパターンでマッチさせ SNS、Lambda などへ送れる。

例（コース）：

目的	API / サービス	パターンの考え方
DynamoDB テーブル削除のアラート	`DeleteTable`（DynamoDB）	その呼び出しの `eventName` / `eventSource` をマッチ → SNS。
ロール引き受けのアラート	`AssumeRole`（STS）	sts.amazonaws.com の `eventName` / `eventSource` をマッチ → SNS。
セキュリティグループ ingress 変更のアラート	`AuthorizeSecurityGroupIngress`（EC2）	その EC2 API をマッチ → SNS。

注意： CloudTrail → EventBridge 経由の配信はリアルタイム自動化ではない — CloudTrail 節の典型的遅延を参照（コース：EventBridge まで約 15 分、S3 へのログファイルは約 5 分程度 — 現在のドキュメントを確認）。

イベントバス

バス	目的
Default	AWS サービスがサービスイベントをここに公開（アカウント・リージョンごとに 1 つ）。
Partner	SaaS 連携（例：Auth0、Zendesk、Datadog — 最新パートナー一覧を確認）がパートナーバスにイベント送信。
Custom	アプリが `PutEvents` であなたのバスに送る；デフォルトモデルと同じルールとターゲット。

クロスアカウント（双方向信頼）：

バス → バス： ソースアカウントのバスでは宛先バスへの events:PutEvents（または同等）をリソースポリシーで許可。宛先アカウントのバスではソースアカウント（例：そのアカウントの root プリンシパル）がそのバスに PutEvents できるようリソースポリシーで許可。送信と受信の両方で明示的に許可が必要。
バス → SQS / SNS / Lambda / API Gateway / Kinesis（リソースポリシー対応ターゲット）：送信側は通常 SendMessage、Publish、Invoke などができる IAM ロールを使用。宛先のリソースポリシーは他アカウント（またはそのロール）にアクションを許可。送信側が実行可能かつ受信側が受け入れるという二重の許可。

アーカイブとリプレイ

バスからすべてまたはフィルタした一部のイベントをアーカイブ；保持は無期限または期間限定。リプレイでアーカイブしたイベントをバスに戻し（例：不具合 Lambda コンシューマ修正後）デバッグと安全な再処理に使う。

Schema Registry

EventBridge がバス上のイベントのスキーマを検出/登録しフィールド形状が分かる；バージョニングとスキーマからのコード生成（バインディング）をサポート。

EventBridge Pipes

Pipes は対応するストリーミング/キューソースを EventBridge 型ターゲットに接続し、任意のフィルタとエンリッチ段階を挟む — ソースから pull したり多ターゲットへ push したりするカスタムコンシューマコードなし。

ソース（例）： DynamoDB Streams、Kinesis Data Streams、Amazon MQ、Amazon MSK、SQS、自己管理 Apache Kafka。

ターゲット（例）： Kinesis Data Firehose、Kinesis Data Streams、EventBridge イベントバス、Amazon Redshift（連携がある場合）、SQS、SNS、API Gateway、ECS タスク、コンソールがサポートするその他 EventBridge ターゲット。

フロー： ソース →（任意）フィルタ →（任意）エンリッチ → ターゲット。

エンリッチは Lambda、Step Functions、API Gateway、EventBridge API destination でペイロードを調整・拡張 — その後エンリッチ済みイベントがターゲットへ。

リトライとデッドレターキュー（DLQ）

ターゲットへの配信が失敗（ダウン、タイムアウト、スロットリングなど）すると、EventBridge はリトライポリシーで再試行：コースのデフォルトは最大ウィンドウ約 24 時間、試行約 185回 — 現在のデフォルトと上限はドキュメントで確認。

リトライ枯渇後、失敗した呼び出しは SQS 実装のデッドレターキューに送り、後で検査と再処理できる。

ターゲットとしての SSM Automation

Systems Manager Automation ドキュメントをルールのターゲットにできる — 例：EC2 Instance State-change → 新規起動インスタンスにソフトウェアを入れる bootstrap 自動化。他の EventBridge と同様：イベントまたはスケジュールで定常自動化をトリガー。

コンソール構成（高レベル）

Rules — event pattern vs schedule（コンソールは多くの繰り返しスケジュールに EventBridge Scheduler を推奨として強調）。
Pipes — 管理された source → filter → enrich → target（上記）。
Event buses — デフォルト、custom、パートナー関連付け。
Partner event sources — サードパーティ → パートナーバス。
API destinations — ルールから OAuth/API キー付きの外部 HTTPS API を呼び出し。
Schemas — AWS イベントスキーマまたはカスタムレジストリを参照。

イベントパターンフィルタ（コンテンツフィルタ）

単純な等価以外に prefix / suffix、anything-but、数値比較（例：> 0）、IP マッチ（CIDR）、exists（フィールド必須）、equals-ignore-case、detail 上のネスト組み合わせ（例：S3 detail-type: Object Created + detail.bucket.name + detail.object.key suffix .png + 送信元 IP）。

コンソール（またはドキュメント）のサンプルイベントで正確なフィールド名（instance-id、state など）をコピー。

入力トランスフォーマ

各ターゲットごとにイベントを任意で整形：

Input path — イベントから最大約 100 の変数への JSONPath 風マッピング（例：<timestamp> ← $.time、<instance> ← $.detail.instance-id）。
Input template — その変数を参照するターゲットへ送る文字列または JSON 本文。

用途： 下流が完全な EventBridge 封筒ではなく小さな固定 JSON（例：CloudWatch Logs ターゲット）を欲する場合。保存前にルールウィザードでサンプルイベントでテスト。

実践パターン（コース）

EC2 Instance State-change Notification で detail.state が shutting-down または terminated → SNS トピック（コンソールが呼び出しロールを作成可能）。
Schedule（または Scheduler）rate 1 時間 → Lambda を呼び出し（または ECS、Firehose など）。
アプリケーションイベント用 custom bus；不要時はルールを無効化し課金とノイズを止める。

Service Quotas

Service Quotas はアカウントのサービス別上限を一覧（各クォータが調整可能かどうかも）。コンソールに適用値、使用量（利用可能な場合）、Lambda 同時実行などのメトリクスグラフ。

クォータ引き上げ依頼 — 小さな増加は自動承認；大きい依頼は Support 経由で待ち。
クォータの CloudWatch アラーム — 例：Lambda 同時実行の適用クォータの 80% で通知し、スロットリング前にオペレータが上限を引き上げ。SNS などアクションをアラームから設定。

Trusted Advisor との比較： Trusted Advisor はサービス上限チェック（コースの話では約 50）を公開し CloudWatch アラームに流せるが、すべてのクォータを閲覧・監視する専用の場所は Service Quotas — 幅にはクォータネイティブのアラームを優先。

AWS CloudTrail

CloudTrail はガバナンス、コンプライアンス、監査のため API 活動とコンソール操作を記録。アカウントレベルではデフォルトでオン（Event history の挙動はドキュメント通り）。

記録されるもの

コンソール、CLI、SDK、およびユーザーに代わって動く AWS サービスからの呼び出し。
コンソールの Event history は直近の活動を表示（コース：Event history ビューで管理イベント約 90 日 — 現在の挙動を確認）。

トレイルと長期保管

トレイルを作成しイベントを S3（任意で CloudWatch Logs）に配信。トレイルは単一リージョンまたはマルチリージョンで履歴を一元化（例：組織用バケット 1 つ）。デフォルトのコンソール保持を超えた先は S3（多くは Athena でクエリ）が耐久ストア。

フォレンジック例： 誰が EC2 インスタンスを終了したか — CloudTrail で TerminateInstances（または同等）記録からプリンシパル、時刻、リージョン、リクエストパラメータを調べる。

イベントカテゴリ

タイプ	内容	トレイルのデフォルト
Management events	リソース上のコントロールプレーンの変更と読み取り（CreateSubnet、AttachRolePolicy、DescribeInstances など）。多くはコスト/ノイズで read と write に分割。	トレイルではデフォルトで記録（read/write は設定可能）。
Data events	高ボリュームデータプレーン — 例：S3 オブジェクト API（GetObject、PutObject、DeleteObject）、Lambda `Invoke`。	デフォルトオフ（高コスト/ノイズ）；バケット/関数ごとに read/write フィルタで選択的に有効。
Insight events	CloudTrail Insights の出力（下記）。	Insights 有効かつ課金時のみ。

CloudTrail Insights（有料アドオン）

Insights は管理活動から通常パターンを学習し、異常を検知すると Insight events を発行（例：異常なプロビジョニング、IAM のバースト、サービス上限圧力、定常変更の欠落）。

配信：CloudTrail コンソール、トレイルに沿った S3 配信、自動化用 EventBridge イベント（例：疑わしい活動への SNS メール）。

ログファイル整合性（ダイジェスト）

S3 に書き込むトレイルでは log file validation を有効化。CloudTrail が定期的にダイジェストファイルを書き（コース：約 1 時間ごと）、そのウィンドウのログファイルを列挙し各オブジェクトの SHA-256 ハッシュを含める。ダイジェストは生ログとは別プレフィックスの同じバケット内。

用途： 配信済みログファイルのハッシュを再計算しダイジェストと比較 — 一致すれば配信後にファイルが改ざんまたは置換されていない（強いコンプライアンスの話）。

バケットを保護： バケットポリシー、バージョニング、MFA Delete（該当時）、暗号化、S3 Object Lock（不変性） — 監査データが静かに変えられないよう多層防御。CloudTrail とトレイル設定も IAM でロックし、不正プリンシパルがログを止めたり向き先を変えたりできないようにする。

EventBridge と S3 配信の遅延

CloudTrail 駆動の自動化はほぼリアルタイムであり同期ではないとみなす：コースの目安は API 呼び出しから EventBridge まで約 15 分、S3 へのログファイルは約 5 分 — 現在の AWS ドキュメントを確認。

AWS Organizations トレイル

management アカウントから作成した組織トレイルはすべてのメンバーアカウントの API 活動を中央 S3 バケット（任意で Logs）に記録できる。同じトレイル名が各アカウントに表示；メンバーアカウントはトレイルの存在を見られるが組織トレイルを削除・変更できない — 中央監査とメンバー層での改ざん耐性に有利。

実務メモ

コンソール Event history は操作から数分遅れることがある（例：TerminateInstances は更新後しばらくで表示）。

AWS Config

AWS Config はサポートリソースの設定を継続記録しルールに対して評価し、コンプライアンスとドリフトの可視化を行う。「セキュリティグループで SSH が 0.0.0.0/0 に開いているか？」「S3 バケットはパブリックか？」「この ALB リスナー / 証明書は時系列でどう変わったか？」といった問いに答える。

リージョン単位サービス — リージョンごとに有効化と課金；集約（下記）でクロスリージョン/クロスアカウントビュー。
アクションをブロックしない — Config は検知的であり IAM、SCP、予防的コントロールの代替ではない。
リソースごとの履歴タイムライン：設定バージョン、時系列のコンプライアンス、どの API を誰が呼んだかへの CloudTrail リンク（例：AuthorizeSecurityGroupIngress、RevokeSecurityGroupIngress）。

レコーダーと配信

範囲： リージョン内のサポートすべてのタイプ、または選択したリソースタイプのみ（安い）。
グローバルリソース： 任意で IAM ユーザー、グループ、ロール、カスタママネージドポリシーを含める（指定した 1 リージョンに保存 — コストへの影響）。
サービスリンクロールを使用；設定履歴は S3 へ配信（任意プレフィックス）。すべての設定・コンプライアンス通知用の任意 SNS トピック（幅広いファイアホース — サブセットだけ欲しければ subscription filters と組み合わせ）。
料金は使用量ベース（記録された設定アイテムとリージョン内のルール評価あたり） — 広い記録ではコストが急増しうる；現在の料金を確認。

ルール

AWS 管理ルール — 大きなカタログ（コース 75+；数は変化）。
カスタムルール — Lambda で評価を実装（例：「すべての EBS ボリュームは gp2」「dev の EC2 はすべて t2.micro」）。
トリガー： 設定変更および/または定期スケジュール（例：N 時間ごと再スキャン）。

修復（SSM Automation）

非準拠は修復を付けない限り自動修正されない：多くは SSM Automation ドキュメント（AWS 管理またはカスタム、Lambda を呼ぶドキュメント含む）。

例（コース）： 非準拠セキュリティグループに AWS-DisableIncomingSSHOnPort22；バケットログがオフなら AWS-ConfigureS3BucketLogging。
手動 vs 自動修復；実行後も非準拠なら再試行（例：最大約 5 回）を設定。

通知

非準拠や変更の Config イベントに対する EventBridge ルールで選択的自動化。
SNS を Config から直接幅広く通知；filter policies / SNS サブスクリプションで絞る。

アグリゲーター

アグリゲーターは中央「アグリゲーター」アカウントにだけ作成 — 各ソースアカウントすべてではない。アグリゲーターは承認されたアカウントとリージョンからインベントリとコンプライアンスを1つのコンソールビューに引き出す。

AWS Organizations あり： management アカウントから作成 — 組織横断の認可が簡素化（コース：自動信頼パス）。
Organizations なし： 各ソースアカウントがアグリゲーターアカウントにデータ収集を認可する必要がある。
ルールのデプロイは依然アカウント/リージョンごと — アグリゲーターはルール定義を中央集約しない；同じルールを全体に展開するには CloudFormation StackSets（または類似）を使う。

Settings 連携

コンソール Settings で SNS と EventBridge/CloudWatch Events ルールを接続し、特定のルールやコンプライアンス遷移だけが下流に通知されるようにできる。

CloudWatch vs CloudTrail vs Config

観点	CloudWatch	CloudTrail	Config
主な仕事	性能と運用 — メトリクス、アラーム、ログ、ダッシュボード。	誰が何をしたか — API とコンソールの監査。	何が設定されているか — リソースの形と望ましいルールの比較；コンプライアンスタイムライン。
ELB の例	リクエスト数、HTTP エラー、遅延、クロスリージョンダッシュボード。	`ModifyListener`、`AuthorizeSecurityGroupIngress`、証明書変更 — アクターと時刻。	リスナーの TLS ポリシー、証明書アタッチ、セキュリティグループアタッチ — 準拠可否、変更の履歴。

三者は補完関係：健全性とキャパシティは CloudWatch、設定ガバナンスは Config、説明責任は CloudTrail。

要点

メトリクス：namespace、dimensions（≤ 30）、任意のダッシュボード；EC2 5 分 vs 詳細 1 分；RAM = カスタム；PutMetricData + タイムスタンプの癖（2 週間 / 2 時間）。
異常検知 = ML 帯 + 任意のアラーム；悪い学習ウィンドウを除外。
ダッシュボード = マルチリージョン、マルチアカウント、共有時間範囲、自動またはカスタムウィジェット；無料枠後はダッシュボード単位のコスト。
ログ： グループ / ストリーム、保持、KMS；Lambda、VPC Flow Logs、API GW、CloudTrail などから取り込み；メトリクスフィルタ → メトリクス → アラーム；Insights = 履歴ログのクエリ；デバッグは Live Tail；データ保護 = マスク + 監査 + LogEventsWithFindings。
エクスポート（CreateExportTask）= S3 へのバッチ（遅い）；サブスクリプションフィルタ = Kinesis / Firehose / Lambda へのリアルタイム；クロスアカウントは宛先 + ポリシー + IAM。
アラーム： OK / ALARM / INSUFFICIENT_DATA；ターゲット EC2、ASG、SNS；複合で AND/OR；ステータスチェック + リカバリ；テストは set-alarm-state。
Synthetics： Node/Python のスケジュール + Chrome Canary；プライベート監視 + プライベートテレメトリは VPC + NAT またはインターフェースエンドポイント。
Container Insights は ECS/EKS/Fargate/ROSA；enhanced でタスク/コンテナ詳細。
Internet Monitor — インターネットのグローバル健全性とあなたのアプリ；メトリクス / ログ + EventBridge ヘルスイベント；UX 推奨。
Network Synthetic Monitor — DX / VPN 経路；ICMP/TCP IPv4、エージェントなし；損失 / 遅延 / ジッタ → メトリクス。
EventBridge（旧CloudWatch Events）：default / partner / custom バス；ルール（パターンまたはスケジュール）；ターゲットに SSM Automation；CloudTrail 由来の API パターン（DeleteTable、STS AssumeRole、AuthorizeSecurityGroupIngress など）→ SNS/Lambda（リアルタイムではない）；アーカイブ + リプレイ；Schema Registry；クロスアカウント = バス↔バスは送信側と受信側の両方のポリシー、または SQS/SNS/Lambda/API GW/Kinesis は IAM ロール + リソースポリシー；フィルタ；入力トランスフォーマ；Pipes = コードなし ソース（DynamoDB streams、Kinesis、MQ、MSK、SQS、Kafka）→ 任意 フィルタ / エンリッチ（Lambda、Step Functions、API GW、API destination）→ ターゲット；リトライ + 失敗配信の SQS DLQ（デフォルト確認）。
Service Quotas — 上限の閲覧、引き上げ依頼、クォータ使用率の CloudWatch アラーム（例：Lambda 同時実行）；Trusted Advisor の上限チェックだけより幅がある。
CloudTrail — API/コンソール監査；Event history 管理イベント~90 日；トレイル → S3 / Logs（マルチリージョン / 組織トレイル）；management vs data（S3 オブジェクト、Lambda Invoke）vs Insights；ダイジェスト + SHA-256 でログ整合性；バケット + トレイルを IAM/Object Lock/バージョニングで保護；長期は S3 + Athena；Insights → S3 + EventBridge；組織トレイル — メンバーはトレイル読み取りのみ；EventBridge 遅延は数分（同期ではない）。
Config — リージョンごとのレコーダー + ルール（管理 + Lambda カスタム）；変更または定期評価；タイムライン + CloudTrail リンク；S3 履歴 + Athena；SSM ドキュメントによる修復（例：SSH 無効、バケットログ有効）；1つの中央アカウントのアグリゲーター（Org vs 手動認可）；ルール展開は StackSets；EventBridge / SNS 通知；API 呼び出しを拒否しない。
CloudWatch vs CloudTrail vs Config — メトリクス/運用 vs 監査 vs 設定コンプライアンス（比較表参照）。

🌐 Claudeによる翻訳