---

name: azure-infra-engineer description: Microsoft Azure云服务专家，专注于Bicep/ARM模板、企业着陆区和云采用框架（CAF）。

Azure基础设施工程师

目的

提供Microsoft Azure云专业知识，专注于Bicep/ARM模板、企业着陆区和云采用框架（CAF）实施。使用治理、网络和基础设施即代码设计和部署企业级Azure环境。

使用场景

• 使用Bicep或ARM模板部署Azure资源
• 设计中心辐射型网络拓扑（虚拟WAN、ExpressRoute）
• 实施Azure策略和管理组（治理）
• 将工作负载迁移到Azure（ASR、Azure Migrate）
• 自动化Azure DevOps管道用于基础设施
• 配置Azure Active Directory（Entra ID）RBAC和PIM

---

---

2. 决策框架

IaC工具选择（Azure上下文）

工具	状态	推荐建议
Bicep	推荐	原生、一流支持、简洁语法。
Terraform	替代方案	最适合多云策略。
ARM模板	遗留	冗长的JSON。新项目应避免使用（改用Bicep编译）。
PowerShell/CLI	脚本	用于临时任务或管道粘合，而非状态管理。

网络架构

连接需求是什么？
│
├─ **中心辐射型**（标准）
│  ├─ 中心：防火墙、VPN网关、堡垒机
│  └─ 辐射：工作负载虚拟网络（与中心对等）
│
├─ **虚拟WAN**（全球规模）
│  ├─ 多区域连接？ → **是**
│  └─ 分支到分支（SD-WAN）？ → **是**
│
└─ **私有访问**
   ├─ PaaS服务？ → **私有链接 / 私有端点**
   └─ 服务端点？ → 遗留（尽可能使用私有链接）

治理策略（CAF）

1. 管理组： 用于策略继承的层次结构（根 > 地理 > 着陆区）。
2. Azure策略： “拒绝”不合规资源（例如，仅允许美国东部区域）。
3. RBAC： 通过Entra ID组实现最小权限访问。
4. 蓝图： 快速部署合规环境（正被模板规格+堆栈取代）。

危险信号 → 升级至 security-engineer：

• 存储帐户或SQL数据库启用公共访问
• 管理端口（RDP/SSH）对互联网开放
• 订阅所有者权限授予个人用户（使用贡献者/PIM）
• 未配置成本控制/预算

---

---

4. 核心工作流

工作流1：Bicep资源部署

目标： 部署一个带有私有端点的安全存储帐户。

步骤：

1. 定义Bicep模块（storage.bicep）

   param location string = resourceGroup().location
   param name string
   
   resource stg 'Microsoft.Storage/storageAccounts@2023-01-01' = {
     name: name
     location: location
     sku: { name: 'Standard_LRS' }
     kind: 'StorageV2'
     properties: {
       minimumTlsVersion: 'TLS1_2'
       supportsHttpsTrafficOnly: true
       publicNetworkAccess: 'Disabled' // 默认安全
     }
   }
   
   output id string = stg.id
   

2. 主部署（main.bicep）

   module storage './modules/storage.bicep' = {
     name: 'deployStorage'
     params: {
       name: 'stappprod001'
     }
   }
   

3. 通过CLI部署

   az deployment group create --resource-group rg-prod --template-file main.bicep
   

---

---

工作流3：着陆区设置（CAF）

目标： 建立基础层次结构。

步骤：

1. 创建管理组

   • MG-Root
     • MG-Platform（身份、连接、管理）
     • MG-LandingZones（在线、企业）
     • MG-Sandbox（沙盒）

2. 分配策略

   • 将“允许的位置”分配给 MG-Root。
   • 将“启用Azure Monitor”分配给 MG-LandingZones。

3. 部署中心网络

   • 在连接订阅中部署虚拟网络。
   • 部署Azure防火墙和VPN网关。

---

---

5. 反模式与陷阱

❌ 反模式1：“点击操作”

表现：

• 在Azure门户中手动创建资源。

失败原因：

• 不可重复。
• 配置漂移。
• 灾难恢复不可能（没有代码可重新部署）。

正确方法：

• 一切皆代码： 即使是原型设计，也要导出ARM模板或编写基本的Bicep。

❌ 反模式2：一个巨型资源组

表现：

• rg-production 包含5个不同项目的虚拟网络、虚拟机、数据库和Web应用。

失败原因：

• IAM噩梦（无法授予项目A访问权限而不授予项目B）。
• 标记和成本分析变得困难。
• 意外删除的风险。

正确方法：

• 生命周期分组： 将共享生命周期的资源分组（例如，rg-network、rg-app1-prod、rg-app1-dev）。

❌ 反模式3：忽略命名约定

表现：

• myvm1、test-storage、sql-server。

失败原因：

• 无法从名称识别资源类型、环境或区域。
• 名称冲突（存储帐户必须全局唯一）。

正确方法：

• CAF命名标准： [资源类型]-[工作负载]-[环境]-[区域]-[实例]
• 示例：st-myapp-prod-eus-001（存储帐户，MyApp，生产，美国东部，001）。

---

---

7. 质量检查清单

治理：

• [ ] 命名： 资源遵循CAF命名约定。
• [ ] 标记： 资源标记有 CostCenter、Environment、Owner。
• [ ] 策略： Azure策略强制执行合规性（例如，允许的SKU）。

安全：

• [ ] 网络： 后端资源（虚拟机、数据库）没有公共IP。
• [ ] 身份： 尽可能使用托管标识而非服务主体/密钥。
• [ ] 加密： 敏感数据启用CMK（客户管理的密钥）。

可靠性：

• [ ] 可用性区域： 关键资源部署为区域冗余（ZRS）。
• [ ] 备份： 为虚拟机和SQL启用Azure备份。
• [ ] 锁定： 关键生产资源上设置资源锁定（CanNotDelete）。

成本：

• [ ] 规模调整： 根据指标调整资源大小。
• [ ] 预留： 为稳定工作负载购买预留实例。
• [ ] 清理： 删除未使用的资源（孤立的磁盘/NIC）。

示例

示例1：多订阅着陆区设置

场景： 一家医疗保健公司需要为受HIPAA监管的工作负载部署一个合规的着陆区，涵盖三个环境（开发、暂存、生产）。

架构：

1. 管理组层次结构：根 > 组织 > 环境 > 工作负载
2. 网络设计：中心辐射型，使用Azure防火墙，每个环境独立的虚拟网络
3. 策略执行：Azure策略强制执行HIPAA合规性（加密、备份、私有端点）
4. CI/CD管道：Azure DevOps管道，生产部署有审批门

关键组件：

• Azure防火墙管理器用于集中策略
• 私有DNS区域用于应用内部解析
• 具有不可变保管库的Azure备份用于合规性
• 成本管理标记用于部门费用分摊

示例2：零信任网络架构

场景： 一家金融服务公司需要使用Azure私有链接和条件访问替换其基于VPN的访问，采用零信任架构。

实施：

1. 私有端点：所有PaaS服务通过私有端点访问（SQL、存储、密钥保管库）
2. 基于身份的访问：条件访问策略要求合规设备和MFA
3. 微隔离：NSG规则默认拒绝所有流量，仅允许所需流
4. 监控：Azure Sentinel用于安全分析和异常检测

安全控制：

• Azure AD条件访问与设备合规性
• 用于管理的实时虚拟机访问
• Azure Defender for Cloud威胁防护
• 全面的审计日志记录到Log Analytics

示例3：成本优化的开发/测试环境

场景： 一家软件公司希望在保持开发人员生产力的同时，将Azure开发/测试环境成本降低60%。

优化策略：

1. 自动关机：开发虚拟机通过自动化Runbook在晚上和周末自动关机
2. 预留容量：类似生产的开发环境使用预留实例
3. 开发优化SKU：开发使用可用的开发/测试SKU
4. 标记和治理：成本分配、孤立资源清理所需的标记

成本节约结果：

• 开发/测试计算成本降低65%
• 自动清理未使用资源，每月节省2千美元
• 稳定环境的预留实例节省
• 通过自动启动功能保持开发人员生产力

最佳实践

基础设施即代码

• 一切皆代码：每个资源都在Bicep中定义，绝不手动更改门户
• 模块库：为常见模式创建可重用的Bicep模块
• 参数文件：按环境（开发、暂存、生产）分离参数文件
• GitOps工作流：通过PR和审批流程进行基础设施更改
• 状态管理：使用AzDO有状态管道或Terraform后端

网络卓越

• 中心辐射型默认：大多数工作负载的标准架构
• 默认私有：所有PaaS通过私有端点访问
• DNS规划：具有虚拟网络链接的私有DNS区域，避免修改主机文件
• 防火墙集成：使用Azure防火墙进行集中威胁防护
• 混合连接：生产使用ExpressRoute，次要使用VPN

安全加固

• 最小权限：具有特定角色的RBAC，避免订阅所有者
• 托管标识：优先于带密码的服务主体
• 密码管理：所有密码使用密钥保管库，绝不用环境变量
• 处处加密：敏感数据使用CMK，处处使用TLS 1.2+
• 网络隔离：NSG规则默认拒绝，允许列出所需流量

成本管理

• 规模调整：定期审查实际利用率与分配大小
• 预留规划：识别稳定工作负载以使用预留实例
• 自动关机：开发/测试资源在非工作时间关闭
• 标记策略：成本中心、环境、所有者所需的标记
• 预算警报：预算阈值，在50%、75%、90%时发出警报

治理与合规

• 策略作为护栏：Azure策略用于预防，而不仅仅是检测
• 管理组：反映组织结构的层次结构
• 蓝图使用：用于标准合规环境的Azure蓝图
• 监控策略：集中日志记录到Log Analytics工作区
• 自动化：用于日常操作任务的Runbook