Before the First Workload: Accounts, Guardrails, and the Landing Zone

A company starts in the cloud with one account, because one account is what you get. Two years later there are 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. Each individual decision was reasonable. The sum is a structure that now costs a migration to fix.

The work that avoids this has a name and it happens before the first workload. Descriptions below follow the Microsoft and AWS documentation as of September 2026.

What a landing zone is

A landing zone is the prepared environment workloads are deployed into — accounts, identity, network, policies, and shared services already configured. Microsoft’s definition is a useful one to quote because it names the purpose rather than the contents: “a proven and flexible architecture for governing, securing, and scaling a multi-subscription Azure environment.”

The split that makes the concept practical is between two layers. A platform landing zone is “the centralized foundation that establishes governance, security, and shared resources for all your Azure workloads,” and most organizations “should have only one platform landing zone per Microsoft Entra tenant.” Application landing zones are “the environments where workload teams deploy and operate workload resources within the guardrails of the platform landing zone.”

Read that pairing as an operating model rather than a diagram. One team builds and owns the foundation; other teams receive a prepared space and work inside it. The thing that makes it real is the handover process — you need “a repeatable process for requesting, creating, and distributing application landing zones to workload teams,” and the documentation notes that automation matters more as requests grow. A landing zone that exists as a standards document rather than as something a team can be given is not a landing zone.

Where to draw account boundaries

Accounts, subscriptions, and projects are the same idea under three names, and they are the strongest administrative boundary a cloud provider offers — the default is that a principal in one cannot act in another. The considerations that decide where the lines go pull against each other, so the structure is a settlement rather than a derivation.

Consideration	What it pushes toward
Blast radius	Separating production from everything else, always. The account is the boundary that makes cross-environment access deliberate rather than accidental — though it is not self-enforcing, since the paths below can re-open it
Billing	One account per team or product, because the account is the boundary cost reports are naturally organized around
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 above the accounts is what keeps this from becoming forty unrelated boxes. Azure’s management group hierarchy “organizes all of your Azure subscriptions and applies governance standards to those subscriptions,” and the structural advice worth copying is that it “separates platform resources and workload resources” — the foundation and the things running on it get different rules.

Grouping by governance regime rather than by organizational chart is what saves the rework. Teams reorganize every couple of years; the set of rules that applies to regulated customer data does not. A hierarchy built around the current org chart needs rebuilding after the next restructure.

The first row needs a qualification, because separate accounts is often treated as a guarantee it is not. The separation holds by default and is undone by things you can grant deliberately: a role in the production account whose trust policy accepts a principal from the sandbox, and a resource-based policy on a production resource naming an outside principal directly — AWS documents that route explicitly, since “to share the resource directly, the resource that you want to share must support resource-based policies,” and in that case the caller “does not have to give up their permissions to receive the role permissions.” Shared networks, shared services, and a shared operator with access to both are the other paths.

So account separation is a strong default worth having, and verifying it means listing the trust relationships and resource policies that cross it rather than counting accounts. It also isolates administrative mistakes rather than provider failures: a regional or service-wide fault affects your accounts together, so resilience to that is a matter of zones and regions rather than of account boundaries.

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.

They restrict, they do not grant. “SCPs do not grant permissions to the IAM users and IAM roles in your organization. No permissions are granted by an SCP. An SCP defines a permission guardrail, or sets limits.” The effective permission is “the logical intersection” of what the policy allows and what identity-based and resource-based policies allow — so a team still needs its own permissions, and least privilege remains a separate job.

They are inherited and cumulative. “Any account has only those permissions permitted by every parent above it,” and within a member account they apply to everyone “including the member account’s root user.” That is what makes them a real boundary rather than a convention an administrator can override locally.

They have documented gaps. “SCPs don’t affect users or roles in the management account. They affect only the member accounts in your organization” — so the account at the top of the hierarchy is the one the guardrails do not constrain, which is precisely why it should hold as little as possible and be tightly controlled by other means. Service-linked roles are also outside their reach. What is not a gap, though it is often read as one, is a member account acting as a delegated administrator — the documentation states that policies apply to those accounts too, so a guardrail that would block a security tool’s own actions blocks them there as well.

Guardrails fail in opposite directions, and the documentation warns about one of those directions explicitly. A guardrail too broad blocks work and gets exceptions until it means nothing; a guardrail applied without testing locks people out of services they were using. AWS states it plainly: “AWS strongly recommends that you don’t attach SCPs to the root of your organization without thoroughly testing the impact that the policy has on accounts,” suggesting instead an organizational unit you move accounts into “one at a time, or at least in small numbers.” There is a specific trap too — removing the default full-access policy without replacing it means “all AWS actions from member accounts will fail.”

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

The single decision with the longest tail is where identities live. One directory with federation into every account beats per-account users, because it means joining and leaving the company is one action rather than forty, and an access review becomes something one team can run rather than forty reconciliations nobody completes.

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 topology is decided once

The shapes in common use differ mainly in who operates the interconnection between networks, and the choice interacts with the account structure rather than being independent of it.

• 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.
• A managed transit service. The provider operates the interconnection fabric, which removes the appliances you would otherwise run and moves the routing policy into the provider’s model.

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

Shared services are where landing zone programmes overreach. The criterion in Microsoft’s guidance is a good filter: “only centralize capabilities that provide clear governance, operational, or economic benefits across multiple workloads.”

Applied honestly, that usually puts identity, network connectivity, logging and security monitoring, and policy enforcement in the centre. It usually leaves application architecture, database engine choice, and deployment tooling with the teams — because centralizing those buys uniformity rather than governance, and it converts the platform team into a queue.

The test I would apply to any candidate: does centralizing it enforce something the organization actually requires, or does it merely replace a team’s choice with the platform team’s preference? The first is governance; the second is a bottleneck that teams route around, which is how shadow accounts appear.

Where a central team does provide something, the useful shape is an easy default rather than a mandate — a golden path that is the fastest way to do the common thing, with the option to deviate and own the consequences. That framing is the core of platform engineering and it applies to a cloud foundation exactly as it does to a developer platform.

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.

Cost allocation follows from the account boundary first and from tags second, which is the reverse of how most organizations attempt it. The account exists whether or not anyone is diligent; a cost allocation tag exists only if it was applied — by a person, by a template, or by a policy you configured for that purpose. So put the coarse boundary where it cannot be forgotten, and use tags for the finer questions: environment, cost centre, application.

Tags can be enforced, and the reason to say so is that tags are unreliable often stands in for we never configured enforcement. Policy engines can refuse to create a resource without the required tags, and can add or inherit a tag automatically — Azure Policy documents the second as the modify effect, including a pattern that “adds or replaces the specified tag and value from the parent resource group when any resource is created or updated,” with existing resources fixed through a remediation task. What remains genuinely outside tagging is what carries no tag: costs that are not resource-shaped, and the shared services whose apportionment is a decision rather than a lookup. Which is the real argument for the account boundary carrying the coarse split, rather than tags being unenforceable.

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. One directory, federation, roles assumed rather than credentials issued. Everything else assumes this.
2. Account hierarchy and address plan. Both cost a migration to revisit. Be generous with each.
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. Shared connectivity and logging, because every workload needs them and rebuilding them per team is waste.
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 catalogue, 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 programme 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? (documentation updated 2026-08-26); 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.