Lately people have been talking about Azure Landing Zones. This primarily refers to the environment in Azure into the workloads be migrated or new workloads are introduced. This means the preparation of the Azure environment. Specifically, the basic structure in Azure, which is necessary to start the first workloads there.

Landing Zone vs. Governance vs. Cloud Adoption Framework

The Cloud Adoption Framework is a process model for adopting the cloud. It describes different phases with aspects that should be considered. I have already mentioned the governance phase in a previous article. It has a great influence on the design of the landing zone, for example with billing and security. The first landing zone is then set up in the ready phase.

(Source: https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/_images/caf-overview-new.png)

MVP Landing Zone

As with most cloud things, start small and grow as you need is a good idea. Microsoft recommends points such as identity or governance when designing the landing zone. As with governance, the points are important, but also very vague.

As a minimal viable product of the landing zone, I recommend implementing the first most important points of governance, i.e. network and technical security. This means decisions regarding hub & spoke, access protection via firewall and/or NSGs and access and authorizations.

I also recommend making decisions about naming conventions and the structure of the subscriptions. It is relevant for the subscription structure, whether each workload has its own subscription or even 3 subscriptions (Dev, Test, Prod) or whether each department receives its own spoke with its own subscription and all workloads. There are different ways. The peering costs should also be considered. Since essential structures (hub and network areas) are set up at the beginning, the naming should also be specified, as these can not be renamed later.

Templates

Microsoft provides various templates, diagrams and scripts for setting up the landing zone. Under the implementation options area there is a list of various scenarios, for example basic foundation for low risk assets.

I do not recommend working with the templates, but simply viewing them as a source of ideas. The templates never have appropriate naming conventions and a structure that contains too many or too few resources. This means that the architecture and its structure with the resources should serve as inspiration and only the things that are necessary should be adopted. Each landing zone should always match the customer’s requirements.

I also recommend not starting with the small environments but with the enterprise environments, as sooner or later you always have to switch to an enterprise environment because the Azure environment has grown accordingly. Customers often need a hub & spoke network architecture, so the environment with enterprise-scale and hub & spoke (see title picture) would be a good starting option.

Fast vs. Correct

Many customers want to quickly set up their first workloads in Azure in order to gain experience. There is nothing wrong with that, but then the right framework, the right governance, is often missing. Often, operational and authorization issues are not clarified, not all recommended information (data protection, security) have been discussed and the network connection is often not well thought out.

There is nothing wrong with starting directly, but it should be obviously that real operation is not possible or that the first workloads have to be rebuilt or recreated. A test environment should only remain a test environment and not go productive.

For the quick tryout I often suggest a sandbox approach. Later on, many customers also want to use the flexibility and speed of Azure and test something quickly. To do this, we set up empty subscriptions, which can optionally be filled with the actual landing zone. In this sandbox subscription, the customer can freely set up his system and do whatever he wants. These sandbox subscriptions are located next to the landing zone and have rudimentary governance and billing rules.

So if something needs to be tried out quickly that may not have be thrown away later, I recommend the sandbox approach. Nevertheless, before the first sandbox is created, you have to think about IP ranges, naming conventions and authorization, but the result can then be used directly and further used.