「マルチアカウント環境でリソースが増えすぎて、本番・検証・開発の区別がタグだけでは追えなくなった」
AWSを本格運用し始めると、こうした壁に当たります。EC2・RDS・VPCなどリソース数が増えるほど、タグの命名規則が崩れたときのコストは大きくなります。コスト把握が属人化し、Terraformのfilterが動かなくなり、本番と検証の取り違えが起きます。
この記事では、AWSタグの命名規則を設計する方法を、VPC設計を例にして解説します。マルチアカウント環境での具体的な命名パターン、必須タグの定義、チーム全体の運用を統一するための仕組みまでカバーします。想定環境はAWS Organizations構成・VPC設計フェーズです。
この記事のポイント
・タグキーは小文字・ハイフン区切り（env / project / team）で統一するのが業界標準
・VPCのNameタグは vpc-{env}-{project}-{連番} 形式で環境と用途を即座に識別できる設計にする
・マルチアカウント環境では account-alias・ou-path を必須タグとして設計段階から定義する
・SCPとIAMポリシー条件キーを組み合わせて、タグなしリソースの作成を強制ブロックできる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜAWSのタグ命名規則が重要なのか
AWSのタグは、EC2・RDS・VPCなどあらゆるリソースに付与できるメタデータです。キー（Key）と値（Value）のペアで管理し、1リソースに最大50件まで設定できます。タグが「ないと困る理由」を3つ挙げます。
コスト配分が見えなくなる
AWSのCost Explorerはタグキーをコスト配分のディメンションとして使えます。
project:webタグが付いていないリソースはどのプロジェクトのコストか区別できず、月次の請求書レビューが担当者の記憶頼りになります。環境の取り違えが起きる
本番（prod）と検証（stg）のVPCが同一アカウントに存在する構成では、タグがないとオペレーターがどちらのリソースを操作しているか誤ります。特にaws CLIやTerraformでリソースIDを直接指定する作業では、タグによる目視確認が唯一の防線になります。
IaCのフィルタリングが機能しなくなる
Infrastructure as Code（IaC）では、タグをフィルタリング条件に使ってリソースを動的に特定します。Terraformのdata sourceでフィルタするとき、命名規則が「Env」「env」「environment」と揺れていると一致しません。
AWSタグの基本設計と命名規則の作り方
1. タグキーの設計方針
タグキーは小文字・ハイフン区切りで統一するのが業界標準です。大文字混在・スペースあり・全角は、スクリプト処理や他ツールとの連携でエラーの原因になります。推奨するタグキーの例です。
・env：環境（prod / stg / dev）
・project：プロジェクト識別子（web / api / data / batch）
・team：担当チーム名（infra / app / security）
・owner：責任者のIDやメールアドレス
・cost-center：コストセンターコード（CC001 / CC002）
・managed-by：管理方法（terraform / cloudformation / manual）
避けるべき例も確認しておきます。
・Env（大文字始まり）：チーム内でenvとEnvが混在する原因になる
・環境（日本語キー）：CLI・APIでエスケープが必要になり、スクリプトが複雑になる
・Environment（長いキー名）：Terraformのコードや設定ファイルで打ち間違いが増える
2. 命名規則のフォーマット
Nameタグのフォーマットは、リソース種別・環境・プロジェクト・識別子を組み合わせた形にします。基本フォーマット：
[リソース種別]-[env]-[project]-[識別子]VPC設計での具体例を示します。
# VPC vpc-prod-web-01 ... 本番・webプロジェクトの第1VPC vpc-stg-web-01 ... 検証・webプロジェクトの第1VPC # サブネット（AZとtierを末尾に付加） subnet-prod-web-pub-1a ... 本番・パブリックサブネット・ap-northeast-1a subnet-prod-web-pri-1a ... 本番・プライベートサブネット・ap-northeast-1a subnet-prod-web-pri-1c ... 本番・プライベートサブネット・ap-northeast-1c # セキュリティグループ sg-prod-web-alb ... 本番・ALB用セキュリティグループ sg-prod-web-app ... 本番・アプリサーバー用セキュリティグループ sg-prod-web-rds ... 本番・RDS用セキュリティグループ
3. 必須タグの定義
組織内で「このタグは全リソースに必ず付ける」と決める必須タグセットを定義します。最小構成は次の5つです。| タグキー | 値の例 | 用途 |
|---|---|---|
| env | prod / stg / dev | 環境識別・コスト分離 |
| project | web / api / batch | プロジェクト別コスト分析 |
| team | infra / app / security | 担当チームへのアラート送付 |
| managed-by | terraform / manual | IaC管理外リソースの把握 |
| cost-center | CC001 / CC002 | 部門別コスト按分 |
マルチアカウント環境でのVPCタグ設計
複数のAWSアカウントをOrganizationsで管理する構成では、アカウント単位を識別するタグが必要です。単一アカウントではenvタグだけで本番・検証を区別できますが、マルチアカウント構成では「どのアカウントのリソースか」が即座に分かる設計にします。1. アカウント識別タグ
マルチアカウント環境での推奨タグを示します。・account-alias：AWSアカウントエイリアス（example-prod / example-stg）
・ou-path：Organizations内のOU階層パス（/root/prod/web）
・account-type：アカウントの種別（production / staging / shared-services / security）
# aws cliでVPCにタグを付与する例（出力例） $ aws ec2 describe-vpcs --filters Name=tag:env,Values=prod --query 'Vpcs[*].{VpcId:VpcId,Name:Tags[?Key==`Name`]|[0].Value}' --output table --------------------------------------------------- | DescribeVpcs | +---------------------+---------------------------+ | Name | VpcId | +---------------------+---------------------------+ | vpc-prod-web-01 | vpc-0a1b2c3d4e5f67890 | | vpc-prod-api-01 | vpc-0f9e8d7c6b5a43210 | +---------------------+---------------------------+ # 出力例（環境により異なります）
2. 環境・用途の分類タグ（VPCレベル）
1アカウントに複数VPCを持つ構成では、VPCレベルのタグに環境とネットワーク用途を明示します。# Terraformでタグを付与する例 resource "aws_vpc" "prod_web" { cidr_block = "10.0.0.0/16" enable_dns_hostnames = true enable_dns_support = true tags = { Name = "vpc-prod-web-01" env = "prod" project = "web" team = "infra" managed-by = "terraform" cost-center = "CC001" account-alias = "example-prod" } }
3. コスト配分タグの有効化
AWS Billing & Cost ManagementでタグをActivateすると、Cost Explorerのフィルタリング軸になります。設定手順は次のとおりです。# マネジメントコンソールでの操作手順 # 1. AWSマネジメントコンソール → 右上のアカウント名 → 請求とコスト管理 # 2. 左メニュー → Cost allocation tags # 3. 「User-defined cost allocation tags」タブを開く # 4. コスト配分に使いたいタグキー（env, project, team, cost-center）を選択 # 5. 「Activate」ボタンをクリック # # 有効化後24時間程度でCost Explorerのフィルタ項目として反映されます
チームで統一するためのタグ運用ルール
タグは設計するだけでは機能しません。チームに周知し、仕組みで強制することが重要です。1. SCPでタグなし作成をブロックする
AWS Organizationsを使っている場合、SCPでタグキーが付いていないEC2やRDSの起動を拒否するポリシーを定義できます。{ "Version": "2012-10-17", "Statement": [ { "Sid": "RequireEnvTagOnEC2", "Effect": "Deny", "Action": [ "ec2:RunInstances" ], "Resource": "arn:aws:ec2:*:*:instance/*", "Condition": { "Null": { "aws:RequestTag/env": "true" } } } ] }
envタグなしでEC2インスタンスを起動しようとした操作は拒否されます（出力例: 「An error occurred (AccessDenied) when calling the RunInstances operation: ...」）。2. Terraform variable validationで命名を強制する
IaCのコードレベルで必須タグをvariableとして定義し、許可された値以外を入力するとapplyが失敗する設計にします。variable "env" { description = "デプロイ環境（prod / stg / dev のいずれか）" type = string validation { condition = contains(["prod", "stg", "dev"], var.env) error_message = "envはprod, stg, devのいずれかを指定してください。" } }
タグ設計でよくある失敗パターン
現場でよく見かける失敗を3つ挙げます。命名規則が途中で変わる
最初に「Env」としていたキーが途中で「env」「environment」に分岐する典型パターンです。既存リソースへの一括タグ変更は
aws ec2 create-tagsコマンドで対処できますが、リソース数が多いほど作業コストが増えます。設計時点でフォーマットをドキュメント化しておくことが最大の予防策です。タグを後付けにする
EC2やRDSを先に作ってタグを後で付けようとすると、漏れが発生します。Terraformでリソース作成時に必ずタグブロックを記述する運用にすることで、この問題を防げます。
値が自由記入になっている
env: 本番、env: production、env: prodが混在するとCost Explorerの集計が崩れます。variable validationやEnum的な定義リストをチームに配布し、値の選択肢を統一します。本記事のまとめ
AWSタグの命名規則設計と、マルチアカウント環境でのVPCタグ運用をまとめます。| やりたいこと | 設計パターン |
|---|---|
| タグキーの命名統一 | 小文字・ハイフン区切り（env / project / team） |
| VPCリソースの識別 | vpc-{env}-{project}-{連番} でNameタグを付与 |
| マルチアカウントの分類 | account-alias・ou-pathタグを全リソースに付与 |
| コスト配分の有効化 | Billing画面でUser-defined tagをActivate |
| タグなし作成の禁止 | SCPとIAMポリシーのaws:RequestTag条件キーを組み合わせる |
| IaCでの命名強制 | Terraform variable validationで許可値を制限する |
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
- 前のページへ：AWSリソースをタグ検索で特定するResource Groupsのマルチ構成管理術｜VPC冗長設計に活用
- この記事の属するカテゴリ：AWS(Amazon Linux)へ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます