概要
個人的なAWS タグ付け方針をまとめる
結論
必須なもの
| タグ名 | 概要 | 例 |
|---|---|---|
| project | プロジェクト名 | HogeHogeService |
| resource | リソース名 | stg_hoge_hoge_service_cdk |
| creator | リソースを作成した方法 | cdk |
不特定多数の人が触る環境の場合
| タグ名 | 概要 | 例 |
|---|---|---|
| owner | 管理者名 | hogehoge_team |
個人用アカウント(or開発アカウント)の場合
| タグ名 | 概要 | 例 |
|---|---|---|
| usetype | 使用種別 | temp |
各タグの説明
project
目的: プロジェクト全体のコストを把握するため
IaCをする場合, この名前=リポジトリ名にしておくと, 迷わなくて済む.
もし, プロジェクト名≠リポジトリ名の場合は, repository タグがあると無難.
resource
目的: リソース単位でコストを把握するため
これがないとコスト管理が難しくなるので必須.
creator
目的: 修正時どのように対応すればよいかを把握するため
コンソールからリソースを修正してよいか否かの判断に役立つ.
具体的には以下がつく想定
| タグの値 | 概要 |
|---|---|
| manual | 手動で作成した場合 |
| cfn | CloudFormationsテンプレートにて作成した場合 |
| sam | SAMテンプレートにて作成した場合 |
| cdk | CDKを使用して作成した場合 |
| sdk | aws cli 等なにかしらAPI経由で動的に作成した場合 |
| terraform | Terraformにて作成した場合 |
※ samはcfnに入れてもいいかも
owner
目的: 管理者を把握するため
何か問題が発生した際, 誰に聞けばよいかが分からないと辛いため.
また, コストの請求にも使用可能.
個人開発であれば, 誰が管理者か自明なため不要.
usetype
目的: 一時的な検証目的か把握するため
特に個人開発において, そのリソースを消してよいかを判断するために使用.
1年前に作成したリソースが必要なものか記憶がない場合がほとんどのため.
お仕事の場合, 開発環境にてリソースの整理をする際, 消してよいか判断のよりどころとして使用.
本番環境の場合, 使用しているサービスのみなはずのため不要.
具体的には以下がつく想定
| タグの値 | 概要 | 削除可否 |
|---|---|---|
| service | 使用しているサービス | NG |
| temp | 一時的な技術検証用 | OK |
| stresstest | 負荷テスト用 | OK |
削除可否の扱い
- 個人開発の場合: 記憶になければOK (記憶にあればそもそも削除してよいか否か分かるはず)
- お仕事の場合: 1,2週間ほど動いていなければ削除してもよさそう (実際にしてよいかは職場ルールによる)
必須にはしなかったもの一覧
AWS公式のタグ戦略 をもとに, 今回は必須にしなかったもの一覧.
いつの日かつけるかも...? 状況によりそう
- アプリケーション ID
-
projectタグでよさそう
-
- アプリケーションロール
- DynamoDB等で, このテーブルがマスターテーブルであるか否かを判断するために使用するのはありかも
- それ以上は現時点であまりイメージがわかず...
- クラスター
- 現時点であまりイメージがわかず...
- 環境
- アカウントごと分けたい派
- バージョン
- アーキテクチャレベルでバージョンを分けるイメージがわかず...
- オートメーション系
- 動的にリソースを作成/削除したことがないため今回は割愛
- 予定削除時間が分かるのであればタグに残しておくのはありかも
- その時間を超えて残っている場合削, 除してよい判断の基準となるため
- コストセンター/ビジネスユニット
- 所有者とコスト管理者が分かれていそうな場合
- それ所有者な気がする
- 顧客
- 顧客が所有者と一致しない場合はつけてもよさそう
- 所有者が作成会社の場合等
- セキュリティー系
- アクセス制限をする場合あってもいいかも
その他つけてもよさそうなタグ
- removal
- CFn スタック等を削除した場合, そのリソースが削除されるか否かを把握するために使用
- dbtype
- このDBの種別を把握するために使用 (マスターテーブルであるか否か)