

# テレメトリ有効化ルール
<a name="telemetry-config-rules"></a>

テレメトリ有効化ルールを作成することで、AWS リソースのテレメトリ収集を自動的に設定できます。ルールは、組織またはアカウント全体でテレメトリ収集を標準化し、一貫したモニタリングカバレッジを確保するのに役立ちます。

**Topics**
+ [ルールの仕組み](#telemetry-config-rules-behavior)
+ [テレメトリ有効化ルールの作成](#telemetry-config-rules-create)
+ [テレメトリルールの管理](#telemetry-config-rules-manage)
+ [サポートされているデータソース](#telemetry-config-troubleshoot-service)

## ルールの仕組み
<a name="telemetry-config-rules-behavior"></a>

テレメトリ設定は、ルールを評価および適用する際に特定のパターンに従います。

### ルール評価階層
<a name="telemetry-config-rules-hierarchy"></a>

有効化ルールは、階層パターンに従って評価されます。最初に組織ルールが評価され、次に組織単位 (OU) に適用されるルール、最後に個々のアカウントに適用されるルールが評価されます。組織レベルのルールは、組織に必要なベースラインテレメトリを提供します。OU およびアカウントレベルのルールによって追加のテレメトリデータを収集することはできますが、収集するテレメトリデータを減らすことはできません。このようなルールが作成された場合、ルールの競合が発生します。

各スコープ (組織、OU、またはアカウント) 内で、ルールはリソースタイプ、テレメトリタイプ、および宛先設定に基づいて一意性を維持する必要があります。ルールが重複すると、競合例外がトリガーされます。例えば CloudWatch への Amazon VPC フローログに関する組織レベルのルールと Amazon VPC フローログに関する OU レベルのルールが存在するなど、同じルールが異なるスコープに存在する場合は、階層内で上位のルールが適用されます。ただし、複数の競合するルールがある場合は、いずれのルールも適用されません。

同じリソースに複数のルールが適用された場合、テレメトリ設定は、次の優先順位で競合を解決します。

1. 組織レベルのルールがアカウントレベルのルールより優先される

1. より具体的なタグ一致が一般的なルールより優先される

1. 複数の競合するルールがある場合は、いずれのルールも適用されません。最初に競合を解決する必要があります。

### 更新時のルールの動作
<a name="telemetry-config-rules-updates"></a>

有効化ルールを更新すると、そのルールに一致する新しいリソースのみが更新された設定を採用します。既存のリソースに対する既存のテレメトリ設定は変更されません。テレメトリデータの手動削除によってリソースが既存のルールに準拠しなくなった場合、そのリソースが準拠状態に戻ると新しい有効化ルールが適用されます。

Amazon VPC フローログの場合、テレメトリ設定は、ルールのスコープに一致するリソースに対してのみ新しいフローログを作成します。現在のルールパラメータと異なっている場合でも、以前に確立された Amazon VPC フローログを削除したり、影響を及ぼしたりすることはありません。CloudWatch Logs の場合、既存のロググループは、リソースパターンと一致している場合に限り維持されます。

### AWS Config との統合
<a name="telemetry-config-automated"></a>

CloudWatch のテレメトリ監査および設定は AWS Config と統合され、有効化ルールに一致するリソースを自動的に検出し、それをテレメトリデータ収集に適用します。有効化ルールを作成すると、テレメトリ設定によって対応する AWS Config レコーダーが作成されます。このレコーダーには、有効化ルールで定義した特定のリソースタイプの設定項目が含まれます。

Amazon CloudWatch では、AWS Config の Internal サービスにリンクされたレコーダーを使用します。CloudWatch が Internal サービスにリンクされたレコーダーの一部として使用する CI には課金されません。

**注記**  
有効化ルールを作成すると、有効化ルールの範囲に基づいてオンにする前に、AWS Config Configuration Items (CI) を介して非準拠のリソース (テレメトリが有効になっていないリソース) が検出されます。リソースの初期検出までには、場合によっては最大 24 時間かかることがあります。

テレメトリ設定では、AWS Config を使用して以下を実行します。
+ 組織またはアカウント全体でリソースを検出する
+ テレメトリ設定の変更を追跡する

### リージョン間のルール
<a name="telemetry-config-rules-multi-region"></a>

ターゲットリージョンを指定してルールを作成すると、現在のリージョンがそのルールの*ホームリージョン*になります。ルールは、選択したスポークリージョンに自動的にレプリケートされます。

マルチリージョンルールの主要な概念:
+ スポークリージョンでは、レプリケートされたルールを編集または削除することはできません。それらを変更または削除するには、ホームリージョンに移動する必要があります。
+ **[すべてのリージョン]** を選択すると、オプトイン時に新しいリージョンが自動的に含まれます。
+ システムは、ホームリージョンとスポークリージョン間のドリフトを修正するために、リージョン間でルールを定期的に整合させます。
+ ホームリージョンのルールに適用されるタグは、スポークリージョンにレプリケートされます。

レプリケートされたルールがスポークリージョンで作成、更新、または削除されると、AWS CloudTrail はスポークリージョンに `AwsServiceEvent` を記録します。これらのイベントは、`observabilityadmin.amazonaws.com` を呼び出しサービスとしてログに記録され、スポークリージョンのルール ARN が含まれます。これらのイベントを使用して、マルチリージョンのルールレプリケーションアクティビティを監査できます。

以下は、スポークリージョンでレプリケートされたルールが作成されたときに記録された AWS CloudTrail イベントの例です。

```
{
    "eventVersion": "1.11",
    "userIdentity": {
        "accountId": "{{123456789012}}",
        "invokedBy": "observabilityadmin.amazonaws.com"
    },
    "eventTime": "2026-04-06T19:50:37Z",
    "eventSource": "observabilityadmin.amazonaws.com",
    "eventName": "CreateTelemetryRule",
    "awsRegion": "{{us-east-1}}",
    "sourceIPAddress": "observabilityadmin.amazonaws.com",
    "userAgent": "observabilityadmin.amazonaws.com",
    "requestParameters": null,
    "responseElements": null,
    "eventID": "{{435d6da2-d099-4775-8944-1e039418de6f}}",
    "readOnly": false,
    "resources": [
        {
            "accountId": "{{123456789012}}",
            "type": "AWS::ObservabilityAdmin::TelemetryRule",
            "ARN": "arn:aws:observabilityadmin:{{us-east-1}}:{{123456789012}}:telemetry-rule/{{my-multi-region-rule}}"
        }
    ],
    "eventType": "AwsServiceEvent",
    "managementEvent": true,
    "recipientAccountId": "{{123456789012}}",
    "eventCategory": "Management"
}
```

`eventName` フィールドには、レプリケートされたルールで実行されたオペレーション `CreateTelemetryRule`、`UpdateTelemetryRule`、または `DeleteTelemetryRule` が反映されます。オペレーションは、直接の顧客 API コールではなく、顧客に代わって ObservabilityAdmin サービスによって実行されるため、`eventType` は常に `AwsServiceEvent` です。

## テレメトリ有効化ルールの作成
<a name="telemetry-config-rules-create"></a>

テレメトリ有効化ルールを作成する際には、以下を指定します。
+ ルールのスコープ (組織、組織単位、またはアカウント)
+ ルールが適用されるリソースタイプ
+ 有効化するテレメトリタイプ (メトリクス、ログ、またはトレース)
+ ルールの対象となるリソースをフィルタリングするためのオプションのタグ
+ 複数のリージョンにわたってルールをレプリケートするためのオプションのターゲットリージョン

**テレメトリ有効化ルールを作成する手順**

1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。

1. ナビゲーションペインで、**[取り込み]** を選択します。

1. **[有効化ルール]** タブを選択します。

1. [**ルールの追加**] を選択します。

1. [**ルール名**] にルールの名前を入力します。

1. **[ルールのスコープ]** で、以下のいずれかを選択します。
   + **[組織]** - ルールは AWS Organizations 全体に適用されます
   + **[組織単位]** - ルールは特定の OU に適用されます
   + **[アカウント]** - ルールは単一のアカウントに適用されます

1. **[データソース]** で、設定する AWS サービスを選択します。

1. **[テレメトリタイプ]** で、有効にするテレメトリのタイプを選択します。

1. (オプション) タグを追加して、ルールの対象となるリソースをフィルタリングします。

1. (オプション) **[ターゲットリージョン]** で、このルールを適用するリージョンを選択します。現在のリージョンは、ルールのホームリージョンとして自動的に指定されます。**[すべてのリージョン]** を選択すると、オプトイン時に新しいリージョンが自動的に含まれます。

1. [**Create rule**] を選択してください。

## テレメトリルールの管理
<a name="telemetry-config-rules-manage"></a>

ルールを作成した後、それらのルールを編集または削除できます。各ルールの対象となっているリソースを表示したり、ルールのコンプライアンスを監視したりすることもできます。

**既存のルールを管理する手順**

1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。

1. ナビゲーションペインで、**[取り込み]** を選択します。

1. **[有効化ルール]** タブを選択します。

1. ルールを選択して詳細を表示したり、次のいずれかのアクションを選択したりします。
   + **[ルールの編集]** – ルール設定を変更します
   + **[削除]** - ルールを削除します

### レプリケートされたルールの管理
<a name="telemetry-config-rules-manage-replicated"></a>

スポークリージョンでレプリケートされたルールを表示すると、コンソールには、そのルールが別のリージョンからレプリケートされたことを示す情報アラートが表示されます。スポークリージョンのレプリケートされたルールでは、**[ルールの編集]** アクションと **[削除]** アクションは無効になっています。

レプリケートされたルールを編集または削除するには、ルールが最初に作成されたホームリージョンに移動します。情報アラートには、ホームリージョンが表示されます。

スポークリージョン内のレプリケートされたルールのタグを追加または変更できます。スポークリージョンで行われたタグの変更は、ルールのローカルコピーにのみ適用され、ホームリージョンにレプリケートされません。

## サポートされているデータソース
<a name="telemetry-config-troubleshoot-service"></a>

テレメトリ有効化ルールでは、次のデータソースがサポートされています。各データソースには、それぞれ固有の動作と設定に関する考慮事項があります。

**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 を使用します
+ <account-id> マクロを使用してロググループを分割できます。
+ CloudWatch は、既に CloudWatch Logs にログを取り込んでいる VPC のリゾルバークエリログを作成しません
+ 有効化ルールは、ルールの範囲に基づいてお客様の VPC の Route 53 クエリログ記録を設定します。CloudWatch は Route 53 プロファイルと関連設定を検出しません。

**NLB アクセスログ**  
アクセスログを有効にする場合:  
+ 何も指定しない場合、デフォルトの CloudWatch ロググループパターンとプレフィックス /aws/nlb/access-logs を使用します
+ CloudWatch は、既に CloudWatch Logs にログを取り込んでいる NLB のログ配信を有効にしません

**サービスにリンクされたチャネルを使用する CloudTrail ログ**  
SLC パスを使用して CloudTrail ログを有効にする場合:  
+ マネージド CloudWatch ロググループ aws/cloudtrail/<event-types> を使用します
+ 顧客が作成した既存の CloudTrail 証跡転送設定は保持されます
+ CloudWatch 有効化ルールは、サービスにリンクされたチャネルのみを使用してログを取り込みます
+ イベントは、ロググループに設定された保持期間を使用します
+ CloudTrail イベントの場合、有効化ウィザードの一部として、CloudWatch に取り込むイベントタイプを少なくとも 1 つ選択できます。
+ イベントが遅延して配信され (追加理由 DELIVERY\_DELAY で示される)、以前に設定した保持期間が短い場合、遅延したイベントを使用できるのが短い保持期間の間のみになる可能性があります。
複数のリージョンで CloudTrail ログを設定するには、有効化ルールを作成するときに **[ターゲットリージョン]** セレクタを使用します。これにより、ホームリージョンから選択したリージョンにルールが自動的にレプリケートされます。

**Amazon Amazon EC2 の詳細なメトリクス**  
詳細モニタリングを有効にする場合:  
+ インスタンス状態の変更はメトリクスの収集に影響する可能性があります

**AWS セキュリティハブ**  
Security Hub のログ記録を有効にする場合:  
+ マネージド CloudWatch ロググループパターン aws/securityhub\_cspm/findings を使用します
+ CloudWatch は、既にマネージド CloudWatch Logs にログを取り込んでいる Security Hub のログ配信を有効化しません

**Amazon Bedrock AgentCore**  
+ ランタイム、ブラウザツール、コードインタープリタツールなど、使用可能なすべての Bedrock AgentCore プリミティブから出力されるログとトレースの両方を有効にします。テレメトリ設定コンソールエクスペリエンスに従ってログ配信ルールを作成し、続いてトレース配信ルールを作成します。
+ トレース配信ルールを作成すると、トランザクション検索が有効になり、CloudWatch X-Ray がアカウントのマネージドロググループに相関があるトレースを送信できるように追加のアクセス許可ポリシーが作成されます。さらに、X-Ray リソースポリシーが作成され、現在および新しい Bedrock AgentCore プリミティブがアカウントにトレースを配信できるようになります。

**Amazon Bedrock AgentCore Gateway**  
Bedrock AgentCore Gateway のログ記録を有効にする場合:  
+ 何も指定されていない場合は、デフォルトの CloudWatch ロググループパターン /aws/bedrock/agentcore を使用します
+ CloudWatch は、既に CloudWatch Logs にログを取り込んでいる Bedrock AgentCore ゲートウェイのログ配信を有効にしません

**Amazon Bedrock AgentCore Memory**  
Bedrock AgentCore Memory のログ記録を有効にする場合:  
+ 何も指定されていない場合は、デフォルトの CloudWatch ロググループパターン /aws/bedrock/agentcore を使用します
+ CloudWatch は、既に CloudWatch Logs にログを取り込んでいる Bedrock AgentCore Memory のログ配信を有効にしません

**Amazon CloudFront ディストリビューション**  
CloudFront ディストリビューションのログ記録を有効にする場合:  
+ CloudWatch は、既に CloudWatch Logs にログを取り込んでいる CloudFront ディストリビューションのログ配信を有効にしません

**Amazon MSK クラスターメトリクス**  
MSK クラスターメトリクスを有効化する場合:  
+ METRICS テレメトリタイプのみをサポート
+ 収集されたメトリクスの詳細度をコントロールするために、拡張モニタリングレベル (PER\_BROKER、PER\_TOPIC\_PER\_BROKER など) を設定できます
+ 同じ MSK クラスター内で、異なる拡張モニタリングレベルを持つルールが共存できます

**OpenTelemetry エンリッチメントメトリクス**  
OpenTelemetry エンリッチメントメトリクスを有効にする場合:  
+ METRICS テレメトリタイプのみをサポート
+ これは、アカウントレベルの有効化であり、ユーザーが設定できる送信先はありません
+ リソースレベルの選択基準はサポートされていません

**Amazon Bedrock AgentCore ワークロード ID**  
Bedrock AgentCore コアワークロード ID ログ記録を有効化する場合:  
+ 何も指定されていない場合は、デフォルトの CloudWatch ロググループパターン /aws/bedrock/agentcore を使用します
+ CloudWatch は、既に CloudWatch Logs にログを取り込んでいる Bedrock AgentCore ワークロード ID のログ配信を有効化しません