Overview of Enterprise Scale Landing Zones

As described in this link, the recommendation is that there are at least two signatures, one for the production environment and the other for the non-production environment. Depending on the size of your environment or the strategy of your company, it may be necessary to create more signatures and in addition to combine the design of signatures with the definition of the landing zone to be created.
The Microsoft Cloud Adoption Framework describes in detail several topics over the enterprise-scale landing zone architecture, which offers a modular design and not only makes it simple to deploy existing and new applications but also allows organizations to start with a lighter deployment implementation and scale depending on their business needs.
Basically, the landing zone will deal with a set of considerations and recommendations based on some design areas:
The choice of network topology to be used is important for the process of governance definition. For example, the Hub and Spoke topology may be inserted in the context of subscriptions as follows:
  • The first subscription for shared services (Hub Virtual Network)
  • A second subscription for the production environment (Spoke Virtual Network - at the top right)
  • A third subscription for the non-production environment (Spoke Virtual Network - at the bottom right)
Approaching the Enterprise Scale Landing Zone, the architecture above could be translated into the architecture below to bring the "enterprise-scale" ability to the environment:
As you can note, this architecture adopts the usage of different Management Groups and Subscriptions to split the environment into two main groups: Platform and Landing Zones, this principle suggests production environments transitioned to business units and workload units. This allows workload owners to have more control and autonomy of their workloads within the guardrails established by the platform foundation.
Currently, enterprise-scale offers different reference implementations, which all can be scaled without refactoring when requirements change over time.