Building Azure landing zones means to leverage a scalable, modular approach to building out your environment based on a common set of design areas. Consequently, knowing and understanding the type of the application and workload (consequently called archetype) is important, as some of the Azure services do have specific requirements and platform dependencies.
The importance of the archetype also called out in the critical design areas, for example Red Hat OpenShift with regards to the DNS infrastructure.[1] Furthermore, this is also one of the reasons why you see different management groups below the landing zone management group.[2] In this specific case, which basically is the Contoso reference implementation, there are three specific landing zones: SAP, Corp and Online.
From the Contoso reference implementation:[3]
- Corp Landing Zones will include all Virtual Networks that do not expose public endpoints and that require connectivity to on-premises, as well as connectivity to other Landing Zones.
- Online Landing Zones include all Virtual Networks that have internet-facing applications via an Azure Application Gateway (v2).
- SAP represents a workload that merits separation given the implied specialization.
How to build archetype landing zones?
In order to build a landing zone for an used archetype, you need to understand all the specific requirements and dependencies. Unfortunately, there is no single place where you can find this information, but you need to gather this information for every Azure service used with this archetype.
However, a general recommendation is to leverage the Azure Architecture Center where you can find many useful information. One specific example I would like to mention is Azure Kubernetes Service (AKS) within the Architecture Center.[4]
In the AKS production baseline (reference architecture), you will find a baseline infrastructure that deploys an AKS cluster, with focus on security. The baseline includes recommendations for networking, security, identity, management, and monitoring of the cluster. Consequently, it’s aligned with the critical design areas in Enterprise-Scale.
Let’s look at one of the covered topics, which is networking security. The documented ingress and egress traffic flow are aligned with the recommendation you will find in Enterprise-Scale.[7][8] To be specific, using an Application Gateway and Web Application Firewall (WAF) to protect ingress traffic and use a Firewall, deployed in the (managed) hub, to protect egress traffic. But something that you will not find mentioned specifically in Enterprise-Scale are the recommended Azure Policy add-on for AKS.[6] Although policy-driven governance is one design principles in Enterprise-Scale, at this juncture you may have to build an AKS landing zone including all the required policy and also role configurations specifically addressing AKS. This may include network, storage, RBAC, and others.
Thus, in a nutshell, and also my personal approach (now independent of AKS):
- Assess the required archetype-specific policyDefinition, policyAssignments, roleDefinitions and roleAssignments.
- Assess whether there are overlaps with existing landing zones (management groups) and existing policyAssignments and roleAssignments.
- Assess whether a new dedicated management group, including the policyAssignments and roleAssignments, does not make the management more complicated (no need to create the same assignments on multiple management groups).
The role of Well-Architected Framework
The AKS production baseline mentioned above also follows the Azure Well-Architected Framework.[5] Though this is an AKS specific use case, all the deployed applications should follow the Well-Architected Framework, and therefore should address:
- Cost optimization
- Operation excellence
- Performance efficiency
- Reliability
- Security
Or in other words: Enterprise-Scale provides the all important recommendations for the platform engineering, the Well-Architected Framework all important recommendations for applications and workloads.
[3] https://github.com/Azure/Enterprise-Scale/blob/main/docs/reference/contoso/Readme.md
[5] https://docs.microsoft.com/en-us/azure/architecture/framework/
[6] https://docs.microsoft.com/en-us/azure/governance/policy/concepts/policy-for-kubernetes