CloudWatch tag propagation, 19 August 2026: opting in renames every destination log group

Summary. On 19 August 2026 AWS added log group tag propagation to CloudWatch Centralization, so tags such as CostCenter now follow log data from source accounts into the destination account. The announcement reads like a checkbox. The documentation does not. Turning tag propagation on requires the destination log group name pattern to contain all three of ${source.logGroup}, ${source.accountId} and ${source.region}, and the default pattern contains only the first. The destination account's TagResource and UntagResource quotas sit at 5 transactions per second each and are marked not adjustable, against a CreateLogGroup limit of 10 per second that is adjustable. Log Centralization itself bills the first log copy at no charge and every additional copy at $0.05 per GB, with storage charged on all copies. And the Cost Explorer payoff the launch post describes needs a separate activation in the Billing console that takes up to 24 hours to appear and up to 24 hours more to switch on, capped at 500 active cost allocation tag keys per payer account.

What actually shipped

CloudWatch Centralization collects log data from multiple AWS Organizations member accounts and Regions into a single destination account using centralization rules. It has been able to do that for a while. What landed on 19 August 2026 is tag copying: per the AWS What's New post, "CloudWatch copies the tags of each source log group to its destination log group and keeps them in sync based on the tag propogation behaviour selected as part of the centralization rule setup." The typo is AWS's.

The stated use case is specific and worth quoting, because it is the part a platform team will be asked to deliver: "a platform team can preserve Application and CostCenter tags on centralized log groups, then use those tags to scope access with IAM conditions and report centralized log spend by team in AWS Cost Explorer."

Two of those three outcomes are real and immediate. IAM conditions on the destination log groups work as soon as the tags land. The Cost Explorer reporting does not arrive with the feature.

The rename nobody mentions

Destination log group names in a centralization rule are built from a pattern. The CloudWatch Logs User Guide states the default plainly: "By default, only the ${source.logGroup} attribute is used, which merges all log groups with the same name in the destination account."

That default is the reason centralization is tidy. Ten accounts running the same Lambda function name produce one destination log group. It is also the reason tag propagation cannot work on top of it, because ten source log groups with ten different CostCenter values would be fighting over one destination resource. The guide resolves this with a hard requirement buried in a best-practices list: "If you enable tag propagation, the pattern must contain all three attributes: ${source.logGroup}, ${source.accountId}, and ${source.region}. This ensures each source log group maps to a unique destination log group."

So enabling tag propagation on an existing rule is not a toggle. It is a change to the naming scheme of every destination log group the rule produces. Anything downstream that names those groups by string — metric filters, subscription filters, Logs Insights saved queries, dashboards, Terraform data sources, IAM resource ARNs — is pointing at the old names.

The 512-character ceiling is not theoretical once the pattern absorbs a 12-digit account ID, a Region string and a full source log group path. The guide's own advice is to "structure destination log group names to be under 512 characters. CloudWatch Logs enforces a maximum log group name length of 512 characters."

There is a related trap one section down. Log stream names get a suffix appended during replication, and the guide notes that "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." Dropped, not queued.

The 5 TPS ceiling in the destination account

Tag propagation does not run once. It keeps tags in sync, which means TagResource and UntagResource calls against destination log groups for as long as the rule is enabled.

The CloudWatch Logs quotas page sets the ceiling for those calls, and the adjustability column is the interesting part.

Read those two columns together. AWS will raise the rate at which centralization can create destination log groups, and it will raise the number of log groups the destination account can hold to a million. It will not raise the rate at which those groups can be tagged. Once tag propagation forces a one-to-one mapping between source and destination log groups, the number of resources needing tags is the full fan-out of every log group in every enrolled account in every enrolled Region, and the tagging path is a fixed 5 calls per second shared with everything else in that account that tags a CloudWatch Logs resource. Your own tagging automation is in the same bucket.

The guide gives you a metric for the general case, CentralizationThrottled, alongside IncomingCopiedBytes and CentralizationError, and recommends alarms on all three.

The health field that stays green

This is the failure mode most likely to bite a team six weeks after rollout. From the guide: "Tag propagation has its own health status (TagPropagationStatus) that is independent of the overall RuleHealth for log delivery. If you misconfigure the destination role, your overall rule health is not affected — only tag propagation shows as unhealthy."

A rule whose tagging has been broken since the day it was enabled reports HEALTHY. Logs keep arriving. The only signal is a second field with its own TagPropagationFailureReason, which takes two documented values:

• RoleNotAssumable: the trust policy does not let the centralization service-linked role assume the destination role, or sts:ExternalId does not match the organization ID.

• RoleLacksPermissions: the role was assumed but the tag call was denied, because the permissions policy is missing logs:ListTagsForResource, logs:TagResource or logs:UntagResource.

If you build an alarm off RuleHealth alone, you will never learn. Check TagPropagationStatus from GetCentralizationRuleForOrganization on a schedule.

The IAM setup is three policies, not one

Tag propagation uses a customer-managed IAM role in the destination account rather than extending the service-linked role. Three pieces have to line up:

1. A trust policy on the destination role allowing arn:aws:iam::<destination-account-id>:role/aws-service-role/logs-centralization.observabilityadmin.amazonaws.com/AWSServiceRoleForObservabilityAdmin_LogsCentralization to call sts:AssumeRole, with the organization ID as external ID.

1. A permissions policy on that role granting logs:ListTagsForResource, logs:TagResource and logs:UntagResource on the destination log groups.

1. iam:PassRole on the destination role, scoped with the iam:PassedToService condition key to logs-centralization.observabilityadmin.amazonaws.com.

The third one is the one that gets missed, because it does not live on the role. The guide is explicit: "This statement goes on your identity policy (the principal calling CreateCentralizationRuleForOrganization or UpdateCentralizationRuleForOrganization), not on the destination role itself." Centralization rules are managed from the Organizations management account or a delegated administrator, so that identity policy usually belongs to a principal a different team controls. If you are already rationing permissions there, the 20 managed policies per role ceiling is worth checking before you add another one.

The Cost Explorer promise, and what it costs

The launch post's headline benefit is reporting centralized log spend by team. Getting there needs three things the announcement does not mention.

First, activation. Propagating a tag onto a log group does nothing for billing until the tag key is activated as a cost allocation tag in the Billing and Cost Management console by the payer account. The AWS Billing User Guide sets the lag: "it can take up to 24 hours for the tag keys to appear on your cost allocation tags page for activation. It can then take up to 24 hours for tag keys to activate." Two days before the first tagged line appears.

Second, the backfill that does not happen. The Billing guide states that "tags are not applied to resources that were created before the tags were created," and the centralization guide states separately that "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." Neither the log data nor the cost attribution is retroactive.

Third, the key budget. A payer account gets 500 active cost allocation tag keys, and only 20 can be activated or deactivated per request. If an organization has let tag keys sprawl across teams, propagating source tags wholesale into the destination account can push against that ceiling rather than clarify anything.

Then the bill itself. The CloudWatch pricing page prices Log Centralization as: "Data transfer and ingestion: the first log copy is free; additional log copies cost $0.05/GB. Storage charges apply for all copies," with a stated compression ratio of 0.15 for each uncompressed byte. Metric centralization is priced the same way, first copy free and $0.05 per GB after.

The word doing the work there is "copies". A destination account is one copy. The optional backup Region the guide recommends for resiliency is a second, so it is $0.05 per GB copied plus storage in both places. On 500 GB a month of centralized logs that is $25 a month for the copy alone, before storage. The tag propagation feature does not change that arithmetic, but it is what finally makes the arithmetic visible per team, which is usually when somebody asks why it is there at all.

The real cost of this feature is not the tagging. It is the rename.

Who this affects, and how to tell if it is you

You are exposed if all of these are true: you run CloudWatch Centralization rules across an Organization, your destination log group pattern is the default or anything short of all three attributes, and someone has asked for per-team log cost reporting. Check the pattern first. If it does not already contain ${source.accountId} and ${source.region}, enabling tag propagation is a migration, and it should be planned as one — inventory the metric filters, subscription filters and IAM resource ARNs that name the current destination groups before you touch the rule.

You are not exposed if you use cross-account observability rather than centralization. That feature queries across accounts without copying data, carries no additional charge, and has no destination log groups to rename.

India-specific considerations

For Indian teams the interesting number is the copy, not the tag. A mid-sized platform running centralization from ap-south-1 into a destination account with a backup Region pays the $0.05 per GB on the second copy plus storage twice, which at 500 GB a month works out to roughly ₹2,100 a month for the copy alone at current rates, before any storage or Logs Insights scanning. That is small, and it is exactly the kind of line that never gets reviewed because nobody can attribute it. Tag propagation is what makes it attributable, which is a reason to enable it and a reason to size the rename properly first.

Where logs carry personal data, note that the destination account and its optional backup Region are additional copies of that data, and the Digital Personal Data Protection Act 2023 obligations follow the copies. The centralization guide's encryption controls matter here: you can require a customer managed KMS key on destination log groups, and if you do, the key needs the tag LogsManaged = true for the centralization service to use it. Get that wrong with conflict resolution set to skip and records are dropped with a DestinationEncryptionMismatch error.

What is still unknown

AWS has not published a documented rate at which tag propagation issues TagResource calls, so there is no way to calculate from the docs how large a fan-out will start throttling against the fixed 5 per second. The guide also does not say what happens to tags already present on a pre-existing destination log group that the rule later adopts, beyond the general statement that tags are kept in sync. Both are worth testing in a non-production destination account before enabling this across an Organization.

FAQ

How eCorpIT can help

eCorpIT runs observability cost and OpenTelemetry migration work for teams operating multi-account AWS estates, including centralization rule design, destination naming schemes that survive a tag propagation rollout, and cost allocation tag hygiene ahead of activation. We are a CMMI Level 5 and ISO 27001:2022 certified engineering organisation with senior-led teams in Gurugram. If you are about to enable tag propagation on live centralization rules, talk to us before the rename, not after.

References

1. Amazon CloudWatch log Centralization now supports log group tag propagation, AWS What's New, 19 August 2026

1. Cross-account cross-Region log centralization, Amazon CloudWatch Logs User Guide

1. CloudWatch Logs quotas, Amazon CloudWatch Logs User Guide

1. Amazon CloudWatch pricing, AWS

1. User-defined cost allocation tags, AWS Billing User Guide

1. Activating user-defined cost allocation tags, AWS Billing User Guide

1. Quotas and restrictions, AWS Billing User Guide

1. Amazon CloudWatch Logs billing and cost, Amazon CloudWatch Logs User Guide

1. CloudWatch billing and cost, Amazon CloudWatch User Guide

1. Encrypt log data in CloudWatch Logs using AWS Key Management Service, Amazon CloudWatch Logs User Guide

1. Creating metrics from log events using filters, Amazon CloudWatch Logs User Guide

Last updated: 22 August 2026.