Azure Landing Zone Checklist

Azure Landing Zone Checklist Skill

This skill guides you through filling out the Microsoft Azure Landing Zone (ALZ) Accelerator checklist — the spreadsheet that captures all decisions needed before deploying an ALZ using Bicep or Terraform via the ALZ Accelerator tool.

The goal is to produce a filled Excel checklist where every decision is justified, best practices are applied by default, and items requiring human input are clearly flagged for the user's attention.

Why this matters

The ALZ Accelerator checklist is the single source of truth for a platform landing zone deployment. Getting it wrong means misconfigured networking, security gaps, or hours of rework. This skill ensures consistency by applying Microsoft's Cloud Adoption Framework (CAF) recommendations while respecting the user's existing infrastructure (IP ranges, subscriptions, naming conventions).

Workflow

Phase 1: Read the checklist

Read the uploaded .xlsx checklist using openpyxl to understand its structure. ALZ checklists typically have three tabs:

• Accelerator - Bootstrap: IaC type, VCS, subscriptions, naming, CI/CD settings
• Accelerator - Bicep: Scenario selection, component toggles, IP addressing, policies
• Accelerator - Terraform: Same as Bicep with additional options (AMBA, Sovereign LZ)

Parse the checklist to identify which fields already have values (column F = "Chosen Value") and which are empty. This tells you what the user has already decided vs. what needs input.

Phase 2: Interview the user

Gather decisions through structured questions. Ask in batches of 3-4 questions to avoid overwhelming the user. Prioritize in this order:

Batch 1 — Foundational decisions:

• IaC type (Bicep or Terraform)
• Version control system (Azure DevOps, GitHub, or local)
• Network topology scenario (Hub & Spoke vs vWAN, single vs multi-region, Azure Firewall vs NVA)
• Azure region

Batch 2 — Component decisions:

• Which components to deploy (DDoS, Private DNS, Bastion, VPN Gateway, ExpressRoute, Zero Trust)
• Security posture (AMA, Defender plans)

Batch 3 — Environment-specific details:

• Azure DevOps / GitHub organization and project names
• Subscription IDs (Management, Connectivity, Identity, Security)
• Pipeline approvers
• IP addressing (ask if they have existing documentation)

When the user says "use best practices" or defers a decision, apply the recommendations from references/alz-best-practices.md. Always explain why a recommendation is made — users trust recommendations they understand.

Phase 3: Map subscriptions

If the user provides a subscription list (from az account list or similar), map subscriptions to ALZ roles by matching naming patterns:

If a required subscription is missing (commonly Security), flag it with a yellow highlight and a comment explaining the options: 1. Create a dedicated subscription (recommended) 2. Share with Management subscription (budget-constrained alternative)

Phase 4: Integrate IP addressing

If the user provides IP documentation (Markdown, CSV, Excel, or text), parse it to extract:

• Subscription-level CIDR blocks — map to ALZ hub/spoke VNets
• Existing hub VNet layout — identify subnet allocations (Gateway, Firewall, Bastion, shared services)
• On-premises public IPs — include in comments for VPN/firewall rule reference
• AKS networking — pod/service CIDRs if applicable

For the ALZ hub VNet, recommend this subnet layout using the connectivity subscription's CIDR block:

Hub VNet: <connectivity-base>/16
  GatewaySubnet:                <base>.0.0/27     (30 hosts)
  AzureFirewallSubnet:          <base>.0.64/26    (62 hosts)
  AzureFirewallManagementSubnet:<base>.0.128/26   (62 hosts)
  AzureBastionSubnet:           <base>.0.192/26   (62 hosts)
  Shared Services:              <base>.1.0/24     (254 hosts)
  DNS Resolver Inbound:         <base>.2.0/28
  DNS Resolver Outbound:        <base>.2.16/28

If no IP documentation is provided, use ALZ defaults and flag for review.

Phase 5: Fill the checklist

Use openpyxl to write values into column F ("Chosen Value") of the appropriate tabs. Apply consistent formatting:

from openpyxl.styles import Font, PatternFill, Alignment
from openpyxl.comments import Comment

# Confirmed values — green background
green_fill = PatternFill('solid', fgColor='CCE5CC')

# Items needing user action — yellow background + red bold text
yellow_fill = PatternFill('solid', fgColor='FFFF00')
action_font = Font(bold=True, color='FF0000', size=10)

# Informational notes — italic yellow background
note_fill = PatternFill('solid', fgColor='FFFFCC')
note_font = Font(italic=True, size=10)

For every cell you fill:

• Add a Comment explaining the rationale or best practice reference
• Use green fill for confirmed decisions
• Use yellow fill + red text for items requiring user action (e.g., "TO BE DEFINED", "TO BE PROVIDED")
• Use light yellow fill + italic for items using defaults that the user should review

Tab-specific logic:

Only fill the tab matching the user's IaC choice. Clear the other tab if it had values from a previous attempt. For the active tab:

1. Scenarios section: Set the chosen scenario to "Yes", all others to "No". Highlight the selected one with a brighter green. 2. Options section: Apply the user's component choices. For any option not explicitly discussed, apply best practice defaults and note this in the comment. 3. Bootstrap tab: Always fill regardless of IaC choice — it's shared.

Phase 6: Present results

After saving the filled checklist:

1. Print a summary table showing all filled values 2. List the items flagged for user action (yellow highlights) 3. Call out any architectural considerations (e.g., cross-region peering needed if ALZ region differs from existing infrastructure) 4. Provide the file link for download

Best practice recommendations

Read references/alz-best-practices.md for the full set of recommendations. The key defaults to apply when the user defers:

• Private networking: true (state storage should never be publicly accessible)
• Separate CI/CD template repo: true (security boundary between code and pipeline definitions)
• Branch policies: true (require PRs for all changes)
• Self-hosted agents/runners: true (required for private networking)
• DDoS Protection: Yes (network-layer protection for all VNet resources)
• Private DNS Zones: Yes (required for Private Endpoints across hub-spoke)
• Azure Bastion: Yes (secure VM access without public IP exposure)
• AMA (Azure Monitoring Agent): Keep enabled (centralized monitoring)
• Defender plans: Keep enabled (threat detection across all resource types)
• Zero Trust: Yes (least-privilege access and micro-segmentation)
• AMBA alerts (Terraform only): Yes (proactive monitoring of platform resources)
• Sovereign Landing Zone: No (unless explicitly required for compliance)

Cross-region considerations

If the user's existing infrastructure is in a different region than the ALZ deployment, flag this in the Bootstrap tab's region comment. They'll need to plan for cross-region VNet peering between the ALZ hub and any existing hub-spoke topology.

Cell Reference Map

The checklist has a fixed structure. Use these exact cell references when writing values to avoid row-offset bugs. Always verify by checking that column B (Name) matches the expected field before writing to column F.

Bootstrap Tab (Accelerator - Bootstrap)

Note: Rows 7, 14, 19, 20, 26, 27, 35, 36, 41 are blank or section headers — skip them.

Bicep Tab (Accelerator - Bicep) — Scenarios

Bicep Tab — Options (rows 17-30)

Terraform Tab (Accelerator - Terraform)

Same scenario layout as Bicep (rows 6-14). Options are rows 17-32:

Validation approach: Before writing any value, read cell B{row} and verify it matches the expected field name. If it doesn't match, scan the sheet to find the correct row. This prevents silent data corruption from template version differences.

Output format

The final deliverable is an .xlsx file with:

• All three tabs preserved from the original template
• Column F filled with chosen values
• Cell comments with rationale and best practice references
• Color coding: green (confirmed), yellow (needs action), light yellow (defaults to review)
• A clear summary in the conversation listing all decisions and flagged items

---

Gotchas

• openpyxl row indices are 1-based — off-by-one bugs corrupt the wrong row silently; verify with cell.value read-back before commit.
• Subscription regex matching breaks on non-standard naming (e.g., sub-xyz-platform-mgmt) — fall back to enumeration when pattern fails.
• Cross-region considerations: VNet peering across regions costs egress traffic; default ALZ template doesn't price this.
• Excel checkboxes vs cell values: openpyxl can't write checkbox state — use cell value "✓" + named range to indicate checked.
• Subscription quota propagation: requested quota increases show as "Approved" before the quota is actually applied — verify with az vm list-usage.

Azure Landing Zone — Best Practice Recommendations

This reference contains Microsoft Cloud Adoption Framework (CAF) and Well-Architected Framework recommendations for each ALZ Accelerator checklist decision. Use these when the user defers a decision or asks for guidance.

Table of Contents

• Bootstrap Settings
• Network Topology
• Security & Monitoring
• Identity & Access
• IP Addressing
• Policy & Governance
• CI/CD Pipeline

---

Bootstrap Settings

IaC Type: Bicep vs Terraform

Both are fully supported. Key differences:

• Bicep: Azure-native, no state management needed, tighter Azure integration
• Terraform: Multi-cloud, larger ecosystem, state file management required (but accelerator handles this)

Recommendation: Match the team's existing skillset. If no preference, Terraform has broader community support.

Version Control System

• Azure DevOps: Best for enterprises already using Azure ecosystem, supports private networking with self-hosted agents
• GitHub: Best for open-source-friendly teams, GitHub Actions integration
• Local: Only for testing/development, not production deployments

Recommendation: Match existing organizational tooling.

Starter Module

Always use platform_landing_zone — it's the comprehensive module that deploys the full ALZ architecture including management groups, policies, connectivity, and identity resources.

Resource Naming

Default naming (alz, mgmt, postfix 1) is suitable for most deployments. Customize only if:

• Organization has strict naming conventions
• Multiple ALZ deployments exist in the same tenant
• Regulatory requirements dictate specific naming patterns

Parent Management Group

Default (Tenant Root Group) is recommended for initial deployments. Use a custom parent only if:

• The tenant is shared across multiple organizations
• There's an existing management group hierarchy to preserve
• Regulatory isolation requires a separate management group tree

---

Network Topology

Hub & Spoke vs Virtual WAN

Recommendation: Hub & Spoke for most organizations. vWAN only for very large, multi-region deployments with complex routing needs.

Single vs Multi-Region

Start with single-region unless:

• Business continuity requires active-active or active-passive across regions
• Data residency laws require resources in multiple geographies
• Latency requirements demand regional proximity to users

Recommendation: Start single-region, expand later. The ALZ architecture supports adding regions incrementally.

Azure Firewall vs NVA

• Azure Firewall: Fully managed, auto-scales, native Azure integration, simpler operations
• NVA (e.g., Palo Alto, Fortinet): Existing vendor relationship, specific feature requirements, existing firewall policies to migrate

Recommendation: Azure Firewall unless the organization has existing NVA investments or specific feature requirements not available in Azure Firewall.

---

Security & Monitoring

Azure Monitoring Agent (AMA)

Keep enabled. AMA provides:

• Centralized log collection to Log Analytics
• Data Collection Rules (DCR) for flexible data routing
• Performance monitoring across all deployed resources
• Integration with Azure Monitor alerts and workbooks

Disabling AMA removes visibility into platform health. Only disable if using a third-party monitoring solution that replaces all AMA capabilities.

Microsoft Defender for Cloud

Keep all plans enabled. Defender provides:

• Servers: Vulnerability assessment, endpoint detection, file integrity monitoring
• Storage: Malware scanning, anomaly detection on storage accounts
• SQL/Databases: SQL injection detection, access anomaly alerts
• Key Vault: Unusual access pattern detection, secret enumeration alerts
• DNS: DNS tunneling detection, communication with known malicious domains
• ARM: Suspicious management plane operations, privilege escalation attempts

The cost of Defender is significantly lower than the cost of a security incident. Only disable specific plans if a third-party tool covers that exact capability.

Azure Monitor Baseline Alerts (AMBA) — Terraform only

Deploy AMBA policies. They provide out-of-the-box alerting for:

• Platform resource health (VPN Gateway, ExpressRoute, Firewall)
• Service health notifications
• Resource availability metrics

Without AMBA, platform issues may go undetected until users report problems.

DDoS Protection Plan

Deploy DDoS Protection Plan. It provides:

• Network-layer protection for all public IPs in linked VNets
• Automatic traffic scrubbing during attacks
• Attack analytics and rapid response support
• Cost protection (credits for scale-out during attacks)

Note: DDoS Protection Plan has a monthly base cost (~$2,944/month). For budget-constrained deployments, DDoS Network Protection (per-IP) is an alternative.

Zero Trust Security

Enable Zero Trust configuration. It enforces:

• Least-privilege access across all management groups
• Micro-segmentation between network tiers
• Continuous verification of identity and device compliance
• NSG/ASG rules that default-deny and explicitly allow required flows

Zero Trust is not an "extra" security layer — it's the baseline architectural pattern that Microsoft recommends for all new Azure deployments.

---

Identity & Access

Dedicated Identity Subscription

The Identity subscription hosts:

• Azure AD Domain Services (if needed)
• Domain controllers (if extending on-premises AD)
• DNS forwarders
• Identity-related Private Endpoints

It should be separate from Management and Connectivity to maintain security boundaries.

Dedicated Security Subscription

A dedicated Security subscription is recommended for:

• Microsoft Sentinel workspace
• Defender for Cloud data
• Security automation (Logic Apps, Functions)
• Security-specific Log Analytics workspace

If budget is constrained, Security workloads can share the Management subscription, but this reduces the security boundary between operations and security teams.

---

IP Addressing

Subnet Sizing for Hub VNet

Address Space Planning

• Allocate generously — IP space is free, re-addressing is expensive
• Use /13 per subscription for maximum flexibility (524,288 addresses)
• Use /16 for individual VNets (65,534 addresses)
• Ensure no overlap with on-premises ranges
• Reserve space for future growth (AKS clusters, additional spokes)

On-Premises Integration

When VPN or ExpressRoute connects to on-premises:

• Document all on-premises CIDR ranges to prevent overlap
• Include on-premises public IPs in firewall/NSG rule comments
• Plan for NAT if overlapping ranges cannot be avoided

---

Policy & Governance

Default Policy Assignments

Keep all default ALZ policy assignments. They enforce:

• Allowed resource locations
• Required tags
• Diagnostic settings to Log Analytics
• Network security baseline
• Encryption requirements

Recommendation: Use enforcement mode changes (DoNotEnforce) rather than removing policies. This preserves audit trail while allowing exceptions.

Custom Management Group Names

Use default ALZ management group names unless:

• Organization has strict naming conventions for all Azure resources
• Multiple ALZ deployments exist and need disambiguation
• Regulatory requirements dictate specific naming

Default names are well-documented and recognized by Microsoft support, making troubleshooting easier.

---

CI/CD Pipeline

Separate Template Repository

Use a separate repository for CI/CD templates. This:

• Prevents developers from modifying pipeline definitions
• Creates a security boundary between infrastructure code and deployment logic
• Allows pipeline template updates independent of infrastructure changes

Private Networking for State Storage

Enable private networking for Terraform state storage. This:

• Prevents state files from being accessible over the internet
• State files contain sensitive information (resource IDs, configuration details)
• Required for compliance in most regulated industries

Self-Hosted Agents/Runners

Use self-hosted agents when private networking is enabled. They:

• Can access private endpoints (storage accounts, Key Vaults)
• Run inside the organization's network boundary
• Provide more control over the execution environment
• Are required when state storage is not publicly accessible

Branch Policies

Enable branch policies to:

• Require pull requests for all changes to main/production branches
• Enforce code review before infrastructure changes are applied
• Create an audit trail of who approved what changes
• Prevent accidental direct pushes to production

Pipeline Approvers

Configure at least 2 approvers for the apply stage:

• Ensures no single person can make infrastructure changes unilaterally
• Creates accountability for production-impacting changes
• Required by most compliance frameworks (SOC 2, ISO 27001)