A landing zone starts aging as soon as real workloads begin using it.
The change is usually gradual. A new account lands in an Organizational Unit (OU) that no longer fits its risk profile. A service control policy gains an exception that stays long after the project ends. An IAM permission set becomes broader through successive requests. A network route added for one workload quietly becomes part of the accepted architecture. The environment can still look governed while the original design and operating reality have started to separate.
AWS treats landing zones as configurations that require ongoing updates. AWS Control Tower documentation states that central cloud administrators are responsible for keeping the landing zone current and resolving reported drift. AWS Control Tower landing zone version 4.0, released in November 2025, is another reminder that the foundation itself continues to change after deployment.
This is where AWS landing zone management becomes an operating discipline — one that sits inside the broader scope of AWS cloud consulting services that help enterprises keep governance design aligned with how their environment actually runs. The question is no longer whether the foundation was designed correctly. It is whether account structures, access models, network patterns, security controls, and governance rules still fit the environment now.
A sound landing zone lifecycle needs two tracks: technical currency and organizational relevance. One keeps AWS-managed components and baselines current. The other tests whether the enterprise still wants the same rules.
Why AWS Landing Zones Age After Setup
Landing zones reflect a point-in-time operating model. Account structure mirrors current business units. Policies reflect known risks. IAM reflects existing teams. Network architecture reflects known connectivity needs.
Then conditions change. New workloads arrive. Business units reorganize. Security teams add tooling. Platform teams introduce new provisioning patterns. Development teams adopt services that earlier policies did not consider. A control that once protected the environment can later obstruct a valid operating pattern, while a permissive exception can outlive its reason for existing.
That is why cloud foundation maintenance should examine design intent, not only configuration health.
A landing zone can be technically healthy and still be outdated — the same tension explored in the evaluation of AWS landing zone vs Control Tower, where design intent and platform capability can quietly diverge over time.
This distinction matters because AWS environment drift is only one form of divergence. AWS Control Tower detects several forms of governance drift and supports reset, OU re-registration, account updates, and API-based remediation for specific cases. Yet an environment can remain technically in sync while its OU model or policy set no longer fits current needs.
A mature AWS landing zone management practice therefore asks two questions:
- Has the deployed configuration moved away from the approved baseline?
- Has the approved baseline moved away from current operating requirements?
They lead to very different actions.
Account Changes Create the First Lifecycle Pressure
Every new account inherits a governance position.
An account enters an OU. That OU carries policy inheritance, controls, logging expectations, access patterns, and often network assumptions. If the OU model no longer reflects workload type, ownership, or data sensitivity, account placement becomes an architectural issue.
This is why account baseline updates require more thought than applying the latest template.
AWS documents an important distinction between landing zone versions and baseline versions. Some landing zone updates require subsequent account updates because the associated baseline changes, while others do not. That relationship should shape the landing zone lifecycle.
| Review area | What to examine | What may have changed |
| OU structure | Account purpose, ownership, risk grouping | Business units, workload classes, regulatory boundaries |
| Account baseline | Logging, roles, configuration, controls | Baseline version, security requirements, operating standards |
| Account placement | Inherited policies and controls | New exceptions, new workload types, reorganized teams |
| Provisioning path | Account Factory or automation logic | Tags, Regions, networking, security tooling |
Existing accounts should not be treated as finished objects. When the shared foundation changes, older accounts may need deliberate remediation or re-baselining.
Start Policy Review With Exceptions
Most policy reviews begin with the policy document. A stronger review begins with the exception register.
Exceptions show where governance is under pressure. One exception can be justified. A recurring pattern usually indicates friction between the baseline and the operating model.
A practical landing zone policy review should examine:
- Controls that teams repeatedly ask to bypass
- Temporary exceptions that have passed their expiry date
- Policies that no longer map to an active risk
- New AWS services that the current policy set does not address
AWS Control Tower supports preventive, detective, and proactive controls — capabilities that are central to how AWS Control Tower accelerates secure multi-account scaling across enterprise cloud organisations. Preventive controls restrict actions through service control policies, detective controls identify noncompliant resources, and proactive controls evaluate supported CloudFormation resources before deployment.
The useful lifecycle question is whether the control still belongs at that enforcement point.
A restriction may remain valid for production OUs while becoming unnecessary elsewhere. A detective control may need wider coverage. A custom policy may no longer be necessary if an AWS-managed control covers the same requirement.
This is where AWS landing zone management becomes governance engineering rather than policy accumulation.
IAM Baselines Need a Separate Review Rhythm
Access models change through organizational change as much as technical change.
Teams split. Responsibilities move. External support providers gain access. Emergency permissions become routine. Permission sets gain actions to solve immediate delivery problems and retain them afterward.
An IAM review inside the landing zone lifecycle should test whether role purpose and trust boundaries still match current responsibilities:
- Administrator roles and permission sets
- Cross-account trust relationships and owners
- Break-glass access and monitoring
- Service roles created by automation
- Temporary rights that have become permanent
AWS Prescriptive Guidance treats authentication and authorization as a core landing zone design area alongside account structure, networking, logging, and resource configuration. Identity therefore belongs in ongoing foundation review, not only initial design.
Network Baselines Drift Through Approved Change
Network drift often comes from legitimate requests.
A workload needs partner connectivity. Another requires a new inspection path. A new Region enters use. Shared services gain routes that were not part of the original design. Each change may be approved, yet the accumulated network can become something nobody would design deliberately from scratch.
Network baselines therefore need periodic review as connectivity requirements change.
The review should compare current connectivity with declared connectivity across route tables, Transit Gateway attachments, VPC endpoints, inspection paths, DNS dependencies, hybrid connectivity, and Region usage.
The aim is to decide which changes have become standard and which remain exceptions. That distinction matters to cloud foundation maintenance because undocumented acceptance creates hidden architecture, and hidden architecture becomes a dependency.
Security Controls Need Versioning and Ownership
Security control sets tend to grow faster than they are rationalized. Duplicate controls create noise. Overlapping controls blur ownership. Old controls can remain attached to risks addressed elsewhere.
A second landing zone policy review should therefore test control purpose as well as coverage.
For each control, record the risk addressed, applicable OU or account population, enforcement method, owner, exception route, and evidence used to confirm effectiveness.
AWS notes that Control Tower controls are continuously updated. Periodic comparison against the current catalog is therefore part of sensible governance.
Without ownership, a control set becomes a record of past decisions rather than a current operating model.
Plan AWS Control Tower Updates as Platform Changes
The AWS Control Tower lifecycle deserves its own maintenance path because foundation updates can have downstream account consequences.
AWS recommends keeping the landing zone on the latest version. Its guidance also separates the landing zone update from member-account updates, and some version changes require accounts to move to a newer baseline.
Before an update, review:
- Current and target landing zone versions
- Baseline compatibility
- Registered OUs and account update requirements
- Customizations touching managed resources
- Logging and control dependencies
- Remediation steps if drift appears
Afterward, confirm that member accounts, OUs, shared accounts, and custom controls are in the expected state.
The second AWS Control Tower lifecycle review should also test whether newer service capabilities can replace older custom mechanisms. Retaining custom machinery by default increases support effort and makes intended governance harder to read.
Treat Drift as Evidence, Not Just a Defect
The second appearance of AWS environment drift deserves analysis before remediation.
A drift event can indicate an unauthorized change. Repeated drift on the same managed resource can indicate something else: the baseline may no longer support a recurring operating requirement.
AWS Control Tower automatically detects supported drift, while resolution can require reset, OU re-registration, account update, or API action depending on the type.
| Drift pattern | Likely meaning | Governance response |
| One-off manual change | Process failure or emergency action | Restore baseline and review access |
| Repeated change to same control | Baseline may conflict with operating need | Review policy intent |
| Similar drift across accounts | Provisioning pattern may be outdated | Update account baseline |
| Drift after platform update | Dependency or customization conflict | Correct integration and retest |
This classification turns remediation data into design feedback. It also prevents teams from repeatedly restoring a baseline that repeatedly needs alteration.
Use Different Maintenance Clocks
A useful landing zone lifecycle should not depend on one annual review.
Different parts of the foundation change at different rates. Drift needs frequent attention. IAM needs ownership checks. Account baselines need review when provisioning patterns or Control Tower baselines change. Network design needs review around major connectivity changes.
One operating model can use four review clocks:
- Event-driven: account creation, OU move, new Region, major network change, Control Tower update
- Monthly: Drift, failed controls, expired exceptions, account status
- Quarterly: IAM, SCPs, control coverage, exception patterns, shared-services dependencies
- Annual: OU design, account strategy, network architecture, policy intent, ownership model
The aim is to stop foundational decisions from becoming permanent simply because no review was scheduled.
Strong AWS landing zone management keeps the approved baseline close to current operating reality.
Treat Account Baselines Like Product Versions
The second use of account baseline updates needs a versioned operating model.
Each baseline version should state what changed, why it changed, which account groups are affected, what validation is required, and how older accounts will be handled.
That makes landing zone lifecycle decisions easier because accounts can be separated into three states:
- Newly provisioned accounts on the current baseline
- Existing accounts scheduled for update
- Approved exceptions on an older baseline for a defined reason
Without that distinction, “current” becomes ambiguous. Two compliant accounts created years apart can carry materially different foundations.
End Lifecycle Reviews With Decisions
A review that ends with a slide deck has missed the purpose.
Each review should produce a small set of decisions: update, retain, remove, standardize, remediate, or accept as an exception. Ownership and due dates matter because foundation debt often grows through deferred decisions.
The final AWS landing zone management check should ask whether six areas still agree with one another: account structure, policy intent, IAM ownership, network architecture, security controls, and platform baseline state.
When one changes, the others may need review.
Conclusion: Keep the Foundation Current
A landing zone is meant to make cloud operations predictable. That promise weakens when the environment changes while the foundation remains frozen.
The strongest landing zone lifecycle practices treat the foundation as a maintained operating system for the AWS organization. A disciplined landing zone lifecycle also makes change history visible before exceptions become permanent. Accounts are revisited. Policies are questioned. IAM reflects current responsibility. Network baselines capture accepted architecture. Controls retain clear ownership. Control Tower updates account for downstream impact.
AWS provides mechanisms for version updates, drift detection, resets, OU re-registration, account updates, and managed controls. The harder work is deciding when the approved design itself needs revision.
That is the real test of AWS landing zone management: whether the foundation still represents how the organization intends to operate now, rather than how it operated on setup day.
Author
Yogita Jain
Content Lead
Yogita Jain leads with storytelling and Insightful content that connects with the audiences. She’s the voice behind the brand’s digital presence, translating complex tech like cloud modernization and enterprise AI into narratives that spark interest and drive action. With a diverse of experience across IT and digital transformation, Yogita blends strategic thinking with editorial craft, shaping content that’s sharp, relevant, and grounded in real business outcomes. At Cygnet, she’s not just building content pipelines; she’s building conversations that matter to clients, partners, and decision-makers alike.