Оффлайн
- Регистрация
- 9 Май 2015
- Сообщения
- 1,605
- Баллы
- 155
The Complete Guide to Production-Grade Azure Landing Zones
Note; If you find any mistakes please do not burn me kindly let me know.
Intro
An Azure Landing Zone is the foundational output of a multi-subscription Azure environment that considers scale, security, governance, networking, and identity. It provides a well-defined, repeatable starting point for all your cloud workloads, ensuring they are deployed into a secure, compliant, and operationally excellent environment from day one. A landing zone solves critical enterprise challenges like inconsistent security postures, sprawling and ungoverned environments, lack of visibility, and ballooning costs by establishing a baseline architecture and "guardrails" through policy.
- Architect and Design: Confidently design an enterprise-grade Azure Landing Zone based on the Cloud Adoption Framework's principles.
- Build with Confidence: Use Infrastructure as Code (Bicep and Terraform) to deploy a complete, modular, and repeatable landing zone.
- Govern at Scale: Implement robust governance using Azure Policy, Management Groups, and Role-Based Access Control (RBAC) to enforce security and compliance.
- Automate Everything: Build and configure CI/CD pipelines in GitHub Actions and Azure DevOps to enable safe, automated, and auditable deployments.
- Operate with Excellence: Establish centralized monitoring, logging, and security to ensure the health, performance, and security of your Azure environment.
- Validate and Test: Write and execute automated tests to continuously validate the compliance and health of your landing zone.
(Estimated Time: 2 Hours)
Before we build, we must prepare our workshop. This module ensures you have all the necessary tools and permissions.
Lab 1.1: Tool Installation
| Step | Action | Command/Instructions | Expected Output/Success Indicator | Time |
| 1 | Install Azure CLI | Follow the official instructions for your OS: | az --version returns the installed version. | 20m |
| 2 | Login to Azure | az login | A browser window opens for authentication. The CLI outputs your subscription details in JSON format. | 5m |
| 3 | Install Bicep | az bicep install | Successfully installed Bicep CLI to... | 5m |
| 4 | Install Terraform | Follow the official instructions: | terraform -version returns the installed version. | 20m |
| 5 | Install VS Code | Download from | VS Code application opens successfully. | 15m |
| 6 | Install VS Code Extensions | From the Extensions view (Ctrl+Shift+X), search for and install: ms-azuretools.azure-cli, ms-azuretools.vscode-bicep, hashicorp.terraform | Extensions appear in the "Installed" list. | 15m |
Lab 1.2: Account and Permissions Verification
Why this matters: A landing zone deployment creates and configures fundamental resources like management groups. These actions require elevated permissions. Verifying them now prevents failures later.
| Step | Action | Command/Instructions | Expected Output/Success Indicator | Time |
|---|---|---|---|---|
| 1 | Verify Role | az ad signed-in-user show --query "userPrincipalName" and check permissions in the Azure portal at the tenant root management group. | You need Owner or a role with Microsoft.Management/managementGroups/write permissions at the root scope. | 10m |
| 2 | Register Providers | az provider register --namespace Microsoft.Management az provider register --namespace Microsoft.Network az provider register --namespace Microsoft.Insights | For each command, the output RegistrationState should eventually be Registered. | 25m |
This section outlines the target state architecture we will build.
Architecture Diagram (Hub-and-Spoke)
/------------------------------------------------------\
| Azure Tenant / Root Management Group |
| |
| /---------------------------------------------\ |
| | Platform Management Group | |
| | /------------------\ /----------------\ | |
| | | Identity MG | | Management MG | | |
| | | (Sub: Identity) | | (Sub: Mgmt) | | |
| | \------------------/ \----------------/ | |
| | /------------------\ | |
| | | Connectivity MG | | |
| | | (Sub: Hub Ntwk) | | |
| | \------------------/ | |
| \---------------------------------------------/ |
| |
| /---------------------------------------------\ |
| | Landing Zones Management Group | |
| | /------------------\ /----------------\ | |
| | | Prod MG | | Non-Prod MG | | |
| | | (Sub: Prod-App1) | | (Sub: Dev-App1)| | |
| | \------------------/ \----------------/ | |
| \---------------------------------------------/ |
\------------------------------------------------------/
Network Flow:
[Spoke VNet (Prod-App1)] <--VNet Peering--> [Hub VNet] <--Firewall--> [Internet/On-Prem]
Naming Convention and Tagging Strategy
Why this matters: A consistent naming and tagging strategy is the bedrock of good governance. It enables automation, simplifies cost management, improves clarity, and enhances security by making resources easily identifiable and groupable.
Naming Convention: [ResourceType]-[WorkloadName]-[Environment]-[AzureRegion]-[Instance]
- Examples: rg-myapp-prod-eastus-001, vnet-hub-prod-eastus-001
Tagging Strategy (Mandatory Tags):
| Tag Key | Purpose | Example Value |
|---|---|---|
| owner | Identifies the business or technical owner. | finance-team@example.com |
| costCenter | Associates resource with an internal cost center. | 12345 |
| environment | The deployment environment. | prod / dev |
| appName | The name of the application or service. | SAP-HANA |
Module 1: Governance Foundation with Management Groups
- Summary: Establish the core hierarchical structure of your Azure environment.
- Time: 3 Hours
- Difficulty: Beginner
- Summary: Configure the identity backbone, defining who can do what.
- Time: 4 Hours
- Difficulty: Intermediate
- Summary: Implement automated guardrails to enforce security and compliance.
- Time: 5 Hours
- Difficulty: Intermediate
- Summary: Build the core network topology for secure connectivity.
- Time: 6 Hours
- Difficulty: Advanced
- Summary: Deploy and configure centralized services for logging and secrets.
- Time: 4 Hours
- Difficulty: Intermediate
- Summary: Organize your Bicep/Terraform code for scalability and reuse.
- Time: 5 Hours
- Difficulty: Intermediate
- Summary: Build automated pipelines to deploy landing zone changes safely.
- Time: 6 Hours
- Difficulty: Advanced
- Summary: Apply all learned concepts to build a complete landing zone from scratch.
- Time: 8 Hours
- Difficulty: Expert
Why this matters: Management groups provide a level of scope above subscriptions, allowing you to apply governance controls like policies and access assignments efficiently and consistently across your entire Azure estate. A well-designed hierarchy is the first and most critical step to scaling your cloud environment securely.
Hands-on Lab: Creating the Management Group Hierarchy
| Step | Action | Command/Instructions | Expected Output/Success Indicator | Time |
|---|---|---|---|---|
| 1 | Create Platform MG | az account management-group create --name "lz-platform" | JSON output describing the new lz-platform MG. | 10m |
| 2 | Create Child MGs | az account management-group create --name "lz-identity" --parent "lz-platform" az account management-group create --name "lz-management" --parent "lz-platform" az account management-group create --name "lz-connectivity" --parent "lz-platform" | JSON output for each new MG. | 15m |
| 3 | Create Landing Zones MG | az account management-group create --name "lz-landingzones" | JSON output for the lz-landingzones MG. | 10m |
| 4 | Create Prod/NonProd MGs | az account management-group create --name "lz-prod" --parent "lz-landingzones" az account management-group create --name "lz-nonprod" --parent "lz-landingzones" | JSON output for each new MG. | 10m |
| 5 | Verify Hierarchy | az account management-group show --name "lz-platform" --expand --recurse | A tree structure in the JSON output showing the parent-child relationships. | 5m |
targetScope = 'tenant'
resource mgPlatform 'Microsoft.Management/managementGroups@2021-04-01' = {
name: 'lz-platform'
properties: { displayName: 'Platform' }
}
resource mgConnectivity 'Microsoft.Management/managementGroups@2021-04-01' = {
name: 'lz-connectivity'
properties: {
displayName: 'Connectivity'
details: { parent: { id: mgPlatform.id } }
}
}
// ... other MGs follow the same pattern
Deployment: az deployment tenant create --location eastus --template-file managementGroups.bicep
Terraform Artifact: management_groups.tf
resource "azurerm_management_group" "platform" {
display_name = "Platform"
name = "lz-platform"
}
resource "azurerm_management_group" "connectivity" {
display_name = "Connectivity"
name = "lz-connectivity"
parent_management_group_id = azurerm_management_group.platform.id
}
// ... other MGs follow the same pattern
Deployment: terraform init && terraform apply
Architectural Deep Dive & Use Case
- Deep Dive: The recommended CAF hierarchy is relatively shallow to reduce complexity. A deep hierarchy modeled after an org chart can become difficult to manage due to complex policy and RBAC inheritance. The functional design (Platform, Landing Zones) provides a more robust model for applying governance.
- Use Case - Preventing Cloud Sprawl: An enterprise is struggling with uncontrolled resource creation and costs. By creating Prod and Non-Prod management groups, they can apply stricter policies (like limiting expensive VM SKUs) to the Non-Prod group while applying stricter security policies to the Prod group, all from a central point of control.
Why this matters: Identity is the modern security perimeter. This pillar focuses on ensuring all access to Azure is authenticated, authorized, and audited according to Zero Trust principles.
Hands-on Lab: Implementing Least Privilege
| Step | Action | Command/Instructions | Expected Output/Success Indicator | Time |
|---|---|---|---|---|
| 1 | Create Custom Role | Create SpokeVnetContributor.json (see below). Then run: az role definition create --role-definition @SpokeVnetContributor.json | JSON output of the new role definition. | 20m |
| 2 | Assign Role | Get your App Team's Group ID: GROUP_ID=$(az ad group show --group "YourAppTeamGroup" --query id -o tsv) Get subscription ID: SUB_ID=$(az account show --query id -o tsv) az role assignment create --assignee $GROUP_ID --role "Spoke VNet Contributor" --scope /subscriptions/$SUB_ID | JSON output of the role assignment. | 15m |
| 3 | Configure PIM | In the Azure Portal, navigate to Azure AD > Privileged Identity Management. Make your platform admin account "eligible" for the built-in Contributor role on the lz-platform management group. | When you go to "My roles" in PIM, you will see the eligible assignment and an "Activate" button. | 30m |
{
"Name": "Spoke VNet Contributor",
"Description": "Allows contributing to resources within a spoke VNet without network modification rights.",
"Actions": [
"Microsoft.Storage/*",
"Microsoft.Compute/*",
"Microsoft.Sql/*",
"Microsoft.Web/*"
],
"NotActions": [
"Microsoft.Network/virtualNetworks/*",
"Microsoft.Network/routeTables/*"
],
"AssignableScopes": [
"/providers/Microsoft.Management/managementGroups/lz-landingzones"
]
}
Architectural Deep Dive & Use Cases
- Deep Dive - Managed Identities: The superior architectural choice over service principals with secrets. A Managed Identity is a credential managed entirely by Azure for a resource (like a VM or Web App). This eliminates the entire class of risks associated with developers managing, rotating, and potentially leaking secrets.
- Use Case 1 - Secure Emergency Access: A production application is down. Using PIM, an on-call engineer requests to activate the Contributor role for 2 hours, providing the incident ticket number as justification. They get temporary, just-in-time access to fix the issue. All actions are audited, and access is automatically revoked, eliminating the risk of a standing privileged account.
- Use Case 2 - Passwordless CI/CD: A CI/CD pipeline needs to deploy resources. Instead of storing a service principal secret in GitHub, the pipeline uses Managed Identity (or workload identity federation) to securely obtain an access token, eliminating secrets from the DevOps toolchain.
Why this matters: Azure Policy is the core of governance, enabling you to enforce rules at scale. It ensures that as new resources are created, they automatically adhere to security and compliance standards, preventing misconfigurations before they happen.
Hands-on Lab: Creating and Assigning Policy
| Step | Action | Command/Instructions | Expected Output/Success Indicator | Time |
|---|---|---|---|---|
| 1 | Create "Enforce Tag" Policy | Create enforce-tag-policy.json (see below). Run: az policy definition create --name "enforce-costCenter-tag" --rules enforce-tag-policy.json --mode All | JSON output of the created policy definition. | 20m |
| 2 | Create Initiative | POLICY_ID=$(az policy definition show --name "enforce-costCenter-tag" --query id -o tsv) Create initiative.json (see below). Then run: az policy set-definition create --name "landingzone-baseline" --definitions initiative.json | JSON output of the created initiative. | 20m |
| 3 | Assign Initiative | INITIATIVE_ID=$(az policy set-definition show --name "landingzone-baseline" --query id -o tsv) MG_ID=$(az account management-group show --name "lz-landingzones" --query id -o tsv) az policy assignment create --name "lz-baseline-assignment" --scope $MG_ID --policy-set-definition $INITIATIVE_ID | JSON output of the policy assignment. | 15m |
| 4 | Test Policy | Try to create a resource group without the costCenter tag under the target MG: az group create -n "test-rg" -l "eastus" | The command should fail with a policy violation error. | 10m |
enforce-tag-policy.json (Deny effect)
{
"if": {
"allOf": [
{ "field": "type", "equals": "Microsoft.Resources/subscriptions/resourceGroups" },
{ "field": "tags['costCenter']", "exists": "false" }
]
},
"then": { "effect": "deny" }
}
initiative.json (placeholder)
{
"properties": {
"displayName": "Landing Zone Baseline Policies",
"policyDefinitions": [
{ "policyDefinitionId": "[POLICY_ID]" }
]
}
}
Architectural Deep Dive & Use Case
- Deep Dive - Policy-as-Code: This is the practice of managing your policy definitions and assignments as code in a Git repository. Every change is peer-reviewed via a pull request and deployed through an automated CI/CD pipeline. This provides versioning, validation (using what-if), and an audit trail for all your governance rules. The DeployIfNotExists effect is a powerful remediation tool to automatically configure things like diagnostic settings.
- Use Case - Enforcing Data Sovereignty (GDPR): A European company must ensure citizen data remains within the EU. A policy initiative is assigned to their EU management group containing an "Allowed Locations" policy that only permits deployment in West Europe and North Europe. This automated guardrail makes it impossible for developers to accidentally violate GDPR, preventing massive potential fines.
Why this matters: A hub-and-spoke network topology centralizes common services like firewalls and gateways, reducing cost and management overhead. It provides a secure and scalable model for connecting multiple workloads (spokes) while enforcing traffic inspection.
Hands-on Lab: Building the Hub-and-Spoke Network
| Step | Action | Command/Instructions | Expected Output/Success Indicator | Time |
|---|---|---|---|---|
| 1 | Deploy Hub VNet | Use the hubNetwork.bicep file below with the command: az deployment group create --resource-group "rg-hub-prod-eastus" --template-file hubNetwork.bicep | Successful deployment. This may take 20-30 minutes for the Firewall to provision. | 30m |
| 2 | Deploy Spoke VNet | Use spokeNetwork.bicep below with the command: az deployment group create --resource-group "rg-spoke-app1-prod-eastus" --template-file spokeNetwork.bicep | Successful deployment. | 15m |
| 3 | Peer the VNets | (Use CLI or Portal to create peering from Hub -> Spoke and Spoke -> Hub) az network vnet peering create ... | Peering status becomes Connected. | 15m |
| 4 | Configure Spoke Route | FW_PRIVATE_IP=$(az network firewall show ... --query "ipConfigurations[0].privateIpAddress") az network route-table route create ... --next-hop-type VirtualAppliance --address-prefix 0.0.0.0/0 --next-hop-ip-address $FW_PRIVATE_IP az network vnet subnet update ... --route-table <YourRouteTable> | Route table is associated with the spoke subnet. | 20m |
hubNetwork.bicep
param location string = resourceGroup().location
param vnetName string = 'vnet-hub-prod-eastus-001'
param firewallName string = 'fw-hub-prod-eastus-001'
resource publicIpFirewall 'Microsoft.Network/publicIPAddresses@2022-01-01' = {
name: '${firewallName}-pip'
location: location
sku: { name: 'Standard' }
properties: { publicIPAllocationMethod: 'Static' }
}
resource hubVnet 'Microsoft.Network/virtualNetworks@2022-01-01' = {
name: vnetName
location: location
properties: {
addressSpace: { addressPrefixes: [ '10.0.0.0/16' ] }
subnets: [
{ name: 'AzureFirewallSubnet', properties: { addressPrefix: '10.0.1.0/24' } }
]
}
}
resource firewall 'Microsoft.Network/azureFirewalls@2022-01-01' = {
name: firewallName
location: location
properties: {
sku: { name: 'AZFW_VNet', tier: 'Standard' }
ipConfigurations: [
{
name: 'fw-ipconfig'
properties: {
subnet: { id: hubVnet.properties.subnets[0].id }
publicIPAddress: { id: publicIpFirewall.id }
}
}
]
}
}
spokeNetwork.bicep
param location string = resourceGroup().location
param vnetName string = 'vnet-spoke-app1-prod-eastus-001'
resource spokeVnet 'Microsoft.Network/virtualNetworks@2022-01-01' = {
name: vnetName
location: location
properties: {
addressSpace: { addressPrefixes: [ '10.10.0.0/16' ] }
subnets: [
{ name: 'snet-workload', properties: { addressPrefix: '10.10.1.0/24' } }
]
}
}
Architectural Deep Dive & Use Case
- Deep Dive - Azure Virtual WAN (vWAN): For enterprises with a significant global footprint and many on-premises sites, vWAN is the strategic evolution of the hub-spoke model. It's a Microsoft-managed service that creates a global transit network, simplifying routing, providing built-in transitivity (spoke-to-spoke communication), and reducing operational overhead compared to managing a mesh of regional hubs yourself.
- Use Case - Securing a Regulated Workload (PCI-DSS): A payment processing application is deployed into a dedicated spoke VNet. A route table forces all its traffic through the central Azure Firewall. The firewall policy is configured to only allow connections to known payment gateways, denying all other internet traffic. This provides the provable network isolation and traffic inspection required to meet PCI compliance.
Why this matters: Centralizing services like logging and secrets management provides a single pane of glass for security and operations, reduces costs, and simplifies management across the entire estate.
Hands-on Lab: Deploying Centralized Logging
| Step | Action | Command/Instructions | Expected Output/Success Indicator | Time |
|---|---|---|---|---|
| 1 | Create Mgmt RG | az group create --name "rg-management-prod-eastus" -l "eastus" | JSON output of new RG. | 5m |
| 2 | Deploy Log Analytics | az deployment group create -g "rg-management-prod-eastus" --template-file logAnalytics.bicep | Successful deployment. | 10m |
| 3 | Create Policy | Create a DeployIfNotExists policy to send diagnostics from all Key Vaults to this workspace. | Policy definition is created. | 20m |
| 4 | Assign Policy | Assign the policy to the lz-landingzones management group, passing the workspace ID as a parameter. | Policy assignment is created. New Key Vaults will now automatically send logs. | 15m |
param location string = resourceGroup().location
param workspaceName string = 'log-analytics-prod-eastus'
resource logAnalyticsWorkspace 'Microsoft.OperationalInsights/workspaces@2021-06-01' = {
name: workspaceName
location: location
properties: {
sku: {
name: 'PerGB2018'
}
retentionInDays: 90
}
}
output workspaceId string = logAnalyticsWorkspace.id
Architectural Deep Dive & Use Case
- Deep Dive - The Subscription Vending Machine: This is the pinnacle of platform automation. It's a workflow (e.g., Logic App, GitHub Actions) that allows application teams to request and receive a new, fully configured, and compliant subscription without manual intervention. The workflow creates the sub, moves it to the correct MG (inheriting policies), deploys a baseline spoke VNet peered to the hub, and assigns the team RBAC. This transforms the platform team from a gatekeeper into an enabler.
- Use Case - Centralized Incident Response: A SOC analyst is alerted to a threat by Azure Defender for Cloud. Because all security signals (Firewall, NSG, Azure AD, Defender) are streamed to a central Log Analytics Workspace and ingested by Azure Sentinel, they can see the entire attack chain in a single incident view—from the initial risky sign-in to the network traffic and the final alert on the VM—drastically reducing investigation time from hours to minutes.
Why this matters: Applying DevOps principles to infrastructure allows for safe, repeatable, and auditable management of your landing zone. Every change is peer-reviewed and automatically validated before being deployed.
Conceptual Lab: Structuring Your Repository & Pipeline
Repository Structure: Organize your code into a logical structure.
/infra
├── /bicep
│ ├── /modules
│ │ ├── network.bicep
│ │ └── policy.bicep
│ └── main.bicep
└── /pipelines
└── deploy-landingzone.yml
Terraform State Management: For Terraform, it is critical to use a remote backend to store the state file securely and to manage locking.
terraform {
backend "azurerm" {
resource_group_name = "rg-tfstate"
storage_account_name = "sttfstateprod"
container_name = "tfstate"
key = "landingzone.tfstate"
}
}
CI/CD Pipeline (GitHub Actions): The pipeline is the engine of GitOps.
- Trigger: On pull request to the main branch.
- CI (Validation) Job:
- Check out the code.
- Install Bicep/Terraform.
- Run a linter to check code style.
- Run az deployment mg what-if (for Bicep) or terraform plan (for Terraform) to preview the changes.
- Post the plan results as a comment on the PR.
- CD (Deployment) Job:
- Trigger: On merge to the main branch.
- Requires a manual approval step in the pipeline.
- Run az deployment mg create (for Bicep) or terraform apply (for Terraform) to deploy the changes.
name: 'Deploy Landing Zone'
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Azure Login
uses: azure/login@v1
with:
creds: ${{ secrets.AZURE_CREDENTIALS }}
- name: Bicep What-If
if: github.event_name == 'pull_request'
run: |
az deployment tenant what-if \
--location eastus \
--template-file ./infra/bicep/main.bicep
deploy:
runs-on: ubuntu-latest
needs: validate
if: github.ref == 'refs/heads/main' && github.event_name == 'push'
environment: production
steps:
- uses: actions/checkout@v2
- name: Azure Login
uses: azure/login@v1
with:
creds: ${{ secrets.AZURE_CREDENTIALS }}
- name: Bicep Deploy
run: |
az deployment tenant create \
--location eastus \
--template-file ./infra/bicep/main.bicep
Module 8: Capstone Project
Objective: Deploy a complete, multi-subscription landing zone using IaC and a CI/CD pipeline, applying all concepts learned.
Statement of Work:
- Governance: Create a management group hierarchy (Platform, Landing Zones, Prod, Non-Prod).
- Networking: Deploy a hub-and-spoke topology. The hub must contain an Azure Firewall and a Log Analytics workspace. Deploy two spoke VNets (one prod, one non-prod) and peer them to the hub.
- Policy: Author and assign a policy initiative that enforces the costCenter tag on all resource groups and requires diagnostic settings on all storage accounts.
- Identity: Create a custom RBAC role for an application team that grants them contributor rights within their spoke VNet but denies them rights to modify the network peering or route tables.
- Automation: All infrastructure must be defined in Bicep or Terraform. The deployment must be executed via a GitHub Actions pipeline that validates changes on a pull request and deploys on merge to main.
Acceptance Criteria & Scoring Rubric:
| Criteria | Pass Condition | Score ( /100) |
|---|---|---|
| Management Groups | Correct hierarchy is deployed and visible. | 15 |
| Network | Hub with Firewall and Spokes are deployed. Peering is Connected. UDR on spokes forces traffic to Firewall. | 30 |
| Policy | Policy initiative is assigned. Attempting to create an untagged RG fails. | 20 |
| RBAC | Custom role is created and assigned. Test user can create a VM but cannot alter peering. | 15 |
| CI/CD | Pipeline runs what-if/plan on PR and successfully deploys on merge to main. | 20 |
| Total | 100 |
Before going live, perform this final go/no-go check.
- [ ] Governance: All required policies are assigned and showing a compliant state.
- [ ] Identity: All administrative access is managed through PIM. No standing privileged accounts exist.
- [ ] Networking: Firewall rules are locked down to least privilege. Hybrid connectivity (if any) is stable and redundant.
- [ ] Operations: Centralized logging is collecting data from all critical resources. High-priority alerts (e.g., for security events) are configured and tested.
- [ ] Costs: Budgets and cost alerts are configured for all subscriptions/management groups.
- [ ] Automation: The CI/CD pipeline is the only way infrastructure changes are deployed. The main branch is protected, requiring PRs and reviews.
- [ ] Validation: Automated health checks are in place to validate core landing zone functionality (e.g., DNS resolution, connectivity through the firewall).