This is a short series on Azure Landing Zones implemented with various levels of difficulty, in which we talk about Microsoft Cloud Adaption Framework and different accelerators they provide, and compare them to live-world experience of implementing an Azure Platform with Everything-as-Code -approach.

In this first part we cover some terminology and the first level – sandbox deployments.

For the past two years we have been implementing Azure Platform and Landing Zones (the artists formerly known as duo Hub & Spoke) and I though to write some notes from things that have briefly crosses our collective minds while doing that. Specifically, let’s talk about Azure Landing Zone implementation with Bicep in four levels of difficulty.

For the first two levels (and beyond with some parts like Azure Policies), you can follow along by browsing the ALZ Bicep repository – The Microsoft reference implementation. For more background information on Azure Landing Zones in general, see the Landing Zones in Microsoft Cloud Adoption Framework guidance.

For a bad analogy, think of Landing Zones as equivalent of what the local municipality provides and requires from you when building a house somewhere; you might get some kind connection to a sewer line and electricity drawn to your property, and probably some bureaucratic goodness that dictates what you can build. Azure Platform is the municipality, and a Landing Zone is the property you get, alongside the basic necessities, so you can start building your house. Or a townhouse. Or Factory. Or whatever Taj Mahal of data industry you dream about.

Terminology

Let’s cover some basic groundwork first, so we think we know what we are talking about. Landing Zone is a very loaded term, just like DevOps and Platform are – it means what you want it to mean, and your meaning might not exactly match with what other people are thinking.

Enterprise

Enterprise is, in this context, simply a big enough entity for which using Landing Zones makes sense. It has multiple internal teams which create and deploy multiple serverless workloads that help the business to generate unbelievable success, not the least by being perfectly aligned with the enterprise architecture used. Or could also be decades old ERPs running in bunch of migrated virtual machines that need to somehow be connected to each other. In any case, some centralized solutions are needed.

Platform / Hub

In this context, when I speak about Platform, I mean the centralized services that an enterprise provides for it’s own internal customers or workloads. Typically these are the services provided by a Cloud Center of Excellence or some other centralized Platform team. In the Azure CAF Context these mean the Hub networking (or the virtual WAN equivalent) and associated services like DNS Forwarding, management services like centralized log analytics, or identity like security groups created in Microsoft Entra ID (the artist formerly known as Azure AD). These are the core services needed for operating in Azure in networked environments – the municipality side of things from the example above.

Landing Zone

Landing Zones are the basic services provided for the internal customers or workloads, upon which they can start building the services that actually bring value – things that tie a single workload to the enterprise networking and identity management. Resource-wise the common examples would be a subscription, virtual network, peering of that virtual network to Hub and granting the access to the Lading Zones for individual contributors, usually in the form of security groups or direct contributor roles. So, the foundations for an individual house builder from the example above.

Now, the CAF documentation happily goes on speaking about the Platform Landing Zones, which is a concept I’m not a great fan of, as if everything is a Landing Zone, then pretty much nothing really is. In this series, when talking about Landing Zones, I specifically mean the basic setup provided for the workloads that tie them into the rest of the Enterprise. I’m also specifically referring to a model where every workload receives multiple subscriptions, which represents their environments (dev/test/preprod/prod, or the equivalents). There are other models out there, like the older shared subscription model, in which workloads receive resource group(s) in shared environment subscriptions.

Workload

Workloads are the internal customers of an enterprise, created and maintained by a project or product team. In ideal setup, the workload team could provision Landing Zones for themselves in a pre-determined and simple manner (think of self-service portals, but let us dive into the hype known as platform engineering a bit later) and have full ownership of the environments they provision into those Landing Zones, and a partial ownership of the Landing Zone resources themselves – while the governance of all of this would be enforced by Azure Policies.

In reality, the ownership of the Landing Zone resources – specifically the network-related configuration – is usually the pain-point both because the complexity of the configuration and the need to enforce Enterprise-level decisions.

Level 1: Sandboxes

There is really no easymode for Landing Zone implementation, but a sandbox environment is probably the most trivial one. On the surface it’s just a one-time deployment of few resources; an Azure subscription as an unit of billing and management and maybe a key vault for storing your secrets. It’s basically a grassland where you can build your first shaky cottages to try out things in Azure. There is probably no need for network connectivity (but it really depends on the needs of sandbox users; at least the network should be disconnected from other environments). Under the hood you’ll have to create the other basic necessities that real Landing Zones have.

Microsoft provides some guidance on sandboxes, but I’ll go through some of the key things below.

Policies and Management group hierarchy

Management groups are the governance hierarchy of Azure and the main uses of them are the environment separation and imposing Azure Policies on the branches of management group structure. While sandboxes might get more leeway when it comes to policies – you don’t have to enforce everything you are enforcing with real Landing Zones on sandboxes – you should really start by having at least an MVP implementation of your policy framework at this level. What policies you want and are required to impose? How do you manage and deploy your policies? Should you impose the same set of policies everywhere (probably yes, with the possible exception of sandboxes).

We are currently using the Policy modules in the ALZ-repository for our customer. While the actual policy definitions are JSON-files and not Bicep, I feel like this is a tradeoff we can live with. You could implement your policy base as Bicep, and I’ll tip my hat if you do, but for us leveraging the power of reference implementation by people who just know more and are more up-to-date with policy changes just makes sense. How about some baked- and built-in Private DNS Zone policies? Don’t mind if I do, didn’t even know they had built-in policies for those until we started using the policy module.

Identity

Even if you are provisioning simple sandboxes, you still need to think about identity and access. What is your strategy for providing user access to subscriptions and setting roles? Do you use Privileged Identity Management? Unfortunately AAD and MS Graph support is still on the waiting list of Bicep releases, so you’ll have to use other means to create things like security groups, secrets and identities. We currently use Powershell and Deployment Scripts for creating security groups, creating identities for deployments, and such.

In the next parts of the series we are covering more complicated scenarios; fire-and-forget -type deployments with ALZ-Bicep accelerator, landing zones as software projects with change and lifecycle management, and finally some thoughts on landing zones with accelerators and special topics like data landing zones.

Check out the second part of the series where we cover the second level of difficulty; deploying basic networked Landing Zones, here. >