Accounts, Guardrails, and the Landing Zone

Imagine a company that starts in the cloud with one account. Two years later it has forty, created by whoever needed one, named after people who have left, with production and experiments sharing a billing boundary and nobody able to say which team spends what. This is a fictional example. Repairing that structure may require ownership and policy changes, and sometimes moving resources between accounts.

A landing zone establishes a foundation before workloads arrive and can also bring an existing estate under managed controls. The design decisions below concern ownership, access, policy, connectivity, and cost.

What a landing zone is

A landing zone is the prepared environment workloads deploy into: accounts, identity, networking, policies, and shared services configured for their requirements. Microsoft describes Azure landing zones as an architecture for governing, securing, and scaling a multi-subscription environment.

Microsoft separates the platform landing zone, which provides governance, security, and shared resources, from application landing zones, where teams operate workloads within those guardrails. Its usual recommendation is one platform landing zone per Microsoft Entra tenant; this is a scope for shared capabilities, not a requirement to place every organization in one tenant.

One team owns the foundation and other teams receive prepared environments. A repeatable process must handle requests, provisioning, and handover. That process can start with manual fulfillment and gain automation as demand grows. A standards document alone does not provide a deployed environment.

Where to draw account boundaries

AWS accounts, Azure subscriptions, and Google Cloud projects provide useful administrative, policy, and cost scopes, but their identity and inheritance models differ. Azure subscriptions can inherit RBAC assignments from management groups; Google Cloud projects inherit allow policies from folders and the organization. Creating a separate container does not remove those grants. Choose the boundary using the effective permissions and dependencies it will actually contain.

Consideration	What it pushes toward
Blast radius	Separate production and experimental administration where their risk differs. Review inherited roles, shared operators, and explicit cross-boundary grants as well as the container itself
Billing	A dedicated account can provide a coarse cost boundary when its owner mapping is maintained. Shared accounts and products spanning accounts need additional allocation metadata
Policy	Grouping workloads that share a regulatory or data-handling regime, so a policy can apply to the group rather than being restated per resource
Service limits	Splitting when a workload approaches a per-account quota — the reason the documentation lists environments as “one or more Azure subscriptions based on workload requirements, team ownership boundaries, or Azure subscription limits”

A hierarchy groups environments for governance. Azure management groups distinguish platform resources from workload resources while allowing both to inherit an appropriate common baseline. Apply additional policies at the scopes that need them rather than assuming the two layers should share no rules.

Group environments by stable policy needs where that reduces duplication. Team structures and regulatory requirements can both change. Keep ownership mappings current and review the hierarchy when either changes, including the effects on inherited access and policy.

In AWS, cross-account access can use a role in the target account or a resource-based policy that grants a caller access directly, where the service supports it. These routes have different authorization contexts: assuming a target role makes the request under that role, while a direct resource grant retains the external principal. Shared networks, services, and operators create further dependencies to inspect.

Verify effective permissions, inherited assignments, trust relationships, resource policies, and shared dependencies rather than counting accounts. Administrative separation also does not isolate provider failures: accounts using the same regional service can fail together. Resilience requires a separate assessment of zones, regions, and dependencies.

Guardrails, and what they cannot do

The hierarchy exists so that policies can attach to it. AWS’s service control policies are the clearest documented example of the mechanism, and the properties that documentation states are worth knowing before anyone writes one.

SCPs restrict permissions; they do not grant them. They bound the actions of IAM principals in the accounts to which they apply, while IAM identity-based or resource-based policies supply grants. Other applicable controls can limit access further. A permissive SCP alone gives no access, and least privilege remains a separate job.

SCP restrictions accumulate through the organization hierarchy. An action needs the required SCP allows at every level on the path, and an applicable explicit deny blocks it. Covered principals include a member account’s root user; a local administrator cannot override the restriction by attaching AdministratorAccess.

SCPs do not constrain management-account principals or service-linked roles. A delegated administrator in a member account remains covered. The resource location is not the test: an external principal granted direct access by a member account’s resource policy is not constrained by that resource-owning account’s SCP. If it assumes a covered role in that account instead, the role’s SCP restrictions apply. Protect resources with appropriate resource policies and, where supported, resource control policies as well. Keep the management account tightly controlled through other mechanisms.

Test guardrails on a limited set of accounts before attaching them broadly. AWS recommends gradual rollout through an organizational unit. Preserve the SCP allows needed along the hierarchy: removing FullAWSAccess without sufficient remaining or replacement allows can block operations, even when IAM grants remain. Test security tooling and recovery access as well as ordinary workloads.

Because these rules are configuration, they belong under version control and review like any other code, which is the practice covered under policy as code. And because a guardrail is a decision about what teams may not do, someone has to own that decision — the decision rights question, and the reason a guardrail with no named owner accumulates exceptions.

Identity comes before everything it protects

Federation and a managed identity source reduce per-account user administration. Provisioning, group membership, access reviews, and offboarding still need an explicit process across the connected systems. Central ownership is useful only when the resulting access state is verified.

The practices that follow from it are much cheaper to establish now than to retrofit. Human access through roles assumed on demand rather than long-lived credentials. Workload access through workload identities rather than keys in configuration. And the privileged path — who can change the foundation itself — separated from everyday access, with its use recorded where someone reads it, which is what an audit log is for.

Network choices with lasting effects

Separate the topology from the service that implements it. Hub and spoke describes how networks connect; managed transit describes who operates part of that connectivity. The two can be combined, and both interact with account boundaries.

• Hub and spoke. A central network holds shared egress, inspection, and on-premises connectivity; each workload network attaches to it. Centralized control of what leaves, at the cost of a shared component every workload depends on.
• Managed transit. A provider-operated transit service can connect workload networks in a hub-and-spoke design. It reduces operation of the transit fabric, but routing, inspection, capacity, and dependent appliances or services still require design and ownership.

Either way, some decisions belong in the foundation rather than in each workload: non-overlapping address ranges allocated centrally, and a single answer to how private name resolution works. Both are cheap now and painful later, as anyone who has tried to connect two networks with the same range knows.

Where data may physically sit is a constraint the topology can violate quietly, through a failover target or a replica in another jurisdiction — which is why data residency belongs in the foundation’s policy set rather than in a per-workload checklist.

What to centralize, and what not to

Microsoft recommends centralizing capabilities when they provide clear governance, operational, or economic benefits across workloads. Evaluate all three benefits against the dependency and coordination costs of sharing.

Identity, connectivity, logging, and policy enforcement are common shared capabilities. Deployment automation and managed database services can also reduce repeated work and improve operations. Providing those capabilities does not require the platform team to choose every application architecture or data model. Decide which choices remain with workload teams and which service commitments the platform owns.

For each candidate, compare duplicated effort, operating cost, reliability, security controls, and the time users spend waiting. A shared self-service delivery system can remove work; a queue for routine changes can add it. Central ownership alone does not determine which result follows.

A golden path should make common work easy while preserving required controls. Teams can use supported alternatives within the organization’s rules; an exception needs the designated authority, an agreed scope, and a support owner. This distinction between implementation choice and mandatory obligations is part of platform engineering. Changes to shared interfaces also need coordination with affected teams.

Ownership and cost allocation

Every account needs a named owner — a person or team accountable for what runs in it and what it spends. Without that, the predictable outcome is a set of accounts nobody will let you delete because nobody is sure what they do.

A dedicated account can provide coarse allocation when its ownership mapping is current. Account IDs alone do not identify the responsible team: accounts may be shared, a product may span several, and ownership may change. Combine that mapping with a cost allocation tag and workload usage records to answer finer questions about application, environment, or cost center.

Tag policies can require or add metadata on supported resource and API paths. Coverage depends on policy scope, exceptions, service support, and the inventory used to detect omissions. Azure Policy modify can populate tags, with remediation tasks for existing resources, but conflicting policies can reject a request or skip a modification depending on their configuration. Tagging is also separate from billing visibility: AWS cost allocation tags need activation. Verify the billing result, including timing and any backfill, and reconcile unallocated costs against the invoice. Untaggable resources, unsupported paths, missing billing metadata, and shared-cost rules can all leave work beyond tag enforcement.

Shared services need an allocation decision of their own: the hub network and the logging pipeline serve everyone, and either they are a platform cost or they are apportioned — either is defensible, and silence produces an argument at budget time. And the whole exercise only matters because it feeds a decision: a team that cannot see its own spend cannot manage it, which is where total cost of ownership stops being a spreadsheet and starts being an incentive. Separating workloads into their own accounts also gives the administrative kind of workload isolation as a by-product — subject to the crossings described earlier — which is a second reason to draw the boundary generously. It does not stop one workload from starving another of capacity, because that is a different boundary in a different place.

A build order, hardest-to-change first

1. Identity. Establish shared identity policy and federation across the directories and tenants the organization requires, with roles assumed rather than long-lived credentials issued. Verify provisioning and access across those boundaries; the rest of the foundation depends on that policy.
2. Account hierarchy and address plan. Plan both early, then distinguish hierarchy moves from resource migrations and address redesign. Moving an account or subscription to another parent changes inherited controls and needs impact review; it does not necessarily move its resources.
3. A small set of guardrails, tested on one group before going wider. Start with the few rules you would not negotiate — region restrictions, mandatory logging, denying the obviously dangerous — rather than a comprehensive policy set.
4. Connectivity and logging. Provide shared capabilities where requirements and operating benefits justify them, with explicit coverage and isolation for workloads that need separate arrangements.
5. The vending process. A team should be able to ask for an environment and receive one configured correctly. Until that exists, the foundation is a document.

Note what is absent: a complete policy catalog, a cost model for everything, a finished network design covering cases nobody has yet. A landing zone is meant to be extended as requirements appear, and a program that tries to finish it before the first workload arrives usually delivers neither. The same governance logic applies as elsewhere — the rules that hold are the ones someone owns and enforces, not the ones written comprehensively and read once.

References:

• Microsoft Learn, What is an Azure landing zone?
• AWS Organizations User Guide, Service control policies (SCPs)
• AWS IAM User Guide, Cross-account resource access in IAM
• Microsoft Learn, Pattern: Using tags in a policy definition
• Microsoft Learn, Azure management groups
• Google Cloud, Resource hierarchy access control
• AWS Organizations, MoveAccount
• AWS Billing, Cost allocation tags
• Microsoft Learn, Azure Policy modify effect
• FinOps Foundation, Allocation
• CNCF, Platforms White Paper