Am I misunderstanding Microsoft's landing zone guidance, or does it leave too much of the Corp and Online zone design unspecified? The documentation I found explains their general purpose and discusses application delivery, but it does not provide enough decision guidance for centralizing traffic inspection or deciding where these zones should be placed.
Important concerns seem underdeveloped, including coupled internet and private-traffic security policies, firewall rule sprawl, a shared blast radius for different traffic types, throughput and SNAT scalability limits, and regulatory requirements for separating environments. These problems become harder to manage across multiple regions and workloads.
I eventually found a more detailed traffic-flow and DMZ-oriented architecture discussion in Microsoft's networking blog, but my team has already implemented a design that is expensive to change. Are Corp and Online zones intended only as illustrative examples, or is there recommended guidance for evaluating these trade-offs before committing to an architecture?
3 Answers
The guidance is intentionally flexible because organizations often already have connectivity they need to preserve. For example, some companies prefer their existing private WAN instead of a cloud-native virtual WAN service, even if that choice costs more. That kind of constraint can significantly change the recommended landing-zone layout, so the official examples should be treated as patterns rather than a complete blueprint.
The design-area questions are useful, but they do not replace an architecture decision process. Before centralizing inspection, compare separate internet and private-traffic paths against a shared design, and evaluate rule ownership, blast radius, regional scaling, SNAT and throughput limits, failover, and regulatory boundaries. A decision matrix or proof of concept is usually more useful than assuming the named zones dictate the topology.
Corp and Online should generally be treated as example organizational patterns, not mandatory landing zones. The platform landing zone guidance is more prescriptive, while the workload and traffic architecture still needs to reflect each organization’s security, connectivity, compliance, and operating-model requirements. In practice, many teams create different landing-zone structures while applying the same underlying principles.
I understand that the final design is ours to own, but these traffic-flow options and their trade-offs should be documented more explicitly. They are central to the architecture rather than minor implementation details.