An AWS Config aggregator organization is how you stop taking inventory from one account at a time. The aggregator is a Config resource in one account and one Region. Pointed at the organization, it collects configuration and compliance data from member accounts where Config is already recording, across the Regions you name. A reviewer who sampled IAM roles last period can run the same query again and get a new result with the same shape. A spreadsheet exported from a single console cannot do that. The next sample starts over.
Rutagon builds the organization aggregator so the inventory is a query, not a tour. The recording cost still lives in the source accounts. The aggregator itself is not an extra Config bill. The configuration item cost article is that recording meter. This article is the read path that makes the sample repeatable. We do not turn on every resource type in every account to make the aggregator look full. An aggregator cannot show what Config never recorded.
What an AWS Config aggregator organization is allowed to see
AWS describes the resource in the multi-account aggregation documentation. An aggregator collects Config data from multiple accounts and Regions, from one account across Regions, or from an organization and the accounts in it that have Config enabled. The view is read-only. You cannot deploy rules through the aggregator or push a snapshot back into a source account. Authorization from each source account is not required when the sources are accounts in the organization. Individual accounts outside that path still need an authorization. We use the organization source so a new account does not wait on someone to paste an aggregator authorization.
The aggregator account is where you create it. The source accounts are the members. A service-linked aggregator exists for services that bring their own scope. The one we are talking about is the organization aggregator you own, so the query list is yours. Using aggregators does not incur any additional costs. That sentence is doing a lot of work, and it is easy to misread. The aggregator adds no fee of its own. Configuration items recorded in each source account still bill the way they always have. Aggregating ten accounts does not multiply the item price by an aggregator tax. It also does not make recording free.
Config has to be enabled in the source account and Region or there is nothing to collect. An account that joined the organization and never started the recorder shows up as a hole, not as an empty compliant set. We treat a missing recorder as a finding. Filling the hole by recording every resource type is how the configuration-item bill moves. The aggregator makes the hole visible. The recorder settings decide the price.
aggregator: organization source, read-only
authorization: not required for accounts in the organization
cost: no additional aggregator charge
source_gap: account or Region with no recorder, so the query cannot see it
rerun: same query, new result, stored next to the last sample
Advanced queries are how the sample is re-run. The configuration schema is the contract. A query for a resource type you care about, such as roles or buckets or security groups, returns the current recorded state through the aggregator. We save the query text with the sample id. The next period runs that text again. A reviewer comparing two exports is comparing two answers to the same question. A reviewer comparing two screenshots is comparing two moods.
What a re-run sample has to include
The sample is not "we have an aggregator." The sample is the query, the time it ran, the aggregator name, the accounts that returned data, and the accounts that were in the organization and returned nothing. That last set is the one spreadsheets drop. If the organization has forty accounts and the query names thirty-two, eight recorders are missing or the Region list is short. We file the gap list with the rows. A clean-looking export that silently skipped accounts is worse than a short export that says who is missing.
Resource relationships and compliance results come along if you recorded them and if rules evaluated them. The aggregator can show noncompliant resources across the organization. It cannot create the rule that marks them. Rules still live in the accounts, or in a deployment path that is not the aggregator. We keep that split in the design note so nobody expects the aggregator to remediate. Read-only means read-only the day someone asks it to push a fix.
Region coverage is part of the query's honesty. You choose source Regions. A resource in a Region you did not add is absent. Teams aggregate the home Region, run the sample, and miss a second Region where someone launched the same workload. We set the Region list from the Regions you actually use, and we re-run when that list changes. Adding a Region later does not rewrite last period's sample. It makes the next one wider. Say so in the record.
The organization CloudTrail trail is a different pipe. CloudTrail tells you an API was called. Config tells you what the resource looked like when it was recorded. The sample that asks "which roles trust a wildcard" is a Config query. The sample that asks "who changed that trust" is the trail. We do not make the aggregator stand in for the trail, and we do not make the trail stand in for inventory. The reviewer usually asks for both. They are two records.
Delegation matters in a real organization. The aggregator does not have to live in the management account if a delegated administrator is the operating model you already chose. It does have to live in an account the compliance lead can query without borrowing production credentials. We put it in the security or audit account you already use for read-only work. Production engineers do not get a mutating path by way of a resource that cannot mutate anything, but they also should not be the only people who can run the sample.
How Rutagon leaves it
We create the organization aggregator, confirm recorders exist where the query must see data, save the query text, and run it once so the first sample has a shape the next one can match. AWS cloud infrastructure is the delivery. The aggregator is code. A console aggregator with no query stored next to it becomes a private bookmark.
We do not enable every resource type because the aggregator can display it. Recording is the cost decision, made per type, with the configuration-item price in view. The aggregator is the reason the decision can be checked later. If a type is off, the re-run says so by returning nothing for that type, and the gap list says whether that was intended.
Rutagon's own accounts use an organization layout and a recorder we can query again. That is the habit. It is not a certification of your accounts. Your sample is your query result, with the missing accounts listed, stored where the next reviewer does not have to ask who exported the CSV.
When the result needs to sit beside a control the compliance lead already tracks, we attach the query output and the gap list to the ticket they already open. We do not ask them to learn a second inventory tool. The aggregator is the source. The ticket is the pointer. If they do not have that ticket, the object in the audit account is still the re-runnable artifact. The point is that the second sample is the same query, not a new project.
Frequently Asked Questions
Does an AWS Config aggregator organization add a second Config bill?
The aggregation documentation says using aggregators does not incur any additional costs. Recording in each source account still bills configuration items the way it did before. The aggregator is the read side. If the bill moves after you turn this on, look at recorders and resource types you enabled so the aggregator would have something to show, not at the aggregator resource itself.
Will a new member account appear automatically?
The organization source includes accounts in the organization that have Config enabled. An account with no recorder is a gap, not a silent success. You do not collect a per-account authorization for organization members. You do have to start Config in the account and Regions you expect the next sample to include.
Can we fix a noncompliant resource from the aggregator?
No. The aggregator is read-only and will not deploy a rule or push a change into the source account. Use it to see the miss, then fix the miss in the account that owns the resource or in the pipeline that owns the rule. The next query should show the resource compliant, because the aggregator does not apply that change for you.
How is a re-run different from exporting the console again?
We store the query text and the account list. The next sample executes that text and records who was missing. A fresh click-through export has no promise it asked the same question or saw the same accounts. The reviewer can diff two results because the question did not change under them.
Does the aggregator replace CloudTrail for the sample?
No. Config aggregation answers what was recorded about the resource, and CloudTrail answers which API calls changed it. A role inventory and a change log are both legitimate samples, and they are not substitutes. We keep the query with the aggregator and the event lookup with the trail.
Ask us to build the organization aggregator so the inventory sample can be run again. Contact Rutagon at rutagon.com/contact, 907-841-8407, or contact@rutagon.com.