どーも！shihopowerです！今日はAWSのタグについて調べてみました。
タグって聞くと「複数のリソースを分類するもの」というイメージがありますよね。でも、いざ使おうとすると「どのリソースに付ければいいの？」「どんな場面で効いてくるの？」という疑問が湧いてきます。
そこで今回は、AWS公式ドキュメントを主な参照先として、タグの基本から具体的なタグキー・値の例まで徹底的に調べてみました！
📋 TL;DR（この記事でわかること）
- タグの基本構造（キーと値のしくみ）
- タグが使えるAWSサービスのカテゴリ
- タグがないと何が困るのか
- タグが活きる4つのユースケース
- 公式準拠の具体的なタグキー・値の一覧
目次
- AWSタグとは？基本のキーと値のしくみ
- タグが使えるAWSサービス一覧（カテゴリ別）
- なぜタグが必要なのか？タグがないと何が困る？
- タグが活きる4つのユースケース
- 実際のタグキー・値はどう書く？公式の具体例まとめ
- まとめ：タグ付け戦略は早めに設計しよう
1. AWSタグとは？基本のキーと値のしくみ
AWSタグとは、AWSリソースに付与できるメタデータのラベルです。タグは「キー（Key）」と「値（Value）」のペアで構成されており、どちらもユーザーが自由に定義できます。
キー（Key） : 値（Value）
Environment : Production
CostCenter : 123-456
Owner : TeamA
公式ドキュメントには次のような説明があります。
タグは、AWSリソースを整理するためのメタデータとして機能するキーと値のペアです。タグはリソースの管理、識別、整理、検索、フィルタリングに役立ち、目的、所有者、環境などの基準別にリソースを分類できます。
（出典：Tag Editor ユーザーガイド）
タグの基本ルール
| 項目 | 内容 |
|---|---|
| 1リソースあたりの最大タグ数 | 50個（ユーザー作成タグ） |
| タグキーの最大文字数 | 128文字（UTF-8） |
| タグ値の最大文字数 | 256文字（UTF-8） |
| 大文字・小文字の区別 |
あり（CostCenter と costcenter は別タグ） |
| 機密情報の格納 | ❌ 禁止（PII等の個人情報は入れない） |
aws: で始まるタグはAWSが予約済みです。ユーザーは編集・削除できません。
（例：aws:cloudformation:stack-name、aws:ec2spot:fleet-request-id）
2. タグが使えるAWSサービス一覧（カテゴリ別）
公式ドキュメントによると、AWSはコストが発生するすべてのコアインフラリソースでタグ付けをサポートしており、その他の多くのリソースもタグ付けに対応しています。
Resource Groups Tagging APIに対応している代表的なサービスをカテゴリ別に紹介します。
🖥️ コンピューティング系
Amazon EC2 / AWS Lambda / Amazon ECS / Amazon EKS / AWS Elastic Beanstalk / Amazon Lightsail
🗄️ ストレージ系
Amazon S3 / Amazon EBS / Amazon EFS / Amazon FSx / Amazon Glacier
🔢 データベース系
Amazon RDS / Amazon Aurora / Amazon DynamoDB / Amazon Redshift / Amazon ElastiCache / Amazon Neptune
🌐 ネットワーク系
Elastic Load Balancing / Amazon Route 53 / AWS Direct Connect / AWS Global Accelerator
🔐 セキュリティ系
AWS IAM / AWS KMS / AWS Certificate Manager / AWS Secrets Manager / Amazon GuardDuty / AWS Security Hub
🛠️ 開発ツール系
AWS CodeBuild / AWS CodePipeline / AWS CodeCommit / AWS CodeDeploy / AWS CloudFormation
🤖 AI / ML系
Amazon Bedrock / Amazon SageMaker AI / Amazon Rekognition / Amazon Comprehend
📊 分析系
Amazon Athena / Amazon EMR / AWS Glue / Amazon Kinesis
リストにないサービスでも、そのサービス固有のネイティブなタグ付け操作でタグ付けできる場合があります。
（出典：Resource Groups Tagging API リファレンス）
3. なぜタグが必要なのか？タグがないと何が困る？
公式ドキュメントのベストプラクティスには、こんな説明があります。
AWSの使用量が複数のアプリケーションにまたがる多くのリソースタイプに増加するにつれて、どのリソースがどのアプリケーションに割り当てられているかを追跡するメカニズムが必要になります。このメカニズムで、コスト監視、インシデント管理、パッチ適用、バックアップ、アクセス制御などの運用アクティビティをサポートしてください。
（出典：AWSリソースのタグ付けのベストプラクティス ホワイトペーパー）
つまり、リソースが増えるにつれてタグなしでは管理が破綻します。具体的にタグがないと困る場面を整理するとこうなります。
| タグがない場合の困りごと | タグがある場合 |
|---|---|
| 誰のリソースかわからない |
Owner タグで所有者が一目瞭然 |
| どの請求がどのチームか不明 |
CostCenter タグでチーム別コストを可視化 |
| 本番・開発が混在して事故が起きる |
Environment タグで環境を明確に区別 |
| 特定のリソースを検索するのが大変 | タグフィルターで瞬時に絞り込み可能 |
| パッチ適用・バックアップの対象が不明確 | タグで対象リソースを自動選別 |
一貫したタグ付け戦略を導入すれば、リソースのフィルタリングと検索、コストと使用状況の監視、AWSインフラストラクチャの大規模な管理が容易になります。
（出典：AWSリソースのタグ付けのベストプラクティス ホワイトペーパー）
4. タグが活きる4つのユースケース
① コスト管理・財務の可視化
こんな場面で使う： 複数チーム・プロジェクト・部署でAWSアカウントを共用しているとき
公式ドキュメントでは次のように説明されています。
コスト配分レポートには各請求期間のすべてのAWSコストが含まれます。タグ付きとタグなしのどちらのリソースもこのレポートに出力されるため、リソース別の請求額を明確に分類できます。例えば、リソースにアプリケーション名のタグを付けると、1つのアプリケーションが実行されているすべてのリソースのコスト総額がわかります。
（出典：AWS Billing and Cost Management ユーザーガイド）
CostCenter、Project、BusinessUnit などのタグをリソースに付けることで、誰がいくら使っているかを月次コストレポートで把握できます。
② 運用の自動化
こんな場面で使う： リソースが大量にあり、手動管理が限界に近いとき
自動化タグは、自動タスクのオプトインまたはオプトアウト、またはアーカイブ、更新、削除の対象となるリソースのバージョンの特定に使用します。たとえば、
startまたはstopスクリプトを実行して業務時間外に開発環境をオフにすれば、コストが削減できます。
（出典：Tag Editor ユーザーガイド）
Environment=Dev のタグが付いたEC2インスタンスだけを夜間に自動停止するスクリプトを組めば、開発環境の無駄なコストを削減できます。
③ アクセス制御（セキュリティ）
こんな場面で使う： チームごとに触れるリソースを制限したいとき
タグ付けをサポートしているAWSリソース（IAMリソースを含む）へのアクセスを制御するには、タグを使用します。IAMユーザーとロールにタグ付けして、アクセスできるユーザーやロールを制御することができます。
（出典：IAM ユーザーガイド）
例えば、IAMポリシーの条件として aws:ResourceTag/Owner を使えば、自分が所有者として登録されているEC2インスタンスだけを起動・停止できるよう制限できます。
④ リソースの検索・整理
こんな場面で使う： アプリケーションを構成するリソースが複数サービスにまたがっているとき
多くのAWSサービスはタグ付けをサポートしているため、異なるサービスのリソースに同じタグを割り当てて、リソースが関連していることを示すことができます。
（出典：AWSリソースのタグ付けのベストプラクティス）
App=MyWebApp というタグをEC2・RDS・S3・Lambdaすべてに付けることで、Tag Editorを使ってアプリを構成するリソース全体を横断的に一覧・管理できます。
5. 実際のタグキー・値はどう書く？公式の具体例まとめ
命名規則の推奨形式
公式ドキュメントでは、次の命名規則を推奨しています。
組織名プレフィックス:カテゴリ:キー名
| 規則 | 内容 |
|---|---|
| 文字種 | すべて小文字 |
| 区切り文字 | 単語間はハイフン（-） |
| プレフィックス | 組織名 + コロン（:）で始める |
例（anycompanyという組織の場合）
anycompany:cost-center → コストセンターのコードを識別
anycompany:environment-type → 開発・テスト・本番の環境を識別
anycompany:application-id → リソースが属するアプリを識別
プレフィックスを使うことで、タグが組織固有のものとして明確に認識でき、AWSやサードパーティーのツールとの混在を避けられます。
（出典：Tag Editor ユーザーガイド）
① コスト配分タグの具体例
（出典：AWSリソースのタグ付けのベストプラクティス ホワイトペーパー）
| タグキー | 値の例 | 用途 | 必須 |
|---|---|---|---|
example-inc:cost-allocation:ApplicationId |
DataLakeX, RetailSiteX
|
アプリ別コスト追跡 | ✅ |
example-inc:cost-allocation:BusinessUnitId |
Architecture, DevOps, Finance
|
部門別コスト監視 | ✅ |
example-inc:cost-allocation:CostCenter |
123-456, 123-789
|
コストセンター別管理 | ✅ |
example-inc:cost-allocation:Owner |
Marketing, RetailSupport
|
予算責任者の特定 | ✅ |
② 自動化タグの具体例
（出典：AWSリソースのタグ付けのベストプラクティス ホワイトペーパー）
| タグキー | 値の例 | 対象リソース | 用途 |
|---|---|---|---|
example-inc:automation:EnvironmentId |
Prod, Dev, Test, Sandbox
|
EC2, RDS, EBS | 環境別スケジューリング |
Stack（EC2公式ガイドの例） |
production, staging
|
EC2 | スタックレベルの識別 |
example-inc:disaster-recovery:rpo |
6h, 24h
|
S3, EBS | 目標復旧時点（RPO）の定義 |
③ アクセス制御タグの具体例
（出典：AWSリソースのタグ付けのベストプラクティス ホワイトペーパー / IAM ユーザーガイド）
| タグキー | 値の例 | 用途 |
|---|---|---|
example-inc:access-control:LayerId |
DB_Layer, Web_Layer, App_Layer
|
レイヤー別アクセス制御 |
Owner |
${aws:username}（IAMユーザー名と一致） |
自分のリソースのみ操作可能に |
④ データ分類・コンプライアンスタグの具体例
（出典：AWSリソースのタグ付けのベストプラクティス ホワイトペーパー）
| タグキー | 値の例 | 対象リソース | 用途 |
|---|---|---|---|
example-inc:data:classification |
Public, Private, Confidential, Restricted
|
S3, EBS | データ分類・ガバナンス |
example-inc:compliance:framework |
PCI-DSS, HIPAA
|
全リソース（本番環境） | 適用コンプライアンスの明示 |
⑤ AWS自動生成タグの例
CloudFormationでリソースを作成すると、以下のタグが自動的に付与されます。（出典：AWSリソースのタグ付けのベストプラクティス）
| タグキー | 内容 |
|---|---|
aws:cloudformation:stack-name |
リソースを作成したスタック名 |
aws:cloudformation:stack-id |
スタックID |
aws:cloudformation:logical-id |
テンプレート内の論理ID |
CLIコマンドでのタグ付け例
（出典：Amazon EC2 ユーザーガイド）
# リソース作成時にタグを付ける
aws ec2 run-instances \
--image-id ami-xxxxxxxx \
--tag-specifications 'ResourceType=instance,Tags=[{Key=Environment,Value=Production},{Key=Owner,Value=TeamA}]'
# 既存リソースにタグを追加する
aws ec2 create-tags \
--resources i-1234567890abcdef0 \
--tags Key=Stack,Value=production
# 複数リソースに一括でタグを追加する
aws ec2 create-tags \
--resources ami-0abcdef1234567890 i-1234567890abcdef0 \
--tags Key=webserver,Value= Key=stack,Value=Production
6. まとめ：タグ付け戦略は早めに設計しよう
この記事で調べた内容を整理すると、こうなります。
| ユースケース | 代表的なタグキー | 効果 |
|---|---|---|
| コスト管理 |
CostCenter, Project, BusinessUnit
|
部門・プロジェクト別の支出を可視化 |
| 運用自動化 |
Environment, Stack, AutoStop
|
パッチ適用・夜間停止などを自動化 |
| アクセス制御 |
Owner, LayerId, DataClass
|
IAMポリシーと連携してアクセスを制限 |
| 検索・整理 |
App, Version, Team
|
複数サービスのリソースを横断管理 |
タグ付けは後から導入しようとすると既存リソースへの対応が大変です。公式ドキュメントのベストプラクティスでも次のように述べられています。
運用における多くのプラクティスと同様に、タグ付け戦略の実装は反復と改善のプロセスです。当面の優先事項から小さく始めて、必要に応じてタグ付けスキーマを拡張します。
（出典：AWSリソースのタグ付けのベストプラクティス ホワイトペーパー）
まずは Name・Environment・CostCenter の3タグから始めてみましょう！ 小さく始めて、組織のニーズに合わせて育てていくのが、公式が推奨するアプローチです。