【AWS】リソースタグ名について整理してみた

いつも記事を読んでいただきありがとうございます！
モブエンジニア（[@mob-engineer](https://qiita.com/mob_engineer))です！

今回取り上げるテーマとして**より良いAWSリソースタグ名戦略**について、私の頭の整理を含めて記事として言語化してみました！

需要があるか分からないですが、最後まで読んでいただけますと幸いです。

:::note info
本記事を執筆するにあたり、AWSから公開されている**AWS リソースのタグ付けのベストプラクティス**を参考にいたしました。また、筆者の理解不足で認識相違などがありましたら、コメントいただけますと幸いです。

https://docs.aws.amazon.com/ja_jp/whitepapers/latest/tagging-best-practices/tagging-best-practices.html

:::

# 目次
1. 本記事を読んでもらいたい読者層
1. （前置き）リソースタグ付けをしないとどうなるのか？
1. リソースタグのベストプラクティスとは？
1. 結局どういったリソースタグ名をつければいいのか？

## 本記事を読んでもらいたい方
次のような悩みを抱えている読者の方に読んでもらえれば幸いです。

1. AWSタグ付けの勘所・ベストプラクティスに関してヒントを探している方
1. リソースタグ名に対してあまり重要度を考えていない方
1. AWSサービスに関してキャッチアップ活動を行っている方

そのうえで、本記事を執筆するにあたり、**初学者でもわかるようにできる限り平易な表現**で執筆していきたいと思います。

## （前置き）リソースタグ付けをしないとどうなるのか？
そもそもの話、AWSリソースには**リソース名**ないし**リソースID**といった、**リソースを識別する一意の情報**が設定されるはずです。そのため、リソースタグ名が無くても、**リソースを構築すること**自体には大きな影響はありません。

そのため、開発プロジェクト内によっては、**とりあえず、リソース名は構築日を入れておこう**といった案外ゆるい運用をしているところも少なからずあるのかなぁと思いました。（私自身もそのような開発プロジェクトに参画した経験があります...）

そのうえで、**リソースタグ名を正しくつけないことによる弊害**について私なりに整理してみました。

### リソースタグ名を正しくつけないことによる弊害
- **どの部署が管理しているリソースか判断できない**
    - 管理部署が分からないことで、**棚卸しする際、誰に確認すればいいのか分からない**といった状況が発生します
- **コスト分析を行うが煩雑になり、早期のコスト削減が行えない**
    - リソースタグが付与されていないことで、**どの部署がどのくらいAWSリソースを利用しているか分からず、コスト分析に時間がかかり、コスト削減に時間がかかってしまう**といったリスクが高くなります
- **開発者の主観によって適当なルールでタグ付けが行われる**
    - リソースタグ名の付与ルールが決まっていないことで、開発者によって**タグ名のルールがばらばらになり、管理が煩雑になる**といったリスクが発生します
- **本番用リソースを誤って削除してしまうリスクが発生する**
    - 本番用リソースへ適切なタグ名を付与しないことで、**IAMポリシーによるリソース削除防止策を講じることができず、誤って本番リソースを削除する**リスクが高くなる

などなど、リソースタグ名一つとっても、**幅広いリスク**があるように見受けられます

## 利害関係者におけるリソースタグ名の考え方
AWS リソースのタグ付けのベストプラクティスを読んでみると、利害関係者ごとに、**どのような観点でリソースタグ名を考えればいいのか**がまとめられておりましたので、抜粋いたします。

https://docs.aws.amazon.com/ja_jp/whitepapers/latest/tagging-best-practices/defining-needs-and-use-cases.html

### 財務部門や事業部門
>投資の価値をコストと照らし合わせて把握し、非効率な状況に対処する際に取るべきアクションの優先順位を決めます。コストと生み出される価値を理解すると、うまくいっていない事業部門や製品提供を見極めることができます。その結果、サポートの継続、代替案の採用（SaaSオファリングやマネージドサービスの使用など）、または不採算のビジネスオファリングの廃止について、根拠のある決定を下すことができます。

### ガバナンス担当者
>データの分類（公開、機密、極秘など）、特定のワークロードが特定の標準や規制に対する監査の対象となるかどうか、および権限、ポリシー、監視などの適切な制御と監視を適用するためのサービスの重要性（サービスまたはアプリケーションがビジネスに不可欠なかどうか）を理解する必要があります。

### 運用部門・開発部門
>ワークロードのライフサイクル、サポート対象製品の実装段階、リリース段階 (開発、テスト、本番など) の管理、および関連するサポートの優先順位付けと利害関係者の管理要件を理解する必要があります。バックアップ、パッチ適用、オブザーバビリティ、非推奨などの義務も定義し、理解する必要があります。

### セキュリティ担当者
>どのコントロールを適用する必要があるか、どのコントロールが推奨されるかを概説します。 InfoSec SecOps は通常、コントロールの実装を定義し、それらのコントロールの管理に一般的に責任を負います。

## リソースタグのベストプラクティスとは？
とはいえ、AWSのリソースタグ名に関して、**どのような戦略をとってリソースタグ名を決定すればいいのか**といった悩みはあるかと思います。（私自身も悩みを感じています）

AWS公式ドキュメントでリソースタグ名のベストプラクティスについてまとめられておりましたので、抜粋しました。

https://docs.aws.amazon.com/tag-editor/latest/userguide/best-practices-and-strats.html

### リソースタグのベストプラクティス
- **個人を特定できる情報(PII)やその他の機密情報を追加しない**
- **標準化された大文字と小文字を区別する形式を使用する**
- **複数の目的をサポートするタグのガイドラインを検討する**
- **自動タグ付けAPIを活用する　※一部サービスのみ**
- **タグが少なすぎるより多すぎるほうが良い**
- **将来の影響を考慮してタグ名を設定する**
- **組織ごとに共通のタグをつけるのであれば、あらかじめAWS Organizationのタグポリシーで制御する**

端的にまとめると、**リソース構築時だけでなく、将来の事業展開を踏まえて、適切なタグ名をつけていく**ことが主にあるのかなぁと思っています。そのうえで、ベストプラクティスでは記載されていなかったですが、AWS Configなどを用いて、**リソース構築時にタグ付けを強制させる**といった前処理も必要なのかなぁと思っています。

## 結局どういったリソースタグ名をつければいいのか？

私個人としては、**リソースタグ名の銀の弾丸はなく、プロジェクトに応じてリソースタグ名を適宜考えていく**ことが大切だと考えています。

そのうえで、どのプロジェクトでも共通していると思うルールとして**小学生でも理解できるタグ名**が最適だと考えています。

例えば、金融機関向け本番サーバに対してリソースタグをつけるとして、**Name:bank-honban**より、**Project:Example-Bank-Update、State：Production、caution:not-destroy**といったほうが**このリソースは何の目的で利用されているのか**がより分かるかと思います。

リソースタグ名に関しては以下ブログがすごくわかりやすくまとめられておりましたので、参考にしていただければと思います。

https://qiita.com/hidekatsu-izuno/items/c1c0ce0b56a822c25e5e

## まとめ

**たかがリソースタグ名**と軽く考えず、**将来の運用を踏まえた適切なリソースタグ名をつけること**が未来の開発者にとって幸せになるのではと考えています。そのうえで、AWS公式ドキュメントでも示している通り、**リソースタグ名についてもPDCAを常に行っていくこと**が大切になりますので、運用を踏まえた見直しを行っていくことをお勧めいたします。

本記事通じて、読者の皆さんが抱えている**リソースタグ名に対する悩み解決**につながっていただければ幸いです。

## 参考サイト

[Tagging AWS Resources and Tag Editor](https://docs.aws.amazon.com/tag-editor/latest/userguide/find-resources-to-tag.html)

[Organizing Your AWS Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)

[AWS Well-Architected](https://aws.amazon.com/jp/architecture/well-architected/?wa-lens-whitepapers.sort-by=item.additionalFields.sortDate&wa-lens-whitepapers.sort-order=desc&wa-guidance-whitepapers.sort-by=item.additionalFields.sortDate&wa-guidance-whitepapers.sort-order=desc)

[Resource Groups Tagging API](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/overview.html)

[AWS リソースのタグ規約を考える](https://qiita.com/hidekatsu-izuno/items/c1c0ce0b56a822c25e5e)

[AWS タグの活用方法と命名ルールを考える](https://dev.classmethod.jp/articles/aws-tagging-basic/)