AWS AmazonCloudWatch documentation change
Summary
Updated documentation for CloudWatch Logs centralization with enhanced monitoring and troubleshooting guidance. Changes include: added note about trusted access and service-linked roles, restructured monitoring section with rule health statuses, CloudTrail integration, metrics recommendations, and detailed troubleshooting scenarios for common centralization failures.
Security assessment
The changes add documentation about security features including KMS key permission requirements, encryption configuration checks, and trusted access setup. However, there's no evidence of addressing a specific security vulnerability or incident. The security-related content focuses on proper configuration of existing security features rather than patching vulnerabilities.
Diff
diff --git a/AmazonCloudWatch/latest/logs/CloudWatchLogs_Centralization.md b/AmazonCloudWatch/latest/logs/CloudWatchLogs_Centralization.md index 29174760a..26e1730c0 100644 --- a//AmazonCloudWatch/latest/logs/CloudWatchLogs_Centralization.md +++ b//AmazonCloudWatch/latest/logs/CloudWatchLogs_Centralization.md @@ -5 +5 @@ -Data centralization conceptsSetting up log centralizationMonitoring centralization +Data centralization conceptsSetting up log centralizationMonitoring and troubleshooting centralization rules @@ -57,0 +58,4 @@ Once the centralization rule is enabled and log events are being replicated to t +###### Note + +It is recommended to enable trusted access through the console, which automatically creates the required service-linked role (SLR). If trusted access is enabled through other methods, the service-linked role will need to be created separately. + @@ -217 +221 @@ Use the following procedure to delete an existing centralization rule. -## Monitoring centralization +## Monitoring and troubleshooting centralization rules @@ -221 +225 @@ You can monitor the status and performance of your centralization rules using Cl -### Monitoring centralization in the console +CloudWatch Logs provides: @@ -223 +227 @@ You can monitor the status and performance of your centralization rules using Cl -Use the CloudWatch Logs console to view the status and activity of your centralization rules. + 1. _Rule health per Centralization rule_ @@ -225 +229 @@ Use the CloudWatch Logs console to view the status and activity of your centrali -###### To monitor centralization rules in the console + 1. Choose **Settings**. @@ -227 +231 @@ Use the CloudWatch Logs console to view the status and activity of your centrali - 1. Navigate to the CloudWatch console in the Management or Delegated Administrator account of the organization. + 2. Navigate to the **Organization** tab. @@ -229 +233 @@ Use the CloudWatch Logs console to view the status and activity of your centrali - 2. Choose **Settings**. + 3. Choose **Manage rules**. @@ -231 +235 @@ Use the CloudWatch Logs console to view the status and activity of your centrali - 3. Navigate to the **Organization** tab. + 2. _Logs API calls with AWS CloudTrail_ @@ -233 +237 @@ Use the CloudWatch Logs console to view the status and activity of your centrali - 4. Choose **Manage rules**. + 3. CloudWatch also publishes metrics for centralization, including log events replicated, errors, and throttling. For more information about these metrics and their dimensions, see [Centralization metrics and dimensions](./CloudWatch-Logs-Monitoring-CloudWatch-Metrics.html#CloudWatchLogs-Centralization-Metrics). @@ -235 +238,0 @@ Use the CloudWatch Logs console to view the status and activity of your centrali - 5. Review the centralization rules list, which displays: @@ -237 +239,0 @@ Use the CloudWatch Logs console to view the status and activity of your centrali - * **Rule name** : The name of each centralization rule @@ -239 +240,0 @@ Use the CloudWatch Logs console to view the status and activity of your centrali - * **Rule status** : Current operational status (Active, Inactive, Error) @@ -241 +242 @@ Use the CloudWatch Logs console to view the status and activity of your centrali - * **Creation date** : When the rule was created +### Centralization rule health status @@ -243 +244 @@ Use the CloudWatch Logs console to view the status and activity of your centrali - * **Destination account ID** : The account ID of the destination account +Each centralization rule has a health status that indicates whether it's operating correctly. You can check rule health through the console or programmatically using the API. @@ -245 +246 @@ Use the CloudWatch Logs console to view the status and activity of your centrali - * **Destination Region** : The Region of the destination account +Rule health statuses include: @@ -247 +248 @@ Use the CloudWatch Logs console to view the status and activity of your centrali - 6. Choose a specific rule name to view the rule configuration details + * `HEALTHY`: The rule is operating normally and replicating log data as configured @@ -248,0 +250 @@ Use the CloudWatch Logs console to view the status and activity of your centrali + * `UNHEALTHY`: The rule has encountered issues and may not be replicating data correctly @@ -249,0 +252 @@ Use the CloudWatch Logs console to view the status and activity of your centrali + * `PROVISIONING`: Centralization for the organization is in the process of being set up. @@ -252 +254,0 @@ Use the CloudWatch Logs console to view the status and activity of your centrali -### Centralization monitoring @@ -254 +255,0 @@ Use the CloudWatch Logs console to view the status and activity of your centrali -You can monitor centralization rules using the console interface and API operations. @@ -256 +257 @@ You can monitor centralization rules using the console interface and API operati -Current monitoring capabilities include: +When a rule is marked as UNHEALTHY, the `FailureReason` field provides details about the specific issue that needs to be addressed. @@ -258 +259 @@ Current monitoring capabilities include: - * _Rule health status_ : Monitor the overall health of centralization rules through the console or `GetCentralizationRuleForOrganization` API +### Monitoring centralization API calls with AWS CloudTrail @@ -260 +261 @@ Current monitoring capabilities include: - * _Rule configuration_ : Review rule settings and last update timestamps +AWS CloudTrail logs API calls made to the centralization service, allowing you to track configuration changes and troubleshoot issues for accounts that are members of your AWS Organizations. @@ -262 +263 @@ Current monitoring capabilities include: - * _Failure reasons_ : View detailed failure information when rules are marked as UNHEALTHY +Key CloudTrail events for centralization include: @@ -264 +265 @@ Current monitoring capabilities include: - * _API activity_ : Track centralization API calls through CloudTrail logs + * `CreateCentralizationRuleForOrganization`: When a new centralization rule is created @@ -265,0 +267 @@ Current monitoring capabilities include: + * `UpdateCentralizationRuleForOrganization`: When an existing rule is modified @@ -266,0 +269 @@ Current monitoring capabilities include: + * `DeleteCentralizationRuleForOrganization`: When a rule is deleted @@ -267,0 +271 @@ Current monitoring capabilities include: + * `GetCentralizationRuleForOrganization`: When rule details are retrieved @@ -269 +273 @@ Current monitoring capabilities include: -### Monitoring rule health + * `ListCentralizationRulesForOrganization`: When rules are listed @@ -271 +274,0 @@ Current monitoring capabilities include: -Each centralization rule has a health status that indicates whether it's operating correctly. You can check rule health through the console or programmatically using the API. @@ -273 +275,0 @@ Each centralization rule has a health status that indicates whether it's operati -Rule health statuses include: @@ -275 +276,0 @@ Rule health statuses include: - * `HEALTHY`: The rule is operating normally and replicating log data as configured @@ -277 +278 @@ Rule health statuses include: - * `UNHEALTHY`: The rule has encountered issues and may not be replicating data correctly +You can use CloudTrail logs to audit centralization configuration changes and correlate them with performance issues or replication failures. @@ -279 +280 @@ Rule health statuses include: - * `PROVISIONING`: Centralization for the organization is in the process of being set up. +### Monitoring recommendations @@ -280,0 +282 @@ Rule health statuses include: +To ensure centralization is working correctly, we recommend setting up CloudWatch alarms on key centralization metrics that we vend to CloudWatch Metrics. This proactive monitoring helps you detect issues early and maintain reliable log centralization across your organization. @@ -281,0 +284 @@ Rule health statuses include: +Key metrics to monitor include: @@ -282,0 +286 @@ Rule health statuses include: + * `IncomingCopiedBytes`: Monitor the volume of log data being successfully replicated to your destination account. A sudden drop or absence of this metric may indicate centralization issues. @@ -284 +288 @@ Rule health statuses include: -When a rule is marked as UNHEALTHY, the `FailureReason` field provides details about the specific issue that needs to be addressed. + * `CentralizationError`: Set up alarms for any errors in the centralization process to quickly identify and resolve issues. @@ -286 +290 @@ When a rule is marked as UNHEALTHY, the `FailureReason` field provides details a -### Monitoring centralization API calls with AWS CloudTrail + * `CentralizationThrottled`: Monitor for throttling events that could impact log replication performance. @@ -288 +291,0 @@ When a rule is marked as UNHEALTHY, the `FailureReason` field provides details a -AWS CloudTrail logs API calls made to the centralization service, allowing you to track configuration changes and troubleshoot issues for accounts that are members of your AWS Organizations. @@ -290 +292,0 @@ AWS CloudTrail logs API calls made to the centralization service, allowing you t -Key CloudTrail events for centralization include: @@ -292 +293,0 @@ Key CloudTrail events for centralization include: - * `CreateCentralizationRuleForOrganization`: When a new centralization rule is created @@ -294 +295 @@ Key CloudTrail events for centralization include: - * `UpdateCentralizationRuleForOrganization`: When an existing rule is modified +For a complete list of available centralization metrics and their dimensions, see [Centralization metrics and dimensions](./CloudWatch-Logs-Monitoring-CloudWatch-Metrics.html#CloudWatchLogs-Centralization-Metrics). @@ -296 +297 @@ Key CloudTrail events for centralization include: - * `DeleteCentralizationRuleForOrganization`: When a rule is deleted +If logs are not being centralized as expected, review the following common scenarios that can prevent log centralization. @@ -298 +299 @@ Key CloudTrail events for centralization include: - * `GetCentralizationRuleForOrganization`: When rule details are retrieved +**Historical log data** @@ -300 +300,0 @@ Key CloudTrail events for centralization include: - * `ListCentralizationRulesForOrganization`: When rules are listed @@ -301,0 +302 @@ Key CloudTrail events for centralization include: +The CloudWatch Logs centralization feature only processes new log data that arrives in source accounts after you create the centralization rule. Historical log data (logs that existed before rule creation) is not centralized. @@ -302,0 +304 @@ Key CloudTrail events for centralization include: +**KMS key permissions** @@ -305 +307,47 @@ Key CloudTrail events for centralization include: -You can use CloudTrail logs to audit centralization configuration changes and correlate them with performance issues or replication failures. +Centralization rules will fail to deliver logs from the source account to the destination log groups if the KMS key provided in the centralization rule doesn't permit CloudWatch Logs to use it. Ensure that the KMS key policy grants the necessary permissions to CloudWatch Logs. For more information, see [Step 2: Set permissions on the KMS key](./CloudWatchLogs-Insights-Query-Encrypt.html#cmk-permissions). + +**Customer Managed KMS keys configuration** + + +If you selected **Do not centralize log groups encrypted with Customer Managed KMS keys** during rule creation, log events from source log groups encrypted with Customer Managed KMS keys will be skipped and not centralized. + +**Destination encryption mismatch** + + +If the destination log group already exists with a different KMS encryption configuration than what the centralization rule specifies, and the conflict resolution is set to SKIP, records will be dropped and a `DestinationEncryptionMismatch` error will be emitted. For example, this occurs when the destination has default encryption but the rule specifies a customer managed KMS key. + +**Trusted access not enabled** + + +Trusted access must be enabled for CloudWatch in AWS Organizations for the management account and the destination account to provide access to the log data. + +**Source selection criteria** + + +Verify that your centralization rule's source selection criteria is configured correctly: + + * _Accounts and regions_ : Ensure that the source accounts and regions where logs originate are included in the rule. Log groups from accounts or regions not specified in the rule will not be centralized. + + * _Log group filters_ : If you configured log group filters, only log groups matching the specified criteria will be centralized. Verify that your log group selection criteria includes the log groups you expect to centralize. + + * _Organization membership_ : Both source and destination accounts must belong to the same AWS Organizations organization. Accounts outside the organization cannot participate in centralization. + + + + +**Log group quota limit reached** + + +If the destination account has reached its log group quota limit, new log groups cannot be created for centralization. Verify that the destination account has sufficient quota to accommodate centralized log groups from all source accounts. You can request a quota increase if needed. + +**Log stream name length limit exceeded** + + +Log stream names have maximum length restrictions. When centralization replicates log streams to the destination account, a suffix is added to the log stream name. If the resulting log stream name exceeds the maximum allowed length, records will be dropped and an `InvalidLogStream` error will be emitted to the customer account. + +**Rule health status** + + +Check the centralization rule health status in the console or using the `GetCentralizationRuleForOrganization` API. If the rule is marked as UNHEALTHY, review the `FailureReason` field for specific details about the issue. + +To diagnose centralization issues, review the centralization rule health status in the console, check CloudWatch metrics for errors and throttling, and examine AWS CloudTrail logs for API call failures. For more information about centralization metrics, see [Centralization metrics and dimensions](./CloudWatch-Logs-Monitoring-CloudWatch-Metrics.html#CloudWatchLogs-Centralization-Metrics).