AWS AmazonCloudWatch documentation change
Summary
Major restructuring and expansion of telemetry enablement rules documentation. Changes include: reorganizing table of contents, adding new sections 'How rules work' and 'Rules across Regions', detailing rule evaluation hierarchy and conflict resolution, adding multi-region rule replication with CloudTrail event examples, updating rule creation steps to include target regions, adding 'Supported data sources' section with updated service-specific details, and removing old troubleshooting section.
Security assessment
The changes are primarily organizational and feature-focused, detailing how telemetry enablement rules work, their hierarchical evaluation, multi-region replication, and supported data sources. There is no mention of addressing a specific security vulnerability, weakness, or incident. The addition of CloudTrail event examples for auditing multi-region rule replication is an operational/logging feature, not a security fix. The changes improve documentation clarity and reflect feature enhancements (multi-region support), but do not introduce or document new security features or address security issues.
Diff
diff --git a/AmazonCloudWatch/latest/monitoring/telemetry-config-rules.md b/AmazonCloudWatch/latest/monitoring/telemetry-config-rules.md index 28b095e5f..c92c302c5 100644 --- a//AmazonCloudWatch/latest/monitoring/telemetry-config-rules.md +++ b//AmazonCloudWatch/latest/monitoring/telemetry-config-rules.md @@ -7 +7 @@ -Enablement rule integration with AWS ConfigUnderstanding enablement rule behaviorCreating telemetry enablement rulesManaging telemetry rulesTroubleshooting telemetry configuration +How rules workCreating a telemetry enablement ruleManaging telemetry rulesSupported data sources @@ -9 +9 @@ Enablement rule integration with AWS ConfigUnderstanding enablement rule behavio -# Working with telemetry enablement rules +# Telemetry enablement rules @@ -15 +15 @@ You can create telemetry enablement rules to automatically configure telemetry c - * Enablement rule integration with AWS Config + * How rules work @@ -17,3 +17 @@ You can create telemetry enablement rules to automatically configure telemetry c - * Understanding enablement rule behavior - - * Creating telemetry enablement rules + * Creating a telemetry enablement rule @@ -23 +21,3 @@ You can create telemetry enablement rules to automatically configure telemetry c - * Troubleshooting telemetry configuration + * Supported data sources + + @@ -25,0 +26 @@ You can create telemetry enablement rules to automatically configure telemetry c +## How rules work @@ -26,0 +28,5 @@ You can create telemetry enablement rules to automatically configure telemetry c +Telemetry configuration follows specific patterns when evaluating and applying rules. + +### Rule evaluation hierarchy + +Enablement rules are evaluated according to a hierarchical pattern. Organizational rules are evaluated first, then rules that apply to organizational units (OUs), and finally rules that apply to individual accounts. Rules at the organizational level provide the baseline required telemetry for your organization. Rules at the OU and account level can collect additional telemetry data, but they cannot collect less telemetry data. If such a rule is created, it will create a rule conflict. @@ -28 +34,20 @@ You can create telemetry enablement rules to automatically configure telemetry c -## Enablement rule integration with AWS Config +Within each scope (organization, OU, or account), rules must maintain uniqueness based on their resource type, telemetry type, and destination configuration. Duplicate rules trigger a conflict exception. If the same rule exists in different scopes, such as an organization level rule for Amazon VPC Flow logs to CloudWatch and an OU level rule for Amazon VPC Flow logs, the rule higher in the hierarchy is applied. However, if there are multiple conflicting rules, none of the rules are applied. + +When multiple rules apply to the same resource, telemetry configuration resolves conflicts using these priorities: + + 1. Organizational-level rules take precedence over account-level rules + + 2. More specific tag matches take precedence over general rules + + 3. If there are multiple conflicting rules, none of the rules are applied. You must resolve the conflicts first. + + + + +### Rule behavior on updates + +If you update an enablement rule, only new resources that match the rule adopt the updated configuration. The existing telemetry settings remain unchanged for existing resources. If a resource becomes non-compliant with an existing rule due to manual deletion of telemetry data, the new enablement rule is adopted once the resource is brought back into compliance. + +For Amazon VPC Flow logs, telemetry config only creates new flow logs for resources that match the rule scope. It does not delete or impact previously established Amazon VPC Flow logs, even if they differ from current rule parameters. For CloudWatch Logs, existing log groups are maintained provided they match the resource pattern. + +### Integration with AWS Config @@ -47 +72 @@ Telemetry config uses AWS Config to: -## Understanding enablement rule behavior +### Rules across Regions @@ -49 +74 @@ Telemetry config uses AWS Config to: -Telemetry configuration follows specific patterns when evaluating and applying rules: +When you create a rule with target Regions, the current Region becomes the _home Region_ for that rule. The rule is automatically replicated to the spoke Regions you select. @@ -51 +76 @@ Telemetry configuration follows specific patterns when evaluating and applying r -Enablement rules are evaluated according to a hierarchical pattern. Organizational rules are evaluated first, then rules that apply to organizational units (OUs), and finally rules that apply to individual accounts. Rules at the organizational level provide the baseline required telemetry for your organization. Rules at the OU and account level can collect additional telemetry data, but they cannot collect less telemetry data. If such a rule is created, it will create a rule conflict. +Key concepts for multi-Region rules: @@ -53 +78 @@ Enablement rules are evaluated according to a hierarchical pattern. Organization -Within each scope (organization, OU, or account), rules must maintain uniqueness based on their resource type, telemetry type, and destination configuration. Duplicate rules trigger a conflict exception. If the same rule exists in different scopes, such as an organization level rule for VPC Flow logs to CloudWatch and an OU level rule for VPC Flow logs, the rule higher in the hierarchy is applied. However, if there are multiple rules in conflict, none of the rules are applied. + * Replicated rules cannot be edited or deleted in spoke Regions. You must navigate to the home Region to modify or remove them. @@ -55 +80 @@ Within each scope (organization, OU, or account), rules must maintain uniqueness -For VPC Flow logs, Telemetry Config only creates new flow logs for resources that match the rule scope. It does not delete or impact previously established VPC Flow logs, even if they differ from current rule parameters. For CloudWatch Logs, existing log groups are maintained provided they match the resource pattern. + * If you select **All regions** , new Regions are automatically included when you opt in to them. @@ -57 +82 @@ For VPC Flow logs, Telemetry Config only creates new flow logs for resources tha -If you update an enablement rule, only new resources that match the rule adopt the updated configuration, the existing telemetry settings remain unchanged for existing resources. If a resource becomes non-compliant with an existing rule due to manual deletion of telemetry data, the new enablement rule is adopted once the resource is brought back into compliance. + * The system periodically reconciles rules across Regions to correct any drift between the home Region and spoke Regions. @@ -59 +84,42 @@ If you update an enablement rule, only new resources that match the rule adopt t -## Creating telemetry enablement rules + * Tags applied to rules in the home Region are replicated to spoke Regions. + + + + +When a replicated rule is created, updated, or deleted in a spoke Region, AWS CloudTrail records an `AwsServiceEvent` in the spoke Region. These events are logged with `observabilityadmin.amazonaws.com` as the invoking service and include the rule ARN in the spoke Region. You can use these events to audit multi-Region rule replication activity. + +The following is an example AWS CloudTrail event recorded when a replicated rule is created in a spoke Region: + + + { + "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" + } + +The `eventName` field reflects the operation performed on the replicated rule: `CreateTelemetryRule`, `UpdateTelemetryRule`, or `DeleteTelemetryRule`. The `eventType` is always `AwsServiceEvent` because the operation is performed by the ObservabilityAdmin service on behalf of the customer, not by a direct customer API call. + +## Creating a telemetry enablement rule @@ -70,0 +137,2 @@ When you create a telemetry enablement rule, you specify: + * Optional target Regions to replicate the rule across multiple Regions + @@ -88 +156 @@ When you create a telemetry enablement rule, you specify: - * **Organization** \- Rule applies across your entire AWS Organizations + * **Organization** – Rule applies across your entire AWS Organizations @@ -90 +158 @@ When you create a telemetry enablement rule, you specify: - * **Organizational unit** \- Rule applies to a specific OU + * **Organizational unit** – Rule applies to a specific OU @@ -92 +160 @@ When you create a telemetry enablement rule, you specify: - * **Account** \- Rule applies to a single account + * **Account** – Rule applies to a single account @@ -98 +166 @@ When you create a telemetry enablement rule, you specify: - 9. Optional: Add tags to filter which resources the rule affects. + 9. (Optional) Add tags to filter which resources the rule affects. @@ -100 +168,3 @@ When you create a telemetry enablement rule, you specify: - 10. Choose **Create rule**. + 10. (Optional) For **Target regions** , select the Regions where you want this rule to apply. The current Region is automatically designated as the home Region for the rule. If you select **All regions** , new Regions are automatically included when you opt in to them. + + 11. Choose **Create rule**. @@ -119,6 +189 @@ After creating rules, you can edit or delete them. You can also view which resou - * **Edit** \- Modify rule settings - - * **Delete** \- Remove the rule - - - + * **Edit rule** – Modify rule settings @@ -126 +191 @@ After creating rules, you can edit or delete them. You can also view which resou -## Troubleshooting telemetry configuration + * **Delete** – Remove the rule @@ -128 +192,0 @@ After creating rules, you can edit or delete them. You can also view which resou -This section describes common issues you might encounter when using telemetry configuration and how to resolve them. @@ -130 +193,0 @@ This section describes common issues you might encounter when using telemetry co -### Rule conflicts and resolution @@ -132,5 +194,0 @@ This section describes common issues you might encounter when using telemetry co -When multiple rules apply to the same resource, telemetry configuration resolves conflicts using these priorities: - - 1. Organizational-level rules take precedence over account-level rules - - 2. More specific tag matches take precedence over general rules @@ -138 +196 @@ When multiple rules apply to the same resource, telemetry configuration resolves - 3. If there are multiple conflicting rules, none of the rules are applied, you must resolve the conflicts first. +### Managing replicated rules @@ -139,0 +198 @@ When multiple rules apply to the same resource, telemetry configuration resolves +When you view a replicated rule in a spoke Region, the console displays an informational alert indicating that the rule was replicated from another Region. The **Edit rule** and **Delete** actions are disabled for replicated rules in spoke Regions. @@ -140,0 +200 @@ When multiple rules apply to the same resource, telemetry configuration resolves +To edit or delete a replicated rule, navigate to the home Region where the rule was originally created. The home Region is displayed in the informational alert. @@ -141,0 +202 @@ When multiple rules apply to the same resource, telemetry configuration resolves +You can add or modify tags on replicated rules in spoke Regions. Tag changes made in spoke Regions apply only to the local copy of the rule and are not replicated back to the home Region. @@ -143 +204 @@ When multiple rules apply to the same resource, telemetry configuration resolves -### Common issues +## Supported data sources @@ -145,31 +206 @@ When multiple rules apply to the same resource, telemetry configuration resolves -Resources not appearing in discovery - - -Verify that: - - * The resource type is supported - - * AWS Config recorder is enabled - - * You have appropriate IAM permissions - - - - -Rules not applying automatically - - -Check: - - * Rule scope configuration - - * Tag filters - - - - -###### Note - -When you create an enablement rule, we discover non-compliant resources (those without telemetry enabled) through AWS Config Configuration Items (CIs) before turning them on based on your enablement rule scope. The initial discovery of the resources may take upto 24 hours to complete in some cases. - -### Service-specific considerations