Azure IaaS 成本优化：把省钱设计进云基础设施

预计阅读时间：8 分钟

企业把关键业务迁到云上、重构云原生应用、扩展 AI 工作负载时，IaaS 成本很容易从“按需弹性”变成“持续膨胀”。真正长期有效的成本优化，不是月底看账单后手动关几台虚拟机，而是在设计、构建和运营 Azure 基础设施时，把成本效率当成架构原则。

成本优化不是砍预算，而是提高每一元的计算产出

Azure IaaS 的成本主要来自虚拟机、磁盘、网络、备份、日志、快照和跨区域流量。很多团队一开始只盯 VM 单价，但长期成本通常藏在这些地方：

VM 规格长期过大，CPU 利用率常年个位数。
测试环境夜间和周末无人使用，却持续运行。
高性能磁盘被默认分配给低 I/O 工作负载。
公网出口、跨区域复制和日志保留策略没有成本边界。
AI 或批处理场景峰谷明显，却按固定容量部署。

更好的做法是从工作负载特征出发：哪些必须 24x7 高可用，哪些可以定时启动，哪些能用 Spot VM，哪些适合预留实例或节省计划。成本优化的目标不是“便宜”，而是让可靠性、性能和预算处在可解释的平衡点。

设计阶段：先给资源贴上业务语义

长期成本治理离不开资源可见性。Azure 资源如果没有统一标签，账单只能按订阅或资源组粗略归类，很难回答“哪个产品线在烧钱”“哪个环境应该被自动关闭”。

可以这样设计标签规范：

environment: prod、staging、dev、test
owner: 团队或负责人邮箱别名
costCenter: 成本中心或项目编号
workload: 业务系统名
shutdown: 是否允许自动关机，例如 true 或 false

下面是一个可以改造的 Azure CLI 示例，用来创建资源组、打标签，并部署一台适合开发环境的 VM。运行前需要安装 Azure CLI，并执行 az login。

#!/usr/bin/env bash
set -euo pipefail

LOCATION="eastus"
RESOURCE_GROUP="rg-demo-cost-dev"
VM_NAME="vm-demo-dev-01"
ADMIN_USER="azureuser"

az group create \
  --name "$RESOURCE_GROUP" \
  --location "$LOCATION" \
  --tags \
    environment=dev \
    owner=platform-team \
    costCenter=demo-001 \
    workload=cost-demo \
    shutdown=true

az vm create \
  --resource-group "$RESOURCE_GROUP" \
  --name "$VM_NAME" \
  --image Ubuntu2204 \
  --size Standard_B2s \
  --admin-username "$ADMIN_USER" \
  --generate-ssh-keys \
  --public-ip-sku Standard \
  --tags \
    environment=dev \
    owner=platform-team \
    costCenter=demo-001 \
    workload=cost-demo \
    shutdown=true

这里选择 Standard_B2s 是因为它适合轻量开发或测试场景。生产工作负载不应照抄规格，而应根据 CPU、内存、磁盘 IOPS、网络吞吐和可用性要求重新评估。

构建阶段：让自动化替代人工记忆

成本优化最怕依赖“大家记得关机器”。更可靠的方式是把策略写成自动化：开发环境定时关机，空闲资源定期扫描，预算超过阈值时通知负责人。

例如，给开发 VM 配置每日自动关机：

RESOURCE_GROUP="rg-demo-cost-dev"
VM_NAME="vm-demo-dev-01"
LOCATION="eastus"

az vm auto-shutdown \
  --resource-group "$RESOURCE_GROUP" \
  --name "$VM_NAME" \
  --time 1900 \
  --email "platform-team@example.com"

如果团队使用 Infrastructure as Code，也可以把标签和 VM 规格写进 Bicep，避免每次手工创建资源时遗漏成本字段：

param location string = resourceGroup().location
param vmName string = 'vm-demo-dev-01'
param adminUsername string = 'azureuser'
param adminPassword string

var commonTags = {
  environment: 'dev'
  owner: 'platform-team'
  costCenter: 'demo-001'
  workload: 'cost-demo'
  shutdown: 'true'
}

resource vm 'Microsoft.Compute/virtualMachines@2023-09-01' = {
  name: vmName
  location: location
  tags: commonTags
  properties: {
    hardwareProfile: {
      vmSize: 'Standard_B2s'
    }
    osProfile: {
      computerName: vmName
      adminUsername: adminUsername
      adminPassword: adminPassword
    }
    storageProfile: {
      imageReference: {
        publisher: 'Canonical'
        offer: '0001-com-ubuntu-server-jammy'
        sku: '22_04-lts-gen2'
        version: 'latest'
      }
      osDisk: {
        createOption: 'FromImage'
        managedDisk: {
          storageAccountType: 'StandardSSD_LRS'
        }
      }
    }
  }
}

这个示例省略了网络接口等完整生产配置，适合作为成本标签和规格选择的 IaC 片段参考。真正落地时，应补齐 VNet、Subnet、NSG、NIC、备份、监控和安全基线。

运营阶段：用指标驱动持续优化

IaaS 成本不是一次性优化项目，而是一组持续运营动作。常见节奏可以是：

每周检查低利用率 VM，确认是否降配、关停或合并。
每月复盘 Azure Advisor、Cost Management 和预算告警。
每季度评估预留实例、Azure Savings Plan、Spot VM 的适用范围。
对 AI、批处理、渲染等弹性工作负载，优先评估自动扩缩和队列驱动架构。

需要特别注意的是，降配和关停都可能影响性能与可用性。对生产系统做优化前，应先看 P95/P99 延迟、CPU 峰值、内存压力、磁盘队列长度和业务峰值窗口，而不是只看平均利用率。

一个简单的检查命令，可以快速列出资源组内 VM 的规格和电源状态：

az vm list \
  --resource-group rg-demo-cost-dev \
  --show-details \
  --query "[].{name:name,size:hardwareProfile.vmSize,powerState:powerState,location:location}" \
  --output table

如果再结合标签筛选，就可以把“允许自动关机的 dev/test 机器”纳入定期巡检脚本。

落地清单：从能看见，到能控制

Azure IaaS 的长期成本优化，可以按这个顺序推进：

先统一标签和命名，让成本能按团队、环境和工作负载归因。
再建立预算、告警和看板，让异常增长能被及时发现。
接着处理低风险场景，例如 dev/test 自动关机、闲置磁盘清理、日志保留周期调整。
然后优化生产规格，用监控数据验证降配、预留实例和节省计划。
最后把策略写入 IaC、CI/CD 和平台规范，避免新资源继续制造浪费。

成本效率不是云迁移后的附加任务，而是 Azure IaaS 架构的一部分。越早把标签、自动化、监控和容量策略固化下来，后续扩展关键业务和 AI 工作负载时，成本曲线就越可控。