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 Tag Policy

AWS Organizationsを使用している場合、Tag Policyを通じて組織全体のタグ標準を管理できます。

Tag Policyでは、次のようなことを定義できます。

許可されるタグキー
タグキーの大文字と小文字の標準
許可されるタグ値
特定のリソースタイプへのタグポリシー適用
タグ準拠状況のレポート

例えば、Environmentタグの値としてdev、stg、prodのみを許可する場合、次のようなポリシーを作成できます。

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

Tag Policyは組織全体にタグ標準を適用するのに役立ちますが、これだけで全てのタグ問題が解決するわけではありません。


注意事項	説明
既存リソースの自動修正ではない	既に誤って付与されたタグを自動的に修正することはない
すべてのサービスが強制サポートではない	リソースタイプごとのサポート範囲を確認する必要がある
必須タグの強制は別途検討が必要	SCP、IAM条件、IaCポリシーと合わせて設計することをお勧めする
例外管理が必要	一部のAWS管理対象リソースや自動生成リソースは例外が必要となる場合がある

—

10. SCPで必須タグを強制する

タグポリシーは標準化には良いですが、リソース作成自体を強く制限するには、SCPやIAM条件を併用できます。

例えば、EC2インスタンスを作成する際にEnvironmentタグがないと作成できないようにするSCPの例は次のとおりです。

{
  "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. タグポリシーを導入する際の現実的な手順

タグポリシーは、最初から強制すると反発が生じたり、デプロイが失敗したりする可能性があります。

現実的な導入手順は次のとおりです。

1段階: 現在のタグ状態の調査

まず、現在のリソースにどのようなタグが付与されているかを確認します。

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

2段階: 標準タグドキュメントの作成

必須タグと許可される値を文書化します。

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

3段階: 新規リソースから適用

既存のリソースを一度にすべて修正しようとせず、新規リソースから標準を適用します。

4段階: IaCへの反映

Terraform、CloudFormation、CDKモジュールに共通タグを組み込みます。

5段階: レポートの適用

AWS Config、Resource Groups Tagging API、Tag Editorを利用して、非準拠リソースを確認します。

6段階: 強制ポリシーの適用

十分に安定したら、Tag Policy、SCP、IAM条件を通じて強制します。

20. 結論

AWSタグは単なる名札ではありません。

適切に設計されたタグは、次を可能にします。

コストをプロジェクト、チーム、サービス別に分析
リソースの所有者と運用責任を識別
開発/運用環境別のセキュリティ基準を適用
バックアップ、パッチ、終了の自動化
AWS Configベースの準拠チェック
IAM ABACベースの権限制御
未使用リソースの整理
監査とセキュリティチェックへの対応

逆に、タグがないか一貫性がない場合、AWS環境が大きくなるにつれて運用が複雑になり、コスト分析が困難になります。

最初から完璧なタグ体系を作成する必要はありません。しかし、少なくとも次の5つのタグは組織標準として定め、始めることをお勧めします。

Environment
Service
Owner
CostCenter
ManagedBy

そして、その後必要に応じてDataClass、Backup、ExpireDate、Compliance、PatchGroupなどのタグを拡張できます。

AWS運用において、タグはコスト管理の始まりであり、セキュリティガバナンスの出発点です。