Using Azure archetypes at scale to simplify governance: Why the CAF works, part 2

Using Azure archetypes at scale to simplify governance: Why the CAF works, part 2

In part 1 we looked at why the Cloud Adoption Framework works. In this post I want to look at the part of it that I think does the most for governance at scale: landing zone archetypes. What are they, and why does governing two hundred subscriptions with them take about the same effort as governing ten?

Start with what you’re hosting

Let’s start by emphasising that archetypes work best when you know the compliance and security requirements of your cloud workloads ahead of time. A good time to learn that lesson is early in adoption, ideally in the Strategy phase https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/strategy/. It sounds something like this: we are Company X, and we need to host workloads that are PCI DSS compliant, or ISO 27001 compliant, or that meet our very rigorous internal security benchmark. Or maybe it’s the Microsoft cloud security benchmark (MCSB), which is a collection of excellent security best practices.

If you don’t know the security requirements of what you’re hosting, that’s the place to start. It’s the cornerstone of everything that follows. What you’re hosting drives your requirements, and your security and information risk should decide what those requirements look like. You don’t need a list of every workload you’ll ever host, but you do need to know the kinds of risk you’ll carry, like the regulations that apply to you and how you classify your data.

Yes, you could just assume the highest standard for everything, but for most organisations I think that’s the wrong default. It comes with an operational toll and added cost that most workloads don’t need. If we’re adopting Azure, it’s because we want to host things there and get the benefits, like lower operational effort and more agility. Locking everything down to PCI level gives a lot of that back. One security posture for the whole estate is either too weak for your regulated workloads or too costly for everything else, and archetypes mean you can host both and have them coexist.

What it looks like without them

You may have seen a tenant where this went wrong. The management groups mirror the org chart, with one per business unit or region, and sometimes Dev, Test and Prod under each of those. Policy gets assigned wherever someone needed it at the time, the same assignments get repeated at different levels, and anything that doesn’t fit gets an exemption. Before long the exemption list is longer than the assignment list, and nobody can tell you what posture a subscription actually has without going and looking.

Microsoft’s management group guidance calls this out directly https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/tailoring-alz:

Don’t duplicate your organisational structure into a deeply nested management group hierarchy. Use management groups for policy assignment versus billing and RBAC purposes.

It also says not to create management groups for production, testing and development. Those should be separate subscriptions in the same management group.

Platform landing zones

Before we get to archetypes properly, I need to explain platform landing zones, commonly referred to as the shared services. These are the connectivity, identity and management landing zones. They exist to provide network services, identity services, platform automation and so on, which the application landing zones (our workloads) consume.

Depending on the operating model, the hub is centrally managed. It hosts either a standard hub VNet or an Azure Virtual WAN hub. Not every workload uses it, though. Some sit in isolated networks with their own VNet and firewall, sometimes called islands.

Each workload on the right is peered to the hub and consumes its central services. Keep this picture in mind, because the network is one of the things that defines an archetype.

So what is an archetype?

In the CAF we use landing zone archetypes to group subscriptions with the same policy requirements, and therefore the same compliance requirements. This is how Microsoft defines one https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/tailoring-alz:

A landing zone archetype describes what needs to be true to ensure a landing zone (Azure subscription) meets the expected environment and compliance requirements at a specific scope.

The examples it gives are Azure Policy assignments, RBAC assignments and “centrally managed resources such as networking”. So an archetype isn’t just a management group. The management group is how you implement it. Because policy is inherited down the tree, everything assigned above it counts too. A subscription in a PCI archetype gets the intermediate root’s policies, plus the Landing Zones policies, plus the PCI ones.

The question we must ask first is: can I categorise the types of workloads I’ll host? Do they have different compliance or security requirements? Should security be more strictly enforced in some than in others? It’s these requirements that drive the archetypes. Whatever types of workload you need to host, that’s the right answer for your archetypes, and Microsoft’s guidance says much the same:

Create management groups under your landing zone management group to represent the types of workloads that you host. These groups are based on the security, compliance, connectivity, and feature needs of the workloads.

Notice connectivity in that list. Out of the box, ALZ gives us Corp and Online (plus Local, for workloads on Azure Local), and the difference between Corp and Online is the hub-and-spoke picture from earlier. Corp is for workloads that connect to the corporate network through the hub. Online is for workloads that need direct internet access, or that don’t need a virtual network at all.

If you look at the ALZ library, every policy assignment Corp adds is about the network: deny public endpoints, deny public IPs on NICs, deny hybrid networking (that’s the hub’s job), and point private endpoints at the central private DNS zones. Online doesn’t add any of its own. It just inherits from Landing Zones. The islands have a different connectivity requirement again, so they don’t belong in Corp. They go in Online or in an archetype of their own.

The platform landing zones work the same way. Identity has its own assignment to deny public IPs. Connectivity can’t have that one, because the hub needs public IPs for its firewall and gateways, so the two get different policy.

Audit or enforce?

Now policy has a target, and we can enforce a posture on an archetype because the workload type requires it. This is where the catch with MCSB comes in: out of the box, it audits. If we look at the initiative definition, none of its effect parameters default to Deny. Assign it as-is and you get a very good report of where you’re falling short, but on its own it won’t stop anyone deploying something non-compliant. The PCI DSS v4.0.1 initiative is the same.

There are ways to enforce it, though:

Set the effect parameters to Deny in your assignment (or DeployIfNotExists or Modify, where the policy supports them). Dozens of the MCSB effect parameters accept Deny.

Use the Deny and Enforce options in Defender for Cloud, which work on a subset of MCSB recommendations.

Assign deny policies directly to the archetype, which is exactly what ALZ does for Corp.

Don’t flip everything to Deny on day one. Run it in audit first, look at what would break, then move it to Deny. And keep in mind that policy only covers the Azure side. PCI DSS also covers people and process, and no initiative does that part for you.

Okay, so how does this let governance scale?

Once we vend a subscription, we place it in an archetype and policy enforces the requirements. That’s pretty much it. The ALZ FAQ uses this as its example of policy-driven governance: a new subscription is created and placed into a management group, and Azure Policy makes sure Defender for Cloud is enabled on it.

Nobody configures controls subscription by subscription, and nobody has to remember that this particular workload needs private endpoints. Policy becomes the guardrail for the archetype, and the archetype is the workload type. Whether we have ten subscriptions or two hundred, the effort is about the same.

It also means subscription vending is where the important decision gets made. When a new workload comes in, the intake asks what it is, what data it handles and what it needs to connect to, and this informs the archetype. This is why knowing roughly what types of workloads you need to host is beneficial.

Some tailored archetypes

The boxes in green are the safest place to change the CAF management group structure. That’s Microsoft’s wording too: it calls the area under Landing Zones “the most common and safest place in the hierarchy to add more archetypes”. Anything assigned at the intermediate root applies to every subscription below it, so that’s where you want to change the least. The example here includes PCI, which is also the example Microsoft uses, so any subscription with that requirement goes in there.

Summary

Archetypes simplify landing zone (workload) governance by letting us group workloads with the same requirements together. Work out your requirements early and let security and information risk shape them. Turn them into archetypes, make sure the policies enforce and don’t only audit, and pick the archetype when you vend each subscription. So why use them? Because once they’re in place, governing a new workload comes down to one decision at vending time, and policy does the rest.