CloudWatch Log Centralization - Simple Cross-Account Logging on AWS

AWS recommends having a central logging account. Every landingzone setup you see out there recommends having one. But actually centralizing logs isn't that easy.

We have written about the Observability Access Manager (OAM) before, because it is a great tool for that. But it was still quite complicated.

Then there were many self-made solutions out there with Log Subscription filters, Data Streams, and more. Also quite a burden.

Until now! AWS just launched in 2025 the ability to centralize logs in an organization. You can create rules, based on Account IDs, Organizational Units, or your whole organization. These rules copy your logs cross-account and cross-region into your dedicated logging account.

Let's see how that looks!

You Need an Organization to Set up Rules

This feature is only available for organizations. That means you need to have an AWS Organization.

Let's assume you have an AWS Organization set up with Controltower (what we would recommend).

You'll have different organizational units (OUs).

production
development

And you have one account called Logging. This is the account where all of your logs should be stored. But this is also the account (in my perspective) that should be the administrator to set up the logs.

CloudWatch on One Page (No Fluff)

Monitor like a pro. Our CloudWatch cheat sheet covers metrics, alarms, and logs - everything you need for effective AWS monitoring.

HD quality, print-friendly. Stick it next to your desk.

By entering your email, you are opting in for our twice-a-month AWS newsletter. Once in a while, we'll promote our paid products. We'll never send you spam or sell your data.

Creating Your First Rule

Delegate an Administrator

To set up the rules you need to be a delegated administrator. Go to your management account, CloudWatch, Settings, Organization. In there you can assign one delegated administrator for logs.

Select your account. I suggest using the Logging account for that.

Create your Rule

Now log into your logging account. Go to the same settings. You are now able to set up centralization rules in here.

You can have up to 50 rules.

A rule consists of the following things:

Name
Source Accounts
Source Regions

The accounts can be based on account IDs, organizational units, or on your whole organization ID.

Once you've created your rule it looks like this:

Now everything is copied over from your production OU accounts to your logging accounts.

Logs have the fields `@aws.account` and `@aws.region`

The logs now have some additional fields for the account number and the region. These fields are visible in Logs Insights.

To be honest, it is quite hard to know which Log Group belongs to which account and which source region. This is why you should use logs insights here.

🙏🏽 AWS Wishlist #1 - Please give us an opportunity to prefix, suffix Log Group names. Or show any other indicator where this Log Group is coming from.

I recommend going into Logs Insights and executing a query like that:

fields @timestamp, @aws.account, @aws.region, @message, @logStream, @log
| filter @aws.account = 123456789012 and @aws.region = 'us-west-2'
| sort @timestamp desc
| limit 100

With that you can see all logs from a specific account and a specific region. Since these fields are also indexed they shouldn't occur many or any costs (need to revise that 😃).

Additional Settings like Retention Are Stripped of

One very important part is that settings of the Log Groups are not applied anymore. For instance the retention setting of how long the logs are stored is gone.

It makes sense to have a kind of two-tiered strategy of your logs. In your application accounts you could save them for 30 days. In your central account you can save them for 1 year. This is often necessary anyway for certifications like SOC2 or ISO27001.

However, it is weird that we can't set this up while creating the rules.

🙏🏽 AWS Wishlist #2 - Please give us additional settings when creating rules that are applied on the Log Groups.

I've handled that with a CRON Job, a Lambda function, and some smart retries to overcome any rate limits.

We set up mainly:

data retention
data protection policies

Protected fields that were protected by a data policy should be still masked. But to be sure, and to not only rely on the member accounts to use them correctly I would apply them again. This is what I'm doing in the CRON job.