検証用のリソースが増えてくると、請求を見ても「どれが何の費用か」が分からなくなります。タグを付ければよいとは聞きますが、キーを何個、どう揃えるかの軸が無いまま付けると、後から直せません。この記事は、付ける前に決めておくことを順に説明します。
この記事の結論
- タグはキーと値の組で、リソースに意味を付ける札です。1つのリソースに同じキーは重複して付けられません。
- 先に決めるのは「何を問いたいか」です。誰の費用か・どの環境か・何のためか、を答えられるキーを少数に絞ります。
- キーと値は大文字小文字を区別します。表記揺れは集計が割れる原因なので、命名規則を先に決めます。
- 費用の集計に使うには、コスト配分タグとして有効化します。反映には最大 24 時間かかります。
- 機密情報や個人情報はタグに入れません。付け漏れは、作った後に探す仕組みと、作るときに揃える仕組みの両方で防ぎます。
タグとは何か｜キーと値の「札」で、リソースに意味を付ける
タグは、AWS のリソースに付けるキーと値の組です。たとえばキーが env、値が dev なら、「このリソースは開発環境のもの」という札になります。リソース自体の動きは変わりません。変わるのは、後から探す・分ける・数えるときの手がかりが増えることです。
タグの使い道は大きく3つあります。
| 使い道 | 例 |
|---|---|
| 探す | 検証用のリソースだけを一覧にする |
| 分ける | 担当ごと・用途ごとに費用を分けて見る |
| 止める | 付いている札を条件に、権限や自動処理の対象を決める |
AWS の公式ドキュメントは、タグの付け方を「用途別」「所有者別」「環境別」などの戦略に分けて紹介しています。この記事では、そのうち学習の段階で最も効く「環境・担当・用途」を選びます。
THREE TAGS札の3層
1つのリソースに環境・担当・用途の札が重なる
決める札
- リソース本体
- 用途の札 purpose
- 担当の札 owner
- 環境の札 env
AWS が持つ
- リソース本体
- 用途の札 purpose
- 担当の札 owner
- 環境の札 env
自分で決めるリソースそのもの
CHECK 1ここまでの確認
同じ意味のタグの値を「Prod」と「prod」で混在させると、費用の集計はどうなる?
答えと解説
答え: 2. 別々の値として扱われ、集計が割れる
タグのキーと値は大文字小文字を区別します。表記揺れは集計が割れる原因です。「なぜ先に設計するのか」を読み直してください。
なぜ先に設計するのか｜付けた後の表記揺れが一番直しにくい
タグは、付けるのは簡単です。難しいのは、揃っていない札を後から直すことです。
公式のベストプラクティスには、タグのキーと値が大文字小文字を区別するとあります。つまり Env=Prod と env=prod は、別のタグです。人が手で付けていると、次のような揺れが自然に起きます。
Envとenvとenvironmentが混在する- 値が
prodとProdとproductionに割れる - 担当が個人名のときと、チーム名のときがある
こうなると、費用をタグで分けたとき、同じ環境の費用が複数の行に割れて出ます。すでに付いた数十のリソースを直すのは、新しく付けるより手間がかかります。だから付ける前に、約束を決めます。
決める順番はこうです。
- 何を問いたいかを言葉にする（例: 「検証の費用は誰のものか」）
- その問いに答えるのに必要なキーだけを選ぶ
- キーの名前と、値の取りうる範囲を決める
- 決めた約束を1か所に書いておく
先に決めるのはキーの数ではなく、問いです。問いが決まれば、必要なキーは自然に少なくなります。
CHECK 2ここまでの確認
リソースにタグを付けただけで、請求の分類にそのタグを使えるか?
答えと解説
答え: 2. 使えない。コスト配分タグとして有効化する必要がある
費用の集計に使うタグは、コスト配分タグとしての有効化が要ります。有効化してから反映されるまで最大 24 時間かかります。「費用で使うにはどうするか」を読み直してください。
最初に決める3つのキー｜環境・担当・用途で何が分かるか
学習の段階でまず決めるなら、次の3つが扱いやすい組み合わせです。
| キーの例 | 答える問い | 値の例 |
|---|---|---|
env |
どの環境のものか | dev / test / prod |
owner |
誰（どのチーム）のものか | チーム名や担当の呼び名 |
purpose |
何のために置いたか | study-vpc / batch など |
3つあれば、請求を見たときに「開発環境の、あるチームの、何用の費用」と読めます。逆に、env だけでは誰に確認すればよいか分からず、owner だけでは本番か検証か分かりません。
キーを増やしたくなったら、まず「そのキーで答える問いは何か」を考えます。答える問いが無いキーは、付ける手間と表記揺れのリスクだけを増やします。公式の上限（1リソースあたりユーザー作成のタグは50個）に近づく前に、運用が追いつかなくなります。
TAG TO BUDGET費用で見るまで
タグは決める→付ける→有効化→見る→見張るの順に使う
-
決める
キーと表記の約束
-
付ける
作るときに同じ札を
-
有効化
コスト配分タグに
-
見る
Cost Explorer で分析
-
見張る
Budgets で通知
命名規則はどう決めるか｜小文字・ハイフン・接頭辞と、大文字小文字の区別
3つのキーが決まったら、書き方の約束を決めます。AWS の公式ドキュメントが挙げる考え方を、学習の場に合わせて整理すると次のとおりです。
- 大文字小文字を決める。 区別されるので、全部小文字に寄せるのが分かりやすい約束です。
- 区切りを決める。 単語をつなぐならハイフンかアンダースコアのどちらかに揃えます。
- 接頭辞を検討する。 組織や用途の接頭辞を付けると、AWS が自動で付ける札や他のチームの札と区別できます。
- 値の候補を決める。 自由入力にせず、
dev/test/prodのように選べる範囲にします。
そして、タグに入れてはいけないものも決めておきます。公式ドキュメントは、タグに機密情報や個人を特定できる情報を入れないよう求めています。タグは請求の画面やレポートなど、多くの場所に出るためです。認証情報、個人情報、社外秘の内容は入れず、環境名や用途のような運用上の分類だけにします。
CHECK 3ここまでの確認
タグの値に入れてよいものはどれ?
答えと解説
答え: 2. 環境名や用途のような、運用上の分類
タグは請求書や多くの画面から見える札なので、機密情報や個人情報は入れません。環境名や用途のような分類だけを入れます。「命名規則はどう決めるか」を読み直してください。
費用で使うにはどうするか｜コスト配分タグの有効化と Cost Explorer・Budgets での絞り込み
ここが、「付けたのに費用に出ない」という詰まりの原因になりやすい場所です。タグを付けただけでは、費用の分類には使えません。 費用の集計に使うタグは、コスト配分タグとして有効化します。有効化してから請求の情報に反映されるまで、公式ドキュメントによれば最大 24 時間かかります。
有効化したあとの使い方は、2つのサービスで役割が違います。
| サービス | 向いていること | タグでの使い方 |
|---|---|---|
| AWS Cost Explorer | 過去のコストと使用状況を可視化・分析する | タグの値でグループ分けして、費用の内訳を見る |
| AWS Budgets | 決めたしきい値に近づいたら知らせる | 特定のタグが付いたリソースの費用を予算の対象にする |
分析は Cost Explorer、通知は Budgets、と覚えると使い分けに迷いません。たとえば、env=test の費用を Cost Explorer で眺めて、増えていたら Budgets でその範囲の予算を決めて見張る、という流れです。
ここで、同じ論点を練習問題で見ると、次のように整理できます。
- 部署やチームごとに費用を分けて集計したい場合は、タグを付けてコスト配分タグとして有効化し、Cost Explorer でタグ別に集計する
- 予算の何割に達したら通知したい場合は、Budgets のしきい値を使う
どちらも「タグで分ける」と「Budgets で知らせる」の組み合わせで、役割は重なりません。
TWO NETS付け漏れの網
付け漏れは作る前と作った後の2つの網で防ぐ
タグの約束
- 前テンプレートに札を書く 札なしを防ぐ新しいリソース
- 前タグポリシーで表記を揃える 揺れを防ぐ新しいリソース
- 後検索で付け漏れを探す 一覧で見つける既存のリソース
- 後Config で継続して評価 違反を検知既存のリソース
付け漏れをどう防ぐか｜後から探す方法と、作るときに揃える方法
約束を決めても、人が手で付ける限り付け漏れは起きます。公式のベストプラクティスは、ガバナンスを「作った後」と「作る前」の2つに分けて考えています。
作った後に探す網
- タグ付けされていないリソースを検索して一覧にする（Tag Editor）
- 必須のタグが付いているかを継続して評価する（AWS Config のルール）
作る前に揃える網
- 作成に使うテンプレート（IaC）にタグを書いておき、毎回同じ札が付くようにする
- 組織でタグのキーや値の表記を強制するタグポリシーを使う
学習の段階では、まず「テンプレートに書く」が一番手軽です。人が思い出すのに頼らず、作るたびに同じ札が付きます。タグポリシーの詳しい設計は、組織で複数のアカウントを運用する段階の話なので、ここでは名前を知っておくだけで十分です。
最後に、全体の約束を1枚にまとめます。
タグでやってはいけない3つ
- 問いを決めずに、思いつくままキーを増やす
- 表記のルールを決めず、人が自由に書く
- 機密情報や個人情報を値に入れる
Cloudory 執筆者（AWS 認定 全冠）
タグは、付ける作業よりも「決める作業」のほうが大事です。まず環境・担当・用途の3つだけ決めて、費用を見るところまで一度通してみてください。足りない問いが出てきたら、そのときにキーを足せば十分です。
次は、費用を下げる設計の考え方に進みます。
READ ALSO — プロフェッショナル向け・段4 設計
AWS のコスト最適化の設計｜見える化・構成・契約・予算の判断軸
参照ソース
- AWS Billing: コスト配分タグの整理 — コスト配分タグの有効化が要ること、反映まで最大 24 時間、機密情報を入れないことの根拠
- Tag Editor: ベストプラクティスと戦略 — 大文字小文字の区別、命名規則、用途別の戦略、作る前と作った後のガバナンス、タグポリシーの根拠
