Azure landing zones – Terraform module design considerations

This article discusses important areas to consider when using the Azure landing zone conceptual architecture as detailed in the Cloud Adoption Framework (CAF).

Terraform is an open-source Infrastructure as Code (IaC) tool, created by HashiCorp, that uses declarative syntax to deploy infrastructure resources. It is extensible, has cross-platform support and enables immutable infrastructure through state tracking.

Design

This article discusses important areas to consider when using the Azure landing zones Terraform module. The module provides an opinionated approach to deploy and operate an Azure platform based on the Azure landing zone conceptual architecture as detailed in the Cloud Adoption Framework (CAF).

Terraform is an open-source Infrastructure as Code (IaC) tool, created by HashiCorp, that uses declarative syntax to deploy infrastructure resources. It is extensible, has cross-platform support and enables immutable infrastructure through state tracking.

Design

The architecture takes advantage of the configurable nature of Terraform and is composed of a primary orchestration module. This module encapsulates multiple capabilities of the Azure landing zones conceptual architecture. You can deploy each capability individually or in part. For example, you can deploy just a hub network, or just the DDoS protection plan, or just the DNS resources. When doing so, you need to take into account that the capabilities have dependencies.

The architecture utilizes an orchestrator approach to simplify the deployment experience. You might prefer to implement each capability using one or more dedicated module instances where each is dedicated to a specific part of the architecture. This is all possible with the correct configuration.

Modules

A core concept in Terraform is the use of modules. Modules enable you to organize deployments into logical groupings. With modules, you improve the readability of your Terraform files by encapsulating complex details of your deployment. You can also easily reuse modules for different deployments.

The ability to re-use modules offers a real benefit when defining and deploying landing zones. It enables repeatable, consistent environments in code while reducing the effort required to deploy at scale.

The Terraform implementation of Azure landing zones is delivered using a single module that acts as an orchestration layer. The orchestration layer allows you to select which resources are deployed and managed using the module. The module can be used multiple times in the same environment to deploy resources independently from each other. This can be useful in organizations where different teams are responsible for the different capabilities, or collections of sub-resources.

Layers and staging

The implementation focuses on the central resource hierarchy of the Azure landing zone conceptual architecture. The design is centered around the following capabilities:

• Core resources
• Management resources
• Connectivity resources
• Identity resources

The module groups resources into these capabilities as they are intended to be deployed together. These groups form logical stages of the implementation.

You control the deployment of each of these capabilities by using feature flags. A benefit of this approach is the ability to add to your environment incrementally over time. For example, you can start with a small number of capabilities. You can add the remaining capabilities at a later stage when you’re ready.

Core resources

The core resources capability of the module aligns to the resource organization design area of the Cloud Adoption Framework. It deploys the foundational resources of the conceptual architecture for Azure landing zones.

Archetypes

An important concept within the core resources capability is the inclusion of archetypes.

Archetypes provide a reusable, code-based approach to defining which policy definitions, policy set definitions, policy assignments, role definitions and role assignments must be applied at a given scope. In the Terraform implementation, these decisions are encapsulated as Archetype Definitions.

To create a landing zone, management groups are associated with an archetype definition. In the below example for a corp landing zone, the archetype_config has a pointer to the “es_corp” archetype definition. That definition contains all the policy and role configurations which will be added to this management group.

  es_corp_landing_zones = {
    "contoso-corp" = {
      display_name               = "Corp"
      parent_management_group_id = "contoso-landing-zones"
      subscription_ids           = []
      archetype_config           = {
        archetype_id ="es_corp"
        parameters   = {}
        access_control = {}
    }
  }

When the built-in archetypes don't align to your requirements, the module provides options to either create new archetypes or make changes to existing.

Management resources

The management resources capability of the module aligns to the management design area of the Cloud Adoption Framework. This capability provides the option to deploy management and monitoring resources to the management platform landing zone.

Connectivity resources

The connectivity resources capability of the module provides the option to deploy the network topology and connectivity of the conceptual architecture for Azure landing zones.

Identity resources

The identity resources capability of the module aligns to the Azure identity and access management design area of the Cloud Adoption Framework. This capability provides the option to configure policies on the Identity platform landing zone.

Module descriptions

This section provides a high-level overview of the resources deployed by this module.

Layer	Resource Type(s)	Description	Useful Links
Core	Management Groups	Management groups are the highest level resources in an Azure tenant. Management groups allow you to more easily manage your resources. You can apply policy at the management group level and lower level resources will inherit that policy. Specifically, you can apply the following items at the management group level that will be inherited by subscriptions under the management group: Azure Policies Azure Role Based Access Controls (RBAC) role assignments Cost controls
Core	Policy definitions, policy assignments, and policy set definitions	DeployIfNotExists (DINE) or Modify policies help ensure the subscriptions and resources that make up landing zones are compliant. Policies are assigned to management groups through policy assignments. The policies ease the burden of management of landing zones. Policy set definitions group sets of policies together. Not all customers are able to use DINE or Modify policies. If that is the case for you, CAF guidance on custom policies provides guidance.
Core	Role definitions and role assignments	Role-based access control (RBAC) simplifies the management of user rights within a system. Instead of managing the rights of individuals, you determine the rights required for different roles in your system. Azure RBAC has several built-in roles. Custom role definitions allow you to create custom roles for your environment. Identity and access management (IAM) is the key security boundary in cloud computing. Azure RBAC allows you to perform role assignments of built-in roles or custom role definitions to Service Principals, Managed Identities or security groups across management groups and subscriptions.
Management	Azure Monitor, Azure Automation, and Microsoft Sentinel	Azure Monitor, Azure Automation and Microsoft Sentinel allow you to monitor and manage your infrastructure and workloads. Azure Monitor is a solution that allows you to collect, analyze and act on telemetry from your environment. Microsoft Sentinel is a cloud-native security information and event management (SIEM). It allows you to: Collect – Collect data across your entire infrastructure Detect – Detect threats that were previously undetected Respond – Respond to legitimate threats with built-in orchestration Investigate – Investigate threats with artificial intelligence Azure Automation is a cloud-based automation system. It includes: Configuration management – Inventory and track changes for Linux and Windows virtual machines and manage desired state configuration Update management – Assess Windows and Linux system compliance and create scheduled deployments to meet compliance Process automation – Automate management tasks
Connectivity	Core networking resource types listed here	Network topology is a key consideration in Azure landing zone deployments. CAF focuses on two core networking approaches: Topologies based on Azure Virtual WAN Traditional topologies
Connectivity	DDoS protection plans	Azure landing zone guidance recommends enabling DDoS Protection Standard. This service offers turnkey protection against DDoS attacks.
Connectivity	DNS Zones, Private DNS Zones, and Private DNS Zone Virtual Network Link	Private DNS zones can be deployed to support the use of private endpoints. A private endpoint is a NIC that is assigned a private IP address from your virtual network. You can use the private IP address to securely communicate to services that supports Azure Private Link. Private DNS zones can be configured to resolve the fully qualified domain name (FQDN) of the service to the private endpoint private IP address.

Using the Terraform module

Deploying core resources

By default, the module will deploy the following hierarchy, which is the core set of landing zone management groups:

• Root
  • Platform
    • Identity
    • Management
    • Connectivity
  • Landing zones
  • Decommissioned
  • Sandbox

The SAP, Corp and Online landing zone management groups don't apply to everyone so they aren't deployed by default. The following are ways to deploy these:

1. For demo purposes, you can set the deploy_demo_landing_zones variable to true that will deploy SAP, Corp and Online landing zones
2. For production purposes, you can turn on the management groups you want by setting the following variables to true:
   • deploy_corp_landing_zones
   • deploy_online_landing_zones
   • deploy_sap_landing_zones
3. You can deploy your own custom landing zone management groups by creating a custom landing zone definition

Deploying management resources

To deploy the management resources, the deploy_management_resources variable must be set to true and the subscription_id_management variable must be set to the ID of the management subscription where the resources are to be deployed.

deploy_management_resources = true
subscription_id_management = <management subscription id>

Deploying connectivity resources

Deploy Connectivity Resources provides guidance on how to deploy these topologies.

Deploying identity resources

To deploy the identity capability, the deploy_identity_resources variable must be set to true and the subscription_id_identity variable must be set to the ID of the identity subscription where the policies are to be configured.

deploy_identity_resources = true
subscription_id_identity = <identity subscription id>

Customizing the Terraform implementation

The Azure landing zone implementations provided as part of the Cloud Adoption Framework suit a wide variety of requirements and use cases. However, there are often scenarios where customization is required to meet specific business needs.

The Azure landing zones Terraform module can be used as the basis of your customized deployment. It provides you a way to accelerate your implementation by removing the need to start from scratch because of a specific required change that rules a ready-made option out.

 Information on customizing the modules is available in the GitHub repo wiki GitHub: Azure landing zones Terraform module – Wiki. You can use it as a starting point and configure it as per your needs.

The architecture takes advantage of the configurable nature of Terraform and is composed of a primary orchestration module. This module encapsulates multiple capabilities of the Azure landing zones conceptual architecture. You can deploy each capability individually or in part. For example, you can deploy just a hub network, or just the DDoS protection plan, or just the DNS resources. When doing so, you need to take into account that the capabilities have dependencies.

The architecture utilizes an orchestrator approach to simplify the deployment experience. You might prefer to implement each capability using one or more dedicated module instances where each is dedicated to a specific part of the architecture. This is all possible with the correct configuration.

Modules

A core concept in Terraform is the use of modules. Modules enable you to organize deployments into logical groupings. With modules, you improve the readability of your Terraform files by encapsulating complex details of your deployment. You can also easily reuse modules for different deployments.

The ability to re-use modules offers a real benefit when defining and deploying landing zones. It enables repeatable, consistent environments in code while reducing the effort required to deploy at scale.

The Terraform implementation of Azure landing zones is delivered using a single module that acts as an orchestration layer. The orchestration layer allows you to select which resources are deployed and managed using the module. The module can be used multiple times in the same environment to deploy resources independently from each other. This can be useful in organizations where different teams are responsible for the different capabilities, or collections of sub-resources.

Layers and staging

The implementation focuses on the central resource hierarchy of the Azure landing zone conceptual architecture. The design is centered around the following capabilities:

• Core resources
• Management resources
• Connectivity resources
• Identity resources

The module groups resources into these capabilities as they are intended to be deployed together. These groups form logical stages of the implementation.

You control the deployment of each of these capabilities by using feature flags. A benefit of this approach is the ability to add to your environment incrementally over time. For example, you can start with a small number of capabilities. You can add the remaining capabilities at a later stage when you’re ready.

Core resources

The conceptual architecture for Azure landing zones.

Archetypes

An important concept within the core resources capability is the inclusion of archetypes.

Archetypes provide a reusable, code-based approach to defining which policy definitions, policy set definitions, policy assignments, role definitions and role assignments must be applied at a given scope. In the Terraform implementation, these decisions are encapsulated as Archetype Definitions.

To create a landing zone, management groups are associated with an archetype definition. In the below example for a corp landing zone, the archetype_config has a pointer to the “es_corp” archetype definition. That definition contains all the policy and role configurations which will be added to this management group.

  es_corp_landing_zones = {
    "contoso-corp" = {
      display_name               = "Corp"
      parent_management_group_id = "contoso-landing-zones"
      subscription_ids           = []
      archetype_config           = {
        archetype_id ="es_corp"
        parameters   = {}
        access_control = {}
    }
  }

When the built-in archetypes don't align to your requirements, the module provides options to either make changes to existing.

Management resources

The management design area of the Cloud Adoption Framework. This capability provides the option to deploy management and monitoring resources to the management platform landing zone.

Connectivity resources

The conceptual architecture for Azure landing zones.

Identity resources

The Azure identity and access management design area of the Cloud Adoption Framework. This capability provides the option to configure policies on the Identity platform landing zone.

Module descriptions

This section provides a high-level overview of the resources deployed by this module.

Layer	Resource Type(s)	Description	Useful Links
Core	Management Groups	Management groups are the highest level resources in an Azure tenant. Management groups allow you to more easily manage your resources. You can apply policy at the management group level and lower level resources will inherit that policy. Specifically, you can apply the following items at the management group level that will be inherited by subscriptions under the management group: Azure Policies Azure Role Based Access Controls (RBAC) role assignments Cost controls
Core	Policy definitions, policy assignments, and policy set definitions	DeployIfNotExists (DINE) or Modify policies help ensure the subscriptions and resources that make up landing zones are compliant. Policies are assigned to management groups through policy assignments. The policies ease the burden of management of landing zones. Policy set definitions group sets of policies together. Not all customers are able to use DINE or Modify policies. If that is the case for you, built-in roles. Custom role definitions allow you to create custom roles for your environment. Identity and access management (IAM) is the key security boundary in cloud computing. Azure RBAC allows you to perform role assignments of built-in roles or custom role definitions to Service Principals, Managed Identities or security groups across management groups and subscriptions.
Management	Azure Monitor, Azure Automation, and Microsoft Sentinel	Azure Monitor, Azure Automation and Microsoft Sentinel allow you to monitor and manage your infrastructure and workloads. Azure Monitor is a solution that allows you to collect, analyze and act on telemetry from your environment. Microsoft Sentinel is a cloud-native security information and event management (SIEM). It allows you to: Collect – Collect data across your entire infrastructure Detect – Detect threats that were previously undetected Respond – Respond to legitimate threats with built-in orchestration Investigate – Investigate threats with artificial intelligence Azure Automation is a cloud-based automation system. It includes: Configuration management – Inventory and track changes for Linux and Windows virtual machines and manage desired state configuration Update management – Assess Windows and Linux system compliance and create scheduled deployments to meet compliance Process automation – Automate management tasks
Connectivity	CAF focuses on two core networking approaches: Topologies based on Azure Virtual WAN Traditional topologies
Connectivity	DDoS protection plans	Azure landing zone guidance recommends enabling DDoS Protection Standard. This service offers turnkey protection against DDoS attacks.
Connectivity	DNS Zones, Private DNS Zones, and Private DNS Zone Virtual Network Link	Private DNS zones can be deployed to support the use of private endpoints. A private endpoint is a NIC that is assigned a private IP address from your virtual network. You can use the private IP address to securely communicate to services that supports Azure Private Link. Private DNS zones can be configured to resolve the fully qualified domain name (FQDN) of the service to the private endpoint private IP address.

Using the Terraform module

Deploying core resources

By default, the module will deploy the following hierarchy, which is the core set of landing zone management groups:

• Root
  • Platform
    • Identity
    • Management
    • Connectivity
  • Landing zones
  • Decommissioned
  • Sandbox

The SAP, Corp and Online landing zone management groups don't apply to everyone so they aren't deployed by default. The following are ways to deploy these:

1. For demo purposes, you can set the deploy_demo_landing_zones variable to true that will deploy SAP, Corp and Online landing zones
2. For production purposes, you can turn on the management groups you want by setting the following variables to true:
   • deploy_corp_landing_zones
   • deploy_online_landing_zones
   • deploy_sap_landing_zones
3. You can deploy your own custom landing zone management groups by creating a custom landing zone definition

Deploying management resources

To deploy the management resources, the deploy_management_resources variable must be set to true and the subscription_id_management variable must be set to the ID of the management subscription where the resources are to be deployed.

deploy_management_resources = true
subscription_id_management = <management subscription id>

Deploying connectivity resources

Deploy Connectivity Resources provides guidance on how to deploy these topologies.

Deploying identity resources

To deploy the identity capability, the deploy_identity_resources variable must be set to true and the subscription_id_identity variable must be set to the ID of the identity subscription where the policies are to be configured.

deploy_identity_resources = true
subscription_id_identity = <identity subscription id>

Customizing the Terraform implementation

The Azure landing zone implementations provided as part of the Cloud Adoption Framework suit a wide variety of requirements and use cases. However, there are often scenarios where customization is required to meet specific business needs.

The Azure landing zones Terraform module can be used as the basis of your customized deployment. It provides you a way to accelerate your implementation by removing the need to start from scratch because of a specific required change that rules a ready-made option out.

Information on customizing the modules is available in the GitHub repo wiki GitHub: Azure landing zones Terraform module – Wiki. You can use it as a starting point and configure it as per your needs.