AWS landing zones on Control Tower, extended where it stops

The AWS assessment concentrates on structure, policy quotas and how much accelerator you genuinely need, because all three are awkward to change once workloads depend on them.

• Organisation and account inventory. Existing accounts, organizational units, applied policies and enrolment state, including anything created outside Control Tower.
• Organizational unit design against funding. Structure modelled on how work is funded and regulated rather than the current org chart, since policy and access inherit from it.
• Policy quota budgeting. Service control policy count and size planned against organisation limits, with detective controls kept out of preventive policy where possible.
• Accelerator scope decided. Which parts of the Landing Zone Accelerator you actually need, since deploying it means taking ownership of the codebase and its upgrades.
• Log archive and retention design. Central bucket structure, encryption key ownership and retention by log type, agreed before organisation-wide logging is switched on.
• Region governance plan. Which regions are opted into and how they are governed, because control coverage varies by region and an unreviewed region is a real gap.

Control Tower first as the foundational landing zone, then only the accelerator components you need on top of it. Vending and central logging are established before workload accounts arrive.

• Control Tower as the foundation. The landing zone established with dedicated log archive and audit accounts, and drift detection against the intended baseline enabled from the start.
• Organizational units before accounts. Hierarchy and inherited policy in place first, so a vended account lands somewhere governed rather than being moved afterwards.
• Vending through Account Factory. New accounts produced as pre-approved configurations, with the Terraform path used where the platform is already Terraform.
• Transit hub with route segmentation. A central router for network and hybrid attachments, with route tables enforcing isolation and shared out to member accounts.
• Logs centralised into the archive account. Organisation-wide API activity and member account log groups streamed to a central bucket the source accounts cannot alter.
• Delegated administration everywhere. Security and posture services operated from a delegated account so the management account is not the day-to-day operations account.

The AWS model gives you a hard permission ceiling at organisation scope and no way to remediate from the same place. Both facts shape the design.

• Permission ceilings at organisation scope. Service control policies and resource control policies applied to organizational units, setting a limit an account administrator cannot raise.
• Identity Center as the only human route. Workforce sign-in and permission sets granted to groups across member accounts, with long-lived local users removed.
• Remediation built, not assumed. Config rules paired with automation for anything that needs fixing rather than blocking, because organisation policy cannot deploy or repair.
• Log archive immutable to its sources. A dedicated account holding centralised logs, encrypted with customer-managed keys that the logged accounts do not control.
• Organisation-wide service enablement. Posture and vulnerability services turned on across accounts from a delegated administrator rather than per account and per region by hand.
• Management account kept out of use. Delegated administrators for security services, with the management account reserved for the small set of actions that genuinely require it.

Account sprawl is the predictable consequence of account-level isolation, so the vending path and the account baseline are what keep it manageable.

• Vending faster than a manual request. The Account Factory path timed against creating an account by hand, because if the governed route is slower it will be worked around.
• Accelerator ownership transferred properly. Handover on the codebase, its configuration files and the upgrade process, since you now operate it rather than consume it.
• Account baseline documented. What a vended account arrives with, what the permission ceiling forbids, and how a team requests something outside it.
• Long-running operations planned for. Enrolment and landing zone update durations built into release planning rather than discovered during a go-live weekend.
• Region opt-in process agreed. Who approves a new region and what governance must be in place before a workload may deploy there.
• Decision records handed over. One record per structural choice covering organizational unit design, policy strategy and accelerator scope, with the reasoning kept.

The three things that degrade an AWS landing zone are drift, accelerator version skew, and regions that were opted into and then forgotten.

• Drift reported and owned. Control Tower drift findings routed to a named owner, with recurring drift treated as a process failure rather than a technical one.
• Accelerator upgrades on a cadence. Version currency maintained deliberately, because skipped releases accumulate skew that eventually blocks a change you need urgently.
• Policy quota headroom watched. Service control policy count and size tracked against organisation limits before a new control is designed rather than after it fails to attach.
• New account and region conformance. Vended accounts and newly opted-in regions checked against the intended baseline, since coverage varies by region.
• Log archive cost and retention. Central bucket growth and lifecycle policies reviewed monthly, because organisation-wide logging grows with every account added.
• Exception register reviewed. Policy exceptions revisited at their review date and either renewed deliberately or removed.