Control Tower, Landing Zones, Central Logging, and Resource Sharing
Key Takeaways
- AWS Control Tower orchestrates AWS Organizations, AWS Service Catalog, and AWS IAM Identity Center to create a landing zone; it does not replace Organizations and it uses your existing management account as the payer
- Landing-zone shared accounts are the management account, the log archive account, and the audit account; mandatory, strongly recommended, and elective controls (historically called guardrails) then apply at the OU
- Account Factory vends or enrolls member accounts into OUs that have the Control Tower baseline, using roles such as AWSControlTowerExecution rather than ad-hoc IAM users
- Central telemetry is an organization CloudTrail trail into the log archive bucket, an AWS Config aggregator (typically in the audit account), and EventBridge rules that PutEvents onto a central bus authorized by aws:PrincipalOrgID
- AWS RAM shares owned resources such as subnets and Transit Gateway with an OU or the organization without invitations once sharing with Organizations is enabled from the management account in the RAM console or equivalent API
Control Tower, Landing Zones, Central Logging, and Resource Sharing
Quick Answer: AWS Control Tower builds and governs a landing zone on top of AWS Organizations. It creates log archive and audit shared accounts, vends member accounts with Account Factory, and enforces controls (historically called guardrails). Central logging uses an organization CloudTrail trail and AWS Config aggregation; notifications use Amazon EventBridge across accounts; shared networking uses AWS RAM, not duplicate Transit Gateways.
Task 1.4 knowledge explicitly lists Organizations, Control Tower, multi-account event notifications, and resource sharing. The professional skill is choosing the thinnest set of those tools that still gives you a governance model, not enabling every dashboard you have ever seen.
Control Tower versus Organizations
Organizations is the account tree, the bill, and the policy engine. Control Tower is an orchestration layer that uses Organizations, AWS Service Catalog, and IAM Identity Center to create a landing zone that follows AWS multi-account strategy guidance. You launch Control Tower from the existing management account. You do not create a second payer. Unregistered OUs in that same organization keep working; they simply are not governed by Control Tower until you enroll them.
A landing zone is the enterprise-wide container: default accounts, OU starting structure, network and security layouts, and the baseline you then extend. Control Tower documentation defines a well-architected environment as one that begins with a landing zone. The root is still not an OU. Control Tower does not govern enrolled accounts at the root; you govern them by placing them in registered OUs.
| Capability | Organizations alone | Organizations + Control Tower |
|---|---|---|
| Account tree, consolidated billing, SCPs/RCPs | Yes | Yes (Control Tower uses them) |
| Opinionated Security OU with log archive + audit accounts | You build it | Provisioned during landing-zone setup |
| Account vending with a baseline | Organizations APIs plus your own automation | Account Factory (Service Catalog) and enrollment of existing accounts |
| Drift detection against a published baseline | You build it | Native drift for the landing zone |
| Mandatory versus elective controls catalog | You write every SCP and Config rule | Catalog of preventive, detective, and proactive controls |
Control Tower is not mandatory to pass an architecture review. It is the right answer when the stem wants a prescriptive, repeatable landing zone with little custom orchestration. Custom landing zones (including Landing Zone Accelerator on AWS) still rest on the same Organizations primitives.
Shared accounts, Account Factory, and controls
Control Tower provisions three shared accounts:
- Management — billing, Account Factory, OU and control administration. Do not run production here.
- Log archive — repository for API activity and resource-configuration logs from accounts in the landing zone.
- Audit — restricted security and compliance account. Control Tower documentation describes programmatic review of other accounts through roles assumed by Lambda, not interactive login into every workload account. This is the natural home for a Config aggregator and other delegated security services.
Account Factory lets IAM Identity Center users (by default in the AWSAccountFactory group or a management group) provision accounts into an OU that has the AWSControlTowerBaseline. Existing accounts enroll only after the AWSControlTowerExecution role is present. Updating a provisioned product with a new Identity Center email creates a new Identity Center user; the old user is not deleted automatically. Recycle accounts by updating parameters rather than leaving abandoned IAM Identity Center principals behind.
Controls (the docs still treat guardrails as a synonym during a terminology transition) apply to an entire OU. Every account in that OU is in scope.
| Control type | What it does | Typical implementation |
|---|---|---|
| Preventive | Stops the API call | SCPs and RCPs |
| Detective | Records noncompliance after the fact | AWS Config rules |
| Proactive | Blocks noncompliant resources before they are provisioned from CloudFormation | CloudFormation hooks |
Mandatory controls always apply and cannot be switched off. Strongly recommended and elective controls can be enabled per OU. The management account is intentionally excepted from controls so you cannot brick the payer; those actions are still logged in the log archive. That exception is another reason never to host regulated workloads there.
Central logging and multi-account notifications
An organization trail in AWS CloudTrail logs events for the management account and every member. Only the management account or a CloudTrail delegated administrator can create or modify that trail. Console-created organization trails are multi-Region for enabled Regions in each member. CloudTrail creates a copy of the trail in members and uses the service-linked role AWSServiceRoleForCloudTrail. Member users can see the trail (describe-trails) but cannot turn it off, delete it, or change selectors. When an account leaves the organization, the trail copy and the service-linked role are removed from that account; historical objects that already landed in the log archive bucket remain according to that bucket’s retention.
Deliver organization-trail objects to the log archive account’s Amazon S3 bucket, with a bucket policy that trusts CloudTrail and typically restricts writes to the organization. Encrypt with a KMS key that the trail role can use. Pair that with AWS Config recorders in each account and an aggregator in the audit account. An aggregator is a read-only replica of configuration and compliance data from source accounts and Regions. If the sources are an organization, authorization from each member is not required. Aggregators do not deploy rules into source accounts and AWS documents that using aggregators does not incur additional Config aggregator charges beyond Config itself.
Amazon EventBridge is the multi-account notification fabric. A central bus in Security Tooling or Audit allows events:PutEvents from the organization with a resource policy conditioned on aws:PrincipalOrgID. Each workload account (or a StackSet) adds a rule whose target is that bus, plus an IAM role that permits the sending bus to PutEvents. Same-Region delivery is supported broadly; cross-Region delivery works only to documented destination Regions. This is how you fan GuardDuty findings, CloudTrail-detected change events, or custom application events into a single response pipeline without giving every account permission to invoke the responder.
Resource sharing with AWS RAM
AWS RAM lets the owning account share a resource with an account, an OU, the organization, or (for some types) IAM roles and users. Typical Task 1.4 shares are VPC subnets, Transit Gateway, Route 53 Resolver rules, and license configurations. Consumers see the resource in the native console as if it lived in their account—unlike a raw resource-based policy that requires the ARN to be known in advance.
Enable sharing with Organizations from the management account using the RAM console or enable-sharing-with-aws-organization. That call creates AWSServiceRoleForResourceAccessManager. Enabling trusted access only in the Organizations console does not create that role, and RAM org sharing then fails—a favorite Professional distractor. The organization must already have all features enabled.
Once org sharing is on, shares with the organization or an OU do not use invitations. Membership changes are live: an account moved into the Production OU gains the Transit Gateway share; an account that leaves the organization loses that share. RAM is Regional; principals use the share in the Region where the resource was created. You can share only resources you own, never resources that were shared with you. Duplicate Transit Gateways in every account is the anti-pattern RAM exists to prevent.
Exam scenario: landing zone for a regulated bank
A bank has Organizations with all features, no Control Tower, CloudTrail in some accounts only, and a Transit Gateway in a shared-services account that application teams cannot see. Leadership wants new country units onboarded in hours, immutable logs, and one inspection VPC.
Launch Control Tower from the existing management account. Accept the Security OU with log archive and audit. Register a Workloads OU and a Sandbox OU. Turn on mandatory controls plus preventive controls that protect the log archive. Create an organization trail (or let Control Tower’s logging baseline own that function) into the log archive bucket. Place a Config aggregator and Security Hub delegated admin in audit. Enable RAM org sharing from the management account, then share the Transit Gateway and inspection subnets with Workloads/Production. Vend each country unit with Account Factory into Production or Sandbox. Route EventBridge events from those accounts to a bus in audit whose policy allows the organization ID. Do not put the Transit Gateway in the management account, and do not ask each country team to create its own trail.
SAP-C02 decision rules
- Need a prescriptive landing zone and account vending? Control Tower on the existing management account.
- Need only a custom OU tree and SCPs? Organizations may suffice; still build log archive and audit accounts by hand.
- Need proof no member can disable logging? Organization trail plus a preventive control/SCP; member IAM cannot edit that trail.
- Need a compliance dashboard across accounts and Regions? Config aggregator in audit, not SSH into 80 accounts.
- Need one network hub? RAM-share Transit Gateway and subnets to an OU; do not clone the hub.
A bank already has AWS Organizations with all features enabled and a messy mix of OUs. Leadership wants a prescriptive landing zone, automated account vending, and mandatory preventive controls without creating a second payer account. What should you recommend?
Security wants one immutable log store and one compliance view across 80 member accounts and multiple Regions. Which design matches Organizations and Control Tower guidance?
Network wants every production VPC to attach to a shared Transit Gateway and to consume shared interface VPC endpoints without duplicating those resources. Workload accounts already sit in a Workloads/Production OU. What is the correct sharing approach?