SAP-C03 Multi-Account Governance: Control Tower, SCPs and RCPs, Centralized Logging, Config Compliance and Patching

Structure organizational units (OUs) around the policies you need to apply, not around the company's org chart. Service control policies (SCPs), resource control policies (RCPs), Control Tower controls and many delegated security services are attached or targeted at OU level and inherited by every account beneath, so the fewest attachments come from an OU tree whose branches match your policy split.

The AWS multi-account guidance uses a small set of recurring OUs:

Design rules that decide scenarios

• Environment beats business unit for guardrails. When guardrails differ by environment rather than by owner, an OU per business unit forces the same policy to be attached once per business unit, and every new unit adds more attachments. Environment-based Workloads OUs (Prod, NonProd) let each policy set be attached once. Tag-based conditions are weaker when account administrators can edit their own tags.
• Stage policy changes. A syntactically valid SCP can still block production through an over-broad condition; validators do not catch logic errors. A Policy Staging OU with realistic test accounts catches them without disrupting developers in NonProd.
• Park, don't remove. An account that must stay open for review but run nothing goes into a Suspended OU. Removing it from the organization would also remove organization trails, guardrails and central security tooling.
• Keep the management account empty. SCPs and RCPs never restrict the management account, so no workloads and no routine security work belong there. Delegate administration of security services to a security tooling account instead.

An AWS Control Tower landing zone is a governed multi-account environment built on AWS Organizations: Control Tower creates a Security OU with two shared accounts, turns on organization-wide CloudTrail and AWS Config logging, sets up IAM Identity Center access, and applies controls to every OU you register.

• Management account: where Control Tower itself runs. Keep people and workloads out of it.
• Log archive account: the central repository that receives CloudTrail and AWS Config logs from every enrolled account.
• Audit account: where security and compliance engineers work. Control Tower creates cross-account roles from it into enrolled accounts (read-only and administrative) and aggregates security notifications there. It is deliberately separate from the log archive so the people investigating are not the people who can touch the evidence store.

Region deny

The Region deny control, set in the landing zone settings or applied per OU, blocks API activity outside the governed Regions while exempting global and Region-independent services such as IAM, Route 53 and CloudFront. Because Control Tower manages it, it follows the governed-Region list when that changes. A hand-written SCP on aws:RequestedRegion can do the same job, but you must maintain the exemption list and Region list yourself.

Drift, re-registration and auto-enrollment

Drift is any change made outside Control Tower that leaves an account or OU different from what Control Tower configured, for example moving an enrolled account between OUs in the Organizations console, or editing a Control Tower-managed SCP by hand. Fix it from Control Tower:

• Re-register the OU (or update the account) to re-apply that OU's baselines and controls to its accounts.
• Turn on auto-enrollment in the Control Tower settings (available in recent landing zone versions) so that an account moved into a registered OU through Organizations is enrolled with that OU's baselines and controls automatically. Auto-enrollment prevents future gaps; it does not repair drift that already exists, and moves between registered OUs with different configurations can still need a re-register.

Editing managed SCPs by hand or shuffling accounts again only creates more drift.

Preventive, detective or proactive controls

Choose the control behavior by when the problem must be caught and which tools create the resources. Control Tower controls come in three behaviors, enabled on registered OUs and reported in the Control Tower console.

Two consequences come up repeatedly:

• A requirement to stop a noncompliant resource during an infrastructure-as-code deployment, judged on properties that no SCP condition key exposes, is the job of proactive controls, provided the resources are created through CloudFormation.
• "Block it from every tool and also report what already exists" needs two controls: a preventive SCP for new creation and a detective Config rule for the existing estate. Read what the detective rule actually evaluates: the managed rule behind encrypted-EBS-volume checks, for example, evaluates only volumes attached to instances, so unattached volumes are outside its scope. When writing the SCP, cover every API that creates the resource. EBS volumes, for example, are created by ec2:CreateVolume and also by ec2:RunInstances at launch, and both support the ec2:Encrypted condition key.

Provision accounts through Control Tower so that every new account is created in a registered OU and enrolled from the start, with the landing zone's logging, the OU's controls and IAM Identity Center access. Accounts created directly in Organizations or invited from outside need a separate enrollment step. Pick the provisioning path by how requests arrive and which infrastructure-as-code tool the team uses.

As a rule, AFT fits teams that already work in Terraform and want account requests to go through Git review and a pipeline; it is the option with infrastructure to run. AFC fits teams that customize with CloudFormation templates and want to keep requesting accounts from the console with nothing extra to operate. Creating accounts with the Terraform aws_organizations_account resource bypasses Control Tower enrollment, and Service Catalog products or StackSets launched into existing accounts never create accounts.

A service control policy sets the maximum permissions for IAM users and roles in member accounts; it grants nothing. A request succeeds only if an identity or resource policy allows it and the SCPs at every level from the root to the account allow it.

Deny lists versus allow lists

• Deny-list strategy (the default): FullAWSAccess stays attached everywhere and you add explicit Deny statements. An explicit deny at any level wins.
• Allow-list strategy: you replace FullAWSAccess with policies that allow only approved services. An action survives only if every level in the path (root, each OU, the account) allows it. If a child OU's allow list omits a service its parent allows, accounts in that child lose the service even with AdministratorAccess.

What SCPs never restrict

• Users and roles in the management account.
• Service-linked roles, which services such as Auto Scaling use to act on your behalf. A Region-deny SCP does not stop an Auto Scaling group from replacing instances in that Region.
• Principals outside the organization. An SCP filters what your own identities can do; it does not evaluate an external account's request to your bucket. That gap is what RCPs close.

SCPs do apply to every member account however it joined, and to every request regardless of when the calling resource was created.

Exemptions for break-glass and pipeline roles

Exempt a role from a deny statement with a condition on aws:PrincipalArn, which for a role session carries the role ARN (arn:aws:iam::<account>:role/<name>), not the assumed-role session ARN. Use ArnNotLike (or StringNotLike) with a wildcard account ID to cover every account:

"Condition": {
  "ArnNotLike": { "aws:PrincipalArn": "arn:aws:iam::*:role/BreakGlassAdmin" }
}

StringNotEquals treats * as a literal character, and aws:SourceArn describes the resource a service acts for, not the caller.

A resource control policy sets the maximum permissions on resources in member accounts, whoever the caller is, including principals outside your organization. That makes RCPs the organization-wide tool for "our resources are reachable only by our identities", even when a developer writes a bucket or key policy that grants another account.

The core perimeter statement denies the supported actions when aws:PrincipalOrgID is not your organization ID. Two refinements decide whether it works in practice:

• AWS service principals (CloudTrail writing logs to S3, S3 server access logging) carry no organization ID. Exempt them with "BoolIfExists": {"aws:PrincipalIsAWSService": "false"} in the deny, or the deny breaks those features.
• Named outside parties, such as an external auditor's account, are exempted by adding aws:PrincipalAccount to the same StringNotEqualsIfExists block as aws:PrincipalOrgID. Conditions in one block are ANDed, so the deny matches only callers that are outside the organization and not the auditor. A bucket-policy grant or an allow statement cannot override an explicit RCP deny.

AWS RAM is not covered by RCPs; to stop sharing outside the organization, use an SCP on ram:RequestedAllowsExternalPrincipals (next section). IAM Access Analyzer detects external access but does not prevent it.

Share network resources such as transit gateways, subnets and Route 53 Resolver rules with AWS Resource Access Manager (RAM), after turning on sharing with AWS Organizations once from the management account (this enables trusted access for RAM). From then on a resource share can name the organization or an OU as the principal: accounts in that OU, including accounts added later, see the resource with no invitation to accept. Sharing to individual account IDs keeps the invitation workflow and per-account maintenance.

Keeping shares inside the organization

• Each share has an allow external principals setting; turning it off on existing shares is not a guardrail for future ones.
• To prevent any account from sharing outside the organization, attach an SCP that denies ram:CreateResourceShare and ram:UpdateResourceShare when ram:RequestedAllowsExternalPrincipals is true.

Transit gateway options that remove manual steps

Sharing the transit gateway lets workload accounts create VPC attachments, but two owner-side settings decide whether those attachments work without a network engineer:

Use custom route tables instead of the defaults when you need segmentation (for example, Prod and NonProd VPCs that must not reach each other); that trades automation for isolation and is typically automated with event-driven tooling. Transit gateway peering connects transit gateways, not VPCs.

Centralize with organization-level features that cover new accounts automatically and that member accounts cannot switch off, delivering into the log archive account.

CloudTrail organization trails

An organization trail, created once by the management account or a CloudTrail delegated administrator, logs every member account, including accounts that join later. Members can see the trail but cannot modify or delete it. Registering the security tooling account as delegated administrator lets the security team create and update organization trails without signing in to the management account; the trail stays owned by the management account.

Member accounts' log files land under AWSLogs/<organization-id>/<account-id>/, while an account trail writes to AWSLogs/<account-id>/. When converting an account trail into an organization trail, the bucket policy must allow s3:PutObject on AWSLogs/<organization-id>/* (with the trail's aws:SourceArn condition) or only the management account's files arrive.

CloudWatch Logs across accounts

Export tasks to S3 are per log group and batch-oriented, so they rarely fit "no per-log-group configuration".

Amazon Bedrock model invocation logging

CloudTrail records that a model was invoked, but not the prompt and response bodies. Only model invocation logging captures request and response data. Its destinations, CloudWatch Logs, Amazon S3 or both, must be in the same account and Region as the logging configuration. With CloudWatch Logs alone, large bodies and binary outputs such as images are not captured inline; adding an S3 location for large data stores them as objects referenced from the log record.

To keep every prompt and response in a log archive account that workload administrators cannot reach, enable logging locally in each account (rolled out to new accounts with automation such as a service-managed StackSet) and then copy it centrally, for example with a CloudWatch Logs centralization rule or S3 replication to the archive bucket. Centralization means a second copy the workload account cannot alter; access that leaves the only copy in the workload account does not meet that bar.

Use the same pattern for every security service: the management account designates a delegated administrator (usually the security tooling or audit account), and that account enables the service for existing members and auto-enables it for new ones. Invitations are only for accounts outside the organization, and custom EventBridge automation reimplements what auto-enable already does.

Amazon GuardDuty

GuardDuty is Regional. The delegated administrator and the auto-enable setting must be configured in every Region you use. Auto-enable acts only in the Region where it is set and only for accounts that join after it is set, so coverage gaps tend to appear per Region and per account age; check the organization configuration in each Region rather than adding accounts one by one.

AWS Security Hub CSPM

• Security Hub CSPM (the original Security Hub, with ASFF findings and security standards) evaluates most controls through service-linked AWS Config rules. If the Config recorder is not running in an account and Region, those controls show no compliance data.
• Central configuration: the delegated administrator picks a home Region, links the other Regions, and writes configuration policies (which standards and controls are on) associated with OUs or accounts. New accounts inherit their OU's policy, replacing drift-prone per-account, per-Region setup.
• Cross-Region aggregation moves findings to the home Region; it does not configure anything. Automation rules update or suppress findings; they never change resources.

The newer AWS Security Hub (generally available since December 2025) correlates findings from GuardDuty, Inspector, Security Hub CSPM and other sources in the OCSF format; the posture checks described above remain Security Hub CSPM.

Amazon Security Lake

Security Lake collects logs and findings, including CloudTrail management events, VPC Flow Logs, Route 53 Resolver query logs and Security Hub findings, across the organization from a delegated administrator, normalizes them to the Open Cybersecurity Schema Framework (OCSF), and stores them as Parquet in S3 buckets you own. Rollup Regions consolidate contributing Regions into one. Consumers are subscribers:

Plan new designs without CloudTrail Lake, which is closed to new customers.

Automate compliance with AWS Config rules evaluated against recorded configuration, deployed organization-wide, viewed through an aggregator, and fixed with Systems Manager Automation runbooks as remediation actions.

An aggregator shows a Region only when the recorder runs there and the aggregator's source Regions include it. Choosing all Regions (including future ones) covers expansion on the aggregator side, but the recorder must still be turned on in the new Region in every account.

Automatic remediation

• Attach a remediation action to a rule, pointing to an AWS-owned Automation runbook (for example, one that turns on S3 Block Public Access or removes an open security group rule), and set it to run automatically. After the runbook fixes the resource, the rule re-evaluates it as compliant.
• The runbook runs in the member account under an IAM role that must exist there. When the rule and remediation are deployed organization-wide in a conformance pack, deploy that role with a service-managed StackSet with automatic deployment so new accounts get it too.
• Security Hub CSPM findings can trigger an EventBridge rule and a Lambda function, but that is custom code to maintain; Security Hub CSPM automation rules only edit findings.

Use Amazon Inspector to find vulnerabilities and AWS Systems Manager Patch Manager to install operating system patches; detection and remediation are separate jobs. GuardDuty is threat detection, not vulnerability management.

Amazon Inspector across the organization

• A delegated administrator activates scan types (EC2, Amazon ECR, Lambda) for members and auto-activates them for new accounts. Scanning is continuous and event-driven (new packages, new images, newly published CVEs), so there are no scan servers or schedules.
• EC2 scan modes: agent-based scanning relies on the SSM Agent (the instance must be a Systems Manager managed node). In hybrid mode, Inspector scans managed instances with the agent and eligible unmanaged instances agentlessly from EBS snapshots, which suits appliances where no software may be installed.
• ECR re-scan duration: with enhanced continuous scanning, an image is re-evaluated against new CVEs only while it is inside its configured duration, measured from push and from last use. Rarely run images fall out of scope with a short duration; lengthening it keeps them monitored without pipeline changes.

Patch Manager at scale

• A patch baseline decides what is approved and when: auto-approval rules by classification and severity (for example, Critical and Important security updates) with an approval delay in days, such as 7 for production and 0 for development.
• A Quick Setup patch policy decides where and when patching runs across accounts and Regions: created from the organization's management account, it targets OUs and Regions, sets a scan-only or scan-and-install operation with separate scanning and installation schedules (for example, daily scans for compliance reporting, installs only in a Sunday maintenance period) and reports compliance centrally.
• Per-account maintenance windows repeat the setup; EC2 Image Builder helps only when instances are replaced; Inventory collects metadata but installs nothing.