Practical Cloud Landing Zone Security Considerations

Editorial note: This is a sample article included with the initial site build. Its publication date is editorially assigned to demonstrate the blog's historical-date capability and can be changed in the frontmatter.

Most cloud security incidents I have reviewed trace back to decisions that were made — or not made — before the affected workload ever existed. The subscription had no policy guardrails. Logging was per-team and optional. The network path to the internet was whatever the first engineer configured.

That is why the landing zone is the highest-leverage security artifact in a cloud program. Here are the considerations that consistently matter.

Decide the boundaries before the hierarchy

Management-group trees are easy to draw and painful to rearrange. Before drawing one, answer three boundary questions:

Blast radius: what is the largest set of resources one compromised credential should be able to touch?
Ownership: who answers the page when a resource in this scope misbehaves?
Policy variance: which workloads legitimately need different rules (regulated data, internet-facing, sandbox)?

The hierarchy falls out of the answers. Doing it in the other order produces org charts, not security boundaries.

Guardrails: audit first, then deny

Policy-as-code is the mechanism that makes a landing zone more than a diagram. The rollout pattern that avoids open war with delivery teams:

1. Deploy policies in audit mode      → see real violations
2. Fix or exempt existing violations  → with expiry dates on exemptions
3. Flip to deny                       → new violations become impossible

Guardrails that belong in nearly every environment:

Allowed regions (data residency and cost)
Required tags — enforced, or the tagging standard is fiction
Diagnostic settings deployed by policy, not by request
Public network exposure denied by default, with a documented exception path
Encryption expectations for storage and databases

Identity boundaries are part of the platform

A landing zone that standardizes networks but not access patterns is half finished. The platform should define:

Role standardization — a small set of built-in-role assignments per archetype, instead of bespoke permissions per project
Privileged access — platform-level roles behind just-in-time elevation with approval
Workload identities — managed identities as the default; credential secrets as the documented exception

Logging is a default, not a request

Central log collection configured by policy, at the management-group level, is the single control that most improves incident response later. It also answers the awkward question of who pays: platform-funded logging removes each team's incentive to quietly turn it off.

What not to centralize

Landing zone security fails in the other direction too. Signs the platform has overreached: every deployment needs a platform-team ticket, exemption requests outnumber deployments, and shadow subscriptions start appearing on corporate cards. The platform owns boundaries and defaults; teams own what happens inside them.

Summary

Landing zone security is boundary design: management groups drawn from blast-radius and ownership answers, guardrails rolled out audit-first, identity patterns standardized at the platform, and logging that nobody has to ask for. Get those right early — they are the decisions that are expensive to change and cheap to inherit.