Landing Zone across clouds
The scaffolding every account, subscription or project inherits - Control Tower, the Azure management group hierarchy with policy, the GCP project factory - with logging, guardrails and identity set before the first workload.
6 verified modules, 2 of them live-tested apply→verify→destroy; the rest are static-validated, live-test pending.
Compare by provider
| Provider | Module | Verification |
|---|---|---|
| Alibaba Cloud | A Resource Directory Where Policy Can Attach and Accounts Can Be Deleted | static-validated |
| AWS | A Control Tower Landing Zone with Governed Regions, Logging Kept a Year, and Controls per Unit | static-validated |
| Azure | Azure Landing Zone Core | ✓ live-tested |
| Google Cloud | GCP Project Factory | ✓ live-tested |
| Huawei Cloud | An Organization Whose Policy Types Are Enabled Before a Policy Needs Them | static-validated |
| Tencent Cloud | An Organization That Says It Is a Billing Hierarchy, Not a Policy One | static-validated |
How to choose
Compare what the platform provides as a product (Control Tower is one; Azure and GCP are patterns the module assembles from management groups, policies, folders and projects), how a new account or project is vended and what it inherits, where the organisation-wide logs land and who owns that account, and how a guardrail is enforced rather than reported.
When not to use
A landing zone is the hardest thing to change later, because everything else sits on it. The unit hierarchy, the logging account and the region list are decisions to make with the people who will live in them for years, not defaults to accept.