AWS Savings Plan权限控制与成本优化实践

1. Savings Plan权限控制体系的核心价值

在云计算成本优化领域，Savings Plan作为预留容量折扣方案，每年能为企业节省数百万美元的计算资源开支。但随之而来的权限管理问题却让许多团队头疼——去年某电商平台就曾因采购权限失控，导致非技术部门误购了价值$80万的冗余EC2实例套餐，最终只能通过复杂的退款流程挽回部分损失。

权限控制体系本质上是在"成本节省灵活性"与"财务安全"之间寻找平衡点。一个设计良好的权限框架需要实现三重目标：

• 采购审批的流程可视化（谁在什么时候买了什么）
• 预算消耗的实时预警（当前支出是否超出部门配额）
• 资源使用的责任追溯（每个SP实例的实际使用者是谁）

2. AWS原生权限方案解析与局限

2.1 IAM策略的基础配置

AWS原生提供通过IAM策略控制Savings Plan操作权限的方式，典型策略示例如下：

json复制{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "savingsplans:CreateSavingsPlan",
        "savingsplans:DescribeSavingsPlans"
      ],
      "Resource": "*",
      "Condition": {
        "NumericLessThan": {
          "savingsplans:PurchaseTerm": "12"
        }
      }
    }
  ]
}

这个策略允许用户创建期限短于12个月的Savings Plan，但存在三个致命缺陷：

1. 无法限制采购金额上限
2. 不能基于业务部门进行资源隔离
3. 缺乏采购前的多级审批流程

2.2 Service Control Policies的进阶用法

在组织级账户中，SCP可以禁止成员账户直接购买Savings Plan：

json复制{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "savingsplans:*",
      "Resource": "*"
    }
  ]
}

但粗暴的全盘禁止会导致所有采购必须通过主账户完成，严重降低运营效率。我们曾为某SaaS公司实施过折中方案——允许成员账户查询和修改已有SP，但创建操作必须通过特定的采购角色完成。

3. 企业级权限控制架构设计

3.1 多维度权限矩阵设计

建议采用RBAC模型结合ABAC属性控制，关键维度包括：

3.2 技术实现关键点

1. 预算硬限制实现：

python复制def check_budget(purchase_amount):
    current_month_spend = get_cost_explorer_data()
    if current_month_spend + purchase_amount > MONTHLY_QUOTA:
        raise BudgetExceededError(
            f"Requested ${purchase_amount} would exceed ${MONTHLY_QUOTA} limit"
        )

2. 审批工作流集成：
   使用EventBridge捕获SavingsPlan API调用事件，触发包含以下步骤的审批流程：

• 自动检查采购参数合规性
• 根据金额路由到对应审批人Slack频道
• 将审批结果写入DynamoDB审计表

4. 混合云场景的特殊处理

对于同时使用AWS和其他云服务商的企业，建议采用以下架构：

code复制[统一采购平台]
    ├── [AWS采购模块] 
    │   └── 集成Organizations API获取账户树
    ├── [财务中台]
    │   └── 实时同步各云厂商的SP使用数据
    └── [合规引擎]
        └── 检查跨云采购的预算分配比例

实际案例：某游戏公司通过该方案实现了：

• 统一查看AWS/Azure/Google Cloud的SP利用率
• 自动平衡各云平台的预留容量分配
• 防止单个云平台采购占比超过预设阈值（如AWS≤60%）

5. 持续优化与异常监控

5.1 使用率告警配置

创建CloudWatch Alarm监控Savings Plan覆盖率指标：

bash复制aws cloudwatch put-metric-alarm \
    --alarm-name "SP-Coverage-Drop" \
    --metric-name "SavingsPlanCoveragePercentage" \
    --namespace "AWS/SavingsPlan" \
    --statistic Average \
    --period 86400 \
    --evaluation-periods 2 \
    --threshold 70 \
    --comparison-operator LessThanThreshold

5.2 自动化回收机制

对于利用率持续低于50%的SP，建议部署以下回收流程：

1. 通过AWS Compute Optimizer识别低效SP
2. 自动生成修改建议（如调整实例族或区域）
3. 触发重新分配审批流程
4. 使用ModifySavingsPlan API实施变更

关键经验：在测试环境先部署SavingsPlanUtilization监控看板，观察1-2个完整计费周期后再实施严格管控，避免因业务波动导致误判。