目标
让 owner、environment、cost-center、data-classification 四个标签成为云资源的强制要求，回填存量资源，并让新资源在缺少标签时无法创建，同时保留可审计的例外流程。
步骤
- 由财务、安全和工程共同确定四个键、允许值和大小写规则，发布示例，避免
Prod与production被当成两个环境。 - 导出资源清单，按账户和服务统计标签覆盖率，按成本和暴露面排序未打标签的资源。
- 用标签编辑器或幂等脚本从账单和归属数据回填标签，把每次修改写入清单以便撤销。不要猜测负责人，无法确认时转交平台团队。
- 先以审计模式挂载策略，观察两周内“本应被拒绝”的事件，修复启动模板、自动伸缩组和第三方集成等无法直接打标签的路径。
- 在生产组织单元启用拒绝策略，并开放有期限、有审批人的例外。示例策略只拦截未带
owner的 EC2 创建：
{"Version":"2012-10-17","Statement":[{"Sid":"RequireOwnerTagOnEc2","Effect":"Deny","Action":"ec2:RunInstances","Resource":"*","Condition":{"Null":{"aws:RequestTag/owner":"true"}}}]}- 每月发布覆盖率和例外报告，到期收回例外值，并逐服务扩展策略覆盖范围。
验证
在生产账户尝试创建未打标签的实例，应返回拒绝；运行覆盖率查询，确认存量资源覆盖率超过 95%；抽查新资源的四个标签值符合分类法；例外清单中每条都有负责人和到期日。
回滚
从组织单元分离策略即可立即恢复创建权限，回填的标签可按清单删除。删除用于成本分摊的标签会丢失当月历史分组，清理前应先导出账单视图。打标签本身是增量操作，真正的风险在于按“缺少标签”而不是明确清单执行批量删除；任何清理都必须使用显式资源列表。如果标签被用于访问控制，还必须限制用户修改对应标签键，否则用户可以通过重新打标签给自己扩权。