alz-accelerator

Azure Landing Zones Accelerator 技能

使用 Azure Verified Modules（AVM）通过 ALZ Accelerator 部署 Azure Landing Zones。本技能总结了 ALZ 核心团队推荐的工作流、决策框架和最佳实践。

核心概念

AVM（Azure Verified Modules）： 一种基础结构即代码标准，用于按照最佳实践部署 Azure 资源。AVM 包含资源模块（单个资源）和模式模块（由资源模块组成的复杂架构模式）。AVM 是部署 Azure Landing Zones 基础结构的唯一推荐方式。

ALZ Accelerator： 一种用于启动整个 Azure Landing Zone 部署的工具，包括 CI/CD 流水线、版本控制和基础结构配置。它在底层使用 AVM 模块。

Deployment Stacks（Bicep）： Bicep 加速器使用 Deployment Stacks 来处理资源生命周期管理，免去手动管理策略分配和资源删除的繁琐工作。

决策框架：Bicep 还是 Terraform

继续部署前，请引导用户完成此项决策。

何时选择 Terraform

• 团队已具备 Terraform 专业知识
• 采用多云策略（AWS、GCP、Azure）—— 无需学习两种 IaC 语言
• Terraform ALZ 模块更成熟（于 2025 年初左右发布），可通过 tfvars 完整配置
• 需要基于状态的漂移检测

何时选择 Bicep

• 仅使用 Azure 的组织，没有多云计划
• 团队熟悉 ARM 模板或 Azure 原生工具
• 无需管理状态文件（优点和缺点兼具——运维更简单，但漂移可见性较低）
• Microsoft ARM/Bicep 产品组建议仅使用 Azure 的团队选择 Bicep
• Bicep ALZ 于 2026 年 2 月左右发布，全面支持 AVM、Deployment Stacks 和可自定义模块

中立观点

• 两者都使用 AVM 模块——底层资源定义相同
• 加速器对两者的支持一致，启动体验也完全相同
• 到 2026 年，两者之间的差距正在迅速缩小
• 默认建议： 根据团队现有技能选择

加速器部署工作流

先决条件

1. 安装 ALZ PowerShell 模块：

   Install-Module -Name ALZ
   

2. 确保具备以下条件：

   • 已通过 Azure CLI 或 PowerShell 完成身份验证
   • GitHub PAT 或 Azure DevOps PAT（取决于 VCS 选择）
   • 至少 4 个平台订阅：Management、Connectivity、Identity、Security
   • 用于存储状态和身份的引导订阅

步骤 1：启动加速器

Deploy-Accelerator

加速器会通过引导式提示以交互方式运行。（截至最新版本）无需提供任何参数。

步骤 2：检查软件

加速器会验证是否已安装所需软件。继续操作前，请处理所有缺失的依赖项。

步骤 3：选择缓存位置

选择用于在设置过程中存储临时文件的位置。通常使用默认值即可。

步骤 4：选择 IaC 语言

选择以下其中一种：

• Terraform — 配置更成熟，所有配置均通过 tfvars 完成
• Bicep — Azure 原生，无状态文件，并通过 Deployment Stacks 管理生命周期

步骤 5：选择版本控制和 CI/CD 平台

选择以下其中一种：

• GitHub（默认，推荐）
• Azure DevOps
• 本地文件系统（用于自定义引导）

步骤 6：选择连接方案

选择网络拓扑：

• Hub and Spoke — 传统的中心辐射式网络，使用 VNet 对等互连（最常见）
• Virtual WAN — 由 Azure Virtual WAN 管理的中心
• 上述方案的多区域变体

步骤 7：交互式配置

加速器会向 Azure 查询现有资源，并提示你进行选择：

1. 引导区域 — 部署状态存储和身份的位置
2. 根管理组 — ALZ 层次结构的父 MG
3. 平台订阅：
   • 管理订阅（Log Analytics、监控）
   • 身份订阅（Active Directory、DNS）
   • 连接订阅（Hub VNet、防火墙、VPN/ER 网关）
   • 安全订阅（Sentinel、Defender）
4. 引导订阅 — 用于 Terraform 状态存储和托管身份

步骤 8：命名约定

接受默认值，或自定义引导资源的命名模式。

步骤 9：运行器配置

选择以下其中一种：

• 自托管运行器 — 推荐用于专用网络
• Microsoft 托管运行器 — 更简单，但需要公共终结点

如果选择自托管运行器，请选择是否启用专用网络（存储帐户无法通过公共网络访问）。

步骤 10：身份验证

提供：

• 个人访问令牌 — GitHub PAT 或 Azure DevOps PAT（存储为环境变量，绝不存入配置文件）
• GitHub/ADO 组织名称
• 应用批准者 — 批准从计划阶段进入应用阶段的用户名

步骤 11：检查并在 IDE 中打开

加速器会生成配置文件并在 VS Code 中打开。请检查并更新：

1. 平台着陆区配置：
   • 主要和次要部署区域（例如，UK South、UK West）
   • Defender 安全联系邮箱
2. 敏感值以环境变量的形式存储在当前终端会话中，而不是存储在纯文本文件中

步骤 12：引导部署

确认配置已完成。加速器将引导部署以下内容：

• 状态存储（Terraform）或部署堆栈（Bicep）
• 用于 CI/CD 的托管身份
• 包含管道的 GitHub 存储库/Azure DevOps 项目
• 分支策略和审批

部署后

加速器完成后：

1. CI/CD 管道会在你选择的 VCS 中创建
2. 计划/What-If 阶段会在 PR 上自动运行
3. 应用/部署阶段需要由配置的批准者批准
4. 后续更改通过配置文件进行，并通过管道推送

AVM 模块架构

ALZ 部署使用以下关键 AVM 模式模块：

模块	用途
管理组	层次结构：租户根 → 平台（管理、连接、身份）→ 着陆区（Corp、Online）
管理	Log Analytics 工作区、Automation Account、监控
连接（Hub-Spoke）	Hub VNet、Azure Firewall、VPN/ER 网关、DNS
连接（vWAN）	Virtual WAN、Virtual Hubs、路由
身份	DNS 区域、域控制器网络
策略	Azure Policy 分配、自定义策略定义

你可以单独使用这些模块（自行组合），也可以通过加速器使用（推荐方式）。

规则

1. 始终使用 AVM 模块 — 如果存在 AVM 模块，切勿使用原始 azurerm/azapi 资源部署 ALZ 资源
2. 使用加速器 — 除非有特定原因，否则不要手动组合模块；加速器会处理引导、CI/CD 和配置
3. 与团队技能相匹配 — 不要在使用 Bicep 的团队中强推 Terraform，反之亦然
4. 生产环境使用专用网络 — 任何生产部署都应使用带专用网络的自托管运行器
5. 切勿将 PAT 存储在配置文件中 — 加速器使用环境变量存储敏感值；请保持这一做法
6. 至少需要四个平台订阅 — 管理、连接、身份、安全 — 不要将它们合并
7. 先计划，再应用 — 批准部署前，务必检查计划/what-if 输出
8. 通过配置自定义，而非编辑模块 — 对于 Terraform，所有自定义都通过 tfvars 进行。对于 Bicep，可以直接编辑模块，但尽可能优先采用配置方式

故障排除

问题	解决方案
部署堆栈缺陷（Bicep）	已知限制 — what-if 尚未得到全面支持。请查看 ALZ GitHub issues
策略分配冲突	使用分离的自定义策略与默认策略结构（Bicep 2026 版）
状态文件管理（Terraform）	状态会自动引导；不要手动修改后端配置
从旧版 ALZ 升级时遇到困难	新版 Bicep 将你的自定义内容与上游模块解耦

资源

• 问题表单：aka.ms/alz/quests
• ALZ 文档：aka.ms/alz
• AVM 注册表：aka.ms/avm
• ALZ 加速器文档：aka.ms/alz/accelerator

---

注意事项

• Bicep what-if 结果仅供参考 — 嵌套部署可能会将已存在的资源显示为“Create”；请以 ARM 部署输出为准，不要只依赖 what-if。
• AVM 模块版本在部署时固定 — 过时的 version: 参数会拉取数月前发布的版本，其中可能包含你已在本地修复的缺陷。
• 管理组 ID 是全局唯一的 — 如果选择的名称发生冲突，部署进行到一半时会返回 409，此时其他部署也已执行一半。
• 默认策略分配包含审核效果，会在非生产环境产生大量活动日志 — 请明确禁用，否则噪声会淹没真实信号。
• 订阅配额在创建时检查，而非验证时 — what-if 会通过，但 5 分钟后创建会因配额错误而失败。
• Bicep 模板规范与原始 .bicep 的区别：模板规范会在 ARM 中进行版本管理；部署原始 .bicep 时则完全跳过该版本管理。