A landing zone is the prepared foundation of a cloud environment. Ideally it is established before the first production workload, but it can also be introduced into an existing environment. AWS describes a multi-account environment with security and compliance guardrails [3]. Microsoft provides an adaptable reference architecture for Azure [1].

It is not a product you buy, and it is not a single resource. It is a design decision that ends up as configuration: where the boundary between two applications runs, who is allowed to do what, which rules apply everywhere, and how the next environment comes into being.

Why the foundation comes before the first application

The usual sequence is the other way round. A project needs an environment at short notice, someone sets it up, it works. With the second project the same thing happens again, and by the twentieth nobody knows all the environments any more.

Three things are then missing at once: a reliable boundary between environments, one place where rules apply to everyone, and a way to assign costs to the people responsible for them. Each of these gaps can be closed individually, but only with production running alongside.

That is why AWS explicitly recommends using several accounts from the start rather than a single one: the account is the isolation boundary for identity and access management, no access is allowed between accounts by default, and sharing has to be enabled explicitly [4].

So the effort does not disappear, it moves. Before the first production workload the structure costs design time. After the fiftieth, rebuilding it costs a project of its own.

The building blocks, independent of the provider

Seven building blocks appear in every implementation. The names change, the tasks remain.

  • Tenant and account boundaries. Which unit separates two applications from each other, and what do you cut along: per application, per environment, per team? That unit is also the boundary for permissions, quotas and usually for billing.
  • Network foundation. Address ranges, egress to the outside, connectivity to your own data centre and name resolution. The addressing plan and DNS are the two decisions that are hardest to correct later.
  • Identity and permissions. Where do the accounts of people come from, where those of machines, and which role applies at which level? Without that answer, personal access with permanent permissions appears.
  • Policies and guardrails. Assess and enforce technical requirements centrally where possible, such as permitted regions, encryption and tags. Assignments, exemptions and evaluation results provide evidence. Organisational measures require supporting documentation.
  • Logging. Who changed what and when, and where does that trail live? It belongs in an environment the application teams have no write access to.
  • Cost allocation. Each unit receives an owner and a cost centre. Assigning these later can make retrospective allocation harder or incomplete.
  • Provisioning as code. Versioned templates make consistent provisioning, reviews and changes easier. Manual steps remain possible, but need the same requirements and a traceable process.

These decisions are connected: access models need clear boundaries and central guardrails need an appropriate scope. Code makes the agreed structure easier to repeat. What is Infrastructure as Code? explains the approach.

Three implementations side by side

The same concept on three platforms. For each of them the same three questions apply: what is the construct called, what is the smallest unit, and how are guardrails enforced?

Azure

Microsoft calls its own implementation the Azure landing zone and describes it as the standardised approach for all organisations using Azure [1]. The structure is a hierarchy of management groups with subscriptions underneath them.

An important organisational boundary in Azure is the subscription. The platform landing zone provides shared capabilities. An application landing zone contains a workload’s environments; each environment can use one or more subscriptions. These can be provisioned consistently through subscription vending [1].

The guardrails come from Azure Policy. An assignment applies to its scope and all child resources inherit it; subscopes can only be excluded explicitly [2]. The deny effect rejects a change that breaks the rule. Microsoft recommends starting with an auditing effect and only enforcing afterwards [2]. For building the environment, Microsoft explicitly recommends infrastructure as code with Bicep or Terraform over the portal route [1].

The details, from network topology to the mistakes that get expensive, are covered in the practice article Azure Landing Zone: building blocks, decisions, mistakes.

AWS

AWS treats the same task as a multi-account strategy. A landing zone there is the multi-account environment based on security and compliance best practices, the enterprise-wide container for the organizational units, accounts, users and resources that are meant to be governed [3].

The smallest unit is the AWS account. It acts as the isolation boundary for identity and access management, and by default no access is allowed between accounts [4]. Accounts are grouped into organizational units; AWS also recommends keeping the security OU clean and placing further security-related accounts in an OU of their own [4].

The guardrails are called controls there, colloquially guardrails. AWS Control Tower sets up the landing zone and applies controls to keep the environment from diverging from best practices; there are preventive, detective and proactive ones [3]. Underneath sit service control policies: they grant no permissions, they set the maximum available permissions for the users and roles of a member account [5]. New accounts are created through Account Factory, a configurable account template that also automates applying the controls [3].

STACKIT

STACKIT is the cloud provider of Schwarz Digits, the IT and digital division of the Schwarz Group [6]. According to the provider, its regions are located exclusively in Germany (eu01) and Austria (eu02) [7]; STACKIT bases its sovereignty claim on EU data centres, a provider headquarters in Germany and open source technology [6]. That is the reason the platform enters a shortlist at all: when a requirement dictates where data sits and which legal system the provider answers to. Anyone who needs a region outside those two countries needs a different platform.

The construct is called Resource Manager. The hierarchy reads organization, folder, project, resource. The organization is the root and a prerequisite for any service; folders group projects, for example by department, environment or region, but they are single-layer: a folder cannot contain other folders [8]. That is a visible difference to Azure, where a management group can hold child management groups [2]. Anyone used to multi-level grouping plans with exactly two levels above the project here.

The smallest unit is the project. The documentation calls it the fundamental container for cloud resources, defining the scope for ownership, resource consumption and access control; every resource belongs to exactly one project, and quotas are enforced at project level [9]. When a project is created, the parent organization or folder, the project type and the billing account are set [10]. Cost allocation therefore happens at the same place as the boundary.

The guardrails run through the role model. STACKIT uses role based access control: a policy assigns a role to a subject for a specific resource, and without a role binding nobody has access [11]. Permissions granted through role bindings on organizations and folders are inherited along the resource hierarchy to folders and projects; an inherited permission can only be removed where it was granted [11]. That is exactly why STACKIT recommends the folder as the level for an environment or a team: rules and access controls applied there secure all projects underneath [12].

The mechanisms are not equivalent. Azure Policy evaluates resource properties; AWS service control policies limit permitted actions and can evaluate supported conditions [2][5]. The cited STACKIT documentation describes role bindings and project quotas. Additional requirements can be checked in the provisioning workflow. To prevent those checks from being bypassed, direct change permissions must be restricted and exceptions controlled.

That fits the rest of the toolbox. A project can be created through the STACKIT Portal, the CLI and the API [10], and for the infrastructure inside it there is an official Terraform provider from STACKIT [13]. The route through code is therefore the same as on Azure and AWS, only with fewer levels above it.

Question Azure AWS STACKIT
Name of the structure Azure landing zone Landing zone, multi-account environment Resource Manager
Level above management group, can be nested organizational unit organization and folder, folders single-layer
Organisational boundary subscription account project
Guardrails Azure Policy, inherited, deny effect controls and service control policies inherited role bindings and quotas
A new unit is created through subscription vending through Account Factory through Portal, CLI or API
As code Bicep or Terraform, recommended by Microsoft Account Factory for Terraform [18] official Terraform provider
The same task in three vocabularies. The mapping is approximate, not identical.

What stays the same in all three implementations

Three points hold regardless of the provider, and they are the reason the design transfers at all.

New environments follow an agreed standard. Automation makes this path more reliable as demand grows. Manual provisioning can also be controlled and traceable; consistent requirements and verification of their implementation are what matter [1].

Inheritance needs an appropriate hierarchy. All three platforms inherit certain requirements or permissions [2][5][11]. Depending on the platform, scopes, conditions or exemptions can further differentiate rules. The design must therefore account for the actual enforcement mechanisms.

Access and policies complement each other. Roles define which actions an identity may perform. Additional policies can further constrain actions or resource states. The design must make clear which mechanism addresses each requirement [2][5].

Where regulation comes in

Audits consider technical and organisational evidence. A landing zone can help demonstrate how cloud requirements are implemented and monitored. The required controls and evidence depend on the scope of the assessment.

ISO/IEC 27001 requires an information security management system, including the assessment and treatment of information security risks. The requirements are generic and intended to be applicable to all organisations, regardless of type, size or nature [14].

NIST SP 800-53 is a catalog of security and privacy controls for information systems and organizations. The controls are explicitly flexible and customisable and meant to be implemented as part of an organisation-wide process to manage risk [15].

The German BSI's C5 criteria catalogue specifies minimum requirements for secure cloud computing and is aimed at providers, their auditors and their customers. The BSI states explicitly that customers should carry out their own risk assessment, obtain the provider's C5 report and repeat that analysis yearly [16].

Requirements that can be expressed technically should be enforced centrally, with results documented. Organisational measures, responsibilities and additional evidence remain part of the assessment. A policy report therefore does not replace a complete evaluation of the requirements [17].

Key takeaway

A landing zone connects clear organisational boundaries, shared capabilities and verifiable guardrails with a standard provisioning process. Azure subscriptions, AWS accounts and STACKIT projects fulfil similar roles but are not interchangeable. Code and automation help evolve the design consistently.

What you can decide afterwards

  • What you cut along: per application, per environment or per team, and which of those boundaries is also the billing boundary.
  • Which rules apply centrally through inheritance, and which of them may reject a change rather than only report it.
  • Whether requirements on data residency and sovereignty drive the platform choice or are checked only after the choice is made.
  • Who creates a new unit: an automated path or a person with a ticket.

Frequently asked questions

Is a landing zone the same as an Azure landing zone?

No. The Azure landing zone is Microsoft's implementation of the concept, with its own terms and its own reference architecture [1]. The concept itself is vendor-neutral; AWS and STACKIT solve the same task with different constructs.

Do we need this for a single application as well?

Not every environment needs the full implementation. Even one application needs clear ownership, appropriate access and security rules, and defined operations. Protection requirements, availability targets and planned growth determine the necessary components.

Can a landing zone be built the same way across several providers?

The building blocks transfer, the terms and the enforcement do not. Management group, organizational unit and folder resemble each other but behave differently, for instance in the depth they allow. Whoever runs both puts the terms deliberately side by side instead of treating them as equal.

When is STACKIT the right choice?

When a requirement dictates where data sits and which legal system the provider answers to. STACKIT names EU data centres and a provider headquarters in Germany as the basis of its sovereignty claim [6] and runs regions in Germany and Austria [7]. Anyone who needs worldwide regions or a specific niche service of a hyperscaler decides differently.

Sources

Read on

Cloud & Platform Azure Landing Zone: building blocks, decisions, mistakes Fundamentals What is Infrastructure as Code? Cloud & Platform Terraform for teams: state, modules, review Service Cloud Engineering