Most organizations built their AWS landing zone as a project: a few weeks of design, an account vending process, a handful of guardrails and a celebratory go-live. Two or three years later, the same landing zone often has hundreds of accounts, organizational units nobody remembers creating, exceptions granted under deadline pressure and controls that no longer match how teams build. The landing zone did not fail. It simply was never operated.
The AWS governance toolbox has changed substantially since many of those landing zones were designed. Resource control policies, declarative policies, automatic account enrollment, a controls-only mode for AWS Control Tower and a re-engineered AWS Security Hub all arrived between late 2024 and the end of 2025, and Control Tower became available in the AWS European Sovereign Cloud in January 2026. This playbook explains how to turn those capabilities into a repeatable governance operation, the kind a mature internal platform team or managed service partner should run every week.
Why Landing Zone Governance Is an Operations Problem
A landing zone is a living system with four moving parts: the account structure, the identity model, the guardrails and the shared services such as logging, networking and security tooling. Each part drifts for predictable reasons:
- Organizational change. Reorganizations, acquisitions and new product lines create accounts and OUs faster than governance can classify them.
- Service evolution. AWS releases new services and features constantly. A guardrail written against yesterday’s API surface may not cover today’s.
- Exception creep. Temporary exemptions become permanent because nobody owns their expiry.
- Tooling sprawl. Teams add their own Terraform modules, pipelines and security scanners that bypass or duplicate central controls.
Treating governance as continuous operations means defining owners, cadences, metrics and change processes for each of these parts, exactly as you would for a production application.
What Changed in the AWS Governance Toolbox
If your landing zone design predates 2025, these changes are worth reviewing because several of them remove long-standing workarounds.
Three layers of organization policy
AWS Organizations now offers three complementary policy families. AWS’s documentation summarizes the distinction clearly: service control policies (SCPs) cap the maximum permissions of principals at the API level, resource control policies (RCPs) cap the maximum permissions on resources, and declarative policies enforce a desired service configuration in the service’s control plane rather than by blocking API calls. Declarative policies also apply to service-linked roles, which SCPs and RCPs do not govern, and they continue to hold when a service introduces new APIs. If a declarative policy is detached, the attribute reverts to its previous state.
This layering matters operationally. SCPs remain the right tool for “nobody in this OU may disable CloudTrail.” RCPs are the right tool for “no resource in this organization may be accessed by principals outside it,” which previously required consistent resource policies on every bucket, key and queue. Declarative policies are the right tool for configuration baselines such as EC2 settings that should simply be true everywhere. AWS has also expanded the declarative policy family well beyond EC2; the Organizations documentation now lists policy types for services including Amazon S3, Amazon Bedrock, Amazon Inspector, Amazon GuardDuty and Security Hub. Declarative policies also provide an account status report showing the current state of supported attributes across accounts, plus custom error messages that can point users to internal guidance.
Control Tower: controls-only mode and automatic enrollment
In November 2025, AWS introduced a Control Tower experience that lets organizations use AWS managed controls from the Control Catalog without adopting the full prescribed landing zone. This is significant for enterprises that built a well-architected multi-account environment with their own tooling and avoided Control Tower because it required restructuring. The same month, AWS announced automatic account enrollment: with landing zone version 3.1 or later and the feature enabled, moving an account into a registered OU enrolls it and applies that OU’s baselines and controls, removing those of the previous OU.
Operationally, automatic enrollment turns OU placement into the primary governance lever. That is powerful and risky at the same time: a mistaken account move now changes the control set immediately. Treat OU moves as change-controlled events.
Account Factory for Terraform plan-only runs
In September 2026, Account Factory for Terraform (AFT) gained plan-only customization runs, letting teams preview the Terraform changes an account would receive without applying them. For governance teams, that provides a safe way to test baseline changes against real accounts before rollout.
A unified Security Hub
In December 2025, AWS made the re-engineered AWS Security Hub generally available. It correlates signals from Amazon GuardDuty, Amazon Inspector and Security Hub CSPM, adds near real-time risk analytics, exposure findings and attack path visualization, and can be enabled across an entire organization. For landing zone operators, this provides a single place to see whether guardrails are producing the intended security outcome, not just whether controls are switched on.
A Reference Governance Model
A governance model that scales typically combines the following elements:
- An OU taxonomy based on control needs, not org charts. Group accounts by the guardrails they need, for example Security, Infrastructure, Workloads-Production, Workloads-NonProduction, Sandbox, Suspended and Policy-Staging. Business-unit structure belongs in tags and cost allocation, not in OU depth.
- A layered guardrail catalog. Document every control with its layer (SCP, RCP, declarative policy, Control Tower detective or proactive control, AWS Config rule), the risk it addresses, its scope, its owner and its exception process.
- A data perimeter. Use RCPs and SCPs together to ensure that only trusted identities access trusted resources from expected networks.
- Centralized evidence. Organization-wide CloudTrail, AWS Config aggregation and Security Hub provide the audit trail and posture view.
- Policy as code. All organization policies, Control Tower configuration and account baselines live in version control with peer review, automated testing and staged rollout.
Identity deserves its own line in the model. Human access should flow through a central identity provider and AWS IAM Identity Center with permission sets mapped to roles, not long-lived IAM users. Workload identities, including the new identities used by AI agents and automation, need the same discipline: named owners, scoped permissions, and regular review of what they actually use. Many landing zone incidents trace back not to a missing guardrail but to an over-privileged role that nobody remembered existed.
A landing zone is only as strong as the process that changes it. Put every guardrail in code, give every exception an expiry date and test every policy change in a staging OU before it reaches production.
The Weekly and Monthly Operating Rhythm
Governance operations work best on a predictable cadence. Here is a rhythm we recommend as a starting point.
Daily
- Triage new critical and high Security Hub exposure findings and route them to workload owners.
- Review account creation and OU move events against the approved request queue.
- Check landing zone and Control Tower drift notifications.
Weekly
- Review open exceptions approaching expiry and confirm renewal or removal with owners.
- Review the declarative policy account status report for unexpected attribute states.
- Summarize posture trends for each production OU and flag regressions.
Monthly
- Review new AWS service launches and feature changes against the guardrail catalog, including whether new services need allow-listing or new controls.
- Run a policy regression test suite in the staging OU, using AFT plan-only runs where relevant.
- Report governance KPIs to security and platform leadership.
Quarterly
- Re-validate the OU taxonomy against how the organization actually builds.
- Run a tabletop exercise for a governance failure, such as an account accidentally moved to Sandbox or a leaked cross-account role.
- Review landing zone version currency and plan upgrades.
Rolling Out Policy Changes Safely
The most common governance outage is self-inflicted: an SCP or RCP that blocks a legitimate workflow in production. A safe change pipeline looks like this:
- Design. Write the policy, the intended effect and the known affected principals or resources. For RCPs, enumerate legitimate external access, such as AWS services acting on your behalf or partner accounts, before drafting conditions.
- Analyze. Use CloudTrail data and IAM Access Analyzer findings to estimate which current activity the policy would block.
- Stage. Attach to a Policy-Staging OU containing representative accounts and run automated tests that exercise common workflows.
- Canary. Attach to one low-risk production OU, monitor access-denied errors for a defined period and keep a rollback ready.
- Promote. Roll out to remaining OUs in waves, with communication to affected teams and custom error messages that link to guidance.
- Verify. Confirm the control produces the intended posture change in Security Hub or the declarative policy status report.
For declarative policies, remember that detaching a policy restores previous attribute values. That is helpful for rollback but means you should record the pre-policy state if you ever need to explain why a configuration changed back.
Metrics That Show Governance Is Working
Leadership rarely needs a list of enabled controls. It needs evidence that risk is going down and delivery is not being slowed. Useful metrics include:
- Percentage of accounts enrolled in governance and in the correct OU.
- Number of active exceptions, average age and percentage past expiry.
- Mean time to remediate critical exposure findings by OU.
- Account vending lead time from request to ready.
- Number of policy-related production incidents per quarter.
- Coverage of the guardrail catalog by automated tests.
Pair security metrics with delivery metrics. If vending lead time climbs or developers report repeated access-denied friction, governance is becoming a bottleneck and teams will route around it.
Common Pitfalls to Avoid
- Deep OU hierarchies that mirror the org chart. They multiply policy inheritance paths and make the effective policy for any account hard to reason about. Keep the hierarchy shallow and control-driven.
- Using SCPs for everything. Before RCPs and declarative policies existed, teams stretched SCPs to cover resource access and configuration baselines. Those statements are hard to read and easy to break; migrate them to the layer that fits.
- Data perimeters without an inventory of legitimate external access. An RCP that blocks access from outside the organization will also block partner integrations, third-party monitoring tools and cross-organization backups unless they are explicitly allowed.
- Exceptions without expiry. Every exemption should carry an owner, a justification and an end date, and the weekly review should enforce it.
- Treating the management account as a workload account. Keep it minimal, restrict access tightly and delegate administration of security services to a dedicated security account.
- Upgrading the landing zone only when forced. Version lag blocks new features such as automatic enrollment. Plan landing zone upgrades as routine maintenance.
Worked Example: Re-Platforming Governance for a Growing Estate
Imagine a software company with about 180 AWS accounts. Its landing zone was built in 2022 with custom tooling rather than Control Tower. It has eleven OUs, several created for individual projects, 40 SCP statements accumulated over time and no RCPs. Security reviews keep finding S3 buckets and KMS keys with overly broad resource policies.
A practical twelve-week plan might look like this. In weeks one to three, the team inventories accounts, OUs and policies, maps each SCP statement to a risk and owner, and designs a target OU taxonomy of seven OUs. In weeks four to six, it enables the Control Tower controls-dedicated experience on the existing organization, registers the new OUs with automatic enrollment, and moves a pilot group of non-production accounts. In weeks seven to nine, it introduces an RCP-based data perimeter that restricts access to organization principals, first in staging and then in non-production, after analyzing CloudTrail for legitimate external access. It also applies declarative policies for configuration baselines that were previously enforced by fragile detective rules. In weeks ten to twelve, it migrates production accounts in waves, consolidates the remaining SCPs into a smaller documented set and turns on organization-wide Security Hub with exposure findings routed to owners.
The outcome is not just fewer findings. It is a governance system the team can explain, test and change safely, with clear evidence for auditors and a lower risk of self-inflicted outages.
Sovereignty, Regulation and the Road Ahead
Two trends will shape landing zone governance through 2027. The first is digital sovereignty. With Control Tower available in the AWS European Sovereign Cloud since January 2026, European organizations can apply the same governance patterns in sovereign environments, but they should plan for separate organizations, identity boundaries and operating procedures rather than assuming a single global landing zone. The second is AI workloads. As teams adopt Amazon Bedrock and agentic applications, governance must cover model access, data access by agents and the new identities those agents use. The expansion of declarative policies to services such as Amazon Bedrock is an early sign of where AWS is heading.
Expect governance operations to become more automated as well. AI-assisted operations agents can already investigate incidents; similar techniques will increasingly help analyze policy impact, suggest exception remediation and summarize posture changes. The human role will concentrate on risk decisions and design.
Conclusion
The AWS landing zone toolbox in 2026 is more capable than ever: layered SCPs, RCPs and declarative policies; Control Tower controls without a forced redesign; automatic enrollment; plan-only testing for account baselines; and a unified Security Hub that shows whether controls deliver outcomes. Capability is not the same as governance, though. The organizations that stay secure and fast are the ones that operate their landing zone with clear ownership, a steady cadence, safe change pipelines and metrics that leadership understands. Whether you build that capability internally or with a managed service partner, start by putting every guardrail in code and every exception on a clock.
How Hanoi Technology Can Help
Hanoi Technology designs and operates AWS landing zone governance as code, from OU taxonomy and layered policies to continuous posture reporting.
Further Reading
- Declarative policies – AWS Organizations User Guide
- AWS Control Tower introduces a Controls Dedicated experience – AWS News Blog
- AWS Control Tower supports automatic enrollment of accounts – AWS What’s New
- AWS Control Tower release notes, January 2026–Present – AWS Documentation
- AWS Security Hub is now generally available with near real-time risk analytics – AWS What’s New