Feedback: Microsoft Docs completely skipped the Online and Corp Landing Zones designs

Hello @Rajesh Swarnkar

You're not missing it. The current Azure Landing Zone documentation does define the intent of Corp and Online, but it doesn't prescribe a complete network/security architecture for each management group.

Microsoft currently describes:

• Corp as subscriptions containing internal/private workloads that require traditional IP routing or hybrid connectivity through the Connectivity platform.
• Online as subscriptions containing public-facing workloads where isolation from internal resources helps reduce attack surface.

Connectivity between Online and Corp is optional and dependent on organizational routing/security requirements, potentially traversing Azure Firewall or an NVA.

That last point is important: Corp and Online are primarily governance/workload classifications, not predefined network security zones with mandatory firewall topologies.

Microsoft's own networking guidance says the ALZ network topology design area establishes the networking foundation but explicitly puts advanced security/compliance and enforcement considerations outside that section's scope.

I do agree with your concern, though. There's a significant architectural gap between saying "Online hosts Internet-facing workloads" and explaining how an enterprise should design inspection boundaries at scale.

For example, I'd expect an enterprise design exercise to explicitly evaluate:

Internet → edge/WAF → Online workload

separately from:

Online → Corp

and:

Corp → Internet / on-premises

rather than automatically forcing all three traffic classes through one centralized security boundary.

Microsoft's application-delivery guidance actually supports some of that separation. It recommends deploying Application Gateway inside the landing zone/spoke with the application it protects, rather than treating it as a shared hub resource, partly because centralization introduces RBAC, scale, and operational concerns.

It also recommends Front Door + WAF for global HTTP/S applications and Application Gateway v2/WAF for regional application delivery.

So I wouldn't say that ALZ requires a single centralized firewall architecture. Quite the opposite: the reference architecture deliberately leaves many of these implementation decisions to the organization.

Your feedback is valid that the documentation could provide a stronger decision framework covering questions such as when to centralize versus distribute inspection, when Online should have a separate security boundary, Online-to-Corp inspection, SNAT/throughput scaling, regional isolation, and regulatory segmentation. Those decisions become extremely expensive to revisit once hundreds of workloads depend on the original topology.

The Microsoft Security blog you found is therefore useful architectural guidance, but I would treat it as an architecture pattern rather than a mandatory extension of the Azure Landing Zone reference architecture.

For an existing environment, I also wouldn't assume you need a complete redesign immediately. If the current topology has become problematic, it may be possible to introduce separate traffic-flow/security boundaries incrementally, starting with new landing zones or regions rather than performing a disruptive migration of everything already deployed.

References:

Microsoft Learn — Azure Landing Zone network topology and connectivity

Microsoft Learn — Plan for application delivery

Microsoft Security Blog — Designing Cloud Landing Zones by Traffic Flow

Please "Accept the Answer" if this information helped you. This will help us and others in the community.