Debesijos pagrindo zona prieš pirmąją apkrovą

A cloud account that grows without a plan becomes difficult to reason about. Resources appear in the wrong subscription, budgets surprise at month end, and nobody can say which environment a workload belongs to. A landing zone fixes that by deciding the structure before the first workload lands.

Separate the concerns

Management groups, subscriptions and resource groups should mirror how the business actually operates: production apart from non-production, shared services apart from workloads, and cost ownership visible per team. This is mostly admin work, and it is the highest-leverage admin work in the whole cloud estate.

Draw the network first

Virtual networks, address space and private endpoints are painful to retrofit once workloads depend on them. Decide hub-and-spoke or landing-point topology early, reserve address ranges generously, and keep internet egress behind a controlled path. A diagram on one page beats ten pages of rules.

Bound identity before workloads

Management identities, break-glass accounts and conditional access belong in the landing zone, not in a workload sprint. When identity boundaries exist first, every later deployment inherits least privilege instead of negotiating it.

Manage everything as code

Terraform from day one — even for the landing zone itself. Console clicks are how drift starts. A reviewed pull request that creates a subscription or a policy assignment is auditable proof for the next security review.

Further reading: Microsoft Cloud Adoption Framework — landing zones.