パート1. AWSタグ付けストラテジー入門

この記事は、著者の許可を得て配信しています。
https://www.cloudforecast.io/blog/aws-tagging-best-practices/

Amazon Web Servicesで長く働いている方であれば、チームのリソースを整理するためにAWSのコスト配分タグを見たり、使ったりしたことがあるのではないでしょうか。AWSでは、タグと呼ばれるキーと値のペアの形で、ほとんどのリソースにメタデータを添付することができます。今回のガイダンス記事（3回シリーズの第1回目）では、AWSのコスト配分タグの最も一般的なユースケースをいくつか取り上げ、タグの選択と整理のためのAWSタグ付けのベストプラクティスを見ていきたいと思います。最後に、実際の企業がAmazon Web Servicesのリソース利用状況を可視化するために利用しているAWSリソースのタグ付け戦略の例をいくつか紹介します。

なぜAWSリソースにタグを付けるのか？

AWSのコスト配分タグを利用することで、AWSのコストを把握し、管理することができます。AWS Cost Explorerではタグを使用してAWSリソースの使用状況を経時的に分解することができ、 CloudForecast のようなツールでは支出の状況を積極的に把握することができます。

AWSリソースにタグを付けるべき理由は、コストの把握とコントロールだけではありません。AWSのコスト配分タグを使用すれば、以下のようなさまざまな疑問の答えを見つけることもできます。

• どのチームメンバーがこのAWSリソースの窓口になっているのか？
• どのくらいのサーバーが最新バージョンのOSにアップデートされているか？
• アラート機能が有効になっているサービスはいくつあるか？
• 低負荷時に不要なAWSリソースはどれか？
• 誰がこのリソースへのアクセス権を持つべきか？

すべてのAWSリソースにAWSコスト配分タグを追加する前に、タグを持続的に管理するための戦略を立てることが不可欠です。AWSタグは便利ですが、一貫して使用するという前提での計画がなければ継続的に使用できず、残念な結果に終わってしまいます。

AWSタグ付けベストプラクティス

すべての組織に通用する完璧なAWSタグ付け戦略はありませんが、知っておくべきAWSタグ付けのベストプラクティスはいくつかあります。

1. 作成したそれぞれのタグがどのように使用されるかを知る

AWSでは、コスト配分タグは、「テクニカル」、「ビジネス」、「セキュリティ」、「オートメーション（自動化）」の4つのカテゴリに分かれています。AWSタグの戦略を作る際には、これらのカテゴリのうちどれが必要かを考えてみましょう。

• テクニカルタグは、エンジニアがリソースを識別して作業するのに役立ちます。アプリケーションやサービス名、環境、バージョン番号などが含まれます。
• ビジネスタグを使用することで、ステークホルダー（利害関係者）はコストや各リソースを担当するチームやビジネスユニットを分析することができます。例えば、昨年発売した新製品にAWSがどのくらいの割合で使われているかを知りたい場合、その努力の投資対効果を判断することができます。
• セキュリティタグは、組織全体でコンプライアンスやセキュリティ基準が満たされていることを確認するためのものです。これらのタグは、アクセスを制限したり、HIPAA や SOC コンプライアンスのための特定のデータセキュリティ要件を示すために使用されたりすることがあります。
• オートメーションタグは、アカウント内の各リソースのクリーンアップ、シャットダウン、使用ルールを自動化するために使用できます。例えば、sandboxサーバーにタグを付けて、スクリプトを実行して、それらが不要になった後は、削除することができます。

2. どのAWSタグを必須にするかを決める

どのAWSタグが必要か、どのように使うかを決める際には、その使い方のルールを決めておきましょう。どのAWSタグを必須にするか、どの文字をデリミタ（区切り文字）として使うか、誰が作成の責任者になるかなどを決めておきましょう。すでに多くのリソースを持っている場合は、タグの割り当てを使用するチームに委任する必要があるかもしれません。

3. 一貫性のあるAWSタグの命名規則を開発する

AWSタグのキーと値のために、一貫性があり、かつ、スケーラブルなAWSタグの命名規則を選択するのは複雑になりがちです。使用できる文字や、AWSタグのキーや値の長さについては、異なるAWSタグの命名規則があります。AWSタグの命名規則を選択する前に、これらのタグの制限事項を必ず読んでおきましょう。

一般的なAWSタグの命名規則のパターンは、単語と単語の間にハイフンを入れて小文字を使い、コロンを使ってネームスペースを作ることです。下に例を出しておきます。

Tag Key    Value
mifflin:eng:os-version    1.0

mifflinは会社名、engはこのタグがエンジニアリングチームに関連していることを示し、os-versionはタグの目的を示し、1.0は値です。

4. 採用するAWSタグの数を制限する

使用すべきタグの数には、技術的にも実践的にも制限があります。AWSは各リソースに50というタグの制限を課しています。さらに重要なのは、タグを必要とする数が多すぎると、エンジニアはタグの使用方法を記録したり、適切な使用方法を覚えたりするのが大変になるということなので、覚えておいてください。

幸いなことに、多くのタグはAWSのビルドインリソースのメタデータに頼ることで回避することができます。例えば、AmazonはデフォルトでcreatedByタグを追加しているので、EC2インスタンスの作成者を保存する必要はありません。どのタグが必要なのかを決めて、新しいタグの作成を制限するようにしましょう。

5. AWSのタグ管理を自動化する

アカウント内のAWSリソースの数が増えてくると、AWSタグの管理、規約の施行、タグの更新がますます難しくなってきます。このガイドのパート2とパート3では、Terraform, CloudFormation, Cloud Custodianを使ってリソース全体のタグを管理する方法を説明します。

また、Amazonではタグポリシー、リソースグループごとのタグ付け、リソースタグ付けAPIが利用可能であり、タグの管理や割り当てを一括して行うことができます。タグ管理プロセスの多くを可能な限り自動化することで、長期的にはタグがより高品質で保守性の高いものになります。

6. AWSのタグを監査して維持する計画を立てる

AWSのタグを定期的に見直すことで、タグの有用性と正確性を確認する必要があります。デプロイするリソースの数にもよりますが、四半期ごとにタグを監査するようにリマインダーを設定したり、毎月タグをレビューして更新するための委員会を作ったりすることが必要になるかもしれません。このガイドのパート3では、タグを管理するためのツールや戦略を見ていきます。

Amazon Web Servicesでは、リソースのタグ付けに関する推奨プラクティスをまとめた包括的なドキュメントを閲覧できます。AWSタグに慣れていない方や、AWSタグ付けのベストプラクティスをより深く知りたい方は、ぜひ参考にしてみてください。

AWSのタグ付け戦略の例

実際のタグ付け戦略の例をいくつか見てみましょう。これらは、様々な理由でリソースを整理するためにAWSタグを使用している実際の企業に採用されたものです。あなたのユースケースとは異なるかもしれませんが、AWSでリソースにどのようにタグを付けるかについての役に立つ知識を得られるはずです。

例1：サービスベースのAWSタグ付け戦略

リソースにタグ付けするための一般的なパターンは、サービスと環境ごとのタグ付けです。例えば、ある組織に2つのサービス(cartとsearch)と2つの環境(prodとdev)がある場合、以下のようなタグを設定することができます。

Key    Value

service cart か search
このリソースを管理するエンジニアの contactName
env prod か dev

これら2つのサービスが単一のRDS インスタンスを共有している場合、データベースには service=cart|searchというタグを付けることができます（このリソースが両方のサービスを提供していることを示すため）。そのアーキテクチャは下のようになります。

上記のようなAWSのタグ付け戦略を選択した場合、時間の経過とともにタグがどのように変化するかを考慮しなければなりません。例えば、同じRDSインスタンスを共有する新しいサービスを追加した場合、データベースのタグを更新して新しいサービスの名前を含める必要があります。このため、あるリソースがすべてのサービスで使用される可能性があることを示すために、単一のタグを使用することを選択するチームもあります（例： service=common）。

どのサービスがAWSのコストに最も貢献しているかを把握したい場合、このようなサービスベースのタグ戦略が一番よいでしょう。ビジネスチームはこれらのタグを使用して、各サービスや環境にいくら支払っているかを確認し、何か質問があれば適切な連絡先に質問を投げかけることができます。

例2：コンプライアンスAWSのタグ付け戦略

AWSのコスト配分タグは、組織のガバナンスやコンプライアンスの管理にも役立つころともあります。 CloudForecastのようなツールは、AWSのタグ付けコンプライアンス機能を介して、リソースに特定の方法でタグを付けることで、タグ付けコンプライアンスを維持するのに便利です。これらのAWSタグは、アクセスを制限したり、特定のリソースに対して追加のセキュリティチェックを行ったりするために利用することができます。

この例では、ユーザーデータを含むリソースにuser-data=trueのタグを付けて、より頻繁に監査を行い、特定の基準を満たしていることを確認しています。すべてのリソースには、責任のあるチームメンバーを指定するための  contact タグと env タグを付け、確実に誰かがそれらを最新の状態に保つための説明責任があるように設定しています。

コンプライアンスタグ戦略を使用しても、他の戦略の使用を妨げるようなことはありません。AWSタグのメリットの1つは、ほぼ無限に近い方法でAWSリソースをセグメント化（「区分できることができる」の方がいいでしょうか）できることです。

例3：アカウントのセグメント化された環境

最後の例は、アカウント単位でのタグ付け戦略です。AWSのIAMパーミッションでは、ユーザー、ロール、チームへのアクセスを細かく割り当てることができますが、組織によっては、さらに一歩進んだものを使用したいという組織もあるでしょう。

「 異種論理環境にまたがるリソースがコロケーションされている場合、リソースのプロビジョニングやネットワーク/IAMポリシーの設計に細心の注意を払わなければ、すぐに他の環境のリソースを誤って使用してしまいます」 - Cars.comのプラットフォームエンジニア

この例では、組織は各リソースにビジネスユニットとチームのタグを指定し、各環境は個別のAWSアカウントを持つようにしました。

これにより、各環境でレポートを作成し、マーケティング（mktg）単位とデータウェアハウス（データ）単位のリソースコストを確認することができます。チームがこの方法でアカウント単位のタグ付けを使用している場合、組織全体のリソース使用状況を見るためにはマスターアカウントを使用する必要があります。また、 CloudForecastを使用して、複数のAWSアカウントにまたがる定期的なコスト報告書や内訳を作成することもできます。

まとめ

AWSを大規模に利用している組織であれば、自分たちに合ったタグ付け戦略を立てる必要があります。上記のAWSタギングのベストプラクティスと事例、そして組織の目標をぜひ参考にしてみてください。

一旦AWSのタグ付け戦略を決めたら、AWSのコスト配分タグの追加と維持のための計画が必要になります。このガイドの次のパートでは、エンジニアリングチームがすべてのAWSリソースで一貫したAWSタグの使用を確認するために導入すべきツールについて見ていきます。