AWS 标签设计指南：连接成本、安全和运营的最基本治理

在运营 AWS 时，EC2、S3、RDS、Lambda、EKS、CloudFront、VPC、EBS 等资源会迅速增加。最初，资源数量不多，仅凭名称即可区分，但随着账户数量的增加以及开发、测试、生产环境的分离，仅凭简单名称进行管理将变得困难。

此时，最基本的管理体系就是标签。

AWS 标签是附加到资源的键值对形式的元数据。例如，您可以为 EC2 实例附加以下标签：

Name = web-prod-ec2-01
Environment = prod
Owner = security-team
Service = homepage
CostCenter = edu-platform
ManagedBy = terraform

通过这种方式附加标签，不仅能提升可读性，还能实现成本分析、所有者追踪、自动化、安全控制、故障响应和权限控制。

1. 为什么要管理标签？

AWS 标签不仅仅是简单的标签。从运营角度来看，它们更像是资源的身份证。

如果没有标签，将出现以下问题：


问题	说明
成本追踪困难	难以了解哪些团队、服务或项目产生了费用
资源所有者不明确	发生故障时难以找到负责人
安全例外管理困难	难以区分哪些资源属于生产环境，哪些属于开发环境
自动化困难	难以仅对特定环境的资源进行备份、终止或扫描
难以识别清理对象	难以区分旧资源、测试资源或未使用资源
权限控制局限	难以设计基于标签的访问控制，即 ABAC

随着 AWS 环境的扩大，标签不再是可选项，而是基本的运营数据。

特别是以下类型的组织，标签体系是必不可少的：

使用多个 AWS 账户的组织
开发、测试、生产环境分离的组织
需要按项目计费的组织
需要应对 ISMS-P、金融安全、内部审计的组织
使用 Terraform、CloudFormation、CDK 等 IaC 工具的组织
运营基于 AWS Organizations 和 Control Tower 的多账户环境的组织

2. 标签设计的核心原则

要有效使用标签， “ 多贴标签” 不如 “ 一致地贴标签” 重要。

例如，如果每个人都以不同的方式附加标签，如下所示，就会出现问题：

env = prod
Env = production
environment = prd
Environment = Prod
ENV = PROD

人类大致可以理解，但成本报告、自动化脚本、IAM 策略和 AWS Config 规则会将其视为不同的值。

因此，标签设计中以下原则至关重要：


原则	说明
标准化	统一组织内的标签键和值
最小化	不强制使用过多标签
自动化	与 IaC 结合，避免手动输入
成本关联	预先选择要激活为成本分配标签的标签
安全关联	与 ABAC、SCP、IAM Condition、AWS Config 连接
例外管理	制定无法附加标签的资源或例外资源的处理标准

—

3. 推荐的标签键设计

AWS 标签可能因组织而异，但通常以下标签可作为基本标签推荐：


标签键	示例值	目的
Name	web-prod-ec2-01	易于人工识别的名称
Environment	dev, stg, prod	区分开发/测试/生产环境
Service	homepage, payment, lms	区分服务或业务系统
Owner	cloud-team, security-team	负责组织或负责人
CostCenter	edu-platform, corp-it	成本分摊标准
Project	ai-class, cloud-migration	项目区分
ManagedBy	terraform, cloudformation, manual	创建/管理方式区分
DataClass	public, internal, confidential	数据敏感度区分
Backup	true, false	是否为备份对象
ExpireDate	2026-12-31	临时资源到期日

如果一开始就强制使用过多的标签，运营人员将难以遵守。建议区分最基本的必填标签和可选标签。

基本必填标签可以从以下几个开始：

Environment
Service
Owner
CostCenter
ManagedBy

如果需要安全或运营自动化，可以添加以下标签：

DataClass
Backup
PatchGroup
ExpireDate
Compliance

4. 标签键名称如何确定？

标签键必须保持一致，包括大小写。

推荐的方法是选择 PascalCase 或 kebab-case 中的一种，并始终保持一致。

PascalCase 示例如下：

Environment
CostCenter
ManagedBy
DataClass
PatchGroup

kebab-case 示例如下：

environment
cost-center
managed-by
data-class
patch-group

在企业运营标准中，PascalCase 在文档和控制台可读性方面较为稳妥。

重要的是整个组织采用相同的方式，而不是使用哪种样式。

应避免的方式如下：

Env
env
ENV
environment
Environment

如果混用，Cost Explorer、Cost and Usage Report、自动化脚本、IAM 条件语句和 Tag Policy 的管理将变得复杂。

5. 环境标签尤为重要

在所有 AWS 标签中，如果只能选择一个最重要的标签，那就是 Environment。

因为根据是生产环境还是开发环境，安全标准、备份标准、监控标准和成本管理标准都会有所不同。

示例如下：

Environment = dev
Environment = stg
Environment = prod

或者，根据组织的不同，可以这样使用：

Environment = development
Environment = staging
Environment = production

这里同样重要的是不要混用。

不好的示例如下：

prod
prd
production
Production
PROD

考虑到运营自动化，标签值最好简短明确。

推荐示例如下：

dev
stg
prod

6. 用于成本管理的标签

在 AWS 成本分析中，标签非常重要。

例如，如果同一个 AWS 账户中混合了多个培训课程、项目、客户和服务，那么仅仅查看 EC2 成本是多少是不够的。

需要像这样附加标签：

Project = aws-security-class
Service = eks-lab
CostCenter = training
Owner = cloudsecuritylab

之后，在 Billing and Cost Management 中将这些标签激活为成本分配标签，就可以在 Cost Explorer 或 Cost and Usage Report 中进行基于标签的成本分析。

常用的成本分析标签如下：


标签键	目的
CostCenter	成本分摊单位
Project	按项目进行成本分析
Service	按服务进行成本分析
Environment	分离开发/运营成本
Owner	按负责团队追踪成本
Customer	按客户进行成本分析
Course	按培训课程进行成本分析

需要注意的是，将标签附加到资源后，并不会立即显示在成本报告中。用于成本分析的用户定义标签必须在 Billing 控制台中单独激活为成本分配标签。

7. 用于安全的标签

标签不仅可以用于成本，还可以用于安全控制。

例如，可以使用以下标签：

DataClass = public
DataClass = internal
DataClass = confidential

可以根据这些标签应用不同的安全策略。

对于 DataClass=confidential 的 S3 存储桶，可以应用以下安全标准：

必须阻止公共访问
必须进行 SSE-KMS 加密
启用 CloudTrail 数据事件日志记录
限制可访问的 IAM 角色
禁止与外部账户共享

另一个例子是，对于 Environment=prod 的资源，可以应用以下标准：

启用详细监控
必须备份
更改时需要批准
强制使用 IMDSv2
限制安全组入站规则
应用终止保护或删除保护

标签成为识别应用安全策略目标的基础。

8. ABAC 和基于标签的权限控制

ABAC 是 Attribute-Based Access Control 的缩写。在 AWS 中，可以使用标签作为属性来控制权限。

例如，假设用户的 IAM 角色具有以下标签：

Team = security

并且 EC2 实例也具有以下标签：

Team = security

在这种情况下，可以创建一个策略，规定“仅当用户的 Team 标签与资源的 Team 标签相同时才允许操作”。

IAM 策略示例如下：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "StartStopOwnTeamInstances",
      "Effect": "Allow",
      "Action": [
        "ec2:StartInstances",
        "ec2:StopInstances"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Team": "${aws:PrincipalTag/Team}"
        }
      }
    }
  ]
}

这种方法的优点是，随着用户或团队的增加，无需不断创建新的 IAM 策略。

但是，要使用 ABAC，标签值必须准确。如果标签标准崩溃，权限体系也可能随之动摇。

因此，ABAC 必须与 Tag Policy、SCP、IAM Condition 和 IaC 自动化一起设计。

9. AWS Organizations 标签策略

如果使用 AWS Organizations，可以通过标签策略管理整个组织的标签标准。

标签策略可以定义以下内容：

允许的标签键
标签键的大小写标准
允许的标签值
对特定资源类型应用标签策略
标签合规性报告

例如，如果只允许 Environment 标签值为 dev、stg、prod，可以创建如下策略：

{
  "tags": {
    "Environment": {
      "tag_key": {
        "@@assign": "Environment"
      },
      "tag_value": {
        "@@assign": [
          "dev",
          "stg",
          "prod"
        ]
      },
      "enforced_for": {
        "@@assign": [
          "ec2:instance"
        ]
      }
    }
  }
}

标签策略有助于在整个组织中应用标签标准，但这并不能解决所有标签问题。


注意事项	说明
不自动修改现有资源	不会自动更正已错误附加的标签
并非所有服务都强制支持	需要检查不同资源类型的支持范围
强制必填标签需单独考虑	建议与 SCP、IAM 条件、IaC 策略一起设计
需要例外管理	某些 AWS 托管资源或自动生成的资源可能需要例外

—

10. 使用 SCP 强制执行必填标签

标签策略有利于标准化，但如果需要强力阻止资源创建，可以结合使用 SCP 或 IAM 条件。

例如，以下是一个 SCP 示例，用于阻止在创建 EC2 实例时如果没有 Environment 标签：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRunInstancesWithoutEnvironmentTag",
      "Effect": "Deny",
      "Action": [
        "ec2:RunInstances"
      ],
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "Null": {
          "aws:RequestTag/Environment": "true"
        }
      }
    }
  ]
}

SCP 是一种强大的控制手段，如果直接应用于生产 OU，可能会导致故障。

推荐的实施顺序如下：

首先编写标签标准文档
在开发账户中进行测试
使用 Tag Policy 应用报告模式
清理不合规资源
从新资源开始，通过 SCP 或 IAM 条件强制执行
在生产 OU 中，结合例外流程逐步应用

11. 使用 AWS Config 检查标签合规性

使用 AWS Config 可以检查资源是否具有必填标签。

例如，使用 required-tags 托管规则可以检查特定资源是否具有所需的标签。

检查目标标签示例如下：

Environment
Owner
Service
CostCenter
ManagedBy

利用 AWS Config 可以创建以下流程：

리소스 생성
→ AWS Config 평가
→ 필수 태그 누락 확인
→ NON_COMPLIANT 표시
→ EventBridge 감지
→ Lambda 또는 Systems Manager Automation으로 알림/수정

虽然也可以连接到自动修复，但自动填充所有标签可能存在风险。

例如，如果 Owner 或 CostCenter 被错误地自动输入，可能会导致成本分配和审计结果出现偏差。因此，需要区分可以自动修复的标签和需要人工确认的标签。

12. 在 Terraform 中标准化标签

如果使用 Terraform，可以利用 Provider 的 default_tags 自动添加通用标签。

示例如下：

provider "aws" {
  region  = "us-east-1"
  profile = "my-sso"

  default_tags {
    tags = {
      Environment = "dev"
      Owner       = "cloud-team"
      Project     = "aws-lab"
      ManagedBy   = "terraform"
    }
  }
}

这样，通过 Terraform 创建的大多数资源都会自动附加通用标签。

对于单个资源，可以添加服务特定的标签。

resource "aws_instance" "web" {
  ami           = "ami-xxxxxxxxxxxxxxxxx"
  instance_type = "t3.micro"

  tags = {
    Name    = "web-dev-ec2-01"
    Service = "homepage"
  }
}

Terraform 标签设计时需要注意以下几点：


项目	说明
使用 default_tags	自动应用通用标签
资源级 tags 并用	添加 Name、Service 等单独标签
标签值变量化	按环境分离 dev、stg、prod
禁止手动更改	在控制台随意修改标签会导致漂移 (drift)
模块标准化	向所有模块传递通用标签变量

例如，环境变量可以这样管理：

variable "common_tags" {
  type = map(string)
  default = {
    Environment = "dev"
    Owner       = "cloud-team"
    CostCenter  = "training"
    ManagedBy   = "terraform"
  }
}

然后，在资源中可以这样合并：

tags = merge(
  var.common_tags,
  {
    Name    = "web-dev-ec2-01"
    Service = "homepage"
  }
)

13. 利用标签进行运营自动化的示例

如果标签设计得当，可以轻松实现运营自动化。

例如，如果想在夜间自动停止开发环境的 EC2，可以使用以下标签：

Environment = dev
AutoStop = true

之后，可以通过 Lambda 或 Systems Manager Automation 查找并停止具有该标签的实例。

CLI 示例如下：

aws ec2 describe-instances 
  --filters 
    "Name=tag:Environment,Values=dev" 
    "Name=tag:AutoStop,Values=true" 
    "Name=instance-state-name,Values=running" 
  --query "Reservations[].Instances[].InstanceId" 
  --output text

备份对象也可以通过标签进行区分：

Backup = true
BackupPlan = daily

补丁组也可以通过标签进行区分：

PatchGroup = linux-prod
PatchWindow = sunday-02

通过这种方式，标签充当了运营自动化的条件语句。

14. 为什么 EC2 尤其需要良好管理标签

EC2 是 AWS 中使用最广泛的资源之一，并且相关资源也会随之创建。

创建一个 EC2 实例可能会牵涉到以下资源：

EC2 Instance
EBS Volume
EBS Snapshot
ENI
Security Group
Elastic IP
Auto Scaling Group
Launch Template
Load Balancer Target Group
CloudWatch Alarm

问题在于，很多情况下只给 EC2 实例附加了标签，而 EBS 卷或快照却遗漏了标签。

在运营中，需要确保标签也能传播到以下资源：


资源	标签管理要点
EC2 Instance	基本标签必填
EBS Volume	需要与实例相同的 Owner、Service、Environment
Snapshot	备份成本分析需要标签
ENI	清理未使用 ENI 和追踪所有者需要
AMI	需要镜像创建目的和到期日
ASG	创建实例时需要设置标签传播

使用 Auto Scaling Group 时，需要检查标签的 PropagateAtLaunch 设置。只有当此值被激活时，ASG 创建的 EC2 实例才会传播标签。

15. 优秀标签设计示例

以下是可在实际工作中使用的基本标签标准示例：


标签键	是否必填	示例值	说明
Name	必填	web-prod-ec2-01	资源名称
Environment	必填	dev, stg, prod	环境区分
Service	必填	homepage, payment	服务名称
Owner	必填	cloud-team	负责组织
CostCenter	必填	corp-it	成本分摊
ManagedBy	必填	terraform, manual	管理方式
Project	可选	cloud-migration	项目名称
DataClass	可选	public, internal, confidential	数据等级
Backup	可选	true, false	是否备份
ExpireDate	可选	2026-12-31	到期日
Compliance	可选	pci, isms-p, none	法规/审计标准

实际标签示例如下：

Name = api-prod-ec2-01
Environment = prod
Service = payment
Owner = platform-team
CostCenter = fintech-service
ManagedBy = terraform
DataClass = confidential
Backup = true
Compliance = isms-p

16. 应避免的标签设计

使用标签时，应避免以下方式：

1) 直接填写人名的方式

Owner = ilsun

在小型组织中可能很方便，但负责人变更后管理会变得困难。

尽可能使用团队或邮件组，而不是个人。

Owner = cloud-team
Contact = cloud-team@example.com

2) 标签值包含过多含义的方式

Name = prod-web-seoul-important-do-not-delete-costcenter123

这种方式不适合自动化。

建议按标签键划分含义。

Environment = prod
Service = web
Region = ap-northeast-2
DeleteProtection = true
CostCenter = costcenter123

3) 临时资源没有到期日的方式

培训、测试、PoC 资源务必附加到期日标签。

ExpireDate = 2026-07-31

如果没有此标签，测试资源可能会保留数月，产生费用。

4) 在标签中包含敏感信息的方式

标签中不应包含密码、令牌、个人信息、客户识别信息等敏感信息。

不好的示例如下：

Password = P@ssw0rd123
Token = eyJhbGciOi...
CustomerEmail = user@example.com

标签可能会暴露在各种管理工具、成本报告、日志和 API 响应中，因此原则上不应包含敏感信息。

17. 标签运营流程

标签并非一劳永逸，需要持续管理。

推荐的运营流程如下：

1. 태그 표준 정의
2. 필수 태그와 선택 태그 분리
3. 태그 값 목록 정의
4. Terraform/CloudFormation/CDK에 반영
5. AWS Organizations Tag Policy 적용
6. AWS Config로 비준수 리소스 탐지
7. Cost Allocation Tag 활성화
8. Cost Explorer에서 비용 검증
9. 예외 리소스 승인 절차 운영
10. 월 1회 태그 품질 리뷰

如果组织规模较小，无需一开始就复杂化。

至少以下 5 个标签，只要保持一致，就能大大提高运营质量：

Environment
Service
Owner
CostCenter
ManagedBy

18. 标签检查 CLI 示例

要检查特定 EC2 实例的标签，可以使用以下命令：

aws ec2 describe-instances 
  --query "Reservations[].Instances[].{
    InstanceId:InstanceId,
    State:State.Name,
    Name:Tags[?Key=='Name']|[0].Value,
    Environment:Tags[?Key=='Environment']|[0].Value,
    Owner:Tags[?Key=='Owner']|[0].Value,
    Service:Tags[?Key=='Service']|[0].Value
  }" 
  --output table

查找没有 Environment 标签的 EC2 实例的示例如下：

aws ec2 describe-instances 
  --query "Reservations[].Instances[?!not_null(Tags[?Key=='Environment'].Value)].{
    InstanceId:InstanceId,
    State:State.Name,
    Name:Tags[?Key=='Name']|[0].Value
  }" 
  --output table

要查询具有特定标签的 EC2，可以使用过滤器，如下所示：

aws ec2 describe-instances 
  --filters "Name=tag:Environment,Values=prod" 
  --query "Reservations[].Instances[].{
    InstanceId:InstanceId,
    Name:Tags[?Key=='Name']|[0].Value,
    Service:Tags[?Key=='Service']|[0].Value
  }" 
  --output table

ASG 标签传播情况可以这样查看：

aws autoscaling describe-auto-scaling-groups 
  --query "AutoScalingGroups[].{
    ASG:AutoScalingGroupName,
    Tags:Tags[].{
      Key:Key,
      Value:Value,
      PropagateAtLaunch:PropagateAtLaunch
    }
  }" 
  --output json

19. 引入标签策略的实际步骤

标签策略如果一开始就强制执行，可能会引起反弹或导致部署失败。

实际的引入顺序如下：

第一步：调查当前标签状态

首先，检查当前资源附加了哪些标签。

Environment, env, Env, ENV가 섞여 있는지
Owner가 개인 이름인지 팀 이름인지
CostCenter가 실제 비용 조직과 연결되는지
Name만 있고 다른 태그가 없는 리소스가 많은지

第二步：编写标准标签文档

将必填标签和允许的值文档化。

Environment: dev, stg, prod
ManagedBy: terraform, cloudformation, console, system
Backup: true, false
DataClass: public, internal, confidential

第三步：从新资源开始应用

不要试图一次性修改所有现有资源，而是从新资源开始应用标准。

第四步：反映到 IaC

在 Terraform、CloudFormation、CDK 模块中添加通用标签。

第五步：应用报告

利用 AWS Config、Resource Groups Tagging API、Tag Editor 检查不合规资源。

第六步：应用强制策略

充分稳定后，通过 Tag Policy、SCP、IAM 条件强制执行。

20. 结论

AWS 标签不仅仅是一个简单的名称标签。

精心设计的标签可以实现以下功能：

按项目、团队、服务分析成本
识别资源所有者和运营责任
应用开发/运营环境特定的安全标准
自动化备份、补丁、终止
基于 AWS Config 的合规性检查
基于 IAM ABAC 的权限控制
清理未使用资源
应对审计和安全检查

反之，如果标签缺失或不一致，随着 AWS 环境的扩大，运营将变得复杂，成本分析也将变得困难。

无需一开始就建立完美的标签体系。但至少建议将以下 5 个标签作为组织标准并开始使用：

Environment
Service
Owner
CostCenter
ManagedBy

之后，可以根据需要扩展 DataClass、Backup、ExpireDate、Compliance、PatchGroup 等标签。

在 AWS 运营中，标签是成本管理的起点，也是安全治理的出发点。