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

Posted at 2024-11-12

いつも記事を読んでいただきありがとうございます！
エンジニアのMasaki(@MASAKIOKUDA-eng)です👍

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

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

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

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

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

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

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

リソースタグ名を正しくつけないことによる弊害

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

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

利害関係者におけるリソースタグ名の考え方

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

財務部門や事業部門

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

ガバナンス担当者

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

運用部門・開発部門

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

セキュリティ担当者

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

リソースタグのベストプラクティスとは？

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

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

リソースタグのベストプラクティス

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

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

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

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

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

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

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

まとめ

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

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