The account that watches everything

Business Challenge

A security team is asked to consolidate. Detection tooling has grown up across three accounts, findings arrive in two consoles, and nobody can say authoritatively which accounts are covered. The proposal is sensible: one security account, everything in it. GuardDuty and Security Hub delegated there. Config delegated there. The organisation trail created from there, and the bucket it writes to created there too, because that is where the security team can reach it.

Everything about that is an improvement on what came before, except the last clause.

Putting the trail's configuration and the trail's output in the same account means one administrator can stop the logging and delete what the logging already produced. Not through a defect — through the ordinary permissions that person needs to do their job. The four previous posts in this block argued that recording must start at account creation, must survive tampering, must be independently detectable and must have a break-glass path. All of that is undone by a single account boundary drawn one account too wide.

AWS draws the line explicitly, and says why

In the AWS SRA, the Security Tooling account is the delegated administrator account for managing CloudTrail, and the corresponding S3 bucket to store the organization trail logs is created in the Log Archive account. This is to separate the management and usage of CloudTrail log privileges. Managing the trail and holding its output are two privileges, and the reference architecture puts them in two accounts on purpose.

Architecture

Three accounts, three jobs, and the boundaries between them are the design.

Diagram: the management account holding the organisation and little else, the security tooling account as delegated administrator configuring detection and running response, and the log archive account holding the output where the tooling account cannot delete it; below, the list of delegated services and the drift by which a read-only account accumulates write access to every member account — Configuring detection and storing its output are different privileges. The reference architecture separates them by account.

What the account is actually for

AWS's definition is broader than "where the findings appear": the Security Tooling account is dedicated to operating security services, monitoring AWS accounts, and automating security alerting and response. The third clause is the one that shapes everything else in this post, because response is an active verb.

The stated objectives are worth reading as design constraints rather than marketing. Provide a dedicated account with controlled access to manage access to the security guardrails, monitoring, and response. Maintain centralised infrastructure to monitor security operations data and maintain traceability, because detection, investigation, and response are essential parts of the security lifecycle. And further support a defense-in-depth organization strategy by maintaining another layer of control over appropriate security configuration and operations such as encryption keys and security group settings.

Why not the management account

The temptation is real: the management account already has organisation-wide reach, and delegation is extra setup. AWS's position is unambiguous — we recommend that you avoid using the AWS Org Management account for deployments unless absolutely necessary. Instead, pass on deployments to member accounts.

The reason connects directly to an earlier post in this block. SCPs don't affect users or roles in the management account. They affect only the member accounts in your organization. Every guardrail you write is invisible there. A security tooling account, by contrast, is an ordinary member account, so the SCPs that stop a trail being disabled or an archive being deleted apply to it in full. Delegation does not weaken the control; it moves privileged work into the only place a control can reach it.

Even where both paths work, AWS still prefers the delegated one: you can create and manage organization trails from both management and delegated administrator accounts. However, as a best practice, you should limit access to the management account and use the delegated administrator functionality where it is available.

The separation is applied consistently, not just to CloudTrail

The same split appears for every service that produces durable output, which is what makes it a principle rather than a CloudTrail quirk.

Config — the AWS Config delegated administrator account is the Security Tooling account, and the AWS Config delivery channel is configured to deliver resource configuration snapshots in a centralized S3 bucket in the Log Archive account.
GuardDuty — active findings are exported to a central S3 bucket in the Log Archive account, so you can retain the findings beyond 90 days. Note the reason: the findings themselves age out, and the archive is what makes them evidence rather than a dashboard.
AWS Artifact — hosted in the tooling account to separate the compliance artifact management functionality from the AWS Org Management account, which AWS calls out as a separation of duty in its own right.

The list is longer than most teams expect

Delegated to this one account: AWS Config, AWS Firewall Manager, Amazon GuardDuty, IAM Access Analyzer, Amazon Macie, AWS Security Hub, Amazon Detective, AWS Audit Manager, Amazon Inspector, AWS CloudTrail, AWS Systems Manager, and AWS Security Incident Response — plus centralised management of root access.

Read that list as a permissions inventory rather than a feature list. Firewall Manager pushes rules into member accounts. Systems Manager runs commands on instances. Root access management can act as root in accounts whose root credentials have been removed. This is not a passive account.

Why This Architecture Holds Up

It makes the security function subject to its own controls

The uncomfortable question about any monitoring system is who monitors it. Putting detection in a member account answers it structurally: the SCPs that bind everyone else bind the security team too, their actions land in the same organisation trail, and the trail's output sits in an account they cannot delete from. None of that depends on the security team's good intentions, which is the point.

Delegation is reversible; management-account sprawl is not

A delegated administrator can be deregistered and re-registered. Resources built in the management account tend to stay there, because moving them is a migration and nobody schedules one. Choosing delegation early is choosing the option that stays open.

One account is the right number, and it is not obvious

The instinct to split further — one account per service, or per team — costs more than it saves. Cross-account findings correlation is the whole value of Security Hub and Detective, and it is exactly what account boundaries make harder. The separation that pays for itself is the one AWS draws: configuration in one account, output in another. Further subdivision buys isolation you did not need and loses correlation you did.

It gives the log archive account a reason to be boring

Because analysis happens in the tooling account, the archive account needs no analysts, no dashboards, no query tooling and almost no human access. That is what makes the Object Lock and delete-denial from the previous post practical rather than obstructive — nobody has a legitimate reason to be in there.

Key Architecture Decisions

1

Never let the tooling account own the bucket it fills

This is the decision the whole architecture turns on, and the convenient answer is the wrong one. The security team needs to read the logs, so putting the bucket where they already have access removes a step. It also removes the separation, because the ability to configure the trail and the ability to delete its output land on the same principal.

Concrete rule

Trail configuration, Config delivery channel and GuardDuty export all point at buckets in the log archive account. Grant the tooling account read on those buckets and nothing else — no s3:DeleteObject, no s3:PutObject, no lifecycle configuration. If an analyst needs to run queries, run them from the tooling account against the archive, not the other way round.

2

Inventory the response roles, because nobody else will

Detection is read-only and easy to approve. Response is not: isolating an instance, revoking a key, quarantining a bucket and applying a firewall rule all require a role in the target account that the tooling account can assume. Each is requested separately, justified separately, and approved separately — and the set is never read as a set.

The question to ask quarterly

Not "is each of these justified" but "what is the union of what this account can do across the organisation". In most estates that union is broader than any production role, and it belongs in the same review as break-glass. Scope each response role to the specific actions its automation performs, and use a permissions boundary so the tooling account cannot grant itself more.

3

Export findings, because the console is not a record

AWS gives the reason directly: GuardDuty active findings are exported to a central S3 bucket in the Log Archive account, so you can retain the findings beyond 90 days. A finding you can still see in the console is a finding that has not aged out yet, which is a different thing from evidence.

Why this matters more than it looks

An investigation usually starts well after the event. The finding that explains an incident discovered in November may have been generated in July, and the console cannot help. Export is the step that turns detection into something an investigation can use, and it is the step most often left for later because nothing breaks without it.

4

Delegate everything that supports it, in one pass

Partial delegation is the worst of both worlds: some services managed from the tooling account, others still run from the management account where no SCP reaches them, and no single place to answer "what is our coverage". The service list is long and known, so treat it as one piece of work rather than a service at a time.

Order that avoids rework

Register the delegated administrator first, then enable each service with auto-enable for new accounts, then point its output at the archive. Doing it the other way — enabling per account and delegating later — leaves per-account configuration that the organisation-level setting does not override, and finding those stragglers is harder than not creating them.

Which account does what

	Management	Security tooling	Log archive
Bound by SCPs?	No	Yes	Yes
Configures detection	Registers the delegate, then stops	Yes	No
Holds the output	No	No — read only	Yes
Can delete the output	Technically yes, which is why it holds nothing	No	Nobody, under Object Lock
Response automation	No	Yes	No
Human access	Break-glass only	The security team	Almost none

The row that decides the design

Read the "can delete the output" row across. The management account can, which is why the previous posts argued for keeping it empty. The tooling account must not, which is why the bucket is elsewhere. And in the archive account nobody can, because compliance-mode Object Lock takes the question out of IAM entirely. Three accounts, three different answers, and the architecture is what makes them different.

Reference: what the tooling account may do to the archive

The bucket policy in the log archive account, from the archive's point of view. The services write; the tooling account reads; nobody deletes.

Log archive bucket — read for the analysts, write for the services, delete for nobody

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ToolingAccountReadsOnly",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::222233334444:root"
      },
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::org-log-archive",
        "arn:aws:s3:::org-log-archive/*"
      ]
    },
    {
      "Sid": "NobodyDeletes",
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "s3:DeleteObject",
        "s3:DeleteObjectVersion",
        "s3:PutLifecycleConfiguration",
        "s3:PutBucketPolicy"
      ],
      "Resource": [
        "arn:aws:s3:::org-log-archive",
        "arn:aws:s3:::org-log-archive/*"
      ]
    }
  ]
}

Two notes. The account principal delegates to account 222233334444 as a whole, so an administrator there still has to grant it onward — which is the cross-account behaviour from earlier in this series, and here it is working for you. And the explicit Deny covers s3:PutBucketPolicy, because a delete denial that can be edited away by the same principal is a comment rather than a control.

Closing Thought

The security tooling account is the least examined account in most organisations, which is an odd place for the one holding the most reach. It gets built during a consolidation, it accumulates response automation one justified request at a time, and because everything it does is defensive nobody applies the scrutiny they would to a production role with the same permissions.

The architecture AWS describes is not really about consolidation. It is about drawing one boundary that consolidation naturally erases: the difference between configuring a control and owning what that control produced. Everything else in the reference architecture follows from taking that seriously, including the parts that look like extra work.

The question to ask of your own layout: if the person who administers detection wanted the record to say something different, how many accounts would they have to compromise? If the answer is one, the tooling and the archive are the same account and the last four posts in this series have been undone by a diagram. If the answer is two, the design is doing what it was built to do.

Next in this series

Security & Identity — that closes the account-structure arc. Next the block turns to the network boundary: VPC endpoints and the data perimeter, and why "it never leaves AWS" is a statement about routing rather than about who can reach your data.

AWS Architecture Series #43 — The account that watches everything