翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# AWS リソースのタグ付けのベストプラクティス
発行日: **2023 年 3 月 30 日** ([ドキュメントの改訂](document-revisions.md))
Amazon Web Services (AWS) では、タグの形式で多くの AWS リソースにメタデータを割り当てることができます。各タグは、リソースや、そのリソースにあるデータに関する情報を保存するためのキーとオプション値で構成される簡単なラベルです。このホワイトペーパーでは、目的、チーム、環境、またはビジネスに関連するその他の基準でリソースを分類することができるタグ付けのユースケース、戦略、手法、ツールに焦点を当てます。一貫したタグ付け戦略を実装することで、リソースのフィルタリングと検索、コストと使用状況のモニタリング、 AWS 環境の管理が容易になります。
このホワイトペーパーは、[「複数のアカウントを使用した AWS 環境の整理](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)」ホワイトペーパーに記載されているプラクティスとガイダンスに基づいています。このホワイトペーパーを読むことをお勧めします。 では、全体的な方法でクラウド基盤を確立 AWS することをお勧めします。追加情報については、「[AWSクラウド基盤の構築](https://docs.aws.amazon.com/whitepapers/latest/establishing-your-cloud-foundation-on-aws/welcome.html)」を参照してください。
## Well-Architected の実現状況の確認
[AWS Well-Architected フレームワーク](https://aws.amazon.com/architecture/well-architected/)は、クラウド内でのシステム構築に伴う意思決定の長所と短所を理解するのに役立ちます。このフレームワークの 6 つの柱により、信頼性、安全性、効率、費用対効果、持続可能性の高いシステムを設計および運用するための、アーキテクチャのベストプラクティスを確認できます。[AWS マネジメントコンソール](https://console.aws.amazon.com/wellarchitected) で無料で提供されている [AWS Well-Architected Tool](https://aws.amazon.com/well-architected-tool/) を使用すると、柱ごとに一連の質問に答えることで、これらのベストプラクティスに照らしてワークロードを評価できます。
クラウドアーキテクチャに関する専門的なガイダンスやベストプラクティス (リファレンスアーキテクチャのデプロイ、図、ホワイトペーパー) については、[AWS アーキテクチャセンター](https://aws.amazon.com/architecture/)を参照してください。
## 序章
AWS では、[Amazon EC2 インスタンス](https://aws.amazon.com/ec2)、[Amazon EBS ボリューム](https://aws.amazon.com/ebs/)、[セキュリティグループ](https://docs.aws.amazon.com/AWSEC2/latest/DeveloperGuide/using-network-security.html)、 [AWS Lambda 関数](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)などのリソースを作成 AWS することで、 にワークロードを簡単にデプロイできます。また、アプリケーションをホストし、データを保存し、時間の経過とともに AWS インフラストラクチャを拡張する AWS リソースのフリートをスケーリングおよび拡張することもできます。 AWS 使用量が複数のアプリケーションにまたがる多くのリソースタイプに増加するにつれて、どのリソースがどのアプリケーションに割り当てられているかを追跡するメカニズムが必要になります。このメカニズムで、コスト監視、インシデント管理、パッチ適用、バックアップ、アクセス制御などの運用アクティビティをサポートしてください。
オンプレミス環境では、この情報は、一般にナレッジ管理システム、文書管理システム、社内の Wiki ページに取り込まれます。構成管理データベース (CMDB) では、標準の変更管理プロセスで、関連する詳細なメタデータの保存や管理ができます。このアプローチでガバナンスは得られますが、開発と保守には追加の作業が必要です。リソースの名前付けには構造化されたアプローチが可能ですが、リソース名に格納できる情報は限られています。
![\[リソースの名前を各部分に分解した図。\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/tagging-best-practices/images/structured-approach-to-resource-naming.png)
例えば、EC2 インスタンスに類似する機能の Name という定義済みのタグがある場合、ワークロードを AWSに移動するときに名前を付けることができます。
2010 年、 [https://aws.amazon.com/blogs/aws/new-amazon-ec2-feature-resource-tagging/](https://aws.amazon.com/blogs/aws/new-amazon-ec2-feature-resource-tagging/) AWS を起動しました。このホワイトペーパーでは、 AWS 環境全体で堅牢なタグ付け戦略を開発および実装するプロセスについて説明します。このガイダンスでは、意思決定や運用活動をサポートするタグ付けの一貫性と適用範囲を確保します。