标签设计决定运维 - AWS 资源标签策略的冷知识与实践命名规则
解析 AWS 资源标签不仅是简单标记，更是成本分配、访问控制、自动化基础的原因，以及标签键命名规则、50 个上限的使用方法、标签策略的治理。
标签不仅仅是标记
AWS 资源标签是以键值对（例：Environment=Production、Team=Backend）为资源附加元数据的功能。乍看是简单的标记，但在 AWS 生态系统中标签发挥三个重要作用。第一，成本分配。Cost Explorer 和 Cost and Usage Report（CUR）基于标签按团队、项目、环境分类成本。没有标签就无法回答「这个月后端团队花了多少钱」这样的问题。第二，访问控制。IAM 策略的条件键可以引用标签值，实现「只能操作 Environment=Development 的资源」这样基于标签的权限控制。第三，自动化。Systems Manager 的 Patch Manager 基于 PatchGroup 标签选择补丁对象，Backup 基于标签自动设定备份策略。
标签键命名规则 - 不先决定后面会很痛苦
标签键的命名规则如果不在组织全体统一就会造成混乱。Environment、environment、env、Env、ENVIRONMENT 都被视为不同的标签键。标签键区分大小写，如果不统一命名规则，同一含义的标签会以多种变体存在，成本分配和访问控制无法正确运作。推荐的命名规则是 PascalCase（Environment、CostCenter、DataClassification）。AWS 自身的系统标签（aws:cloudformation:stack-name 等）使用小写加冒号分隔，但用户标签使用 PascalCase 可以明确区分。标签值也需要统一格式。Environment 的值是 Production 还是 production 还是 prod？事先决定并文档化很重要。
50 个标签上限的使用方法
AWS 资源可附加的标签上限是 50 个（不含 aws: 前缀的系统标签）。50 个看似很多，但组织变大后意外地会被消耗。成本分配用（Environment、Team、Project、CostCenter）、运维管理用（ManagedBy、BackupPolicy、PatchGroup）、安全用（DataClassification、Compliance）、生命周期管理用（CreatedDate、ExpiryDate、AutoShutdown）等，按用途分类后 15 至 20 个很快就用完了。剩余的 30 个留给应用特有的元数据和未来扩展。建议将标签分为「必须标签」（所有资源必须附加）和「推荐标签」（根据资源类型附加），分层管理。
标签策略 - 组织全体的标签治理
AWS Organizations 的标签策略是标准化组织内账户使用的标签键和值的功能。在标签策略中定义「Environment 标签的值必须是 Production、Staging、Development 之一」，就能检测 Prod 或 production 等非标准值。标签策略有「检测模式」和「强制模式」两种。检测模式报告违规但不阻止资源创建，强制模式在标签不符合策略时阻止资源创建。建议先以检测模式开始把握现状，修正后切换到强制模式。
基于标签的成本分配的陷阱
基于标签的成本分配有需要了解的陷阱。第一，并非所有资源都支持标签。数据传输费用、Route 53 查询费用、CloudWatch 指标费用等不绑定资源的成本无法用标签分类。这些「无法标记的成本」可能占总体的 20% 至 30%。第二，成本分配标签从启用时点开始生效，不追溯过去。如果忘记启用标签，过去数月的成本数据将无法按标签分类。第三，共享资源（NAT Gateway、Transit Gateway 等多团队共用的资源）的成本分配需要另外的分摊逻辑。仅靠标签无法自动按使用比例分配共享资源的成本。要深入了解 AWS 资源管理和成本优化，相关书籍 (Amazon) 也可作为参考。