Azure Enterprise Infra Planner

Azure Enterprise Infra Planner 是什么

Azure Enterprise Infra Planner 面向企业级 Azure 基础设施设计，围绕网络、身份、安全、合规、备份、灾备和多资源拓扑生成经过 WAF 评审的计划，并直接输出 Bicep 或 Terraform，不依赖 azd。

适用场景与选择边界

适合 Landing Zone、Hub-Spoke、私有终结点、多区域灾备、订阅级部署和 VM Backup 等平台级方案；也能参考现有环境做 brownfield 设计。应用中心的 azd 工作流优先 Azure Prepare；只想画现有资源关系使用 Resource Visualizer。它也不直接替代 CAF Landing Zone 的组织治理项目。

核心能力与工作机制

流程通过环境 insights、Azure 最佳实践、Well-Architected 服务指南、文档和 Bicep schema 收集证据，产出结构化计划、约束与资源组合检查，再经过批准门生成 IaC 并运行 bicep build、terraform validate 或 Checkov。

实际工作流

先区分 greenfield 与 referenced brownfield，收集业务、区域、身份、网络、合规和 RTO/RPO；发现现有环境并写 .azure/insights.json，设计架构和成本边界，用户批准计划后才生成 infra，验证通过后再讨论部署。

输入、输出与交付物

需要工作负载描述、组织与订阅结构、连接需求、数据分类、合规、区域、可用性、RTO/RPO、预算和 IaC 偏好。输出是 .azure 下的洞察和计划、架构决策、资源拓扑、约束、WAF 清单以及 infra 目录中的 Bicep 或 Terraform；计划和代码应可追溯到输入。

依赖、账号与权限

需要 Azure 读取权限获取现状，生成和验证需 Azure CLI、Bicep 或 Terraform；部署还需要更高权限但不应在计划未批准时使用。

限制与安全风险

企业网络、身份和 SKU 组合错误会造成大范围安全或连通性问题；brownfield 信息不全会导致冲突。自动生成 IaC 不能替代组织策略、威胁建模和变更审批。发现与规划主要只读并写本地文件；生成 IaC 会改变工作区，真正执行 deployment 或 terraform apply 会创建大量计费资源，必须在批准与验证后单独确认。

适合谁使用

适合云架构师、平台工程师和负责企业网络与治理的团队。

上手与验收建议

先用一个代表性业务域完成计划与静态验证，不立即部署到生产订阅。验收要检查计划状态 approved、输入约束完整、架构满足 WAF 与 RTO/RPO、所有 IaC 文件存在并通过格式与静态验证；brownfield 还要与现有资源和策略交叉核对。

来源、版本与许可

本条目依据 Microsoft 官方 azure-skills 仓库固定提交中的完整 Azure Enterprise Infra Planner Skill、skills.sh 市场详情和仓库 MIT 许可证整理，核验日期为 2026 年 9 月 20 日。来源未提供官方中文展示名，因此导航保留官方英文名称。

常见问题

1. Azure Enterprise Infra Planner 主要解决什么问题？

Azure Enterprise Infra Planner 面向企业级 Azure 基础设施设计，围绕网络、身份、安全、合规、备份、灾备和多资源拓扑生成经过 WAF 评审的计划，并直接输出 Bicep 或 Terraform，不依赖 azd。适合 Landing Zone、Hub-Spoke、私有终结点、多区域灾备、订阅级部署和 VM Backup 等平台级方案；也能参考现有环境做 brownfield 设计。

2. 开始前需要准备哪些输入和上下文？

需要工作负载描述、组织与订阅结构、连接需求、数据分类、合规、区域、可用性、RTO/RPO、预算和 IaC 偏好。需要 Azure 读取权限获取现状，生成和验证需 Azure CLI、Bicep 或 Terraform；部署还需要更高权限但不应在计划未批准时使用。

3. 执行后会得到什么结果或文件？

输出是 .azure 下的洞察和计划、架构决策、资源拓扑、约束、WAF 清单以及 infra 目录中的 Bicep 或 Terraform；计划和代码应可追溯到输入。

4. 需要哪些账号、工具和最小权限？

需要 Azure 读取权限获取现状，生成和验证需 Azure CLI、Bicep 或 Terraform；部署还需要更高权限但不应在计划未批准时使用。企业网络、身份和 SKU 组合错误会造成大范围安全或连通性问题；brownfield 信息不全会导致冲突。自动生成 IaC 不能替代组织策略、威胁建模和变更审批。

5. 它会修改本地文件或云端资源吗？

发现与规划主要只读并写本地文件；生成 IaC 会改变工作区，真正执行 deployment 或 terraform apply 会创建大量计费资源，必须在批准与验证后单独确认。

6. 哪些需求不应该交给这个 Skill？

应用中心的 azd 工作流优先 Azure Prepare；只想画现有资源关系使用 Resource Visualizer。它也不直接替代 CAF Landing Zone 的组织治理项目。

7. 遇到失败或结果异常时怎样处理？

MCP 失败时最多重试一次并回退参考，计划缺批准必须停止；IaC 验证失败要修复而不能部署。发现 SKU 或配对约束冲突时应回到计划阶段。

8. 如何验收结果确实可靠？

验收要检查计划状态 approved、输入约束完整、架构满足 WAF 与 RTO/RPO、所有 IaC 文件存在并通过格式与静态验证；brownfield 还要与现有资源和策略交叉核对。