Azure Landing Zone – A foundation for your cloud workloads

Share Content

Listen audio version of this post:

Azure Landing Zone – A foundation for your cloud workloads

Contact Us → Contact Us →

Time and again it happens that we start to build something small, then later we expand it and realize that it grew too fast and uncontrolled. And now is a mess, an uncontrollable big ball of Mud, so to speak. Sadly, this has happened more times we can count despite our best efforts and intentions. Migrating workloads or building cloud-native software of enterprise-scaled proportions often falls victim to this outcome. And something like this is likely to happen when you build your infrastructure without a proper Cloud Governance model.

Cloud Adoption Framework (later CAF) helps to achieve and maintain proper structure and consistency in your cloud infrastructure across your organization. If you have heard of CAF previously then most probably you have also heard of landing zones. What are the landing zones? Well, to understand them we need first to make a short glance at what CAF is. So, what is CAF? 

We could spend days describing what CAF is and how and when it is used in the cloud adoption journey, but since we want to focus on landing zones, then a more concise description is provided here. CAF, as its name suggests, is a framework that helps the adoption of the cloud platform and services in your enterprise. A framework usually means a reference against which we can compare, that what we are doing is follow its guidance. Simply put, CAF is a set of best practices and guidelines in the form of documentation and tools to help organizations in adopting the cloud as an enabler for their businesses. CAF helps them to align business goals with technical capabilities. 

In this blog we focus on Microsoft’s vision of the Cloud Adoption Framework (since mainstream cloud platforms differ in their vision for cloud adoption). The CAF covers the whole lifecycle of cloud-enabled applications and services. Typically, two kinds of workloads are placed into the cloud during the adoption phase. You might have an application that could bring the most value if migrated to the cloud or you just create something new from scratch. In either of these cases, it is of paramount importance that you are ready to deploy them into the cloud. And you are not ready to do this unless, according to CAF, you are not “Cloud Ready”. * When you are then that’s where landing zones come in.  

What is a landing zone?

It’s not easy to find analogies for landing zones but think of a simple retail store with a lot of goods to sell. When you are to open a store for your own business, how will you organize it? Where do you start? Would you just randomly choose a venue, buy some shelves, and cash register and place them without a thought? Probably not. You will have to think carefully if the venue fits your business needs. Is this venue affordable? Does it provide all required services when comes to amenities? Does it enable smooth logistics? How’d I secure my store against theft and vandalism? How do I implement surveillance? What kind of rules and policies I’d have to set for an ideal and graceful customer experience and smooth operations within your store? These are the kind of questions you have to ask before you even start to migrate to your new store. What if you’d have all these questions answered for you by the HQ of the chain or franchise? Generally, a chain or franchise has these things thought about beforehand, so every store does not need to reinvent and rediscover what has been already done in myriad other stores. They might even use the same resources such as networking solutions or surveillance systems. 

The landing zone works in a similar fashion. When you migrate to the cloud, having an opinionated, battle-proven platform will save you time and money, and maybe some nerves, too. Microsoft provides this and already many of their customers have adopted the cloud in this manner. When you are cloud-ready – your strategy is set up and your adoption is well planned then it is time to deploy your landing zone. 

Bear in mind that a landing zone is not just a place to lift-and-shift your workloads. You can also create secure and high-performance connectivity to your internal network. Sometimes you just need the flexibility and scalability of the cloud but you might feel that you don’t need to migrate everything there. Then again, if your business is relatively new it might be a good choice to go to the public cloud to begin with.  

In concrete terms, the landing zone is a set of Azure resources set in a specific structure and order. It gives guidance to which resources go, where sets up role based access control (RBAC) in a secure way and sets policy assignments according to Microsoft’s recommendations. 

Implementation options 

There are some of the aspects that a landing zone addresses that help to start migrating workloads or innovate creating new cloud-native solutions. One of the challenges in this regard is the sheer number of choices. One of the first implementations of Microsoft’s proposed landing zone model is called Enterprise-Scale. The term itself is nowadays used to describe Microsoft’s proposed way to structure management groups, subscriptions, resources, accesses, and policies in a certain order and have their policy assignments and RBAC setup beforehand. See figure 1 for more details. 


Source: learn.microsoft.com

Another option to deploy a landing zone is to use the Azure portal tool called ‘Azure landing zone accelerator’. There are further options to deploy a landing zone via Azure Blueprints. These are valid options, but they lack an appropriate DevOps way of working, namely, to manage the infrastructure changes via Infrastructure-as-Code (IaC).  

There are also ARM and Bicep templates Microsoft provides. When we undertook the journey to find an appropriate IaC solution for the landing zone which could also provide configurable parts (instead of making all from scratch).  

Our choice - CAF for Terraform landing zones

We in Siili felt that none of the aforementioned solutions was something we’d like to experiment. Bicep might be an alternative, but at the time, according to our estimations, the solution wasn’t mature enough for production use.  

We also wanted something more modern and maintainable. So we did some digging and after some wrong turns, we discovered that our best option lies in Microsoft’s Terraform support and their opinionated landing zone solution. The implementation is a configuration based collection of interconnected Terraform modules, which, complex as it sounds, is easy to adapt to your needs. The starting point to get your environment set and deployed is this site https://aztfmod.github.io.

The main tool to develop, or more specifically to configure your deployable landing zone is called Rover. It’s a dev container you can take advantage of in Visual Studio Code, for example. It contains about 30 CLI-style tools that help you to create landing zones via Ansible and Terraform. Dev containers help multiple developers to share their environments for stability of outcomes. Also, containerization helps transition the code into CI/CD pipelines. 

Generally speaking, you have some key considerations that have an impact on your decisions regarding the landing zone. First of all, what will be your operating model and implementation type? How do you segregate the responsibilities around landing zone platform services vs. workloads? You may choose to have a centralized team that manages all infrastructure, a decentralized model where each team will take care of the platform and workload services and resources, or something in between. Secondly are you going to start small and expand or are you going all in with Enterprise-Scale complexity? Both options have their pros and cons, but we do not cover them here.  

All options are configurable by the CAF for the Terraform landing zones solution. You can also set up naming conventions and tagging to maintain consistency across resources. 

After careful consideration and decision making you can now start the actual deployment. One key thing to understand in this Terraform solution is that the state is segregated into several layers called levels. Each of the levels has its purpose, access management, and secret values. See figure 2 for explanations on each level. 


Source: aztfmod.github.io

In concrete terms, each level is a resource group, protected by an appropriate RBAC setup containing a storage account with a blob, which in turn contains the state of the infrastructure for that level. Levels 1 and 2 are so-called core platform levels that contain Enterprise-Scale management groups and policies, Identity services (if you need to manage domain controllers), management services, platform subscription creation, and optionally Connectivity services (if you work in a hybrid environment). These core services are rarely altered since they are shared between various workloads.  

Level 3 can be described as the application platform level which is more workload specific. It might, for example, contain the spoke network for the application. This is also the level at which different application environments are usually (dev, QA, staging, prod). 

Level 4 contains the state of the infrastructure of the application workload resources.  

Level separation helps to reduce the risk of making unintentional changes to your core platform services, as the application development team has its own level where they can safely operate without compromising the platform landing zones or other workloads for that matter.  

Rover and Terraform help to develop and maintain a consistent Landing zone for your workloads. How to use them is the skill needed to keep your Azure Landing Zone in a healthy state and consistently expand your infrastructure. The inner workings of CAF for Terraform landing zones are outside of the scope of this blog post, but you can acquire more knowledge about the subject by visiting here  https://aztfmod.github.io/documentation/. The tools and solutions are updated by Microsoft employees, but it is also community-driven so you can contribute to it. 


In summary the key advantages of Azure landing zones: 

  • Enhanced productivity: By streamlining the process of setting up and managing your cloud infrastructure, an Azure landing zone can help improve efficiency and reduce the time and effort required to spin up new resources and environments.

  • Improved security: Landing zones provide core security controls such as network segmentation and identity and access management, and strong foundation for security in your Azure environment. 

  • Greater scalability: Azure landing zones are designed to be scalable, allowing you to easily add new resources and services as your needs evolve. This makes it easy to adapt to changing business needs and support rapid growth. 

  • Simplified onboarding: An Azure landing zone can help make the onboarding process for new team members easier by providing a well-defined and standardized environment that they can use as a starting point for their work. 

  • Enhanced collaboration: An Azure landing zone can help improve collaboration within your organization by providing a shared environment that can be used by multiple teams. This can make it easier for teams to share resources and collaborate on projects. 

  • Improved compliance: A well-defined and standardized Azure landing zone can help improve compliance within your organization by providing a clear and consistent set of policies and controls that apply across your environment. 

We are confident that leveraging Azure landing zones will help you with your Cloud adoptation journey. It is a real time-saver. Even if you have already started your journey toward the cloud, you can still utilize CAF principles and guidelines. We in Siili help you with your cloud adaptation journey. We have helped countless organizations to migrate and innovate their workloads in the cloud. Let us know when you are ready to start your journey. 

* Some organizations might want to deviate from adopting the cloud in the suggested order and might think of doing “Strategy” and “Plan” phases in parallel with “Ready”, but it is far safer to establish some business motivations and outcomes, financial and technical considerations before to start deploying anything concrete into the cloud. 

Written by: Marko Ruotsalainen, Cloud Architect.

Related Stories

Spiking Now

Get Our Latest News

Immerse yourself into the latest twists and turns of life at Siili! Subscribe to our monthly newsletter, and stay up to date with our stories.