# 経費支出と使用量の認識
**Topics**
+ [COST 2. どのように使用状況を管理するのですか?](cost-02.md)
+ [COST 3. コストと使用量はどのように監視すればよいでしょうか?](cost-03.md)
+ [COST 4. リソースはどのように廃止するのですか?](cost-04.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 組織の要件に基づいてポリシーを策定する
組織によるリソースの管理方法を定義するポリシーを策定し、定期的に検査します。ポリシーでは、リソースのライフタイム全体にわたる作成、変更、廃止を含む、リソースとワークロードのコスト面をカバーする必要があります。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
組織のコストおよびコスト要因を把握することは、コストと使用量を効果的に管理して、コスト削減の機会を特定するうえできわめて重要です。組織では一般に、複数のワークロードが複数のチームによってオペレーションされています。各チームはさまざまな組織単位に属する可能性があり、そのそれぞれに独自の収益の流れがあります。リソースのコストをワークロード、それぞれの組織、製品オーナーに帰属させることができると、リソースを効率的に使用し、無駄を削減できます。コストと使用量を正確にモニタリングすることで、ワークロードがどの程度最適化されているか、また組織単位や製品の収益性がどの程度であるかを理解するのに役立ちます。この知識により、組織内のどこにリソースを割り当てるかについて、より多くの情報に基づいた意思決定が可能になります。使用量が変化するとコストも変動するため、組織内のあらゆるレベルの使用量を認識することは、変化を促進する鍵となります。使用量と支出を認識するために、多面的なアプローチを取ることを検討してください。
ガバナンスを実行するための最初のステップは、組織の要件を使用して、クラウド使用に関するポリシーを策定することです。ポリシーでは、組織がクラウドをどのように使用するかや、リソースをどのように管理するかを定義します。ポリシーではコストや使用量に関係するリソースとワークロードのあらゆる局面、つまりリソースのライフタイム全体にわたる作成、変更、廃止をカバーする必要があります。クラウド環境でのあらゆる変更について、ポリシーと手順の遵守と実装を徹底してください。IT の変更管理会議では、質問を提起して、計画された変更によるコストへの影響 (増加または減少)、ビジネスの正当性、期待される結果を確認します。
ポリシーを簡単に理解し、組織全体で効果的に実装するには、シンプルなものにする必要があります。また、ポリシーは、(使用されるように) 遵守と解釈が容易で、(チーム間で誤解が生じないように) 具体的である必要があります。さらに、お客様のビジネス状況や優先順位が変わるとポリシーが古くなるため、(当社のメカニズムと同様に) 定期的に検査し、更新する必要があります。
使用する地理的リージョンやリソースを稼働する時間帯など、大局的な幅広いポリシーから始めます。続いてポリシーを徐々に絞り込み、さまざまな組織単位やワークロードに対応させます。一般的なポリシーの例としては、どのサービスと機能を利用できるか (例えば、テスト環境や開発環境では低パフォーマンスのストレージ)、どのタイプのリソースを各グループで使用できるか (例えば、開発用アカウントのリソースの最大サイズをミディアムにする)、これらのリソースをどの程度のスパンで使用するか (一時的、短期、特定の期間)、などがあります。
**ポリシーの例**
次に、コスト最適化に焦点を当てた独自のクラウドガバナンスポリシーを作成するために確認できるポリシーの例を示します。組織の要件と関係者の要求に基づいてポリシーを調整してください。
+ **ポリシー名:** リソースの最適化やコスト削減ポリシーなど、明確なポリシー名を定義します。
+ **目的:** このポリシーを使用すべき理由と、期待される成果について説明します。このポリシーの目的は、ビジネス要件を満たすために必要なワークロードのデプロイと実行に、必要な最小限のコストがあると確認することです。
+ **範囲:** このポリシーを誰が使用すべきか、いつ使用すべきかを明確に定義します。例えば、DevOps X Team が X 環境 (本番環境または非本番環境) で us-east のお客様にこのポリシーを使用する、などです。
**ポリシーステートメント**
1. ワークロードの環境とビジネス要件 (開発、ユーザー受け入れテスト、本番稼働前、または本番稼働) に基づいて、us-east-1 または複数の us-east リージョンを選択します。
1. Amazon EC2 と Amazon RDS インスタンスが、午前 6 時から夜 8 時 (東部標準時 (EST)) に実行されるようにスケジュールを立てます。
1. 8 時間後に未使用の Amazon EC2 インスタンスをすべて停止し、24 時間非アクティブ状態の未使用の Amazon RDS インスタンスをすべて停止します。
1. 非本番環境で非アクティブ状態が 24 時間続いたら、未使用の Amazon EC2 インスタンスをすべて終了します。Amazon EC2 インスタンス所有者に (タグに基づいて) 本番環境で停止した Amazon EC2 インスタンスを確認するように促し、使用していない場合は Amazon EC2 インスタンスが 72 時間以内に終了することを通知します。
1. m5.large などの汎用インスタンスファミリーとサイズを使用し、AWS Compute Optimizer を使用して CPU とメモリの使用率に基づいてインスタンスのサイズを変更します。
1. 自動スケーリングの使用を優先し、トラフィックに基づいて実行中のインスタンスの数を動的に調整します。
1. 重要ではないワークロードにはスポットインスタンスを使用します。
1. キャパシティ要件を確認し、予測可能なワークロードに備えて削減プランやリザーブドインスタンスをコミットして、クラウド財務管理チームに通知します。
1. Amazon S3 ライフサイクルポリシーを使用して、アクセス頻度の低いデータを安価なストレージ階層に移動します。保存ポリシーが定義されていない場合は、Amazon S3 Intelligent-Tiering を使用してオブジェクトをアーカイブ階層に自動的に移動します。
1. Amazon CloudWatch を使用して、リソースの使用状況をモニタリングし、スケーリングイベントをトリガーするアラームを設定します。
1. それぞれの AWS アカウントについて、AWS Budgets を使用して、コストセンターとビジネスユニットに基づいてアカウントのコストと使用量の予算を設定します。
1. AWS Budgets を使用してアカウントのコストと使用量の予算を設定すると、支出を常に把握し、予期しない請求を回避できるため、コストをより適切に制御できます。
**手順:** このポリシーを実装するための詳細な手順を提供するか、各ポリシーステートメントの実装方法を説明する他のドキュメントを参照してください。このセクションでは、ポリシー要件を実行するためのステップバイステップの手順を説明する必要があります。
このポリシーを実装するために、さまざまなサードパーティー製ツールや AWS Config ルールを使用してポリシーステートメントの遵守を確認したり、AWS Lambda 関数を使用して自動修復アクションをトリガーしたりできます。AWS Organizations を使用してポリシーを適用することもできます。さらに、リソースの使用状況を定期的に見直し、必要に応じてポリシーを調整して、ビジネスニーズが引き続き満たされていることを確認する必要があります。
## 実装手順
+ **関係者とのミーティングを設ける:** ポリシーを策定するには、組織内の関係者 (クラウドビジネスオフィス、エンジニア、またはポリシー実施部門の意思決定者) に、要件を明記して文書化するよう依頼します。幅広く開始し、各ステップで最小単位まで継続的に絞り込んでいくという反復型アプローチを採用します。チームメンバーには、組織単位やアプリケーションの所有者など、ワークロードの直接の関係者に加えて、セキュリティチームや財務チームなどのサポートグループを含めます。
+ **確認する:** 誰が AWS クラウドにアクセスしてデプロイできるかを指定したポリシーに、チームが同意していることを確認します。チームが組織のポリシーに従っているかどうか、同意したポリシーと手順に沿ってチームがリソースを作成しているかどうかを確認します。
+ **オンボーディングトレーニングセッションを作成する:** 新しい組織メンバーに対し、コスト意識を定着させ、組織の要件を特定するために、オンボーディングトレーニングコースを完了するよう求めます。新しいメンバーは、以前の経験から異なるポリシーを想定している場合や、ポリシーについてまったく考えていない場合があります。
+ **ワークロードの場所を定義する: **ワークロードの運用場所 (国や国内のエリアなど) を定義します。この情報は、AWS リージョンとアベイラビリティーゾーンへのマッピングに使用されます。
+ **サービスとリソースを定義してグループ化する: **ワークロードに必要なサービスを定義します。サービスごとに、タイプ、サイズ、必要なリソースの数を指定します。アプリケーションサーバーやデータベースストレージなどの機能別にリソースのグループを定義します。リソースは複数のグループに属することができます。
+ **機能別にユーザーを定義およびグループ化する:** ワークロードに関係するユーザーについて、当該ユーザーが誰かまたは組織内での地位に焦点を当てるのではなく、何を行うか、またはどのようにワークロードを使用するかに焦点を当てて定義します。類似するユーザーまたは機能をグループ化します。AWS 管理ポリシーをガイドとして使用できます。
+ **アクションを定義する:** 特定済みの場所、リソース、およびユーザーを使用して、ワークロードのライフタイム (開発、運用、廃止) にわたって成果を得るために、それぞれが必要とするアクションを定義します。各場所で、グループ内の個々の要素ではなく、グループに基づいてアクションを特定します。開始時には読み取りまたは書き込みを幅広く設定し、それぞれのサービスについて、特定のアクションへと絞り込んでいきます。
+ **レビュー期間を定義する:** ワークロードと組織の要件は時間の経過とともに変化する可能性があります。ワークロードのレビュースケジュールを定義して、組織の優先順位に合わせた状態を維持します。
+ **ポリシーを文書化する: **定義されたポリシーが、必要に応じて組織でアクセス可能であることを確認します。これらのポリシーは、環境へのアクセスを実装、保守、監査するために使用されます。
## リソース
**関連ドキュメント:**
+ [クラウドにおける変更管理](https://docs.aws.amazon.com/whitepapers/latest/change-management-in-the-cloud/change-management-in-cloud.html)
+ [ジョブ機能の 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/)
+ [AWS のサービスのアクション、リソース、および条件キー](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_actions-resources-contextkeys.html)
+ [AWS 管理とガバナンス](https://aws.amazon.com/products/management-and-governance/)
+ [IAM ポリシーを使用して AWS リージョンへのアクセスを制御する](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/)
**関連動画:**
+ [AWS での大規模な管理とガバナンス](https://www.youtube.com/watch?v=xdJSUnPcPPI)
# COST02-BP02 目標およびターゲットを策定する
ワークロードのコストおよび使用量の両方について、目標およびターゲットを策定します。目標は、期待される成果に基づく方向性を組織に示し、ターゲットは、ワークロードについて具体的に達成すべき測定可能な成果を示します。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
組織のコスト、目標使用量、ターゲットを設定します。AWS で成長を続ける組織にとって、コスト最適化の目標を設定して追跡することは重要です。これらの目標や[主要業績評価指標 (KPI)](https://aws.amazon.com/blogs/aws-cloud-financial-management/unit-metric-the-touchstone-of-your-it-planning-and-evaluation/) には、オンデマンドでの支出の割合や、AWS Graviton インスタンスまたは gp3 EBS ボリュームタイプなどの特定の最適化されたサービスの導入などが含まれます。事業運営において重要な効率向上を測定できる測定可能で達成可能な目標を設定します。目標は、組織に期待される成果に関するガイダンスと方向性をもたらします。
ターゲットは、具体的かつ測定可能な達成すべき成果をもたらします。つまり、目標は進みたい方向を示し、ターゲットはその方向へどこまで進み、その目標をいつ達成する必要があるかを表します。このとき、「SMART」、つまり具体的 (specific)、測定可能 (measurable)、割り当て可能 (assignable)、現実的 (realistic)、タイムリー (timely) であることをガイダンスとします。「プラットフォームの使用量を大幅に増加させ、コストは微増 (非線形) にとどまるようにする」などは目標の例です。「プラットフォームの使用量を 20% 増加させ、コスト増は 5% 未満に抑える」などはターゲットの例です。ワークロードを 6 か月ごとに効率化する必要があるというケースも、目標としてはよくあります。付随する目標は、ビジネスあたりのコストメトリクスを 6 か月ごとに 5% 削減する必要があるというものです。適切なメトリクスを使用し、組織に合わせて計算された KPI を設定してください。基本的な KPI から始めて、後でビジネスニーズに応じて発展させていくことができます。
コスト最適化の目標は、ワークロードの効率を高めることです。つまり、ワークロードのビジネス成果あたりのコストを経時的に削減することです。すべてのワークロードにこの目標を設定するのと併せて、6 か月～1 年ごとに効率を 5% 高めるなどのターゲットを設定します。クラウドの場合、これは、コスト最適化能力の構築と、新しいサービスや機能のリリースによって達成できます。
ターゲットは、目標達成のために到達を目指す数値化可能なベンチマークであり、このベンチマークによって実際の結果をターゲットと比較します。コンピューティングサービス (スポット導入、Graviton 導入、最新のインスタンスタイプ、オンデマンドカバレッジなど)、ストレージサービス (EBS GP3 導入、古い EBS スナップショット、Amazon S3 Standard ストレージなど)、またはデータベースサービスの使用量 (RDS オープンソースエンジン、Graviton 導入、オンデマンドカバレッジなど) のユニットあたりのコストについて、KPI を使用してベンチマークを設定します。これらのベンチマークと KPI により、最も費用対効果の高い方法で AWS のサービスを利用していることを確認することができます。
次の表は、参照用の標準の AWS メトリクスの一覧です。これらの KPI の目標値は、組織によって異なります。
| カテゴリ | KPI (%) | 説明 |
| --- | --- | --- |
| コンピューティング | EC2 使用量カバレッジ | SP \$1 RI \$1 スポットを使用した EC2 インスタンス (コストまたは時間単位) と EC2 インスタンスの合計 (コストまたは時間単位) の比較 |
| コンピューティング | コンピューティング SP/RI 使用率 | 利用可能な SP または RI 時間の合計に対する SP または RI の使用時間 |
| コンピューティング | EC2/時間コスト | EC2 コストをその時間に実行されている EC2 インスタンスの数で割った値 |
| コンピューティング | vCPU コスト | すべてのインスタンスの vCPU あたりのコスト |
| コンピューティング | 最新のインスタンス生成 | Graviton (またはその他の最新世代のインスタンスタイプ) のインスタンスの割合 |
| データベース | RDS カバレッジ | RI を使用した RDS インスタンス (コストまたは時間単位) と RDS インスタンスの合計 (コストまたは時間単位) の比較 |
| データベース | RDS 使用率 | 利用可能な RI 時間の合計に対する使用された RI 時間 |
| データベース | RDS の稼働時間 | RDS コストをその時間に実行されている RDS インスタンスの数で割った値 |
| データベース | 最新のインスタンス生成 | Graviton (またはその他の最新インスタンスタイプ) のインスタンスの割合 |
| [Storage (ストレージ)] | ストレージの使用率 | 最適化ストレージコスト (Glacier、ディープアーカイブ、低頻度アクセスなど) を合計ストレージコストで割ったもの |
| Tagging | タグ付けされていないリソース | Cost Explorer: 1. クレジット、割引、税金、返金、マーケットプレイスを除外し、最新の月額コストをコピーします。 2. Cost Explorer で **[タグ付けされていないリソースのみ表示]** を選択します。 3. **タグ付けされていないリソース**の額を月額コストで割ります。 |
この表を使用して、組織の目標に基づいて算出した目標値またはベンチマーク値を含めます。正確かつ現実的な KPI を定義するには、ビジネスの特定のメトリクスを測定し、そのワークロードのビジネス成果を理解する必要があります。組織内のパフォーマンスメトリクスを評価する場合は、個別の目的を果たすさまざまな種類のメトリクスを識別します。これらのメトリクスは、ビジネス全体への影響を直接測定するものではなく、技術的なインフラストラクチャのパフォーマンスと効率を主に測定するものです。例えば、サーバーの応答時間、ネットワークレイテンシー、システムの稼働時間などを追跡します。これらのメトリクスは、インフラストラクチャが組織の技術面での運用をどの程度サポートしているかを評価するうえで非常に重要です。ただし、顧客満足度、収益増加、市場シェアなど、より広範なビジネス目標に関する直接的なインサイトは得られません。ビジネスパフォーマンスを包括的に理解するには、ビジネスの成果と直接相関する戦略的なビジネスメトリクスを、これらの効率性メトリクスの補完として使用します。
KPI と関連するコスト削減の機会をほぼリアルタイムで把握し、経時的に進捗状況を追跡します。KPI 目標の定義と追跡を始める際は、[クラウドインテリジェンスダッシュボード](https://wellarchitectedlabs.com/cloud-intelligence-dashboards/) (CID) の KPI ダッシュボードをお勧めします。KPI ダッシュボードには、コストと使用状況レポート (CUR) から取得したデータに基づいた一連の推奨コスト最適化 KPI が表示され、カスタム目標の設定や経時的な進捗状況の追跡ができます。
KPI 目標を設定して追跡する別のソリューションがある場合は、そのソリューションが組織内のすべてのクラウド財務管理のステークホルダーによって採用されていることを確認してください。
### 実装手順
+ **予想される使用レベルを定義する:** まず、使用レベルに焦点を当てます。アプリケーションの所有者、マーケティング、およびより広範のビジネスチームと協力して、ワークロードに対して予想される使用レベルを把握します。顧客の需要が経時的にどのように変化するか、季節的な要因による増加やマーケティングキャンペーンによって何が変化する可能性があるかなどを考慮します。
+ **ワークロードのリソースとコストを定義する:** 使用レベルを定義したうえで、これらの使用レベルを満たすために必要なワークロードリソースの変化を数値化します。ワークロードコンポーネントのサイズまたはリソースの数を増やすこと、データ転送を増やすこと、または特定のレベルでワークロードコンポーネントを別のサービスに変更することが必要な場合があります。こうした主要ポイントごとにコストを特定し、使用量の変化に伴うコストの変化を予測します。
+ **ビジネス目標を定義する:** 予想される使用量とコストの変化から結果を取得し、これを、予想されるテクノロジーや実行中のプログラムの変化と組み合わせて、ワークロードの目標を策定します。目標は、使用量とコスト、および使用量とコストの関係を考慮したものにする必要があります。目標はシンプルかつ大局的なものにして、そのビジネスで求められる成果を従業員が理解できるような内容にする必要があります (未使用のリソースを一定のコストレベル以下に抑えるなど)。未使用リソースのタイプごとに目標を定義したり、目標とターゲットでの損失原因となりうるコストを具体的に定義したりする必要はありません。使用量に変化がない状態でコストの変化が予想される場合は、組織的なプログラム (トレーニングや教育による能力向上など) を用意しておきます。
+ **ターゲットを定義する:** 定義された目標ごとに、測定可能なターゲットを指定します。ワークロードの効率改善が目標である場合、ターゲットでは、改善の量 (通常は 1 USD あたりのビジネス成果) と、その改善をいつ達成すべきかを数値化します。例えば、過剰プロビジョニングによる無駄を最小限に抑えるという目標を設定したとします。この場合、ターゲットとしては、実稼働ワークロードの最初の階層でコンピューティングの過剰プロビジョニングによる無駄を階層コンピューティングコストの 10% 以下に抑える、さらに 2 つ目のターゲットとして、実稼働ワークロードの 2 つ目の階層でコンピューティングの過剰プロビジョニングによる無駄を階層コンピューティングコストの 5% 以下に抑える、といったような内容が考えられます。
## リソース
**関連ドキュメント:**
+ [ジョブ機能の 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/)
+ [IAM ポリシーを使用して AWS リージョンへのアクセスを制御する](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/)
+ [S.M.A.R.T. 目標](https://en.wikipedia.org/wiki/SMART_criteria)
+ [CID KPI ダッシュボードでコスト最適化 KPI を追跡する方法](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-to-track-your-cost-optimization-kpis-with-the-kpi-dashboard/)
**関連動画:**
+ [Well-Architected ラボ: 目標とターゲット (レベル 100)](https://catalog.workshops.aws/well-architected-cost-optimization/en-US/2-expenditure-and-usage-awareness/150-goals-and-targets)
**関連する例:**
+ [単位メトリクスとは](https://aws.amazon.com/blogs/aws-cloud-financial-management/what-is-a-unit-metric/)
+ [ビジネスをサポートする単位メトリクスの選択](https://aws.amazon.com/blogs/aws-cost-management/selecting-a-unit-metric-to-support-your-business/)
+ [実際の単位メトリクス: 得た教訓](https://aws.amazon.com/blogs/aws-cost-management/unit-metrics-in-practice-lessons-learned/)
+ [単位メトリクスがビジネス機能間の調整にどのように役立つか](https://aws.amazon.com/blogs/aws-cost-management/unit-metrics-help-create-alignment-between-business-functions/)
# COST02-BP03 アカウント構造を実装する
組織にマッピングされるアカウントの構造を実装します。これは、組織全体でのコストの割り当てと管理に役立ちます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
AWS Organizations では、ワークロードを AWS でスケールする際に環境を一元管理するのに役立つ、複数の AWS アカウントを作成できます。組織単位 (OU) 構造で AWS アカウントをグループ化し、各 OU の下に複数の AWS アカウントを作成することで、組織階層をモデル化できます。アカウント構造を作成するには、まず、どの AWS アカウントを管理アカウントにするかを決定する必要があります。その後、「[管理アカウントに関するベストプラクティス](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices_mgmt-acct.html)」と「[メンバーアカウントのベストプラクティス](https://docs.aws.amazon.com/organizations/latest/userguide/best-practices_member-acct.html)」に従って、設計したアカウント構造に基づき、メンバーアカウントとして新しい AWS アカウントを作成したり、既存のアカウントを選択したりできます。
組織の規模や使用状況にかかわらず、少なくとも 1 つの管理アカウントとそれに紐づく 1 つのメンバーアカウントを常に持つことをお勧めします。すべてのワークロードリソースはメンバーアカウント内にのみ存在する必要があります。管理アカウントにはリソースを作成しないでください。AWS アカウントをいくつ持つべきかについて、一律の答えはありません。現在と将来の運用モデルとコストモデルを評価し、AWS アカウントの構造が組織の目標を反映するようにします。ビジネス上の理由から複数の AWS アカウントを作成する企業もあります。次に例を示します。
+ 組織単位、コストセンター、特定のワークロード間で、管理、会計、請求の職務機能を切り離す必要がある場合。
+ AWS のサービスの制限が特定のワークロードのみに設定される場合。
+ ワークロードとリソース間の隔離と分離には要件があります。
[AWS Organizations](https://aws.amazon.com/organizations/) 内では、[一括請求](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html)により、1 つ以上のメンバーアカウントと管理アカウントとの間に構造が作成されます。メンバーアカウントを使用すると、コストと使用量をグループ別に分離し、区別できます。一般的には、各組織単位 (財務、マーケティング、営業など)、各環境ライフサイクル (開発、テスト、本番など)、各ワークロード (ワークロード a、b、c) にメンバーアカウントをいったん分離したうえで、一括請求を使用してこれらの連結アカウントを集約します。
一括請求機能により、複数のメンバー AWS アカウントの支払いを単一の管理アカウントにまとめつつ、リンクされた各アカウントのアクティビティを可視化することができます。コストと使用量が管理アカウントに集計されると、サービスの従量制割引とコミットメント割引 (Savings Plans とリザーブドインスタンス) を最大限に活用し、割引額を最大化できます。
次の図は、AWS Organizations を組織単位 (OU) で使用して複数のアカウントをグループ化し、各 OU の下に複数の AWS アカウントを配置する方法を示しています。アカウントを整理するためのパターンを提供するために、さまざまなユースケースやワークロードに OU を使用することをお勧めします。
![\[複数のアカウントを組織単位にグループ化する方法を示すツリー図。\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/images/aws-organizations-ou-grouping.png)
[AWS Control Tower](https://aws.amazon.com/controltower/) では、複数の AWS アカウントのセットアップと構成をすばやく行い、ガバナンスが組織の要件に適合していることを確認できます。
**実装手順**
+ **分離要件を定義する: **分離の要件は、セキュリティ、信頼性、財務構造など、複数の要因の組み合わせです。各要因を順番に確認し、ワークロードまたはワークロード環境を他のワークロードから分離するかどうかを指定します。セキュリティは、アクセス要件とデータ要件への準拠を促進します。信頼性は、環境やワークロードが他の環境に影響を与えないように制限を管理します。Well-Architected フレームワークのセキュリティと信頼性の柱を定期的に見直し、提供されるベストプラクティスに従います。財務構造により、厳格な財務分離 (異なるコストセンター、ワークロードのオーナーシップ、説明責任) が実現します。分離の一般的な例としては、実稼働ワークロードとテストワークロードを別々のアカウントで実行することや、組織内の個々の事業部門や部署、またはアカウントを所有する関係者に請求書と請求データを提供できるように別のアカウントを使用することなどが挙げられます。
+ **グループ化要件を定義する:** グループ化要件は分離要件を上書きしませんが、管理を支援するために使用されます。分離を必要としない同様の環境またはワークロードをグループ化します。例として、1 つ以上のワークロードから複数のテスト環境または開発環境をグループ化することが挙げられます。
+ **アカウント構造を定義する:** これらの分離およびグループ化を使用して、各グループのアカウントを指定し、分離要件が維持されるようにします。これらのアカウントは、メンバーアカウントまたは連結アカウントです。これらのメンバーアカウントを単一の管理アカウントまたは支払者アカウントでグループ化することで使用量が合算されるため、すべてのアカウントでの従量制割引がより大きくなり、すべてのアカウントに対して単一の請求書が発行されます。請求データを分離し、各メンバーアカウントに請求データの個別のビューを表示することができます。メンバーアカウントが使用量や請求データを他のアカウントに表示してはならない場合、または AWS から別々の請求書を必要とする場合は、複数の管理アカウントまたは支払者アカウントを定義します。この場合、各メンバーアカウントは独自の管理アカウントまたは支払者アカウントを持つことになります。リソースは常にメンバーアカウントまたは連結アカウントに配置する必要があります。管理アカウントまたは支払者アカウントは、管理のためにのみ使用してください。
## リソース
**関連ドキュメント:**
+ [コスト配分タグの使用](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html)
+ [ジョブ機能の 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/)
+ [IAM ポリシーを使用して AWS リージョンへのアクセスを制御する](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/organizations/latest/userguide/orgs_best-practices_mgmt-acct.html)と[メンバーアカウント](https://docs.aws.amazon.com/organizations/latest/userguide/best-practices_member-acct.html)のベストプラクティス
+ [複数のアカウントで AWS 環境を構成する](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)
+ [共有リザーブドインスタンスと Savings Plans の割引の有効化](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-turn-on-process.html)
+ [一括請求](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html)
+ [一括請求](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)
**関連動画:**
+ [AWS Organizations のご紹介](https://www.youtube.com/watch?v=T4NK8fv8YdI)
+ [AWS Organizations のベストプラクティスを使用するマルチアカウント AWS 環境を設定する](https://www.youtube.com/watch?v=uOrq8ZUuaAQ)
**関連する例:**
+ [通信会社の AWS マルチアカウント戦略の定義](https://aws.amazon.com/blogs/industries/defining-an-aws-multi-account-strategy-for-telecommunications-companies/)
+ [AWS アカウントを最適化するためのベストプラクティス](https://aws.amazon.com/blogs/architecture/new-whitepaper-provides-best-practices-for-optimizing-aws-accounts/)
+ [AWS Organizations での組織単位のベストプラクティス](https://aws.amazon.com/blogs/mt/best-practices-for-organizational-units-with-aws-organizations/?org_product_gs_bp_OUBlog)
# COST02-BP04 グループとロールを実装する
ポリシーに沿ったグループおよびロールを実装し、各グループのインスタンスおよびリソースを作成、変更、廃止できるユーザーを管理します。例えば、開発、テスト、本番グループを実装します。これは、AWS のサービスやサードパーティーのソリューションに適用されます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
ユーザーのロールとグループは、安全で効率的なシステムを設計および実装するうえで基本となる構成要素です。ロールとグループは、組織が統制の必要性と柔軟性や生産性の要件とのバランスを図るうえで役立ち、最終的には組織の目標とユーザーのニーズの実現を助けます。AWS Well-Architected フレームワークの「セキュリティの柱」の「[ID とアクセス管理](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/identity-and-access-management.html)」セクションで推奨されているように、適切な条件下で適切なリソースへのアクセスを提供するために、堅牢な ID 管理とアクセス許可が必要です。ユーザーには、それぞれの業務を完遂するために必要なアクセス権のみを与えます。そうすることで、不正アクセスや誤用に伴うリスクが最小限に抑えられます。
ポリシーを作成した後で、組織内の論理グループとユーザーロールを作成できます。アクセス許可を割り当て、使用量を制御できるようになり、強固なアクセス制御メカニズムの実装を助け、機密情報への不正アクセスも防止できます。人材のおおまかなグループ化から始めます。通常これは、組織単位と役職 (IT 部門のシステム管理者、会計監査担当者、ビジネスアナリストなど) と合致します。グループによって、類似したタスクに従事し、類似したアクセス権を必要とするユーザーを分類します。ロールとは、グループとして義務付けられた仕事の定義を指します。個々のユーザー単位ではなく、グループやロール単位でアクセス許可を管理する方が簡単です。ロールとグループを通じてユーザー全員に一貫して体系的にアクセス許可を割り当てることで、ミスや不整合を防ぐことができます。
ユーザーのロールが変更された場合、管理者は個々のユーザーアカウントを設定し直さなくても、ロールまたはグループのレベルでアクセス権を調整できます。例えば、IT のシステム管理者はすべてのリソースを作成するためのアクセスが必要ですが、分析チームのメンバーは分析リソースを作成するアクセスのみで十分です。
### 実装手順
+ **グループを実装する:** 必要に応じて、組織のポリシーで定義されているユーザーのグループを使用して、対応するグループを実装します。ユーザー、グループ、認証のベストプラクティスについては、AWS Well-Architected フレームワークの「[セキュリティの柱](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html)」を参照してください。
+ **ロールとポリシーを実装する:** 組織のポリシーで定義されているアクションを使用して、必要なロールとアクセスポリシーを作成します。ロールとポリシーのベストプラクティスについては、AWS Well-Architected フレームワークの「[セキュリティの柱](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html)」を参照してください。
## リソース
**関連ドキュメント:**
+ [ジョブ機能の 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/)
+ [セキュリティの柱 - AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html)
+ [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/)
+ [AWS Identity and Access Management ポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html)
**関連動画:**
+ [アイデンティティ管理とアクセス管理を使用する理由](https://www.youtube.com/watch?v=SXSqhTn2DuE)
**関連する例:**
+ [IAM ポリシーを使用して AWS リージョンへのアクセスを制御する](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/)
+ [クラウド財務管理ジャーニーの開始: クラウドコストオペレーション](https://aws.amazon.com/blogs/aws-cloud-financial-management/op-starting-your-cloud-financial-management-journey/)
# COST02-BP05 コストコントロールを実装する
組織のポリシーと定義済みのグループおよびロールに基づいてコントロールを実装します。これらは、リージョンやリソースタイプへのアクセスコントロールなど、組織の要件によって定義されたコストのみが発生することを保証するものです。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
コスト管理を導入する際の一般的な最初のステップは、ポリシー外のコストまたは使用状況イベントが発生した場合に通知するように設定することです。ワークロードや新しいアクティビティを制限したり悪影響を与えたりすることなく、迅速に行動し、是正措置の必要性の有無を確認できます。ワークロードと環境の制限を理解したら、ガバナンスを適用できます。[AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) では、AWS コスト、使用量、コミットメント割引 (Savings Plans とリザーブドインスタンス) の通知を設定し、月額予算を定義できます。予算は、集計コストのレベル (例えば、全コスト)、またはリンクアカウント、サービス、タグ、アベイラビリティーゾーンなどの特定のディメンションのみを含む詳細レベルで作成できます。
AWS Budgets で予算制限を設定したら、[AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) を使用して予期しないコストを削減します。AWS Cost Anomaly Detection は、機械学習を使用してコストと使用状況を継続的にモニタリングし、異常な支出を検出するコスト管理サービスです。これにより、異常な支出と根本原因を特定するため、迅速に対策を講じることができます。まず、AWS Cost Anomaly Detection でコストモニタを作成し、ドルのしきい値 (影響が 1,000 USD を超える異常に対してアラートを出すなど) を設定し、アラートの設定を選択します。アラートを受信したら、異常の背後にある根本原因とコストへの影響を分析できます。また、AWS Cost Explorer では独自の異常解析を監視および実行することもできます。
[AWS Identity and Access Management](https://aws.amazon.com/iam/) および [AWS Organizations サービスコントロールポリシー (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scp.html) を使用して AWS にガバナンスポリシーを適用します。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)を参照してください。
[AWS Service Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) を管理することで、ガバナンスを導入することもできます。Service Quotas を最小限のオーバーヘッドで設定し、正確に維持することで、組織の要件以外のリソースの作成を最小限に抑えることができます。これを実現するには、要件がどれだけ速く変化するかを理解し、進行中のプロジェクト (リソースの作成と廃止の両方) を理解し、クォータ変更をどれだけすばやく実装できるかを考慮する必要があります。[Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) を使用して、必要に応じてクォータを増加させることができます。
**実装手順**
+ **支出に関する通知を実装する:** 定義した組織のポリシーを使用して、[AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) を作成し、支出がポリシーを外れた場合に通知を提供するようにします。アカウントごとに複数のコスト予算を設定し、アカウント全体の支出を通知します。アカウント内のより小さな単位について、各アカウント内にコスト予算を追加で設定します。これらの単位は、アカウント構造によって異なります。一般的な例としては、AWS リージョン、ワークロード (タグを使用)、または AWS のサービスがあります。個人の E メールアカウントではなく、E メール配信リストを通知の受信者として設定します。金額を超えたときの実際の予算を設定するか、予測された使用量が通知されたときの予測された予算を使用します。特定の IAM または SCP のポリシーを適用したり、ターゲットの Amazon EC2 または Amazon RDS インスタンスを停止したりできる AWS Budget アクションを事前設定することもできます。予算に関するアクションは、自動的に開始するか、ワークフローの承認を得るようにすることができます。
+ **異常な支出に関する通知を実装する:** [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) を使用して、組織内の予想外のコストを削減し、異常とみられる支出の根本原因を分析します。指定した粒度で異常な支出を特定するコストモニタを作成し、AWS Cost Anomaly Detection で通知を設定すると、異常な支出が検出された際にアラートが送信されます。これにより、異常の背後にある根本的な原因を分析し、コストへの影響を理解できます。AWS Cost Anomaly Detection を設定する際に AWS Cost Categories を使用して、予想外のコストの根本原因を分析し、必要なアクションをタイムリーに実行できるプロジェクトチームまたはビジネスユニットチームを特定します。
+ **使用量のコントロールを実装する:** 定義した組織のポリシーを使用して、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/)
+ [IAM ポリシーを使用して AWS リージョンへのアクセスを制御する](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/)
+ [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/)
+ [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/)
+ [AWS コストを管理する](https://aws.amazon.com/getting-started/hands-on/control-your-costs-free-tier-budgets/)
**関連動画:**
+ [AWS Budgets を使用して支出と使用量を追跡するにはどうすればよいですか?](https://www.youtube.com/watch?v=Ris23gKc7s0)
**関連する例:**
+ [IAM アクセス管理ポリシーの例](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_examples.html)
+ [サービスコントロールポリシーの例](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html)
+ [AWS 予算アクション](https://aws.amazon.com/blogs/aws-cloud-financial-management/get-started-with-aws-budgets-actions/)
+ [タグを使用して Amazon EC2 リソースへのアクセスを制御する IAM ポリシーを作成する方法を教えてください。](https://aws.amazon.com/premiumsupport/knowledge-center/iam-ec2-resource-tags/)
+ [IAM アイデンティティのアクセスを特定の Amazon EC2 リソースに制限することはできますか?](https://aws.amazon.com/premiumsupport/knowledge-center/restrict-ec2-iam/)
+ [Slack でのコスト異常検出のための Amazon Q Developer in chat applications との統合](https://aws.amazon.com/aws-cost-management/resources/slack-integrations-for-aws-cost-anomaly-detection-using-aws-chatbot/)
# COST02-BP06 プロジェクトのライフサイクルを追跡する
プロジェクト、チーム、環境のライフサイクルを追跡、計測、監査して、不要なリソースの使用やそれに伴う支払いを回避できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
プロジェクトのライフサイクルを効果的に追跡することで、組織は計画、管理、リソースの最適化を改善し、コスト管理を強化できます。追跡で得られたインサイトは、意思決定に役立つ貴重な情報となり、コスト効率性やプロジェクト全体の成功に寄与します。
ワークロードのライフサイクル全体を追跡すれば、ワークロードやワークロードコンポーネントが不要になった時点でわかります。既存のワークロードとコンポーネントが使用中のように見える場合がありますが、AWS が新しいサービスや機能をリリースした時点で、廃止または刷新される可能性があります。ワークロードの以前のステージに注目してください。ワークロードが本番稼働状態になったら、以前の環境は廃止するか、再び必要になるまでキャパシティを大幅に削減することができます。
リソースに期間やリマインダーのタグを付けて、ワークロードがレビューされた時点をマークしておくことができます。例えば、開発環境の前回のレビューから数か月経っている場合は、再度レビューを行って、新しいサービスを導入できるか、環境が使用中かを調査する適切なタイミングである可能性があります。アプリケーションを AWS の [myApplications](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/aws-myApplications.html) でグループ化してタグ付けし、重要度、環境、最終レビュー、コストセンターなどのメタデータを管理および追跡できます。ワークロードのライフサイクルを追跡すると共に、アプリケーションのコスト、状態、セキュリティ体制、パフォーマンスをモニタリングおよび管理できます。
AWS には、エンティティのライフサイクル追跡に使用できるさまざまな管理およびガバナンスサービスが用意されています。[https://aws.amazon.com/config/](https://aws.amazon.com/config/) または [https://aws.amazon.com/systems-manager/](https://aws.amazon.com/systems-manager/) を使用して、AWS リソースと設定の詳細なインベントリを入手できます。プロジェクトやアセットを管理する既存のシステムを統合して、組織内のアクティブなプロジェクトや製品を追跡することが推奨されます。現在のシステムを AWS が提供する豊富なイベントやメトリクスと組み合わせることにより、重要なライフサイクルイベントのビューを作成し、前もってリソースを管理し、不要なコストを削減できます。
[アプリケーションライフサイクル管理 (ALM)](https://aws.amazon.com/what-is/application-lifecycle-management/) と同様に、プロジェクトのライフサイクルを追跡するには、設計と開発、テスト、本番稼働、サポート、ワークロードの冗長性など、複数のプロセス、ツール、チームが連携する必要があります。
プロジェクトのライフサイクルの各段階を注意深く監視することで、組織は重要なインサイトを得て管理を強化し、プロジェクトを計画から実施、完遂に至るまで円滑に進めることができます。入念な監視下で、プロジェクトは品質基準を満たすだけでなく、納期どおりに予算内で完了し、全体的なコスト効率が向上します。
エンティティライフサイクル追跡の実装の詳細については、[https://aws.amazon.com/architecture/well-architected/](https://aws.amazon.com/architecture/well-architected/)を参照してください。
### 実装手順
+ **プロジェクトのライフサイクルモニタリングプロセスを確立する:** [Cloud Center of Excellence チーム](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/cost_cloud_financial_management_function.html)は、プロジェクトのライフサイクルモニタリングプロセスを確立する必要があります。ワークロードを監視するための構造的かつ体系的なアプローチを確立し、プロジェクトの管理、可視性、パフォーマンスを高めます。監視プロセスの効果と価値を最大限に引き出すために、プロセスの透明性と協調性を高め、継続的に改善していきます。
+ **ワークロードレビューを実行する:** 組織のポリシーに従い、定期的に既存のプロジェクトを監査し、ワークロードレビューを実施します。監査に費やされる労力の量は、組織のおおよそのリスク、価値、またはコストに比例する必要があります。監査に含めるべき主な領域は、インシデントまたは機能停止の組織に対するリスク、価値、組織への寄与 (収益またはブランドに対する評価で測定)、ワークロードのコスト (リソースおよび運用の合計コストとして測定)、およびワークロードの使用量 (時間単位ごとの組織の成果の数で測定) です。これらの領域がライフサイクルを通じて変化する場合、完全または部分的な廃止など、ワークロードの調整が必要です。
## リソース
**関連ドキュメント:**
+ [AWS でのタグ付けのガイダンス](https://aws.amazon.com/solutions/guidance/tagging-on-aws/)
+ [ALM (アプリケーションライフサイクル管理) とは何ですか?](https://aws.amazon.com/what-is/application-lifecycle-management/)
+ [ジョブ機能の AWS 管理ポリシー](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)
**関連する例:**
+ [IAM ポリシーを使用して AWS リージョンへのアクセスを制御する](https://aws.amazon.com/blogs/security/easier-way-to-control-access-to-aws-regions-using-iam-policies/)
**関連ツール**
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Systems Manager](https://aws.amazon.com/systems-manager/)
+ [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/)
+ [AWS Organizations](https://aws.amazon.com/organizations/)
+ [AWS CloudFormation](https://aws.amazon.com/cloudformation/?c=mg&sec=srv)
# COST 3. コストと使用量はどのように監視すればよいでしょうか?
コストをモニタリングし、適切に配分するためのポリシー手順を定めます。これにより、ワークロードのコスト効率を測定し、向上させることができます。
**Topics**
+ [COST03-BP01 詳細情報ソースを設定する](cost_monitor_usage_detailed_source.md)
+ [COST03-BP02 コストと使用状況に組織情報を追加する](cost_monitor_usage_org_information.md)
+ [COST03-BP03 コスト属性カテゴリを特定する](cost_monitor_usage_define_attribution.md)
+ [COST03-BP04 組織のメトリクスを確立する](cost_monitor_usage_define_kpi.md)
+ [COST03-BP05 請求およびコスト管理ツールを設定する](cost_monitor_usage_config_tools.md)
+ [COST03-BP06 ワークロードメトリクスに基づいてコストを配分する](cost_monitor_usage_allocate_outcome.md)
# COST03-BP01 詳細情報ソースを設定する
コスト管理ツールとレポートツールを設定して、コストと使用状況に関するデータの分析と透明性を改善します。コストと使用量の追跡と区別を容易にするログエントリを作成するようにワークロードを設定します。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
時間単位の粒度など、コスト管理ツールの詳細な請求情報により、組織は消費量をさらに詳細に追跡でき、コスト増加の原因を特定する手助けとなります。これらのデータソースは、組織全体のコストと使用量の最も正確なビューを提供します。
AWS Data Exports を使用して AWS Cost and Usage Report (CUR) 2.0 のエクスポートを作成できます。これは、AWS から詳細なコストと使用状況の詳細を取得するための新しい推奨方法です。これにより、課金されるすべての AWS のサービスについて、日単位または時間単位の精度による使用量、レート、コスト、使用属性 (CUR と同じ情報) が提供されます。また、いくつかの改善点も提示されます。CUR では、タグ付け、場所、リソース属性、アカウント ID など想定可能なあらゆる側面からレポートを作成できます。
作成するエクスポートのタイプとして、標準データエクスポート、Quick 統合によるコストと使用状況ダッシュボードへのエクスポート、レガシーデータエクスポートの 3 種類のエクスポートタイプがあります。
+ **[標準データエクスポート]**: Amazon S3 に定期的に配信されるテーブルのカスタマイズされたエクスポート。
+ **[コストと使用状況ダッシュボード]**: Quick へのエクスポートと統合により、事前構築済みのコストと使用状況ダッシュボードをデプロイします。
+ **[レガシーデータのエクスポート]**: レガシー AWS Cost and Usage Report (CUR) のエクスポートです。
次のカスタマイズを行ったデータエクスポートを作成できます。
+ リソース ID の包含
+ 分割コスト配分データ
+ 時間単位の詳細
+ バージョニング
+ 圧縮タイプとファイル形式
Amazon ECS または Amazon EKS でコンテナを実行するワークロードの場合、分割コスト配分データを有効にすると、コンテナワークロードによる共有コンピューティングリソースとメモリリソースの消費状況に基づいて、個々のビジネスユニットやチームにコンテナコストを配分できます。分割コスト配分データにより、新しいコンテナレベルのリソースのコストと使用状況データが AWS Cost and Usage Report に導入されます。分割コスト配分データは、クラスターで実行されている個々の ECS サービスとタスクのコストを計算することで算出されます。
コストと使用状況ダッシュボードは、コストと使用状況ダッシュボードテーブルを定期的に S3 バケットにエクスポートし、事前構築済みのコストと使用状況ダッシュボードを Quick にデプロイします。コストと使用状況データのダッシュボードをすぐにデプロイしたい場合は、このオプションを使用します (カスタマイズはできません)。
必要に応じて、レガシーモードで CUR をエクスポートできます。[AWS Glue](https://aws.amazon.com/glue/) など他の処理サービスを統合して分析用にデータを準備して、SQL でデータをクエリして [Amazon Athena](https://aws.amazon.com/athena/) でデータを分析したりできます。
### 実装手順
+ **データエクスポートを作成する:** 必要なデータを使用してカスタマイズされたエクスポートを作成し、エクスポートのスキーマを制御します。基本的な SQL を使用して請求とコスト管理データのエクスポートを作成し、Quick と連携して請求とコスト管理データを可視化します。また、標準モードでデータをエクスポートして、Amazon Athena などの他の処理ツールでデータを分析することもできます。
+ **コストと使用状況レポートを設定する:** 請求コンソールを使用して、少なくとも 1 つのコストと使用状況レポートを設定します。すべての識別子とリソース ID を含む時間単位の粒度でレポートを設定します。粒度が異なる他のレポートを作成して、概要情報を提供することもできます。
+ **Cost Explorer で時間単位の詳細度を設定する:** 過去 14 日間の時間単位の粒度でコストと使用状況データにアクセスするには、請求コンソールで時間単位とリソースレベルのデータを有効にすることを検討してください。
+ **アプリケーションログ記録を有効にする:** アプリケーションがもたらすビジネスの各成果がログに記録され、追跡および測定が可能であることを確認します。このデータの粒度が少なくとも 1 時間単位であることを確認し、コストと使用状況のデータと一致するようにします。ログ記録とモニタリングの詳細については、[Well-Architected 運用上の優秀性の柱](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html)についてのホワイトペーパーを参照してください。
## リソース
**関連ドキュメント:**
+ [AWS Data Exports](https://docs.aws.amazon.com/cur/latest/userguide/what-is-data-exports.html)
+ [AWS Glue](https://aws.amazon.com/glue/)
+ [Quick](https://aws.amazon.com/quicksight/)
+ [AWS コスト管理の料金](https://aws.amazon.com/aws-cost-management/pricing/)
+ [AWS リソースのタグ付け](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)
+ [Cost Explorer によるコストの分析](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html)
+ [AWS Cost and Usage Reportの管理](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html)
**関連する例:**
+ [AWS アカウントのセットアップ](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_1_AWS_Account_Setup/README.html)
+ [AWS Billing and Cost Management のデータエクスポート](https://aws.amazon.com/blogs/aws-cloud-financial-management/introducing-data-exports-for-billing-and-cost-management/)
+ [AWS Cost Explorer の一般的なユースケース](https://aws.amazon.com/blogs/aws-cloud-financial-management/aws-cost-explorers-new-ui-and-common-use-cases/)
# COST03-BP02 コストと使用状況に組織情報を追加する
組織、ワークロード属性、およびコスト配分カテゴリに基づいてタグ付けスキーマを定義します。これによりコスト管理ツールで、フィルター処理によるリソースの検索や、コストおよび使用状況のモニタリングを行うことができます。目的、チーム、環境、またはビジネスに関連するその他の基準によって、可能な限りすべてのリソースに一貫したタグ付けを実装します。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
[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 タグエディタ](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html)では、複数のリソースのタグを追加、削除、管理できます。タグエディタを使用してタグ付けするリソースを検索し、検索結果からそのリソースのタグを管理します。
[AWS Cost Categories](https://aws.amazon.com/aws-cost-management/aws-cost-categories/) を使用すると、リソースにタグを付けることなく組織としての意味をコストに割り当てることができます。コストと使用量に関する情報を、一意の内部組織構造にマッピングできます。アカウントやタグなどの請求ディメンションを使用して、コストをマッピングおよび分類するカテゴリルールを定義します。これにより、タグ付けに加えて、より高いレベルの管理機能が提供されます。また、特定のアカウントとタグを複数のプロジェクトにマッピングすることもできます。
**実装手順**
+ **タグスキーマを定義する:** すべての利害関係者をビジネス全体から集めて、スキーマを定義します。これには通常、技術、財務、および管理ロールの担当者が含まれます。すべてのリソースに必要なタグのリストと、リソースに必要なタグのリストを定義します。タグの名前と値が組織全体で一貫していることを確認します。
+ **リソースをタグ付けする:** 定義したコスト帰属カテゴリを使用して、カテゴリに従ってワークロードのすべてのリソースに[タグを付けます](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)。効率を高めるには、CLI、タグエディタ、AWS Systems Manager などのツールを使用します。
+ **AWS Cost Categories を実装する:** タグ付けを実装しなくても [Cost Categories](https://aws.amazon.com/aws-cost-management/aws-cost-categories/) を作成できます。Cost Categories では、既存のコストと使用量ディメンションを使用します。スキーマからカテゴリルールを作成し、それをコストカテゴリに実装します。
+ **タグ付けを自動化する:** すべてのリソースにわたってタグ付けの高いレベルを維持していることを確認するには、タグ付けを自動化して、リソースの作成時に自動的にタグ付けされるようにします。[AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-resource-tags.html) などのサービスを使用して、リソースの作成時にタグ付けされていることを確認します。Lambda 関数を使用して自動的にタグ付けするカスタムソリューションや、ワークロードを定期的にスキャンし、タグ付けされていないリソースをすべて削除するマイクロサービスを作成することもできます。これは、テスト環境および開発環境に最適です。
+ **タグ付けをモニタリング、レポートする:** 組織全体でタグ付けの高いレベルを維持していることを確認するには、ワークロード全体でタグをレポートおよびモニタリングします。[AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) を使用して、タグ付けされたリソースとタグ付けされていないリソースのコストを表示したり、[タグエディタ](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)などのサービスを使用したりできます。タグ付けされていないリソースの数を定期的に確認し、必要なレベルのタグ付けになるまでタグを追加するアクションを実行します。
## リソース
**関連ドキュメント:**
+ [タグ付けのベストプラクティス](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)
+ [AWS CloudFormation リソースタグ](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)
+ [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)
+ [AWS コストと使用状況レポートの管理](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html)
**関連動画:**
+ [コストセンターまたはプロジェクトによる請求を分割するための AWS リソースをどのようにタグ付けすればよいか教えてください](https://www.youtube.com/watch?v=3j9xyyKIg6w)
+ [AWS リソースのタグ付け](https://www.youtube.com/watch?v=MX9DaAQS15I)
# COST03-BP03 コスト属性カテゴリを特定する
組織内のコストを内部消費エンティティに配分するために使用できるビジネスユニット、部門、プロジェクトなどの組織カテゴリを特定します。こうしたカテゴリを活用して、支出の説明責任の徹底、コスト意識の向上、効果的な消費行動の促進を図ります。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
コストを分類するプロセスは、予算編成、会計、財務報告、意思決定、ベンチマーキング、およびプロジェクト管理においてきわめて重要です。費用を分類してカテゴリ化することで、チームはクラウドジャーニーで発生するコストの種類をよりよく理解でき、情報に基づいた意思決定を行い、予算を効果的に管理できるようになります。
クラウド支出の説明責任は、統制の取れた需要とコスト管理に対する強力なインセンティブを確立します。その結果、クラウド支出の大部分を消費するビジネスユニットやチームに割り当てている組織では、クラウドコストを大幅に節約できます。また、クラウド支出を配分することで、組織は一元化されたクラウドガバナンスのベストプラクティスをさらに採用できるようになります。
定期的なミーティングで、財務チームやその他の関係者と協力し、組織内でコストを配分する方法の要件を理解します。ワークロードのコストは、開発、テスト、本稼働、廃止などライフサイクル全体にわたって配分する必要があります。学習、スタッフ育成、アイデア創出に要したコストが、どのように組織に帰属するかを理解します。これは、この目的で使用される金額を、一般的な IT コスト予算ではなく、トレーニング予算や開発の予算に正しく割り当てるうえで役立ちます。
組織内のステークホルダーとコスト属性カテゴリを定義したら、[AWS Cost Categories](https://aws.amazon.com/aws-cost-management/aws-cost-categories/) を使用して、コストと使用状況の情報を特定のプロジェクトのコストや部門やビジネスユニットの AWS アカウントなど、AWS クラウドの有意義なカテゴリにグループ化します。カスタムカテゴリを作成して、アカウント、タグ、サービス、料金タイプなどのさまざまなディメンションを使用して定義したルールに基づき、コストと使用状況の情報をカスタムカテゴリにマッピングすることもできます。コストカテゴリを設定すると、カテゴリごとにコストと使用状況の情報を確認できるようになり、組織の戦略や購入に関する決定をより適切に行うことができます。これらのカテゴリは、AWS Cost Explorer、AWS Budgets、および AWS Cost and Usage Report にも表示されます。
例えば、ビジネスユニット (DevOps チーム) のコストカテゴリを作成し、各カテゴリの下に、複数のルール (各サブカテゴリのルール) を作成します。各ルールでは、定義したグループに基づいて、複数のディメンション (AWS アカウント、コスト配分タグ、サービス、料金タイプ) を使用します。Cost Categories を使うと、ルールベースのエンジンを使用してコストを分類できます。ルールを設定することで、コストをカテゴリ別に分類します。ルール内では、特定の AWS アカウント、AWS サービス、料金タイプなどの各カテゴリについて、複数のディメンションを使用してフィルター処理を行うことができます。これらのカテゴリは、[AWS Billing and Cost Management](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-what-is.html) [コンソール](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/view-billing-dashboard.html)で使用できます。これには AWS Cost Explorer、AWS Budgets、AWS Cost and Usage Report および、AWS Cost Anomaly Detection が含まれます。
例として、次の図は、組織でコストと使用状況の情報をグループ化する方法を示しています。例えば、複数のチーム (コストカテゴリ)、複数の環境 (ルール)、そして複数のリソースまたはアセットを持つ各環境 (ディメンション) にグループができます。
![\[組織内のコストと使用量の関係を詳述したフローチャートです。\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/images/cost-usage-organization-chart.png)
コストカテゴリを使用して、コストのグループを作成することもできます。コストカテゴリの作成後 (使用状況レコードの値が更新されるまでに最長で 24 時間かかります)、作成したコストカテゴリは、[AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)、[AWS Budgets](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html)、[AWS Cost and Usage Report](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html)、および [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) に表示されます。AWS Cost Explorer および AWS Budgets では、コストカテゴリが追加の請求ディメンションとして表示されます。これを使用して、特定のコストカテゴリ値でフィルタリングしたり、コストカテゴリ別にグループ化したりできます。
### 実装手順
+ **組織のカテゴリを定義する:** 社内の関係者およびビジネスユニットとミーティングを行い、組織の構造と要件を反映したカテゴリを定義します。これらのカテゴリは、ビジネスユニット、予算、コストセンター、部門など、既存の財務カテゴリの構造に直接マッピングされます。トレーニングや教育など、クラウドがもたらすビジネスの成果を確認します。これらは組織のカテゴリでもあります。
+ **機能を反映したカテゴリを定義する:** 社内の関係者およびビジネスユニットとミーティングを行い、企業内の機能を反映したカテゴリを定義します。これは、ワークロードまたはアプリケーション名、および実稼働、テスト、開発などの環境のタイプである場合があります。
+ **AWS Cost Categories を定義する:** [AWS Cost Categories](https://aws.amazon.com/aws-cost-management/aws-cost-categories/) を使用してコストと使用状況情報を整理するコストカテゴリを作成して、AWS コストと使用状況を[有意義なカテゴリ](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/create-cost-categories.html)にマッピングします。同じリソースに複数のカテゴリを割り当てることも、同じリソースを複数の異なるカテゴリに含めることもできるため、必要な数のカテゴリを定義します。これにより、AWS Cost Categories を使用したカテゴリ化された構造内で[コストを管理](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html)できるようになります。
## リソース
**関連ドキュメント:**
+ [AWS リソースのタグ付け](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)
+ [コスト配分タグの使用](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.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)
+ [AWS Cost and Usage Report の管理](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html)
+ [AWS Cost Categories](https://docs.aws.amazon.com/wellarchitected/latest/framework/aws-cost-management/aws-cost-categories/)
+ [AWS Cost Categories を用いてコストを管理する](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-cost-categories.html)
+ [コストカテゴリを作成する](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/create-cost-categories.html)
+ [コストカテゴリのタグ付け](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/tag-cost-categories.html)
+ [コストカテゴリ内で料金を分割する](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/splitcharge-cost-categories.html)
+ [AWS Cost Categories の機能](https://aws.amazon.com/aws-cost-management/aws-cost-categories/features/)
**関連する例:**
+ [AWS Cost Categories でコストと使用状況のデータを整理する](https://aws.amazon.com/blogs/aws-cloud-financial-management/organize-your-cost-and-usage-data-with-aws-cost-categories/)
+ [AWS Cost Categories を用いてコストを管理する](https://aws.amazon.com/aws-cost-management/resources/managing-your-costs-with-aws-cost-categories/)
# COST03-BP04 組織のメトリクスを確立する
このワークロード用のメトリクスを組織内で定めます。ワークロードのメトリクスの例として、作成された顧客レポートや顧客に提供されるウェブページが挙げられます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
ワークロードのアウトプットがビジネスの成功に対してどのように測定されるかを理解します。通常、各ワークロードには、パフォーマンスを示す主な成果の小さな組み合わせがあります。多数のコンポーネントを含む高度なワークロードがある場合は、リストに優先順位を付けるか、各コンポーネントのメトリクスを定義して追跡できます。チームと協力して、どのメトリクスを使用するか理解します。この単位は、ワークロードの効率または各ビジネス成果のコストを把握するために使用されます。
**実装手順**
+ **ワークロードの成果を定義する:** ビジネスの利害関係者とミーティングをして、ワークロードの成果を定義します。これらは顧客の使用状況の主要な測定指標であり、技術的メトリクスではなく、ビジネスメトリクスである必要があります。ワークロードごとに少数の概要的なメトリクス (5 つ未満) が存在する必要があります。ワークロードが異なるユースケースで複数の成果を生成する場合は、それらを単一のメトリクスにグループ化してください。
+ **ワークロードコンポーネントの成果を定義する:** 必要に応じて、大規模で複雑なワークロードがある場合、または明確に定義された入出力を使用してワークロードをコンポーネント (マイクロサービスなど) に簡単に分割できる場合は、各コンポーネントのメトリクスを定義します。この作業では、コンポーネントの価値とコストを反映する必要があります。最大のコンポーネントから開始し、大きさ順で、最小のコンポーネントまで作業します。
## リソース
**関連ドキュメント:**
+ [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)
+ [AWS コストと使用状況レポートの管理](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html)
# COST03-BP05 請求およびコスト管理ツールを設定する
クラウド支出を管理および最適化するには、組織のポリシーに合ったコスト管理ツールを設定します。これには、コストと使用状況のデータを整理して追跡し、統合された請求とアクセス許可での制御の強化、予算編成と予測を通じた計画の改善、通知またはアラートの受信、リソースと価格の最適化によるコスト削減を行うサービス、ツール、リソースが含まれます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
確固たる説明責任を確立するには、まずアカウント戦略をコスト配分戦略の一部として検討します。これを正しく行えば、それ以上先に進む必要はないかもしれません。正しく行えない場合、認識の欠如が発生し、さらに問題点が増える可能性があります。
クラウド支出の説明責任を推進するには、コストと使用状況の可視化が可能なツールへのアクセスをユーザーに許可します。AWS では、以下の目的に合わせてすべてのワークロードとチームを設定することをお勧めします。
+ **整理:** 独自のタグ付け戦略と分類を使用して、コスト配分とガバナンスのベースラインを確立します。AWS Control Tower や AWS Organizations などのツールを使用して複数の AWS アカウントを作成します。サポートされている AWS リソースにタグを付け、組織構造 (ビジネスユニット、部門、プロジェクト) に基づいてわかりやすく分類します。特定のコストセンターのアカウント名にタグ付けし、それを AWS Cost Categories とマッピングして、ビジネスユニットのアカウントをコストセンターのグループにまとめることで、ビジネスユニットの所有者が複数のアカウントの消費を 1 か所で確認できるようにします。
+ **アクセス:** 組織全体の請求情報を一括請求で追跡します。適切なステークホルダーとビジネスオーナーがアクセスできることを確認します。
+ **制御:** 適切なガードレールを使用して、効果的なガバナンスメカニズムを構築し、サービスコントロールポリシー (SCP)、タグポリシー、IAM ポリシー、予算アラートを使用する際の想定外のシナリオを回避します。例えば、チームが効果的な制御メカニズムを使用する場合のみ目的のリージョンで推奨リソースを作成できるようにしたり、特定のタグ (cost-center など) がないとリソースを作成できないようにしたりすることができます。
+ **現状確認:** 現在のコストと使用量を示すダッシュボードを設定します。ダッシュボードはオペレーションダッシュボードと同様に、作業環境内の目に付きやすい場所で使用できるようにする必要があります。データをエクスポートし、AWS Cost Optimization Hub のコストと使用状況ダッシュボードまたは任意のサポート対象製品を使用することで、このような可視性が可能になります。ペルソナごとに別々のダッシュボードを作成しなければならない場合があります。例えば、マネージャーのダッシュボードはエンジニアリングのダッシュボードとは異なる場合があります。
+ **通知:** コストまたは使用量が定義された制限を超え、AWS Budgets または AWS コスト異常検出で異常が発生した場合に通知します。
+ **レポート:** すべてのコストと使用量の情報を要約します。詳細で帰属先が特定可能なコストデータを使用して、クラウド支出の認識と説明責任の意識を高めます。レポートを使用するチームと関連性があり、推奨事項を含めたレポートを作成します。
+ **追跡:** 設定された目標またはターゲットに対する現在のコストと使用量を表示します。
+ **分析:** チームメンバーは、さまざまなフィルター (リソース、アカウント、タグなど) を使用して、時間単位、日単位、または月単位でカスタム分析とディープ分析を実行できます。
+ **検査:** リソースのデプロイとコスト最適化の機会を最新の状態に保ちます。Amazon CloudWatch、Amazon SNS、または Amazon SES を使用して、組織レベルでのリソースデプロイに関する通知を受け取ります。AWS Trusted Advisor または AWS Compute Optimizer を使用してコスト最適化の推奨事項を確認します。
+ **トレンドレポート:** 指定した期間のコストと使用量の変動を、指定の詳細度で示します。
+ **予測:** 作成した予測ダッシュボードで、将来の推定コストを示し、リソースの使用量と支出を見積もります。
[AWS Cost Optimization Hub](https://aws.amazon.com/aws-cost-management/cost-optimization-hub/) を使用して、統合された潜在的なコスト削減の機会を一元的な場所から理解し、Amazon Athena と統合するためのデータエクスポートを作成できます。また、AWS Cost Optimization Hub を使用してコストと使用状況ダッシュボードをデプロイすることもできます。このダッシュボードでは、Quick を使用してインタラクティブなコスト分析を行ったり、コストに関するインサイトを安全に共有したりできます。
組織に必須のスキルや処理能力がない場合、[AWS ProServ](https://aws.amazon.com/professional-services/)、[AWS Managed Services (AMS)](https://aws.amazon.com/managed-services/)、または [AWS パートナー](https://aws.amazon.com/partners/)を利用できます。サードパーティーのツールを利用することもできますが、利用に際しては必ず価値提案を検証するようにしてください。
### 実装手順
+ **ツールへのチームベースのアクセスを許可する:** アカウントを設定してグループを作成し、必要なコストと使用状況レポート (グループの使用状況に関するもの) へのアクセスを許可します。また、[AWS Identity and Access Management](https://aws.amazon.com/iam/) を使用して AWS Cost Explorer などのツールへの[アクセスを制御](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-access.html)します。これらのグループには、アプリケーションを所有または管理するすべてのチームの代表者を含める必要があります。これにより、すべてのチームがコストと使用状況の情報にアクセスして、各自の使用を追跡できるようになります。
+ **コストタグとカテゴリを整理する:** チーム、ビジネスユニット、アプリケーション、環境、プロジェクト全体でコストを整理します。リソースタグを使用して、コスト配分タグごとにコストを整理します。タグ、アカウント、サービスなどを使用してディメンションに基づいて Cost Categories を作成し、コストをマッピングします。
+ **AWS Budgets を設定する:** ワークロードのすべてのアカウントで[AWS Budgets を設定](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html)します。タグとコストカテゴリを使用して、アカウント全体の支出に対する予算とワークロードに対する予算を設定します。予算額を超えたときや、推定コストが予算を超えるときにアラートを受信するよう、AWS Budgets の通知を設定します。
+ **AWS コスト異常検出を設定する:** [AWS コスト異常検出](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/)を使用することにより、コストと使用状況をモニタリングし、通常と異なる支出を検出できます。集計レポートでアラートを個別に受信したり、E メールまたは Amazon SNS トピックでアラートを受信したりすることで、異常の根本原因を分析および特定し、コストの増加を引き起こしている要因を特定できます。
+ **コスト分析ツールを使用する:** [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) をワークロードとアカウントについて設定し、さらに分析を行うためにコストデータを視覚化します。ワークロードのダッシュボードを作成することにより、全体的な支出、ワークロードの主要な使用状況メトリクス、過去のコストデータに基づく将来のコストの予測を追跡できます。
+ **コスト削減分析ツールを使用する:** AWS Cost Optimization Hub を使用して、未使用リソースの削除、適切なサイズ設定、Savings Plans、予約、Compute Optimizer の推奨事項など、カスタマイズされた推奨事項でコスト削減の機会を特定します。
+ **高度なツールを設定する:** 任意でビジュアルを作成して、インタラクティブな分析やコストインサイトの共有を支援できます。AWS Cost Optimization Hub でデータエクスポートを使用すると、Quick を活用したコストと使用状況ダッシュボードを組織に合わせて作成し、さらなる詳細と粒度が得られます。また、[Amazon Athena](https://docs.aws.amazon.com/athena/?id=docs_gateway) でデータエクスポートを使用して高度な分析機能を実装することで高度なクエリを実施したり、[Quick](https://docs.aws.amazon.com/quicksight/?id=docs_gateway) でダッシュボードを作成したりできます。[AWS パートナー](https://aws.amazon.com/marketplace/solutions/business-applications/cloud-cost-management)と協力して、統合されたクラウド請求書のモニタリングと最適化のためのクラウド管理ソリューションを導入できます。
## リソース
**関連ドキュメント:**
+ [AWS Billing and Cost Management とは](https://docs.aws.amazon.com/cost-management/latest/userguide/what-is-costmanagement.html)
+ [ベストプラクティスの AWS 環境を確立する](https://aws.amazon.com/organizations/getting-started/best-practices/)
+ [AWS リソースのタグ付けのベストプラクティス](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)
+ [AWS リソースのタグ付け](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)
+ [AWS Cost Categories](https://aws.amazon.com/aws-cost-management/aws-cost-categories/)
+ [AWS Budgets によるコストの分析](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html)
+ [AWS Cost Explorer によるコストの分析](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer-what-is.html)
+ [AWS データエクスポートとは](https://docs.aws.amazon.com/cur/latest/userguide/what-is-data-exports.html)
**関連動画:**
+ [クラウドインテリジェンスダッシュボードのデプロイ](https://www.youtube.com/watch?v=FhGZwfNJTnc)
+ [FinOps またはコスト最適化のメトリクスまたは KPI に関するアラートを受け取る](https://www.youtube.com/watch?v=dzRKDSXCtAs)
**関連する例:**
+ Quick を活用した[コストと使用状況ダッシュボード](https://aws.amazon.com/blogs/aws-cloud-financial-management/new-cost-and-usage-dashboard-powered-by-amazon-quicksight/)
+ [AWS コストと使用状況ガバナンスワークショップ](https://catalog.workshops.aws/well-architected-cost-optimization/en-US/2-expenditure-and-usage-awareness/20-cost-and-usage-governance)
# COST03-BP06 ワークロードメトリクスに基づいてコストを配分する
使用量メトリクスや業績に基づいてワークロードのコストを配分し、ワークロードのコスト効率を測定します。インサイトとチャージバック機能が利用できる分析サービスにより、コストと使用状況データを分析するプロセスを実装します。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
コスト最適化とは、最低の価格点でビジネス成果を達成するということです。ワークロードメトリクス (ワークロードの効率で測定) に基づいてワークロードのコストを配分することによってのみ達成できます。定義されたワークロードメトリクスを、ログファイルまたは他のアプリケーションのモニタリングを使用してモニタリングします。このデータをワークロードのコストと組み合わせます。ワークロードのコストは、特定のタグ値またはアカウント ID のコストを確認することで取得できます。この分析を時間単位で実行します。静的なコストコンポーネント (恒久的に実行されるバックエンドデータベースなど) でリクエストレートが変化する (使用量のピークが午前 9 時から午後 5 時で、夜間のリクエストはほとんどない、など) 場合、通常、効率性は変化します。静的コストと変動コストの関係を理解しておくと、最適化アクティビティの焦点を絞ることができます。
共有リソースのワークロードメトリクスの作成は、Amazon Elastic Container Service (Amazon ECS) や Amazon API Gateway のコンテナ化されたアプリケーションのようなリソースに比べて難しい場合があります。ただし、使用量を分類してコストを追跡する方法はあります。Amazon ECS および AWS Batch の共有リソースを追跡する必要がある場合は、AWS Cost Explorer で分割コスト配分データを有効にできます。分割コスト配分データを使用すると、コンテナ化されたアプリケーションのコストと使用状況を把握して最適化し、共有コンピューティングリソースとメモリリソースの消費状況に基づいてアプリケーションコストを個々のエンティティに配分できます。
### 実装手順
+ **ワークロードメトリクスにコストを割り当てる:** 定義されたメトリクスと設定されたタグを使用して、ワークロードの出力とワークロードのコストを組み合わせたメトリクスを作成します。Amazon Athena や Amazon 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)
+ [AWS コストと使用状況レポートの管理](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-reports-costusage-managing.html)
**関連する例:**
+ [AWS 分割コスト配分データにより Amazon ECS および AWS Batch のコストの可視性を向上する](https://aws.amazon.com/blogs/aws-cloud-financial-management/la-improve-cost-visibility-of-containerized-applications-with-aws-split-cost-allocation-data-for-ecs-and-batch-jobs/)
# 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-BP05 データ保持ポリシーを適用する](cost_decomissioning_resources_data_retention.md)
# COST04-BP01 ライフタイム全体にわたってリソースを追跡する
ライフタイム全体にわたって、リソースや、リソースとシステムとの関係を追跡するメソッドを定義し、実装します。タグ付けにより、リソースのワークロードまたは機能を特定できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
不要になったワークロードリソースを廃止します。一般的な例としては、テスト用途のリソースがあります。テストが完了したら、リソースは削除できます。タグを使用してリソースを追跡する (およびそれらのタグに関するレポートを実行する) ことで、使用されなくなったり、ライセンスの有効期限が切れたりした場合に、廃止する資産を特定するのに役立ちます。リソース追跡には、タグの使用が効果的な方法です。リソースにその機能か、または廃止可能になる既知の日付をラベリングできます。そうすると、これらのタグでレポートを作成できます。機能タグを付ける場合の例として、`feature-X testing` という値であれば、ワークロードのライフサイクルの観点からリソースの目的を識別できます。もう 1 つの例は、削除されるタグキーの名前や値などのリソースに `LifeSpan` または `TTL` を使用して、廃止の期間や特定の時間を定義するものです。
**実装手順**
+ **タグ付けスキームを実装する:** リソースが属するワークロードを識別するタグ付けスキームを実装し、ワークロード内のすべてのリソースが適切にタグ付けされることを確認します。タグ付けにより、目的、チーム、環境など、ビジネスに関連した基準でリソースを分類することができます。タグ付けのユースケース、戦略、テクニックの詳細については、「[AWS のタグ付けのベストプラクティス](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)」を参照してください。
+ ** ワークロードのスループットまたは出力モニタリングを実装する:** 入力リクエストまたは出力完了に対してワークロードスループットモニタリングまたはアラームを実装します。ワークロードのリクエストまたは出力がゼロになったときに、ワークロードのリソースが使用されなくなったことを示す通知を提供するように設定します。ワークロードが通常の条件下で定期的にゼロまで下がる場合は、時間要因を組み込みます。未使用または十分に活用されていないリソースの詳細については、「[AWS Trusted Advisor コスト最適化チェック](https://docs.aws.amazon.com/awssupport/latest/user/cost-optimization-checks.html)」を参照してください。
+ **AWS リソースをグループ化する:** AWS リソースのグループを作成します。[AWS Resource Groups](https://docs.aws.amazon.com/ARG/latest/userguide/resource-groups.html) を使用すると、同じ AWS リージョンにある AWS リソースを整理し管理することができます。ほとんどのリソースにタグを追加して、組織内のリソースを識別および並べ替えることができます。サポートされているリソースに一括でタグを追加するときは[タグエディタ](https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html)を使用します。承認済み製品のポートフォリオを作成、管理し、エンドユーザーに配布して、製品ライフサイクルを管理するときは、[AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/index.html) の使用を検討してください。
## リソース
**関連ドキュメント:**
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/)
+ [AWS Trusted Advisor コスト最適化チェック](https://docs.aws.amazon.com/awssupport/latest/user/cost-optimization-checks.html)
+ [AWS リソースのタグ付け](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)
+ [カスタムメトリクスをパブリッシュする](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
**関連動画:**
+ [AWS Trusted Advisor を使用してコストを最適化する方法](https://youtu.be/zcQPufNFhgg)
**関連する例:**
+ [AWS リソースを整理するにはどうすればよいですか?](https://aws.amazon.com/premiumsupport/knowledge-center/resource-groups/)
+ [AWS Trusted Advisor を使用してコストを最適化する方法を教えてください。](https://aws.amazon.com/premiumsupport/knowledge-center/trusted-advisor-cost-optimization/)
# COST04-BP02 廃止プロセスを実装する
未使用のリソースを特定して廃止するためのプロセスを実装します。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
組織全体で標準化されたプロセスを導入し、未使用のリソースを特定し、排除します。このプロセスでは、組織のすべての要件が満たされていることを検証するために、検索を実行する頻度と、リソースを削除するプロセスを定義する必要があります。
**実装手順**
+ **廃止プロセスを作成、実装する:** ワークロードの開発者や所有者と協力して、ワークロードとそのリソースの廃止プロセスを構築します。このプロセスでは、ワークロードが使用中であるかどうか、およびワークロードの各リソースが使用中であるかどうかを検証する方法を網羅する必要があります。リソースを廃止するために必要なステップを詳述し、サービスから削除すると同時に、規制要件の遵守を確保します。ライセンスやアタッチされたストレージなど、関連するリソースも含める必要があります。廃止プロセスが開始されたことをワークロードの所有者に通知します。
プロセスの一部として何を確認する必要があるかについては、以下の廃止手順を使用してください。
+ **廃止されるリソースを特定する:** AWS クラウドで廃止の対象となるリソースを特定します。必要な情報をすべて記録し、廃止スケジュールを設定します。タイムラインでは、プロセス中に予期せぬ問題が発生した場合 (およびそのタイミング) を考慮してください。
+ **調整とコミュニケーションをする:** ワークロードの所有者と協力して、廃止されるリソースを確認します。
+ **メタデータを記録してバックアップを作成する:** メタデータ (パブリック IP、リージョン、AZ、VPC、サブネット、セキュリティグループなど) を記録し、本番環境のリソースに必要な場合、または重要なリソースである場合はバックアップ (Amazon Elastic Block Store スナップショットの作成、AMI の取得、キーのエクスポート、証明書のエクスポートなど) を作成します。
+ **Infrastructure as Code の検証をする:** リソースが CloudFormation、Terraform、AWS Cloud Development Kit (AWS CDK)、またはその他の Infrastructure as Code デプロイツールでデプロイされたかどうかを判断し、必要に応じて再デプロイできるようにします。
+ **アクセスの防止をする:** リソースが必要かどうかを判断する間にリソースの使用を防ぐため、制限付きコントロールを一定期間適用します。必要に応じて、リソース環境を元の状態に戻せることを確認します。
+ **内部廃止プロセスを遵守する:** 組織ドメインからのリソースの削除、DNS レコードの廃止、または設定管理ツール、モニタリングツール、自動化ツール、およびセキュリティツールからのリソース削除など、組織の管理タスクと廃止プロセスに従います。
リソースが Amazon EC2 インスタンスである場合は、次のリストを参照してください。詳細については、「[Amazon EC2 リソースを削除するか、終了する方法を教えてください。](https://aws.amazon.com/premiumsupport/knowledge-center/delete-terminate-ec2/)」を参照してください。
+ すべての Amazon EC2 インスタンスとロードバランサーを停止または終了します。Amazon EC2 インスタンスは、終了後しばらくの間コンソールに表示されます。実行状態にないインスタンスには課金されません。
+ Auto Scaling インフラストラクチャを削除する
+ すべての専有ホストを解放します。
+ Amazon EBS ボリュームと Amazon EBS スナップショットをすべて削除します。
+ すべての Elastic IP アドレスを解放します。
+ すべての Amazon マシンイメージ (AMI) の登録を解除します。
+ すべての AWS Elastic Beanstalk 環境を終了します。
リソースが Amazon Glacier ストレージ内のオブジェクトであり、最小保存期間を満たす前にアーカイブを削除した場合、日割り計算による早期削除料が課金されます。Amazon Glacier の最小保存期間は使用するストレージクラスによって異なります。各ストレージクラスの最小保存期間の概要については、[Amazon S3 ストレージクラスのパフォーマンス](https://aws.amazon.com/s3/storage-classes/?nc=sn&loc=3#Performance_across_the_S3_Storage_Classes)を参照してください。早期削除料金の計算方法の詳細については、「[Amazon S3 の料金](https://aws.amazon.com/s3/pricing/)」を参照してください。
次の簡単な廃止プロセスのフローチャートは、廃止手順を概説しています。リソースを廃止する前に、廃止対象として特定したリソースが組織で使用されていないことを確認します。
![\[リソースを廃止するステップを示すフローチャートです。\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/images/decommissioning-process-flowchart.png)
## リソース
**関連ドキュメント:**
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/)
+ [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)
**関連動画:**
+ [CloudFormation スタックを削除するがいくつかのリソースを保持する](https://www.youtube.com/watch?v=bVmsS8rjuwk)
+ [Amazon EC2 インスタンスを起動したユーザーを確認するには](https://www.youtube.com/watch?v=SlyAHc5Mv2A)
**関連する例:**
+ [Amazon EC2 リソースを削除するか、終了する方法を教えてください。](https://aws.amazon.com/premiumsupport/knowledge-center/delete-terminate-ec2/)
+ [自分のアカウントで EC2 インスタンスを起動したユーザーを確認するにはどうすればよいですか?](https://aws.amazon.com/premiumsupport/knowledge-center/ec2-user-launched-instance/)
# COST04-BP03 リソースを廃止する
定期監査や使用状況の変化などのイベントを契機としてリソースを廃止します。通常、廃止は定期的に行われ、手動または自動で実行できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
使用していないリソースを検索する場合は節減額の程度によって検索頻度と投入する労力を決定する必要があるため、コスト発生額の小さいアカウントの分析は、コスト発生額が高額のアカウントよりも頻度を下げるべきです。イベントの検索および廃止は、製品が寿命を迎えた場合や交換する場合など、ワークロードの状態の変化によって開始されます。イベントの検索および廃止は、市況の変化や製品終了などの外部イベントによって開始される場合もあります。
**実装手順**
+ **リソースを廃止する:** これは、不要になった AWS リソースの廃止段階またはライセンス契約の終了段階です。スナップショットやバックアップの取得などの不要な中断を防ぐために、廃止段階に移行してリソースを廃止する前に完了したすべての最終チェックを完了します。廃止プロセスを使用して、未使用と識別された各リソースを廃止します。
## リソース
**関連ドキュメント:**
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/)
# COST04-BP04 自動的にリソースを廃止する
重要度が低いリソース、不要なリソース、使用率が低いリソースを特定して廃止する作業を適切に行えるようにワークロードを設計します。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
オートメーションを使用して、廃止プロセスの関連コストを削減または削除します。自動廃止するようにワークロードを設計すると、そのライフタイム全体にわたるワークロードコストを削減できます。[Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) または [Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide) を使用して、廃止プロセスを実行できます。[API または SDK](https://aws.amazon.com/developer/tools/) でカスタムコードを実装し、ワークロードリソースを自動的に廃止することもできます。
[モダンアプリケーション](https://aws.amazon.com/modern-apps/)はサーバーレスファースト、つまりサーバーレスサービスの採用を優先するように構築されています。AWS は、コンピューティング、インテグレーション、データストアというスタックの 3 つのレイヤーすべてに対応する[サーバーレスサービス](https://aws.amazon.com/serverless/)を開発しました。サーバーレスアーキテクチャを使用すると、トラフィックの少ない間、自動的にスケールアップおよびスケールダウンしてコストを節約できます。
**実装手順**
+ **Amazon EC2 Auto Scaling または Application Auto Scaling を実装する:** サポートされているリソースは Amazon EC2 Auto Scaling または Application Auto Scaling で設定します。これらのサービスは、AWS サービス利用時の使用率とコスト効率の最適化に役立ちます。これらのサービスは、需要が低下すると余分なリソースを自動的に削除するため、過剰な支出を避けることができます。
+ **インスタンスを終了するように CloudWatch を設定する:** [CloudWatch アラーム](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/UsingAlarmActions.html#AddingTerminateActions) を使用してインスタンスを終了するように設定できます。廃止プロセスのメトリクスを使用して、Amazon Elastic Compute Cloud アクションでアラームを実装します。ロールアウトする前に、非本番環境でオペレーションを検証します。
+ **ワークロード内にコードを実装する:** AWS SDK または AWS CLI を使用してワークロードリソースを廃止できます。AWS と統合し、使用されなくなったリソースを終了または削除するコードをアプリケーション内に実装します。
+ **サーバーレスサービスを使用する:** アプリケーションを構築および実行する際は[サーバーレスアーキテクチャ](https://aws.amazon.com/serverless/)と[イベント駆動型アーキテクチャ](https://aws.amazon.com/event-driven-architecture/)を AWS で構築することを優先します。AWS は、自動的に最適化されたリソース使用率と自動廃止 (スケールインとスケールアウト) を提供するサーバーレステクノロジーサービスを提供します。サーバーレスアプリケーションでは、リソース使用率が自動的に最適化され、過剰プロビジョニングの費用が発生しません。
## リソース
**関連ドキュメント:**
+ [Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/)
+ [Amazon EC2 Auto Scaling の使用を開始する](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html)
+ [Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/)
+ [AWS でのサーバーレス](https://aws.amazon.com/serverless/)
+ [EC2 インスタンスを停止、終了、再起動、または復旧するアラームを作成する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/UsingAlarmActions.html)
+ [Amazon CloudWatch アラームへの終了アクションの追加](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/UsingAlarmActions.html#AddingTerminateActions)
**関連する例:**
+ [AWS CloudFormation スタックの自動削除のスケジュール](https://aws.amazon.com/blogs/infrastructure-and-automation/scheduling-automatic-deletion-of-aws-cloudformation-stacks/)
# COST04-BP05 データ保持ポリシーを適用する
サポートされるリソースでデータ保持ポリシーを定義し、組織の要件に従ってオブジェクトの削除を処理します。不要または孤立したリソースや不要になったオブジェクトを、特定して削除します。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
データ保持ポリシーとライフサイクルポリシーを使用して、特定されたリソースの廃止プロセスに関連するコストとストレージコストを削減します。データ保持ポリシーとライフサイクルポリシーを定義してストレージクラスの移行や削除を自動で実行すると、ライフタイム期間の全体的なストレージコストが削減されます。Amazon Data Lifecycle Manager を使用して、Amazon Elastic Block Store スナップショットおよび Amazon EBS-backed Amazon マシンイメージ (AMI) の作成と削除を自動化できます。また、Amazon S3 Intelligent-Tiering または Amazon S3 ライフサイクル設定を使用して、Amazon S3 オブジェクトのライフサイクルを管理できます。また、[API または SDK](https://aws.amazon.com/tools/) を使用してカスタムコードを実装することで、オブジェクトを自動的に削除するライフサイクルポリシーとポリシールールを作成することもできます。
**実装手順**
+ **Amazon Data Lifecycle Manager を使用する:** Amazon Data Lifecycle Manager のライフサイクルポリシーを使用して、Amazon EBS スナップショットと Amazon EBS-backed AMI の削除を自動化します。
+ **バケットにライフサイクル設定をセットアップする:** バケットで Amazon S3 ライフサイクル設定を使用して、ビジネス要件に基づいて Amazon S3 がオブジェクトのライフサイクル中に実行するアクションおよびオブジェクトライフサイクルの終了時の削除アクションを定義します。
## リソース
**関連ドキュメント:**
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/)
+ [Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/dlm/?icmpid=docs_homepage_mgmtgov)
+ [Amazon S3 のバケットのライフサイクル設定を行う方法](https://docs.aws.amazon.com/AmazonS3/latest/userguide/how-to-set-lifecycle-configuration-intro.html)
**関連動画:**
+ [Amazon Data Lifecycle Manager を使用した Amazon EBS スナップショット管理の自動化](https://www.youtube.com/watch?v=RJpEjnVSdi4)
+ [ライフサイクル設定ルールを使用して Amazon S3 バケットを空にするにはどうすればよいですか?](https://www.youtube.com/watch?v=JfK9vamen9I)
**関連する例:**
+ [ライフサイクル設定ルールを使用して Amazon S3 バケットを空にするにはどうすればよいですか?](https://aws.amazon.com/premiumsupport/knowledge-center/s3-empty-bucket-lifecycle-rule/)