# 経費支出と使用量の認識
**Topics**
+ [COST 2 使用状況はどのように管理すればよいですか?](w2aac19c13b7b5.md)
+ [COST 3 使用状況とコストはどのようにモニタリングすればよいですか?](w2aac19c13b7b7.md)
+ [COST 4 不要なリソースはどのように削除すればよいですか？](w2aac19c13b7b9.md)
# COST 2 使用状況はどのように管理すればよいですか?
発生コストを適正な範囲内に抑えつつ、目的を確実に達成するためのポリシーとメカニズムを設定します。チェックアンドバランスのアプローチを採用することで、無駄なコストを費やすことなくイノベーションが可能です。
**Topics**
+ [COST02-BP01 組織の要件に基づいてポリシーを策定する](cost_govern_usage_policies.md)
+ [COST02-BP02 目標およびターゲットを策定する](cost_govern_usage_goal_target.md)
+ [COST02-BP03 アカウント構造を実装する](cost_govern_usage_account_structure.md)
+ [COST02-BP04 グループとロールを実装する](cost_govern_usage_groups_roles.md)
+ [COST02-BP05 コストコントロールを実装する](cost_govern_usage_controls.md)
+ [COST02-BP06 プロジェクトのライフサイクルを追跡する](cost_govern_usage_track_lifecycle.md)
# COST02-BP01 組織の要件に基づいてポリシーを策定する
組織のリソースの管理方法を定義するポリシーを策定します。ポリシーでは、リソースのライフサイクル全体にわたる作成、変更、削除を含む、リソースとワークロードのコスト面をカバーする必要があります。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
組織のコストおよびコスト要因を把握することは、コストと使用量を効果的に管理し、コスト削減の機会を特定するうえできわめて重要です。組織では一般に、複数のワークロードが複数のチームによってオペレーションされています。各チームはさまざまな組織単位に属する可能性があり、そのそれぞれに独自の収益の流れがあります。リソースのコストをワークロード、それぞれの組織、製品オーナーに帰属させることができると、リソースを効率的に使用し、無駄を削減できます。コストと使用量を正確にモニタリングすることで、各組織単位や製品の収益性が把握できるようになり、より確かな情報に基づいて組織内のリソース配分を決定できます。使用量が変化するとコストも変動するため、組織内のあらゆるレベルの使用量を認識することは、変化を促進する鍵となります。使用方法と支出を認識するために多面的なアプローチを取ることを検討してください。
ガバナンスを実行するための最初のステップは、組織の要件を使用して、クラウド使用に関するポリシーを作成することです。ポリシーでは、組織がクラウドをどのように使用するかや、リソースをどのように管理するかを定義します。ポリシーではコストや使用量に関係するリソースとワークロードのあらゆる局面、つまりリソースのライフタイム全体にわたる作成、変更、削除をカバーする必要があります。
ポリシーを簡単に理解し、組織全体で効果的に実装するには、シンプルなものにする必要があります。使用許可する地理的リージョンや、リソースを実行する時間帯など、幅広い高レベルのポリシーから始めます。続いてポリシーを徐々に絞り込み、さまざまな組織単位やワークロードに対応させます。一般的なポリシーの例としては、どのサービスと機能が利用できるか (例えば、テスト環境や開発環境ではパフォーマンスが低下するストレージ)、どのタイプのリソースが各グループで使用できるか (例えば、開発用アカウントのリソースの最大サイズはミディアム) などがあります。
**実装手順**
+ **チームメンバーとのミーティングを設ける: **ポリシーを開発するために、組織からすべてのチームメンバーを集め、要件を指定し、適切に文書化します。幅広く開始し、各ステップで最小単位まで継続的に絞り込んでいくという反復型アプローチを採用します。チームメンバーには、組織単位やアプリケーションの所有者など、ワークロードの直接の関係者に加え、セキュリティチームや財務チームなどのサポートグループを含みます。
+ ** ワークロードの場所を定義する: **ワークロードの運用場所 (国や国内のエリアなど) を定義します。この情報は、AWS リージョンとアベイラビリティーゾーンへのマッピングに使用されます。
+ ** サービスとリソースを定義およびグループ化する: **ワークロードに必要なサービスを定義します。サービスごとに、タイプ、サイズ、必要なリソースの数を指定します。アプリケーションサーバーやデータベースストレージなどの機能別にリソースのグループを定義します。リソースは複数のグループに属することができます。
+ **機能別にユーザーを定義およびグループ化する: **ワークロードに関係するユーザーについて、当該ユーザーが誰かまたは組織内での地位に焦点を当てるのではなく、何を行うか、またはどのようにワークロードを使用するかに焦点を当てて定義します。類似したユーザーまたは機能をグループ化します。AWS 管理ポリシーをガイドとして使用できます。
+ ** アクションを定義する:** 以前に特定した場所、リソース、およびユーザーを使用して、そのライフタイム (開発、運用、削除) にわたってワークロードの成果を得るために、それぞれが必要とするアクションを定義します。各場所で、グループ内の個々の要素ではなく、グループに基づいてアクションを特定します。開始時には読み取りまたは書き込みを幅広く設定し、それぞれのサービスについて、特定のアクションへと絞り込んでいきます。
+ ** レビュー期間を定義する:** ワークロードと組織の要件は、時間の経過とともに変化する可能性があります。ワークロードのレビュースケジュールを定義して、組織の優先順位に合わせた状態を維持します。
+ **ポリシーを文書化する: **定義されたポリシーが、組織の必要に応じてアクセス可能であることを確認します。これらのポリシーは、環境へのアクセスを実装、保守、監査するために使用されます。
## リソース
**関連するドキュメント:**
+ [AWS Managed Policies for Job Functions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)
+ [AWS 複数アカウントの請求戦略](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/)
+ [Actions, Resources, and Condition Keys for AWS Services](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_actions-resources-contextkeys.html)
+ [クラウド製品](https://aws.amazon.com/products/)
+ [Control access to AWS リージョン using IAM policies](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/)
+ [グローバルインフラストラクチャリージョンと AZ](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/)
# COST02-BP02 目標およびターゲットを策定する
ワークロードのコストおよび使用量の両方について、目標を策定します。目標はコストと使用状況について組織に方向性を提供し、ターゲットはワークロードについての測定可能な結果を提供します。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
組織のコスト、目標使用量、ターゲットを設定します。目標は、期待される成果に関するガイダンスと指示を組織にもたらします。ターゲットは、具体的かつ測定可能な達成すべき結果をもたらします。目標の一例: プラットフォームの使用量を大幅に増加させ、コストは微増 (非線形) にとどまるようにする。ターゲットの一例:プラットフォームの使用率を 20% 増加させ、コスト増は 5% 未満。もう 1 つの一般的な目標となるのは、ワークロードを 6 か月ごとにより効率的にするという必要性です。この種のターゲットとして、ワークロードの結果あたりのコストを 6 か月ごとに 5% 削減する必要があるというケースも考えられます。
クラウドワークロードの一般的な目標は、ワークロードの効率を高めることです。これは、ワークロードのビジネス成果あたりのコストを経時的に削減することです。この目標と合わせて、6～12 か月ごとに効率を 5% 向上させるなどのターゲットをすべてのワークロードに設定することを推奨します。これは、クラウド内でコスト最適化の機能を構築し、新しいサービスやサービス機能のリリースを行うことで達成できます。
**実装手順**
+ **予想される使用レベルを定義する: **まず、使用レベルに焦点を当てます。アプリケーションの所有者、マーケティング、およびより大きなビジネスチームと協力して、ワークロードに対して予想される使用レベルを把握します。顧客の需要が時間の経過とともにどのように変化するか、季節的な増加やマーケティングキャンペーンによって変化が生じるかどうか、などを考慮します。
+ ** ワークロードのリソースとコストを定義する: **使用レベルを定義した上で、これらの使用レベルを満たすために必要なワークロードリソースの変化を数値化します。ワークロードコンポーネントのサイズまたはリソースの数を増やしたり、データ転送を増やしたり、特定のレベルでワークロードコンポーネントを別のサービスに変更したりすることが必要な場合があります。これらの主な各ポイントにおけるコストと、使用状況が変更された場合のコストの変化を指定します。
+ **ビジネス目標を定義する: **予想される使用量とコストの変化から結果を取得し、これを、予想されるテクノロジーや実行中のプログラムの変化と組み合わせて、ワークロードの目標を策定します。目標は、使用状況、コスト、および両者の関係を対象に含めたものである必要があります。コストは変化するが使用状況に変化がないことが予想される場合は、トレーニングや教育などの機能構築などの組織プログラムが存在していることを確認します。
+ **ターゲットを定義する: **定義された目標ごとに、測定可能なターゲットを指定します。目標がワークロードの効率を高めることである場合、ターゲットは、改善 (通常は 1 ドルあたりのビジネス出力量の改善) の量と、改善がいつ実現されるかを数値化します。
## リソース
**関連するドキュメント:**
+ [AWS ジョブ機能の管理ポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)
+ [AWS 複数アカウントの請求戦略](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/)
+ [Control access to AWS リージョン using IAM policies](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/)
# COST02-BP03 アカウント構造を実装する
組織にマッピングされるアカウントの構造を実装します。これは組織全体でのコストの割り当てと管理に役立ちます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
AWS は 1 つの親アカウントと複数の子アカウントからなる構造です。このアカウント構造は、一般に管理 (親、旧称は支払者) アカウント、メンバー (子、旧称はリンク) アカウントと呼ばれます。ベストプラクティスは、組織の規模や使用量にかかわらず、1 つのメンバーアカウントを持つマスターを少なくとも常に 1 つ持つことです。すべてのワークロードリソースが存在するのは、メンバーアカウント内のみとする必要があります。
AWS アカウントの最適な数は状況に応じて異なります。現在と将来の運用モデルとコストモデルを見積もり、AWS アカウントの構造が組織の目標を反映するようにします。ビジネス上の理由から複数の AWS アカウントを作成する企業もあります。次に例を示します。
+ 組織単位、コストセンター、特定のワークロード間で、管理、会計、請求の職務機能を切り離す必要がある場合。
+ AWS のサービスの制限が特定のワークロードのみに設定される場合。
+ ワークロードとリソース間の隔離と分離には要件があります。
では [AWS Organizations](https://aws.amazon.com/organizations/)io1[一括請求 (コンソリデーティッドビリング)](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html) により、1 つ以上のメンバーアカウントと管理アカウントとの間に構造が作成されます。メンバーアカウントを使用すると、コストと使用量をグループ別に区別できます。一般的には、各組織単位 (財務、マーケティング、営業など)、各環境ライフサイクル (開発、テスト、本番など)、各ワークロード (ワークロード a、b、c) にメンバーアカウントをいったん分離したうえで、一括請求 (コンソリデーティッドビリング) を使用してこれらのアカウントを集約します。
一括請求 (コンソリデーティッドビリング) 機能を使用すると、複数のメンバー AWS アカウントの支払いを単一の管理アカウントにまとめつつ、各リンクアカウントのアクティビティの可視性も維持できます。コストと使用量が管理アカウントに集計されると、サービスの従量制割引とコミットメント割引 (Savings Plans とリザーブドインスタンス) を最大限に活用し、割引額を最大化できます。
[AWS Control Tower](https://aws.amazon.com/controltower/) では、複数の AWS アカウントのセットアップと構成をすばやく行い、ガバナンスが組織の要件に適合していることを確認できます。
**実装手順**
+ **分離要件を定義する: **分離の要件は、セキュリティ、信頼性、財務構造など、複数の要因の組み合わせです。各要因を順番に確認し、ワークロードまたはワークロード環境を他のワークロードから分離するかどうかを指定します。セキュリティは、アクセスとデータ要件を確実に守るものです。信頼性は、環境やワークロードが他の環境に影響を与えないように制限を確実に管理するものです。財務構造は、厳格な財務分離と説明責任を確保するものです。分離の一般的な例としては、本番稼働用ワークロードとテストワークロードが別々のアカウントで実行されることや、請求書と請求データをサードパーティー組織に提供できるように別のアカウントを使用することが挙げられます。
+ **グループ化要件を定義する:** グループ化要件は分離要件を上書きしませんが、管理を支援するために使用されます。分離を必要としない同様の環境またはワークロードをグループ化します。この例としては、1 つ以上のワークロードから複数のテスト環境または開発環境をグループ化することが挙げられます。
+ **アカウント構造を定義する: **これらの分離およびグループ化を使用して、各グループのアカウントを指定し、分離要件が維持されるようにします。これらのアカウントは、メンバーアカウントまたは連結アカウントです。これらのメンバーアカウントを単一の管理アカウントまたは支払者アカウントでグループ化することで、使用量が合算されるので、すべてのアカウントでの従量制割引がより大きくなり、すべてのアカウントに対して単一の請求書が提供されます。請求データを分離し、各メンバーアカウントに請求データの個別のビューを提供することができます。メンバーアカウントが使用量や請求データを他のアカウントに表示してはならない場合、または AWS から別々の請求書を必要とする場合は、複数の管理アカウントまたは支払者アカウントを定義します。この場合、各メンバーアカウントは独自の管理アカウントまたは支払者アカウントを持つことになります。リソースは常にメンバーアカウントまたは連結アカウントに配置する必要があります。管理アカウントまたは支払者アカウントは、管理のためにのみ使用してください。
## リソース
**関連するドキュメント:**
+ [AWS ジョブ機能の管理ポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)
+ [AWS 複数アカウントの請求戦略](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/)
+ [Control access to AWS リージョン using IAM policies](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/)
+ [AWS Control Tower](https://aws.amazon.com/controltower/)
+ [AWS Organizations](https://aws.amazon.com/organizations/)
+ [一括請求](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html)
**関連する例:**
+ [CUR の分割とアクセスの共有](https://wellarchitectedlabs.com/Cost/Cost_and_Usage_Analysis/300_Splitting_Sharing_CUR_Access/README.html)
# COST02-BP04 グループとロールを実装する
ポリシーに沿ったグループおよびロールを実装し、各グループのインスタンスおよびリソースを作成、変更、削除できるユーザーを管理します。たとえば、開発、テスト、本番グループを実装します。これは、AWS のサービスやサードパーティーのソリューションに適用されます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
ポリシーを作成すると、組織内のユーザーの論理グループとロールを作成できます。これにより、アクセス許可の割り当てと使用量の制御が可能になります。人材のおおまかなグループ化から始めます。通常これは、組織単位と役職 (IT 部門のシステム管理者、会計監査担当者など) と合致します。グループとは、類似したタスクに従事し、類似したアクセスを必要とするユーザーの集団を指します。ロールとは、グループとして義務付けられた仕事の定義を指します。たとえば、IT のシステム管理者はすべてのリソースを作成するためのアクセスが必要ですが、分析チームのメンバーは分析リソースを作成するアクセスのみで十分です。
**実装手順**
+ ** グループを実装する: **必要に応じて、組織のポリシーで定義されているユーザーのグループを使用して、対応するグループを実装します。ユーザー、グループ、および認証のベストプラクティスについては、セキュリティの柱を参照してください。
+ ** ロールとポリシーを実装する: **組織のポリシーで定義されているアクションを使用して、必要なロールとアクセスポリシーを作成します。ロールとポリシーのベストプラクティスについては、セキュリティの柱を参照してください。
## リソース
**関連するドキュメント:**
+ [AWS ジョブ機能の管理ポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)
+ [AWS 複数アカウントの請求戦略](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/)
+ [Control access to AWS リージョン using IAM policies](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/)
+ [Well-Architected セキュリティの柱](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html)
**関連する例:**
+ [Well-Architected ラボ: 基本的なアイデンティティとアクセス](https://wellarchitectedlabs.com/Security/100_Basic_Identity_and_Access_Management_User_Group_Role/README.html)
# COST02-BP05 コストコントロールを実装する
組織のポリシーと定義済みのグループおよびロールに基づいてコントロールを実装します。これにより、組織の要件で定義されているとおりにコストが発生することが保証されます。例えば、AWS Identity and Access Management (IAM) ポリシーでリージョンまたはリソースタイプへのアクセスをコントロールできます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
コストコントロールを実装する際の一般的な最初のステップは、ポリシー外のコストまたは使用量イベントが発生した場合に通知するように設定することです。これにより、ワークロードや新しいアクティビティを制限したり悪影響を与えたりすることなく、迅速に行動し、是正措置の必要性の有無を確認できます。ワークロードと環境の制限を理解したら、ガバナンスを適用できます。AWS では、通知を実行する AWS Budgets により、AWS のコスト、使用量、コミットメント割引 (Savings Plans とリザーブドインスタンス) の月次予算を定義できます。予算は、集計コストのレベル (たとえば、全コスト)、またはリンクアカウント、サービス、タグ、アベイラビリティーゾーンなどの特定のディメンションのみを含む詳細レベルで作成できます。
次のステップとして、AWS では [AWS Identity and Access Management](https://aws.amazon.com/iam/) (IAM) と [AWS Organizations サービスコントロールポリシー (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)を介して、ガバナンスポリシーを適用できます。IAM により、AWS のサービスとリソースへのアクセスを安全に管理できます。IAM を使用すると、AWS のリソースを作成および管理できるユーザー、作成できるリソースのタイプ、リソースを作成できる場所を制御できます。これにより、不要なリソースの作成が最小限に抑えられます。以前に作成したロールとグループを使用して [IAM ポリシーを割り当て、](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) 適切な使用量を適用します。SCP は組織内のすべてのアカウントで利用可能なアクセス許可の上限を一元的に制御し、アカウントがアクセスコントロールのガイドライン内に収まるようにします。SCP はすべての機能が有効になっている組織でのみ使用可能で、デフォルトでメンバーアカウントのアクションの可否を SCP を設定できます。アクセス管理の実装の詳細については、 [Well-Architected セキュリティの柱のホワイトペーパー](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html) を参照してください。
Service Quotas を管理することで、ガバナンスを導入することもできます。サービスクォータを最小オーバーヘッドに設定し、正確に維持するよう徹底することで、組織に不要なリソースの作成を最小限に抑えることができます。これを実現するには、要件がどれだけ速く変化するかを理解し、進行中のプロジェクト (リソースの作成と削除の両方) を理解し、クォータ変更をどれだけすばやく実装できるかを考慮する必要があります。[Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) を使用して、必要に応じてクォータを増加させることができます。
**実装手順**
+ ** 支出に関する通知を実装する:** 定義した組織のポリシーを使用して、AWS Budgets を作成し、支出がポリシーを外れた場合に通知を提供するようにします。アカウントごとに 1 つずつ、複数のコスト予算を設定し、アカウントの支出全体について通知するようにします。次に、アカウント内のより小さな単位について、各アカウント内にコスト予算を追加で設定します。これらの単位は、アカウント構造によって異なります。一般的な例としては、AWS リージョン、ワークロード (タグを使用)、または AWS のサービスがあります。E メール配信リストが通知の受取人として設定されており、また、個人の E メールアカウントではないことを確認します。金額を超えたときの実際の予算を設定するか、予測された使用量が通知されたときの予測された予算を使用します。
+ ** 使用量のコントロールを実装する: **定義した組織のポリシーを使用して、IAM ポリシーとロールを実装し、ユーザーが実行できるアクションと実行できないアクションを指定します。AWS ポリシーには、複数の組織ポリシーを含めることができます。ポリシーを定義するのと同じ方法で、幅広く開始し、各ステップでより詳細なコントロールを適用します。サービスの制限も、使用量に対する効果的なコントロールです。すべてのアカウントに正しいサービス制限を実装します。
## リソース
**関連するドキュメント:**
+ [AWS ジョブ機能の管理ポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)
+ [AWS 複数アカウントの請求戦略](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/)
+ [Control access to AWS リージョン using IAM policies](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/)
**関連する例:**
+ [Well-Architected ラボ: コストと使用量のガバナンス](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_2_Cost_and_Usage_Governance/README.html)
+ [Well-Architected ラボ: コストと使用量のガバナンス](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_2_Cost_and_Usage_Governance/README.html)
# COST02-BP06 プロジェクトのライフサイクルを追跡する
プロジェクト、チーム、環境のライフサイクルを追跡、計測、監査して、不要なリソースの使用やそれに伴う支払いを回避できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
ワークロードのライフサイクル全体を確実に追跡します。これにより、ワークロードやワークロードコンポーネントが不要になった場合、削除や変更が可能になります。これは、新しいサービスや機能をリリースする際に特に便利です。既存のワークロードとコンポーネントは使用されているように見えても、顧客を新しいサービスにリダイレクトするために使用を停止する必要があります。ワークロードの以前のステージに注目してください。ワークロードが本番稼働状態になったら、以前の環境は廃棄することと、再び必要になるまでキャパシティーを大幅に削減することも可能です。
AWS には、エンティティのライフサイクル追跡に使用できる管理およびガバナンスサービスが多数用意されています。専用のインフラストラクチャで [AWS Config](https://aws.amazon.com/config/) または [AWS Systems Manager](https://aws.amazon.com/systems-manager/) を使用すると、AWS リソースと設定の詳細なインベントリが入手可能です。プロジェクトやアセットを管理する既存のシステムを統合して、組織内のアクティブなプロジェクトや製品を追跡することを推奨します。現在のシステムを AWS が提供する豊富なイベントやメトリクスと組み合わせることにより、重要なライフサイクルイベントのビューを作成し、前もってリソースを管理し、不要なコストを削減できます。
ウェブアプリケーションのバックエンドに関する推奨事項については、 [Well-Architected 運用上の優秀性の柱のホワイトペーパー](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html) を参照してください。
**実装手順**
+ ** ワークロードの確認を実行する: **組織のポリシーで定義されているところに従って、既存のプロジェクトを監査します。監査に費やされる労力の量は、組織のおおよそのリスク、価値、またはコストに比例する必要があります。監査に含めるべき主な領域は、インシデントまたは機能停止の組織に対するリスク、価値、組織への寄与 (収益またはブランドに対する評価で測定)、ワークロードのコスト (リソースおよび運用の合計コストとして測定)、およびワークロードの使用量 (時間単位ごとの組織の成果の数で測定) です。これらの領域がライフサイクルを通じて変化する場合、完全または部分的な削除など、ワークロードの調整が必要です。
## リソース
**関連するドキュメント:**
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [AWS managed policies for job functions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)
+ [AWS 複数アカウントの請求戦略](https://aws.amazon.com/answers/account-management/aws-multi-account-billing-strategy/)
+ [Control access to AWS リージョン using IAM policies](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/)
# COST 3 使用状況とコストはどのようにモニタリングすればよいですか?
コストをモニタリングし、適切に配分するためのポリシー手順を定めます。これにより、ワークロードのコスト効率を測定し、向上させることができます。
**Topics**
+ [COST03-BP01 詳細情報ソースを設定する](cost_monitor_usage_detailed_source.md)
+ [COST03-BP02 コスト属性カテゴリを特定する](cost_monitor_usage_define_attribution.md)
+ [COST03-BP03 組織のメトリクスを確立する](cost_monitor_usage_define_kpi.md)
+ [COST03-BP04 請求およびコスト管理ツールを設定する](cost_monitor_usage_config_tools.md)
+ [COST03-BP05 コストと使用状況に組織情報を追加する](cost_monitor_usage_org_information.md)
+ [COST03-BP06 ワークロードメトリクスに基づいてコストを配分する](cost_monitor_usage_allocate_outcome.md)
# COST03-BP01 詳細情報ソースを設定する
AWS のコストと使用状況レポートおよび Cost Explorer の時間単位の粒度を設定し、コストと使用状況の詳細情報を提供します。ワークロードが、もたらされるすべてのビジネス成果のログエントリを持つように設定します。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
AWS Cost Explorerで時間単位の粒度を有効にし、 [AWS Cost and Usage Report (CUR)](https://aws.amazon.com/aws-cost-management/aws-cost-and-usage-reporting/)を作成します。これらのデータソースは、組織全体のコストと使用量の最も正確なビューを提供します。CUR では、課金されるすべての AWS のサービスについて、日単位または時間単位の使用量の粒度、料金、コスト、使用属性が提供されます。CUR には、タグ付け、場所、リソース属性、アカウント ID など想定可能なすべてのディメンションがあります。
以下のカスタマイズ項目で CUR を設定します。
+ リソース ID を含める
+ CUR を自動更新する
+ 時間単位の詳細
+ **バージョニング:** 既存のレポートを上書きする
+ **データ統合:** Amazon Athena (Parquet 形式、圧縮)
予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [AWS Glue](https://aws.amazon.com/glue/) を使用して分析用のデータを準備し、 [Amazon Athena](https://aws.amazon.com/athena/) を使用して、データ分析を実行し、SQL を使用してデータをクエリします。また、 [Amazon Quick](https://aws.amazon.com/quicksight/) を使用して、カスタムの可視化や複雑な可視化を行い、組織全体に配布することもできます。
**実装手順**
+ ** コストと使用状況レポートを設定する: **請求コンソールを使用して、少なくとも 1 つのコストと使用状況レポートを設定します。すべての識別子とリソース ID を含む時間単位の粒度でレポートを設定します。粒度が異なる他のレポートを作成して、概要情報を提供することもできます。
+ ** Cost Explorer で時間単位の粒度を設定する: **請求コンソールを使用して、[時間およびリソースレベルのデータ] を有効にします。
**注記**
この機能を有効にすると費用が発生します。詳細については、料金を参照してください。
+ **アプリケーションログ記録を設定する:** アプリケーションがもたらすビジネスの各成果がログに記録され、追跡および測定が可能であることを確認します。このデータの粒度が少なくとも 1 時間単位であることを確認し、コストと使用状況のデータと一致するようにします。ログ記録とモニタリングの詳細については、「 [Well-Architected 運用上の優秀性の柱](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html) 」を参照してください。
## リソース
**関連するドキュメント:**
+ [AWS アカウント設定](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_1_AWS_Account_Setup/README.html)
+ [AWS Cost and Usage Report (CUR)](https://aws.amazon.com/aws-cost-management/aws-cost-and-usage-reporting/)
+ [AWS Glue](https://aws.amazon.com/glue/)
+ [Amazon Quick](https://aws.amazon.com/quicksight/)
+ [AWS コスト管理の料金](https://aws.amazon.com/aws-cost-management/pricing/)
+ [AWS リソースのタグ付け](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)
+ [AWS Budgets を用いてコストを分析する](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html)
+ [Cost Explorer を用いてコストを分析する](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html)
+ [Managing AWS Cost and Usage Reports (AWS コストと使用状況レポートの管理)](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html)
+ [Well-Architected 運用上の優秀性の柱](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html)
**関連する例:**
+ [AWS アカウント設定](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_1_AWS_Account_Setup/README.html)
# COST03-BP02 コスト属性カテゴリを特定する
組織内でのコストの配分に使用可能な組織カテゴリを特定します。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
財務チームやその他の関係者と協力し、組織内でコストを配分する方法の要件を理解します。ワークロードのコストは、開発、テスト、本稼働、廃止などライフサイクル全体にわたって配分する必要があります。学習、スタッフ育成、アイデア創出に要したコストが、どのように組織に帰属するかを理解します。この目的で使用される金額を一般的な IT コスト予算ではなく、トレーニング予算や開発の予算に正しく割り当てるのに便利です。
**実装手順**
+ **組織カテゴリを定義する:** ステークホルダーとミーティングをして、組織の構造と要件を反映するカテゴリを定義します。これらは、ビジネス単位、予算、コストセンター、部門など、既存の財務カテゴリの構造に直接マッピングされます。トレーニングや教育など、クラウドがもたらすビジネスの成果を確認します。これらは組織のカテゴリでもあります。複数のカテゴリをリソースに割り当てることができます。また、リソースは複数の異なるカテゴリに存在することができるため、必要な数のカテゴリを定義します。
+ **機能カテゴリを定義する:** 利害関係者とミーティングをして、ビジネス内の機能を反映するカテゴリを定義します。これは、ワークロードまたはアプリケーション名、および実稼働、テスト、開発などの環境のタイプである場合があります。複数のカテゴリをリソースに割り当てることができます。また、リソースは複数の異なるカテゴリに存在することができるため、必要な数のカテゴリを定義します。
## リソース
**関連するドキュメント:**
+ [AWS リソースのタグ付け](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)
+ [AWS Budgets を用いてコストを分析する](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html)
+ [Cost Explorer を用いてコストを分析する](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html)
+ [Managing AWS Cost and Usage Reports (AWS コストと使用状況レポートの管理)](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html)
# COST03-BP03 組織のメトリクスを確立する
このワークロード用のメトリクスを組織内で定めます。ワークロードのメトリクスの例として、作成された顧客レポートや顧客に提供されるウェブページが挙げられます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
ワークロードのアウトプットがビジネスの成功に対してどのように測定されるかを理解します。通常、各ワークロードには、パフォーマンスを示す主な成果の小さな組み合わせがあります。多数のコンポーネントを含む高度なワークロードがある場合は、リストに優先順位を付けるか、各コンポーネントのメトリクスを定義して追跡できます。チームと協力して、どのメトリクスを使用するか理解します。この単位は、ワークロードの効率または各ビジネス成果のコストを把握するために使用されます。
**実装手順**
+ **ワークロードの成果を定義する: **ビジネスの利害関係者とミーティングをして、ワークロードの成果を定義します。これらは顧客の使用状況の主要な測定指標であり、技術的メトリクスではなく、ビジネスメトリクスである必要があります。ワークロードごとに少数の概要的なメトリクス (5 つ未満) が存在する必要があります。ワークロードが異なるユースケースで複数の成果を生成する場合は、それらを単一のメトリクスにグループ化してください。
+ **ワークロードコンポーネントの成果を定義する: **必要に応じて、大規模で複雑なワークロードがある場合、または明確に定義された入出力を使用してワークロードをコンポーネント (マイクロサービスなど) に簡単に分割できる場合は、各コンポーネントのメトリクスを定義します。この作業では、コンポーネントの価値とコストを反映する必要があります。最大のコンポーネントから開始し、大きさの順番で、最小のコンポーネントまで作業します。
## リソース
**関連するドキュメント:**
+ [AWS リソースのタグ付け](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)
+ [Analyzing your costs with AWS Budgets](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html)
+ [Cost Explorer によるコストの分析](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html)
+ [Managing AWS Cost and Usage Reports](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html)
# COST03-BP04 請求およびコスト管理ツールを設定する
AWS Cost Explorer と AWS Budgets を組織のポリシーに沿って設定します。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
使用量を変更してコストを調整するには、組織内の各ユーザーがそれぞれのコストと使用量の情報にアクセスできる必要があります。クラウドを使用する場合、すべてのワークロードとチームに次のツールを設定することを推奨します。
+ **レポート:** すべてのコストと使用情報を要約する。
+ **通知:** コストまたは使用量が設定された制限を超えた場合に通知する。
+ **現在の状態: **現在のコストと使用量を示すダッシュボードを設定する。ダッシュボードはオペレーションダッシュボードと同様に、作業環境内の目に付きやすい場所で使用できるようにする必要があります。
+ **傾向: **要求した期間におけるコストと使用量の変動を、必要な詳細度で示す。
+ **予測: **将来の推定コストを示す。
+ **追跡: **設定された目標またはターゲットに対する現在のコストと使用量を表示する。
+ **分析: **チームメンバーが、すべての可能なディメンションを使用して、時間単位の詳細度までカスタムおよび詳細な分析を実行する機能を提供する。
AWS のネイティブツール ( [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)、 [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/)、および [Amazon Athena](https://docs.aws.amazon.com/athena/?id=docs_gateway) と [Quick](https://docs.aws.amazon.com/quicksight/?id=docs_gateway) など) を使用して、この機能を提供できます。サードパーティー製のツールを使用することもできますが、このツールのコストが組織に価値をもたらすことを確認する必要があります。
**実装手順**
+ ** コスト最適化グループを作成する: **アカウントを設定し、必要なコストと使用状況レポートにアクセスできるグループを作成します。このグループには、アプリケーションを所有または管理するすべてのチームの代表者を含める必要があります。これにより、すべてのチームがコストと使用情報にアクセスできることが保証されます。
+ ** AWS Budgets を設定する:** ワークロードのすべてのアカウントで AWS Budgets を設定します。タグを使用して、アカウント全体の支出の予算とワークロードの予算を設定します。
+ ** AWS Cost Explorer を設定する: **ワークロードとアカウントで AWS Cost Explorer を設定します。全体的な支出を追跡するワークロードのダッシュボードと、ワークロードの主要な使用状況メトリクスを作成します。
+ ** 高度なツールを設定する: **必要に応じて、さらなる詳細と粒度を提供する組織用のカスタムツールを作成できます。高度な分析機能を実装するには [Amazon Athena](https://docs.aws.amazon.com/athena/?id=docs_gateway)を使用し、ダッシュボードを実装するには [Quick](https://docs.aws.amazon.com/quicksight/?id=docs_gateway)を使用します。
## リソース
**関連するドキュメント:**
+ [AWS リソースのタグ付け](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)
+ [AWS Budgets を用いてコストを分析する](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html)
+ [Cost Explorer を用いてコストを分析する](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html)
+ [Managing AWS Cost and Usage Reports (AWS コストと使用状況レポートの管理)](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html)
**関連する例:**
+ [Well-Architected ラボ - AWS アカウント設定](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_1_AWS_Account_Setup/README.html/)
+ [Well-Architected ラボ: 請求の可視化](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_5_Cost_Visualization/README.html)
+ [Well-Architected ラボ: コストと使用に関するガバナンス](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_2_Cost_and_Usage_Governance/README.html)
+ [Well-Architected ラボ: コストと使用状況の分析](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_4_Cost_and_Usage_Analysis/README.html)
+ [Well-Architected ラボ: コストと使用状況の可視化](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_5_Cost_Visualization/README.html)
# COST03-BP05 コストと使用状況に組織情報を追加する
組織、ワークロード属性、コスト配分カテゴリに基づいてタグ付けスキーマを定義します。すべてのリソースにタグを付けます。Cost Categories を使用して、組織の属性に従ってコストと使用状況をグループ化します。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
タグ付けを [AWS で実装し、](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) リソースに組織の情報を追加します。追加した情報は、コストと使用状況の情報に追加されます。タグはキーと値のペアです。キーは定義されており、組織全体で一意である必要があります。値はリソースのグループに対して一意です。キーと値のペアの一例としては、キーが Environment で、値は Production となります。本稼働環境のすべてのリソースには、キーと値のペアがあります。タグ付けにより、関連性の高い組織情報を使用して、コストを分類、追跡できます。組織のカテゴリ (コストセンター、アプリケーション名、プロジェクト、オーナーなど) を表すタグを適用し、ワークロードやワークロードの特性 (テストや本番など) を識別して、組織全体のコストと使用状況の帰属先を付与できます。
AWS リソース (Amazon Elastic Compute Cloud インスタンスや Amazon Simple Storage Service バケットなど) にタグを付け、そのタグをアクティブ化すると、AWS はこの情報をコストと使用状況レポートに追加します。タグ付けされたリソースとタグ付けされていないリソースに対してレポートを実行し、分析を実行することで、内部のコスト管理ポリシーへの準拠を強化し、正確な帰属を保証できます。
組織のアカウント全体に AWS タグ付け基準を作成、導入することで、AWS 環境を一貫性のある統一された方法で管理することができます。タグ使用のルールを定義するには、 [タグポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html) を AWS Organizations で使用します。このルールは、AWS Organizations のアカウントの AWS リソースに対してタグをどのように使用できるかを定めたものです。タグポリシーを使用すると、AWS リソースにタグを付ける標準アプローチを簡単に導入できます。
[AWS Tag Editor](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html) では、複数のリソースのタグを追加、削除、管理できます。
[AWS Cost Categories](https://aws.amazon.com/aws-cost-management/aws-cost-categories/) を使用すると、リソースにタグを付けることなく組織としての意味をコストに割り当てることができます。コストと使用量に関する情報を、一意の内部組織構造にマッピングできます。アカウントやタグなどの請求ディメンションを使用して、コストをマッピングおよび分類するカテゴリルールを定義します。これにより、タグ付けに加えて、別のレベルの管理機能が提供されます。また、特定のアカウントとタグを複数のプロジェクトにマッピングすることもできます。
**実装手順**
+ **タグ付けスキーマを定義する:** すべての利害関係者をビジネス全体から集めて、スキーマを定義します。これには通常、技術、財務、および管理ロールの担当者が含まれます。すべてのリソースに必要なタグのリストと、リソースに必要なタグのリストを定義します。タグの名前と値が組織全体で一貫していることを確認します。
+ ** リソースにタグを付ける: **定義したコスト帰属カテゴリを使用して、カテゴリに従ってワークロードのすべてのリソースにタグを付けます。CLI、Tag Editor、Systems Manager などのツールを使用して、効率を向上させます。
+ **Cost Categories を実装する: **タグ付けを実装せずに Cost Categories を作成できます。Cost Categories は既存のコストと使用状況ディメンションを使用します。スキーマからカテゴリルールを作成し、それを Cost Categories に実装します。
+ **タグ付けを自動化する:** すべてのリソースにわたってタグ付けの高いレベルを維持していることを確認するには、タグ付けを自動化して、リソースの作成時に自動的にタグ付けされるようにします。サービス内の機能、または AWS CloudFormation などのサービスを使用して、リソースの作成時にタグ付けされるようにします。ワークロードを定期的にスキャンし、タグ付けされていないリソースをすべて削除するカスタムマイクロサービスを作成することもできます。これは、テスト環境および開発環境に最適です。
+ ** タグ付けをモニタリングおよびレポートする: **組織全体でタグ付けの高いレベルを維持していることを確認するには、ワークロード全体でタグをレポートおよびモニタリングします。AWS Cost Explorer を使用して、タグ付けされたリソースとタグ付けされていないリソースのコストを表示したり、Tag Editor などのサービスを使用したりできます。タグ付けされていないリソースの数を定期的に確認し、必要なレベルのタグ付けになるまでタグを追加するアクションを実行します。
## リソース
**関連するドキュメント:**
+ [AWS CloudFormation Resource Tag](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-resource-tags.html)
+ [AWS Cost Categories](https://aws.amazon.com/aws-cost-management/aws-cost-categories/)
+ [AWS リソースのタグ付け](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)
+ [Amazon EC2 および Amazon EBS でリソース作成時のタグ付けのサポートを追加](https://aws.amazon.com/about-aws/whats-new/2017/03/amazon-ec2-and-amazon-ebs-add-support-for-tagging-resources-upon-creation-and-additonal-resource-level-permissions/)
+ [AWS Budgets を用いてコストを管理する](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html)
+ [Cost Explorer によるコストの分析](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html)
+ [Managing AWS Cost and Usage Reports](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html)
# COST03-BP06 ワークロードメトリクスに基づいてコストを配分する
メトリクスや業績に基づいてワークロードのコストを配分し、ワークロードのコスト効率を測定します。AWS のコストと使用状況レポートを分析するプロセスを実装します。これには、洞察力とチャージバック機能を提供する [Amazon Athena](https://docs.aws.amazon.com/athena/?id=docs_gateway)を使用します。
**このベストプラクティスが確立されていない場合のリスクレベル:** 低
## 実装のガイダンス
コスト最適化によって、最低価格でビジネス成果が提供されます。これは、ワークロードメトリクス (ワークロードの効率で測定) ごとにワークロードのコストを配分することによってのみ達成できます。定義されたワークロードメトリクスを、ログファイルまたは他のアプリケーションのモニタリングを使用してモニタリングします。このデータをワークロードのコストと組み合わせます。ワークロードのコストは、特定のタグ値またはアカウント ID でコストを確認することで取得できます。この分析は時間単位で実行することをお勧めします。リクエストレートが変化する静的なコストコンポーネント (24 時間年中無休で実行されるバックエンドデータベースなど) がある場合、通常、効率性は変化します (たとえば、使用量のピークは午前 9 時から午後 5 時で、夜間のリクエストはほとんどありません)。静的コストと変動コストの関係を理解しておくと、最適化のアクティビティに集中する一助となります。
**実装手順**
+ ** ワークロードメトリクスにコストを割り当てる: **定義されたメトリクスと設定されたタグ付けを使用して、ワークロードの結果とワークロードのコストを組み合わせたメトリクスを作成します。Amazon Athena や Quick などの分析サービスを使用して、ワークロード全体や任意のコンポーネントに対する効率性ダッシュボードを作成します。
## リソース
**関連するドキュメント:**
+ [AWS リソースのタグ付け](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)
+ [AWS Budgets を用いてコストを分析する](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html)
+ [Cost Explorer を用いてコストを分析する](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html)
+ [Managing AWS Cost and Usage Reports (AWS コストと使用状況レポートの管理)](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html)
# COST 4 不要なリソースはどのように削除すればよいですか？
プロジェクトの開始から終了まで変更管理とリソース管理を実装します。これにより、使用されていないリソースをシャットダウンまたは終了して、無駄を減らします。
**Topics**
+ [COST04-BP01 ライフタイム全体にわたってリソースを追跡する](cost_decomissioning_resources_track.md)
+ [COST04-BP02 削除プロセスを実装する](cost_decomissioning_resources_implement_process.md)
+ [COST04-BP03 リソースを削除する](cost_decomissioning_resources_decommission.md)
+ [COST04-BP04 自動的にリソースを削除する](cost_decomissioning_resources_decomm_automated.md)
# COST04-BP01 ライフタイム全体にわたってリソースを追跡する
ライフタイム全体にわたって、リソースや、リソースとシステムとの関係を追跡するメソッドを定義し、実装します。タグ付けにより、リソースのワークロードまたは機能を特定できます。
**このベストプラクティスが確立されていない場合のリスクレベル:** 高
## 実装のガイダンス
不要になったワークロードリソースを廃止します。一般的な例としては、テスト用途のリソースがあります。テストが完了したら、リソースは削除できます。タグでリソースを追跡する (およびそのタグのレポートを作成する) ことは、廃棄するアセットの特定に役立ちます。リソース追跡には、タグの使用が効果的な方法です。リソースにその機能か、または廃止可能になる既知の日付をラベリングできます。そうすると、これらのタグでレポートを作成できます。機能タグを付ける場合の一例として、 `feature-X testing` という値であれば、ワークロードのライフサイクルの観点からリソースの目的を識別できます。
**実装手順**
+ ** タグ付けスキームを実装する: **リソースが属するワークロードを識別するタグ付けスキームを実装し、ワークロード内のすべてのリソースが適切にタグ付けされることを確認します。
+ ** ワークロードのスループットまたは出力モニタリングを実装する: **ワークロードのスループットのモニタリングまたはアラームを実装し、入力リクエストまたは出力の完了時にトリガーします。ワークロードのリクエストまたは出力がゼロになり、ワークロードのリソースが使用されなくなったことを示す通知を提供するように設定します。ワークロードが通常の条件下で定期的にゼロに低下する場合は、時間要因を組み込みます。
## リソース
**関連するドキュメント:**
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/)
+ [AWS リソースのタグ付け](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)
+ [カスタムメトリクスの発行](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
# COST04-BP02 削除プロセスを実装する
孤立したリソースを特定して削除するためのプロセスを実装します。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
組織全体の標準化プロセスで、使用されていないリソースを特定して廃棄します。検索の実行頻度および組織のすべての要件を確実に満たすために、このプロセスではリソースを削除するプロセスを定義する必要があります。
**実装手順**
+ **削除プロセスを作成して実装する: **ワークロードの開発者や所有者と協力して、ワークロードとそのリソースの削除プロセスを構築します。このプロセスでは、ワークロードが使用中であるかどうか、および各ワークロードリソースが使用中であるかどうかを確認する方法を採り入れる必要があります。このプロセスでは、リソースを削除するために必要なステップを採り入れ、サービスから削除すると同時に、規制要件の遵守を確保する必要もあります。ライセンスやアタッチされたストレージなど、関連するリソースも対象となります。このプロセスでは、削除プロセスが実行されたことをワークロードの所有者に通知する必要があります。
## リソース
**関連するドキュメント:**
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/)
# COST04-BP03 リソースを削除する
定期監査や使用状況の変化などのイベントを契機として、リソースを削除します。通常、削除は定期的に行われ、手動または自動で行われます。
**このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム
## 実装のガイダンス
使用していないリソースを検索する場合は節減額の程度によって検索頻度と投入する労力を決定する必要があるため、コスト発生額の小さいアカウントの分析は、コスト発生額が高額のアカウントよりも頻度を下げるべきです。イベントの検索および廃止は、製品が寿命を迎えた場合や交換する場合など、ワークロードの状態の変化によってトリガーされます。イベントの検索および廃止は、市況の変化や製品終了などの外部イベントによってトリガーされる場合もあります。
**実装手順**
+ **リソースを削除する: **削除プロセスを使用して、孤立したと識別された各リソースを削除します。
## リソース
**関連するドキュメント:**
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/)
# COST04-BP04 自動的にリソースを削除する
重要度が低いリソース、不要なリソース、使用率が低いリソースを特定して削除する作業を適切に行えるようにワークロードを設計します。
**このベストプラクティスが確立されていない場合のリスクレベル:** 低
## 実装のガイダンス
オートメーションを使用して、廃棄プロセスの関連コストを削減または削除します。自動削除するようにワークロードを設計すると、そのライフタイム全体にわたるワークロードコストを削減できます。AWS リソースと設定の詳細なインベントリは、 [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) を使用して実行します。また、APIまたはSDKを使用して [カスタムコードを実装し、](https://aws.amazon.com/developer/tools/) ワークロードリソースを自動的に削除することもできます。
**実装手順**
+ ** AWS Auto Scaling を実装する: **サポートされているリソースについては、AWS Auto Scaling で設定します。
+ ** CloudWatch を設定して、インスタンスを終了させる:** インスタンスは、CloudWatch アラームを使用して終了するように設定できます。削除プロセスのメトリクスを使用して、Amazon Elastic Compute Cloud (Amazon EC2) アクションでアラームを実装します。ロールアウトする前に、非本番環境でオペレーションを検証します。
+ **ワークロード内にコードを実装する:** AWS SDK または AWS CLI を使用して、ワークロードリソースを削除できます。AWS と統合されるアプリケーション内にコードを実装し、使用されなくなったリソースを終了または削除します。
## リソース
**関連するドキュメント:**
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/)
+ [インスタンスを停止、終了、再起動、または復旧するアラームを作成する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/UsingAlarmActions.html)
+ [Getting Started With Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html)