Azure Enterprise-Scale: an ARM template set for landing zones, not a turnkey tenant

The documentation left the repository, and that changes the project

The first thing the README does is tell you its documentation has moved. An Important callout states that all documentation has moved to a central consolidated technical documentation library at https://aka.ms/alz/techdocs, and the homepage of the repository is https://aka.ms/alz.

This is a meaningful change in what the repository is. What remains is implementation, and the README's own framing confirms it: the Enterprise-Scale reference implementations are intended to support adoption by providing prescriptive guidance based on authoritative design for the Azure platform as a whole.

So if you arrive expecting a self-contained guide to Azure landing zones, you will not find one here. The documentation is on the Microsoft platform, versioned and updated separately from the templates, and the two can drift. Anyone pinning a template version needs to check the documentation site for the matching guidance rather than assuming the README reflects current practice.

The repository still carries its own architecture document at docs/EnterpriseScale-Architecture.md, and the README links to it as the place where the design principles and critical design areas are defined. That file, not the README, is where the arguments live.

Five ARM template scenarios, not one

The repository provides five templates representing different scenarios, composed using ARM templates, and there is a Deploy To Azure button plus a link to the Azure Landing Zones options page at aka.ms/alz/aac.

Five is the important number. The README stresses that the architecture is modular by design and allows customers to start with foundational landing zones that support their application portfolios, and that it scales alongside the business requirements regardless of scale point. Not every enterprise adopts Azure the same way, and the technical considerations and design recommendations may lead to different trade-offs based on the scenario. Some variation is expected.

That framing cuts against the most common failure mode with reference architectures, which is deploying the largest template because it is there and then discovering it funds far more than the organisation needs. Here the intended entry point is the smallest landing zone that supports the application portfolio you actually have, whether those applications are migrating or being built new.

The stated outcome is a strategic design path and target technical state for the Azure environment, with a baseline built on a multi-subscription design for the entire tenant regardless of scale point.

Multi-subscription and 1:N landing zones as the organising idea

Two claims in the README do most of the architectural work.

The first is the multi-subscription design applied across the whole tenant. The second is the enterprise-scale architecture leading to 1:N landing zones, which the repository presents as the route to both long-term self-sufficiency and migration velocity across the organisation.

The velocity argument is specific: the architecture includes designs for segmentation and separation of duty, which the README credits with letting teams act within appropriate landing zones. That is a governance design choice with an organisational consequence. Teams get autonomy bounded by where they sit in the subscription hierarchy, rather than a central platform team approving each request.

Operational excellence is described in similar terms: autonomy for platform and application teams with policy-driven governance and management. Governance is enforced by Azure Policy assignments rather than by a process document, which is why the repository is full of policy artifacts.

The compliance claim is the one to read carefully, because it is conditional. For reaching security and compliance requirements on a timeline, the README says that enabling all recommendations during setup ensures resources are compliant from a monitoring and security perspective. That is a statement about configuration, not about an audit outcome.

Automation surface: ARM, Policy, Bicep and Terraform modules

The automation story is listed as ARM, Policy, Bicep and Terraform Modules, which tells you the templates are not the only deployment path and that the project expects to be consumed rather than copied.

The repository layout supports that. `eslzArm/` is the ARM template area, `examples/` holds parameter files and worked examples, `workloads/` is separate from the platform layer, and `tests/` and `utils/` exist for validation and helper scripts. Top-level directories also include `src/` and `docs/`.

The examples are numbered, which is the clearest signal of intended order in the whole repository. The repository ships `examples/10-create-managementgroup.parameters.json`, then `examples/20-create-child-managementgroup.parameters.json`, then `examples/30-create-policydefinition-at-managementgroup.parameters.json`, and finally `examples/40-create-policyassignment-at-managementgroup.parameters.json`.

The numbering is the deployment sequence. Create the management group, then child management groups, then define a policy at the management group, then assign it. Note the scope in the filenames: policy definitions and assignments are applied at management group level, not at subscription level, which is the mechanism behind the governance claims above.

The examples directory is organised into subdirectories named `landing-zones/`, `management-groups/` and `policies/`, mirroring those three layers.

The precondition nobody skips: cross-discipline agreement first

The README has a section on conditions for success, and it is the part most likely to be ignored by someone who arrived to deploy a template.

It states that to get the intended value out of the reference implementation, readers must have a collaborative engagement with key customer stakeholders across critical technical domains such as identity, security and networking. It goes further: the success of cloud adoption hinges on cross-discipline cooperation within the organisation, because key requisite design decisions are cross cutting and, to be authoritative, must involve domain subject matter expertise and stakeholders within the customer.

There is also an assumption of prior knowledge. Readers are expected to have a broad understanding of key Azure constructs and services in order to fully contextualise the prescriptive recommendations.

Read together, these say the templates are the last step. The design decisions are the work. The README is explicit that the architecture is ultimately defined by the design decisions that organisations must make, and that it will continue to evolve alongside the Azure platform.

That framing is also why variation between customers is expected rather than a defect. If two enterprises end up with different topologies from the same repository, the repository is behaving as designed.

Maintenance rhythm, roadmap, and the contribution gate

This is a Microsoft-owned repository with an active release cadence and a governance process that has a cost.

Releases are tagged by date rather than by semantic version: 2026-04-29, 2026-08-07 and 2026-10-07 are the recent ones. The last push was on 2026-10-16, so the repository is being worked on.

Forward planning is explicit. The README states that the architecture is continuously updated to align with advancements in the Azure platform and insights from customer feedback, and points to the Azure Landing Zones Roadmap at aka.ms/alz/roadmap for what is coming. Anyone adopting these templates should treat that roadmap as part of the upgrade plan, since a platform alignment change can alter what a previously compliant deployment looks like.

Contributions are not a plain pull request. Most contributions require agreeing to a Contributor License Agreement hosted at cla.opensource.microsoft.com, declaring the right to grant rights to the contribution. The project also ships SECURITY.md, SUPPORT.md and CODE_OF_CONDUCT.md.

The code is under the MIT license. The CLA is the constraint that matters if you plan to contribute upstream; the MIT license is the constraint that matters if you only consume the templates.

Where this reference architecture is the wrong tool

There are two obvious mismatches, and both are about organisational scale rather than technical capability.

A single team shipping one application does not need a multi-subscription tenant baseline. Deploying a landing zone hierarchy to hold one workload can add governance friction. The README's own answer is to start with foundational landing zones sized to the application portfolio, which for a small portfolio is small.

A team with no shared authority over identity, security and networking cannot satisfy the stated conditions for success. The templates will run and the governance model will not work, because policy assignments without an agreed design decision behind them just block deployments for reasons nobody can explain to a developer.

A third boundary is documentation. Because the guidance moved off the repository, this is not an offline resource. If your environment blocks access to the Microsoft documentation site, the README is not enough to reason about the architecture, and the architecture document at docs/EnterpriseScale-Architecture.md is the only local fallback the repository points to.

The comparison to make is not with other landing zone templates but with the alternative of designing your own subscription topology. Azure gives you management groups, Azure Policy and the portal, and a small organisation can use those capabilities. What the reference implementation adds is validated design and a starting configuration, and that is worth more only at a size where getting the design wrong is expensive.

Editorial conclusion

Adopt Azure Enterprise-Scale if you are standing up an Azure tenant for an organisation large enough that subscription topology, identity, governance and logging have to be settled before the first workload ships, because the value is the multi-subscription baseline and the policy assignments that keep it compliant rather than any single resource template. Do not adopt it for a single team or a single application: the README states plainly that the success of cloud adoption hinges on cross-discipline cooperation across identity, security and networking, and that readers are assumed to have a broad understanding of key Azure constructs before the prescriptive recommendations make sense. Verify three things before you deploy: that your stakeholders have already agreed the design decisions recorded in docs/EnterpriseScale-Architecture.md, that the template scenario you pick matches the scale point you are at rather than the largest one available, and that your CI can target these ARM templates at a management group rather than a subscription, since that is the scope the parameter files are written for. The MIT license applies to the code; contributions require a Microsoft CLA. The last push was on 2026-10-16, and releases are dated snapshots rather than version numbers, so track changes through the roadmap at aka.ms/alz/roadmap.

Frequently asked questions

Official sources

1. Azure/Enterprise-Scale on GitHub
2. License: MIT
3. Project website
4. README
5. Releases