テレメトリ有効化ルールの使用
テレメトリ有効化ルールを作成することで、AWS リソースのテレメトリ収集を自動的に設定できます。ルールは、組織またはアカウント全体でテレメトリ収集を標準化し、一貫したモニタリングカバレッジを確保するのに役立ちます。
有効化ルールと AWS Config の統合
CloudWatch のテレメトリ監査および設定は AWS Config と統合され、有効化ルールに一致するリソースを自動的に検出し、それをテレメトリデータ収集に適用します。有効化ルールを作成すると、テレメトリ設定によって対応する AWS Config レコーダーが作成されます。このレコーダーには、有効化ルールで定義した特定のリソースタイプの設定項目が含まれます。
Amazon CloudWatch では、AWS Config の Internal サービスにリンクされたレコーダーを使用します。CloudWatch が Internal サービスにリンクされたレコーダーの一部として使用する CI には課金されません。
注記
有効化ルールを作成すると、有効化ルールの範囲に基づいてオンにする前に、AWS Config Configuration Items (CI) を介して非準拠のリソース (テレメトリが有効になっていないリソース) が検出されます。場合によっては、リソースの最初の検出が完了するまでに最大 24 時間かかることがあります。
テレメトリ設定では、AWS Config を使用して以下を実行します。
-
組織またはアカウント全体でリソースを検出する
-
テレメトリ設定の変更を追跡する
有効化ルールの動作について
テレメトリ設定は、ルールを評価および適用する際に特定のパターンに従います。
有効化ルールは、階層パターンに従って評価されます。最初に組織ルールが評価され、次に組織単位 (OU) に適用されるルール、最後に個々のアカウントに適用されるルールが評価されます。組織レベルのルールは、組織に必要なベースラインテレメトリを提供します。OU およびアカウントレベルのルールによって追加のテレメトリデータを収集することはできますが、収集するテレメトリデータを減らすことはできません。このようなルールが作成された場合、ルールの競合が発生します。
各スコープ (組織、OU、またはアカウント) 内で、ルールはリソースタイプ、テレメトリタイプ、および宛先設定に基づいて一意性を維持する必要があります。ルールが重複すると、競合例外がトリガーされます。例えば CloudWatch への VPC フローログに関する組織レベルのルールと VPC フローログに関する OU レベルのルールが存在するなど、同じルールが異なるスコープに存在する場合は、階層内で上位のルールが適用されます。ただし、複数のルールが競合している場合は、いずれのルールも適用されません。
VPC フローログの場合、テレメトリ設定は、ルールのスコープに一致するリソースに対してのみ新しいフローログを作成します。現在のルールパラメータと異なっている場合でも、以前に確立された VPC フローログを削除したり、影響を及ぼしたりすることはありません。CloudWatch Logs の場合、既存のロググループは、リソースパターンと一致している場合に限り維持されます。
有効化ルールを更新した場合、そのルールに一致する新しいリソースのみが更新された設定を採用し、既存のリソースについては既存のテレメトリ設定が変更されずに残ります。テレメトリデータの手動削除によってリソースが既存のルールに準拠しなくなった場合、そのリソースが準拠状態に戻ると新しい有効化ルールが適用されます。
テレメトリ有効化ルールの作成
テレメトリ有効化ルールを作成する際には、以下を指定します。
-
ルールのスコープ (組織、組織単位、またはアカウント)
-
ルールが適用されるリソースタイプ
-
有効化するテレメトリタイプ (メトリクス、ログ、またはトレース)
-
ルールの対象となるリソースをフィルタリングするためのオプションのタグ
テレメトリ有効化ルールを作成する手順
CloudWatch コンソールの https://console.aws.amazon.com/cloudwatch/
を開いてください。 -
ナビゲーションペインで、[テレメトリの設定] を選択します。
-
[有効化ルール] タブを選択します。
-
[ルールの追加] を選択します。
-
[ルール名] にルールの名前を入力します。
-
[ルールのスコープ] で、以下のいずれかを選択します。
-
[組織] - ルールは AWS Organizations 全体に適用されます。
-
[組織単位] - ルールは特定の OU に適用されます。
-
[アカウント] - ルールは単一のアカウントに適用されます。
-
-
[データソース] で、設定する AWS サービスを選択します。
-
[テレメトリタイプ] で、有効にするテレメトリのタイプを選択します。
-
オプション: タグを追加して、ルールの対象となるリソースをフィルタリングします。
-
[Create rule] を選択してください。
テレメトリルールの管理
ルールを作成した後、それらのルールを編集または削除できます。各ルールの対象となっているリソースを表示したり、ルールのコンプライアンスを監視したりすることもできます。
既存のルールを管理する手順
CloudWatch コンソールの https://console.aws.amazon.com/cloudwatch/
を開いてください。 -
ナビゲーションペインで、[テレメトリの設定] を選択します。
-
[有効化ルール] タブを選択します。
-
ルールを選択して詳細を表示したり、次のいずれかのアクションを選択したりします。
-
[編集] - ルールの設定を変更します。
-
[削除] - ルールを削除します。
-
テレメトリ設定のトラブルシューティング
このセクションでは、テレメトリ設定を使用する際に発生する可能性がある一般的な問題と、その解決方法について説明します。
ルールの競合と解決策
同じリソースに複数のルールが適用された場合、テレメトリ設定は、次の優先順位で競合を解決します。
-
組織レベルのルールがアカウントレベルのルールより優先される
-
より具体的なタグ一致が一般的なルールより優先される
-
競合する複数のルールがあり、いずれのルールも適用されない場合は、まず競合を解決する必要があります。
一般的な問題
- リソースが検出に表示されない
-
以下を確認してください。
-
リソースタイプがサポートされている
-
AWS Config レコーダーが有効になっている
-
適切な IAM アクセス許可がある
-
- 自動的にルールが適用されない
-
以下を確認してください。
-
ルールのスコープ設定
-
タグフィルター
-
注記
有効化ルールを作成すると、有効化ルールの範囲に基づいてオンにする前に、AWS Config Configuration Items (CI) を介して非準拠のリソース (テレメトリが有効になっていないリソース) が検出されます。場合によっては、リソースの最初の検出が完了するまでに最大 24 時間かかることがあります。
サービス固有の考慮事項
- Amazon VPC フローログ
-
フローログの作成時:
-
いずれも指定しない場合はデフォルトのパターン /aws/vpc/vpc-id を使用する
-
お客様が作成した既存のフローログは保持される
-
ルールの更新は新しいフローログにのみ影響する
-
<vpc-id>、<account-id> マクロを使用してロググループを分割できます。
-
CloudWatch は、既に CloudWatch Logs にログを取り込んでいる VPC のフローログを作成しません
-
- Amazon EKS コントロールプレーンのログ記録
-
コントロールプレーンのログ記録を有効にする場合:
-
デフォルトの CloudWatch ロググループパターン /aws/eks/<cluster-name>/cluster を使用します。Amazon EKS は、クラスターごとにロググループを自動的に作成します。
-
ルールの更新は、新しいクラスターにのみ影響するか、スコープ付きログタイプが有効になっていないクラスターにのみ影響します。
-
api, audit, authenticator, controllerManager, scheduler など、特定のログタイプを有効にできます
-
- AWS WAF ウェブ ACL ログ
-
WAF ログを作成する場合:
-
デフォルトの CloudWatch ロググループパターンを使用し、常にプレフィックスとして aws-waf-logs- が付きます
-
ルールの更新は、新しいウェブ ACL または、CloudWatch Logs に対してログ記録が有効になっていない既存のウェブ ACL にのみ影響します。
-
CloudWatch は、既に CloudWatch Logs にログを取り込んでいるウェブ ACL のログを有効にしません
-
- Amazon Route 53 Resolver ログ
-
リゾルバークエリのログ記録を有効にする場合:
-
何も指定されていない場合は、デフォルトの CloudWatch ロググループパターン /aws/route53resolver を使用します
-
CloudWatch は、既に CloudWatch Logs にログを取り込んでいる VPC のリゾルバークエリログを作成しません
-
有効化ルールは、ルールの範囲に基づいて VPC の Route 53 クエリログ記録を設定します。CloudWatch は Route 53 プロファイルと関連設定を検出しません。
-
- NLB アクセスログ
-
アクセスログを有効にする場合:
-
何も指定しない場合、デフォルトの CloudWatch ロググループパターンとプレフィックス /aws/nlb/access-logs を使用します
-
CloudWatch は、既に CloudWatch Logs にログを取り込んでいる NLB のログ配信を有効にしません
-
- Amazon Bedrock AgentCore テレメトリ
-
-
ランタイム、ブラウザツール、コードインタープリタツールなど、使用可能なすべての Bedrock AgentCore プリミティブから出力されるログとトレースの両方を有効にします。テレメトリ設定コンソールエクスペリエンスに従ってログ配信ルールを作成し、続いてトレース配信ルールを作成します。
-
トレース配信ルールを作成すると、トランザクション検索が有効になり、CloudWatch X-Ray がアカウントのマネージドロググループに相関があるトレースを送信できるように追加のアクセス許可ポリシーが作成されます。さらに、X-Ray リソースポリシーが作成され、現在および新しい Bedrock AgentCore プリミティブがアカウントにトレースを配信できるようになります。
-
- サービスにリンクされたチャネルを使用する CloudTrail ログ
-
SLC パスを使用して CloudTrail ログを有効にする場合:
-
マネージド CloudWatch ロググループ aws/cloudtrail/<event-types> を使用します
-
顧客が作成した既存の CloudTrail 証跡転送設定は保持されます
-
CloudWatch 有効化ルールは、サービスにリンクされたチャネルのみを使用してログを取り込みます
-
イベントは、ロググループに設定された保持期間を使用します
-
CloudTrail イベントの場合、有効化ウィザードの一部として、CloudWatch に取り込むイベントタイプを少なくとも 1 つ選択できます。
-
イベントが遅延して配信され (追加理由 DELIVERY_DELAY で示される)、以前に設定した保持期間が短い場合、遅延したイベントを使用できるのが短い保持期間の間のみになる可能性があります。
-
重要: マルチリージョンデプロイの場合: CloudWatch 有効化ルールでは、AWS リージョンごとに個別の設定が必要であり、一部のリージョンではまだ利用できません。包括的なマルチリージョンカバレッジについては、リージョンの可用性が拡大するまで CloudWatch にイベントを送信する CloudTrail 証跡を引き続き使用することを検討してください。
-