# Landing Zone Governance Controls Guide

Use this reference for AWS landing zone, Control Tower, Organizations, OU, account vending, guardrail, delegated admin, centralized logging, and audit/security account reviews.

## What people get wrong

The lazy story is:

> Control Tower deployed successfully, so the landing zone is governed.

Wrong. Landing-zone governance fails through account sprawl, OU drift, missing delegated-admin scope, weak SCPs, logging gaps, and unclear account lifecycle ownership.

Common bad assumptions:

- OUs mirror the org chart safely.
- SCPs are complete guardrails rather than coarse permission boundaries.
- Centralized logging exists because an audit account exists.
- Account vending is safe without lifecycle, budget, and ownership controls.
- Sandbox accounts are low risk.
- Control Tower drift is only an operational nuisance.

## Landing-zone failure modes

- Workloads are placed in OUs with wrong controls, data residency, or production isolation.
- SCPs block break-glass or deployments, or fail to prevent risky services/Regions.
- CloudTrail, Config, Security Hub, GuardDuty, Macie, IAM Access Analyzer, and log archive coverage differ across accounts/Regions.
- Account factory/vending lacks owner, cost center, environment, network, identity, and decommission metadata.
- Delegated administrator roles create hidden privilege concentration.
- Shared network/log/security accounts become single points of governance failure.

## Minimum safe workflow

1. Identify organization scope, management account constraints, Control Tower state, OUs, Regions, and account inventory.
2. Classify accounts by environment, data sensitivity, workload criticality, ownership, and lifecycle stage.
3. Review preventive controls: SCPs, Control Tower controls, Region restrictions, IAM boundaries, and break-glass path.
4. Review detective controls: organization trails, Config aggregators, Security Hub, GuardDuty, Macie, log archive, and alert routing.
5. Check account vending and decommission workflow for owner, budget, network, identity, tagging, and closure criteria.
6. Return governance gaps with blast radius, evidence level, owner, and staged remediation.
7. Do not recommend management-account or SCP changes without explicit approval and rollback plan.

## Verification targets

- AWS Organizations OUs, accounts, delegated admins, SCPs, tag policies, backup policies, and Region restrictions
- AWS Control Tower landing-zone version, enabled controls, drift status, Account Factory/account vending process
- log archive/audit/security account design, CloudTrail organization trail, Config aggregator, and S3/KMS log protection
- identity center/federation, break-glass, permission sets, and management-account access controls
- shared networking accounts, VPC sharing, Transit Gateway ownership, and account baseline templates
- account owner metadata, budgets, tags, support model, and decommission evidence

## When to push back

Push back if the user asks to:

- flatten OUs for convenience without blast-radius analysis
- deploy SCPs without testing break-glass and pipeline impact
- call Control Tower deployment proof of full governance
- skip centralized logs or delegated-admin coverage checks
- create accounts without owner, budget, lifecycle, and data classification
- mutate management-account controls from advisory review alone

# Official sources

Use this reference only when you need source grounding for AWS service behavior or the detailed source list.

## AWS documentation

Use these as starting points, not as proof of the user's live AWS state:
- https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html
- https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html
- https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html
- https://docs.aws.amazon.com/controltower/latest/controlreference/control-reference.html

## Grounding rule

Official documentation explains AWS service behavior. It does not prove the user's current account, Region, quota, resource configuration, IAM boundary, pricing, entitlement, or operational state. Prefer read-only AWS MCP or CLI evidence, repository evidence, or sanitized user-provided evidence for current-state claims.

## Current MCP/documentation refresh (2026-06-02)

Service facts from official docs:
- AWS Control Tower automates multi-account governance with controls, account provisioning, and drift prevention/detection around a landing zone.
- AWS multi-account landing-zone guidance emphasizes OU structure, workload isolation, and separating production from non-production environments.

Sampled live evidence:
- Read-only regional availability sampling reported AWS Control Tower and AWS Organizations as `isAvailableIn` in `us-east-1`, `us-west-2`, `eu-west-1`, and `ap-southeast-1`.
- Sampled product availability is not proof that a landing zone is enabled, healthy, drift-free, or compliant in the user's organization.

Review implications:
- Require evidence for organization structure, OUs/accounts, SCPs, delegated admin, controls/guardrails, identity center, logging/audit accounts, network boundaries, and drift.
- Do not infer landing-zone health from service availability; inspect Control Tower state, Organizations policy attachments, Config/CloudTrail coverage, and exceptions.

# Safety checklist

Use this reference before privileged, destructive, traffic-changing, cost-changing, compliance-impacting, or production-impacting recommendations.

## Non-negotiables

- Never ask users to paste secrets, access keys, session tokens, private keys, customer identifiers, or sensitive account data into chat.
- Use read-only AWS MCP or read-only AWS CLI evidence for live state when available; otherwise use repository evidence, sanitized user evidence, or official documentation and label the evidence level.
- Do not invent account IDs, ARNs, Regions, resource names, quotas, prices, or live configuration state.
- Require explicit user approval before privileged, destructive, traffic-changing, cost-changing, or production-impacting actions.
- Use current official AWS documentation for service behavior when the answer depends on AWS service details.
- Keep remediation least-privilege, reversible, and scoped to the requested workload or account boundary.

## Stress checks

- What can expose data?
- What can escalate privilege?
- What can break production or block rollback?
- What can create unbounded cost?
- What compliance or audit evidence is missing?
- What rollback or validation path is unproven?

## Evidence labels

Use `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live AWS state.

# Workflow and output contract

Use this reference only when performing the full review, implementation guidance, incident triage, or production-readiness pass.

## Review domains

Check these areas before giving a verdict:
- Management account, log archive, audit/security accounts, workloads, sandbox, infrastructure, and suspended account boundaries
- OU hierarchy, SCP/control inheritance, delegated admin, and policy staging
- Central CloudTrail/logging, Config/Security Hub posture, and evidence retention
- Account lifecycle, ownership, tagging, budgets, and exception process

## Safe workflow

1. **Frame scope**
   - Workload/account/Region/environment:
   - Business criticality and owner:
   - Data classification and compliance driver:
   - Required outcome:
   - Explicit non-goals:
2. **Collect evidence**
   - Prefer read-only AWS MCP or read-only AWS CLI evidence for current-state claims when available.
   - Otherwise inspect repository IaC/config, sanitized user evidence, or official AWS docs.
   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
3. **Stress-test risk**
   - What can expose data?
   - What can escalate privilege?
   - What can break production or block rollback?
   - What can create unbounded cost?
   - What evidence is missing?
4. **Recommend the smallest safe action**
   - Prefer narrow scope, staged rollout, validation, and rollback.
   - If the safest action is to stop and gather evidence, say that plainly.

## Output contract

Return this structure:
```markdown
# AWS Landing Zone Governor: <scope>
## Executive verdict
- Status: READY / READY WITH RISKS / NOT READY / NEEDS EVIDENCE
- Biggest risk:
- Evidence level:
## Scope and assumptions
- Confirmed:
- Unknown:
- Out of scope:
## Findings
| Severity | Finding | Evidence | Why it matters | Minimum safe action |
|---|---|---|---|---|
## Recommended actions
1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
## Validation
- Commands or checks:
- Expected result:
## Residual risk
- <risk or explicit none>
```