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.

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.

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.

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.

Pricing

The first copy of your log copy is free.
After that, you pay a charge of $0.05/GB of logs copies.
Which is quite fair in my perspective!

Additionally, you have the normal storage costs of CloudWatch.

🚀 Read the Full Tutorial →