Cloud organization landing zones: AWS Organizations, Control Tower and account boundaries
Explain landing zones through AWS Organizations, Control Tower, account boundaries and policy ceilings. Plan enrollment, shared services and exceptions without assuming governance is automatic.
TL;DR: A landing zone establishes the account structure, identity access and shared controls on which workloads are placed. AWS Organizations provides organization-level structures and policies; Control Tower can establish and govern a landing zone within that organization.
Start with ownership and failure boundaries
An account boundary can separate production from experiments, isolate billing ownership and reduce the reach of administrative mistakes. It is not a substitute for resource-level permissions or a recovery strategy. Define who owns each account, what data it holds and which central services it depends on.
Organizational units group accounts for administration and policy application. Design them around control requirements and operating responsibility. Mirroring every temporary reporting line can create constant account moves and surprising inherited-policy changes.
A landing zone also needs an account provisioning path, log destinations, access recovery and network decisions. Creating a folder structure alone leaves workload teams to discover the missing pieces during their first deployment.
The diagram is illustrative. Central security and logging arrangements depend on the selected landing-zone version and configuration. Do not memorize a fixed account count as the definition of a landing zone.
SCPs constrain permissions; identities still need grants
Service control policies define limits for affected member-account principals. They do not grant IAM permissions. A principal still needs an applicable permission grant, and the complete authorization evaluation can include other policies and explicit denies. AWS's SCP documentation also states that SCPs do not restrict users and roles in the management account.
Suppose a sandbox role has an IAM grant to create resources in two regions, while the applicable SCP permits only one. The role cannot use the second region under that combination. Conversely, allowing a region through the SCP does not give every role permission to create resources there.
Keep the management account's workload and access footprint small. A broad assumption that organization controls constrain every identity equally can conceal a powerful exception at the top of the hierarchy.
Control Tower governance has an enrollment scope
Control Tower can establish a landing zone in a new or existing organization. Existing organizational units and accounts do not all become governed merely because a landing zone exists. Registration and enrollment scope matter. AWS documents this in deployment planning.
| Design choice | Evidence to inspect | Failure from assuming completion |
|---|---|---|
| Account enrollment | Actual governed-account inventory | Legacy account misses expected controls |
| Central logging | Delivery, retention and access checks | Enabled trail produces inaccessible evidence |
| Region restrictions | Applicable policies and exceptions | Automation fails in an undeclared region |
| Account vending | Owner, budget and access defaults | Unowned account persists after a project |
A control can prevent an action, detect a violation or participate in another enforcement path depending on the control type. Describe the specific control and its response. “Guardrails enabled” is too vague to explain whether a dangerous API request is blocked immediately or reported afterward.
Work through an existing-account migration
Assume an acquisition brings twelve existing accounts into a planned operating model. Inventory identities, organization membership, network dependencies and log destinations first. Test one low-risk account against the intended policies before applying a broad restriction to production accounts.
A region-deny policy may interrupt a backup copy or a shared identity workflow. The right response is to identify and narrowly document the dependency, assign an owner and define expiry for any exception. Leaving every account unrestricted because one exception exists abandons the original design; forcing the policy without checking dependencies can break recovery.
Verify that centralized evidence remains accessible if a workload account is compromised. Test log retrieval and access boundaries with synthetic events in an authorized environment. Merely seeing a configured CloudTrail resource does not demonstrate that the intended events arrive or that an attacker cannot remove the only useful copy.
Translate the objective when changing clouds
Azure management groups and subscriptions, and Google Cloud organizations, folders and projects, have their own policy inheritance and identity semantics. Use the same design questions about ownership and boundaries, then study the platform-specific evaluation rules. Do not translate an AWS account diagram into another provider by renaming every box and assuming equivalent permissions.
Self-check: a legacy production account belongs to the AWS organization, but expected Control Tower controls are absent. What must you inspect? Check whether its OU and account are within the governed enrollment scope, then inspect applicable controls and status. Organization membership alone does not prove that the account completed the landing-zone governance process.
For a Google Cloud implementation, hierarchy and Shared VPC separates project ownership, inherited access and the host-project network dependency.