Uundaji / Maelezo ya uwanda
Landing zone kabla ya mzigo wa kazi wa kwanza
Akaunti za wingu zinabaki rahisi kusimamiwa wakati usajili, mtandao na mipaka ya utambulisho vipo kabla ya kitu chochote kupelekwa.
Maelezo haya ya uwanda yamechapishwa kwa Kiingereza.
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.
