タグの設計が運用を決める - AWS リソースタグ戦略の雑学と実践的な命名規則
AWS リソースタグが単なるラベルではなくコスト配分、アクセス制御、自動化の基盤である理由、タグキーの命名規則、タグの上限 50 個の使い方、タグポリシーによるガバナンスを解説します。
タグは単なるラベルではない
AWS リソースタグは、キーと値のペア (例: Environment=Production、Team=Backend) でリソースにメタデータを付与する機能です。一見すると単純なラベル付けですが、AWS のエコシステムではタグが 3 つの重要な役割を果たしています。第 1 に、コスト配分です。Cost Explorer と Cost and Usage Report (CUR) は、タグに基づいてコストを分類できます。Environment タグで Production と Development のコストを分離し、Team タグでチームごとのコストを可視化できます。コスト配分タグを有効化すると、請求書にタグ別のコスト内訳が表示されます。第 2 に、アクセス制御です。IAM ポリシーの Condition で aws:ResourceTag を使用すると、特定のタグを持つリソースだけにアクセスを許可できます。たとえば、Team=Backend タグを持つ EC2 インスタンスだけを Backend チームが操作できるポリシーを設定できます。第 3 に、自動化です。Systems Manager のリソースグループ、AWS Backup のバックアップ計画、Auto Scaling のターゲット選択など、多くの AWS サービスがタグに基づいてリソースを選択します。
タグキーの命名規則 - 最初に決めないと後で苦労する
タグキーの命名規則は、組織全体で統一しないと混乱を招きます。Environment、environment、env、Env、ENVIRONMENT はすべて異なるタグキーとして扱われます。タグキーは大文字小文字を区別するため、命名規則を統一しないと、同じ意味のタグが複数のバリエーションで存在し、コスト配分やアクセス制御が正しく機能しません。推奨される命名規則は、PascalCase (Environment、CostCenter、ProjectName) または kebab-case (environment、cost-center、project-name) のいずれかに統一することです。AWS 自身が使用するシステムタグは aws: プレフィックスが付いており (例: aws:cloudformation:stack-name)、ユーザーは aws: プレフィックスのタグを作成できません。最低限設定すべきタグは 4 つです。Environment (Production/Staging/Development)、Team または Owner (責任者)、Project または Application (プロジェクト名)、CostCenter (コスト配分先) です。この 4 つがあれば、コスト配分、責任の所在、リソースの目的が明確になります。
タグの上限 50 個の使い方
AWS リソースに付与できるタグの上限は 50 個です (aws: プレフィックスのシステムタグを除く)。50 個は多いように見えますが、組織が大きくなると意外に消費されます。コスト配分用 (Environment、Team、Project、CostCenter)、運用管理用 (ManagedBy、BackupPolicy、PatchGroup)、セキュリティ用 (DataClassification、Compliance)、自動化用 (AutoShutdown、ScheduleStart、ScheduleStop) など、用途ごとにタグが増えていきます。タグの値にも制約があります。キーは最大 128 文字、値は最大 256 文字です。値に JSON を埋め込む (例: Schedule={start:09:00,stop:18:00}) ことは技術的に可能ですが、可読性が低く、IAM ポリシーの条件式で扱いにくいため推奨されません。タグの値が空文字列であることは許可されていますが、タグの存在自体がフラグとして機能する場合 (例: DoNotDelete タグの有無でリソースの削除を制御) に使用されます。
タグポリシー - 組織全体のタグガバナンス
AWS Organizations のタグポリシーは、組織内のアカウントで使用されるタグキーと値を標準化する機能です。タグポリシーで「Environment タグの値は Production、Staging、Development のいずれかでなければならない」と定義すれば、Prod や production のような非標準の値を検出できます。タグポリシーは「検出モード」と「強制モード」の 2 つのモードで動作します。検出モードでは、非準拠のタグを検出してレポートしますが、リソースの作成はブロックしません。強制モードでは、非準拠のタグを持つリソースの作成を拒否します。ただし、強制モードは一部のリソースタイプでのみサポートされており、すべてのリソースに適用できるわけではありません。タグポリシーと併用して、AWS Config のルール required-tags を使用すると、必須タグが付与されていないリソースを自動的に検出し、修復アクション (タグの自動付与) を実行できます。タグの付け忘れは、リソースの作成直後に検出して修正するのが最も効率的です。
タグベースのコスト配分の落とし穴
タグベースのコスト配分には、知っておくべき落とし穴があります。第 1 に、すべてのリソースがタグをサポートしているわけではありません。データ転送料金、Route 53 のクエリ料金、CloudWatch のメトリクス料金など、リソースに紐づかないコストはタグで分類できません。これらの「タグ不可能なコスト」は、全体の 20〜30% に達することがあります。第 2 に、コスト配分タグは有効化した時点からしか機能しません。過去に遡ってタグベースのコスト配分を行うことはできません。組織の初期段階でコスト配分タグを有効化しておくことが重要です。第 3 に、タグの付け忘れです。開発者が手動でリソースを作成する際、タグの付与を忘れることは日常的に発生します。CloudFormation や CDK でリソースを作成する場合は、テンプレートにタグを定義すれば自動的に付与されますが、コンソールや CLI で手動作成したリソースにはタグが付きません。Service Control Policy (SCP) で、特定のタグがないリソースの作成を拒否するポリシーを設定すれば、タグの付け忘れを強制的に防止できます。タグ戦略とコスト管理を体系的に学ぶには、専門書籍 (Amazon)が参考になります。