Am I overlooking something, or is the guidance for designing Corp and Online landing zones incomplete? The available documentation seems to describe their purpose but provides little practical direction on traffic inspection, zone placement, or how to choose between different architectures. It also does not clearly address coupled internet and private security policies, firewall rule sprawl, shared blast radius, throughput and SNAT scaling limits, or regulatory separation requirements. These concerns become even more important when an organization operates across multiple regions and workloads. I found a more detailed traffic-flow and DMZ-focused architecture discussion elsewhere, but my team has already implemented a design that is expensive to change. How are others handling these decisions, and is there a recommended way to evaluate whether a redesign is worthwhile?
3 Answers
Corp and Online should be treated as example patterns rather than mandatory landing zones. The platform landing zone principles are the important part; organizations generally adapt the management groups, network topology, inspection points, and workload boundaries to their own requirements. I agree that the guidance would be more useful if it included decision trees for traffic inspection and clearer trade-offs between centralized and distributed firewalls.
A lot of organizations already have private connectivity such as MPLS, so they may choose to keep using it instead of adopting a virtual WAN-based approach. That choice affects routing, inspection placement, cost, and operational ownership. The key is to compare the options against actual traffic flows and scaling requirements rather than assuming the example Corp and Online structure fits every environment.
That is part of the problem: the choice is often driven by existing connectivity and cost, while the long-term impact on firewall capacity, rule management, and regional separation is not made explicit.
The design-area questions are a useful starting point, but they are not a complete reference architecture. You still have to decide where inspection occurs, which traffic types share controls, how much isolation is required, and whether regional or workload-level firewalls are justified. I would document those decisions as explicit architecture principles and use them to identify the most expensive risks in the current design before considering a full redesign.
I understand that the final design is organization-specific, but these zones are central to the overall operating model. The documentation should still explain the major options and the consequences described in the traffic-flow architecture examples.