# コスト最適化 コスト最適化 **Topics** + [ # クラウド財務管理を実践する ](a-practice-cloud-financial-management.md) + [ # 経費支出と使用量の認識 ](a-expenditure-and-usage-awareness.md) + [ # 費用対効果の高いリソース ](a-cost-effective-resources.md) + [ # 需要を管理しリソースを供給する ](a-manage-demand-and-supply-resources.md) + [ # 継続的最適化 ](a-optimize-over-time.md) # クラウド財務管理を実践する クラウド財務管理を実践する **Topics** + [ # COST 1 クラウド財務管理はどのように実装すればよいですか? ](w2aac19c13b5b5.md) # COST 1 クラウド財務管理はどのように実装すればよいですか? 組織はクラウド財務管理の実装により、AWS によってコストと使用状況の最適化とスケーリングをすることで、ビジネス価値と財務上の成功を実現できます。 **Topics** + [ # COST01-BP01 コスト最適化担当者を設定する ](cost_cloud_financial_management_function.md) + [ # COST01-BP02 財務とテクノロジーの連携を確立する ](cost_cloud_financial_management_partnership.md) + [ # COST01-BP03 クラウドの予算と予測を確立する ](cost_cloud_financial_management_budget_forecast.md) + [ # COST01-BP04 組織のプロセスにコスト意識を採り入れる ](cost_cloud_financial_management_cost_awareness.md) + [ # COST01-BP05 コスト最適化に関して報告および通知する ](cost_cloud_financial_management_usage_report.md) + [ # COST01-BP06 コストをプロアクティブにモニタリングする ](cost_cloud_financial_management_proactive_process.md) + [ # COST01-BP07 新しいサービスリリースに関する最新情報を把握しておく ](cost_cloud_financial_management_scheduled.md) # COST01-BP01 コスト最適化担当者を設定する COST01-BP01 コスト最適化担当者を設定する 組織全体のコスト認識を確立し、維持する責任を持つチーム (クラウドビジネスオフィスまたは Cloud Center of Excellence) を作成します。このチームには、組織全体の財務、テクノロジー、およびビジネスの役割を持つ人材が必要です。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 ## 実装のガイダンス 実装のガイダンス クラウドコンピューティングにおけるコスト意識の文化を確立し、維持する責任を負うクラウドビジネスオフィス (CBO) または Cloud Center of Excellence (CCOE) チームを確立します。これは社内の個人でも、チームでもかまいません。組織全体から財務、テクノロジーなどの主なステークホルダーを集めてチームを新規編成することもできます。 担当者 (個人またはチーム) は、コスト管理とコスト最適化活動に必要な時間を優先順序を付けて配分します。小規模な組織の場合、大企業のフルタイムの担当と比較すると、費やす時間の割合は少ない場合があります。 プロジェクトマネジメント、データサイエンス、財務分析、ソフトウェアやインフラストラクチャ開発など、複合的な能力が求められます。す。担当者は次の 3 つの異なる所有権内でコスト最適化を実行することにより、ワークロードの効率を高めることができます。 + **一元化: **財務オペレーション、コスト最適化、CBO、CCOE などの指定チームを通じて、お客様はガバナンスの仕組みを設計、導入し、ベストプラクティスを全社的に推進することができます。 + **分散型:** テクノロジーチームに影響を与え、最適化を実行させる。 + **ハイブリッド:** 一元化されたチームと分散されたチームの両方が協力して、コストの最適化を実行することができます。 この担当者は、コスト最適化目標 (ワークロード効率メトリクスなど) に対する実行および提供能力を評価されることになります。 この担当者が変化を起こすためには、エグゼクティブスポンサーシップを確保しなければならず、これが重要な成功要因です。エグゼクティブスポンサーは、クラウド利用のコスト効率を判断する最高責任者として、担当者の考え方を上長にエスカレーションして、組織が定める優先事項としてコスト最適化活動が扱われるようサポートします。そうでなければ、ガイダンスは無視され、コスト削減の機会が優先されなくなります。エグゼクティブスポンサーと担当者は協力して、組織のクラウド利用を効率化し、ビジネスバリューの実現を継続できるようにします。 ビジネス、Enterprise-On-Ramp、またはエンタープライズサポートプランを利用していて、このチームまたは担当者の構築に支援が必要な場合は、アカウントチームを通じてクラウド財務管理 (CFM) のエキスパートにご連絡ください。 **実装手順** + ** 主要なメンバーを定義する:** 組織のすべての関連部分が貢献し、コスト管理に関与している状況を確保する必要があります。一般的な組織内チームには、通常、財務、アプリケーションまたはプロダクトの所有者、管理、技術チーム (DevOps) が含まれています。一部は専属 (財務、技術) で、その他は必要に応じて定期的に関与します。CFM を実行する個人またはチームには、一般に以下のスキルセットが必要です。 + ソフトウェア開発スキル - スクリプトとオートメーションが構築される場合。 + インフラストラクチャエンジニアリングスキル - スクリプトまたはオートメーションをデプロイし、サービスまたはリソースのプロビジョニング方法を理解するためです。 + 運用の洞察力 - CFM とは、クラウドの効率的な利用を測定、モニタリング、修正、計画、拡張することで、クラウドで効率的に運用することです。 + **目標とメトリクスを定義する: **この担当者は、さまざまな方法で組織に価値をもたらす必要があります。これらの目標は定義され、組織が進化するにつれて継続的に進化します。一般的な活動には、組織全体のコスト最適化に関する教育プログラムの作成と実行、コスト最適化のためのモニタリングやレポート作成などの組織全体の標準策定、最適化に関するワークロード目標の設定などがあります。この担当者は、組織のコスト最適化機能について定期的に組織に報告する必要もあります。 価値ベースの重要業績指標 (KPI) を定義できます。KPI には、コストベースと価値ベースがあります。KPI を定義すると、効率性と予想されるビジネス成果の観点から、予想されるコストを計算できます。価値ベースの KPI は、コストおよび使用量のメトリクスをビジネスバリュー因子に結び付け、AWS 経費の変更の合理化に役立ちます。価値ベースの KPI を導き出す最初のステップは、組織横断的に協力し、KPI の標準セットを選択し、合意することです。 + ** 定期的なミーティングを設定する: **グループ (財務、技術、およびビジネスチーム) は定期的に会合を開いて、目標とメトリクスをレビューする必要があります。一般的なミーティングでは、組織の状態の確認、現在実行中のプログラムの確認、全体的な財務および最適化メトリクスの確認を行います。その後、主要なワークロードが詳細に報告されます。 このような定期的なミーティングの際に、ワークロードの効率性 (コスト) とビジネス成果をレビューできます。例えば、ワークロードのコストが 20% 増加したが、顧客使用量も増加したかもしれません。この場合、この 20% のコスト増加を投資と解釈できます。このような定期的なミーティングにより、チームは組織全体にとって有意義な価値ベースの KPI を特定できます。 ## リソース リソース **関連するドキュメント:** + [AWS CCOE ブログ](https://aws.amazon.com/blogs/enterprise-strategy/tag/ccoe/) + [クラウドビジネスオフィスの作成](https://aws.amazon.com/blogs/enterprise-strategy/creating-the-cloud-business-office/) + [CCOE - Cloud Center of Excellence](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-laying-the-foundation/cloud-center-of-excellence.html) **関連動画:** + [Vanguard CCOE 成功事例](https://www.youtube.com/watch?v=0XA08hhRVFQ) **関連する例:** + [Could Center of Excellence (CCoE) を活用した企業全体の変革](https://aws.amazon.com/blogs/enterprise-strategy/using-a-cloud-center-of-excellence-ccoe-to-transform-the-entire-enterprise/) + [企業全体を変革する CCOE の構築](https://docs.aws.amazon.com/whitepapers/latest/public-sector-cloud-transformation/building-a-cloud-center-of-excellence-ccoe-to-transform-the-entire-enterprise.html) + [CCOE を構築するときに回避すべき 7 つの落し穴](https://aws.amazon.com/blogs/enterprise-strategy/7-pitfalls-to-avoid-when-building-a-ccoe/) # COST01-BP02 財務とテクノロジーの連携を確立する COST01-BP02 財務とテクノロジーの連携を確立する クラウドジャーニーのすべての段階で、コストと使用状況に関するディスカッションに財務チームとテクノロジーチームを参加させます。チームは、定期的に集まり、組織の最終目的や目標、コストと使用状況の現状、財務や会計のプラクティスなどのトピックについて話し合います。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 ## 実装のガイダンス 実装のガイダンス 承認、調達、インフラストラクチャのデプロイサイクルが短縮されるため、テクノロジーチームは、クラウドでのイノベーションを迅速に行うことができます。ファイナンス組織はこれまでプロジェクト承認時のデータセンターやオンプレミス環境の調達に大量に使用されていた時間とリソースを調整することができます。 財務および調達組織の観点から見ると、資本予算、資本要求、承認、調達、物理的インフラストラクチャの設置のプロセスは、何十年にもわたって学習され、標準化されてきたプロセスの一つです。 + エンジニアリングチームや IT チームは、通常、依頼主である + さまざまな財務チームが承認者、調達者として機能する + 運用チームは、すぐに使えるインフラストラクチャのラック、スタック、および引き渡しを行う ![\[Circular workflow diagram showing technology teams, procurement, supply chain, and operations interactions.\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/cost01-bp02-finance-and-procurement-workflow.png) クラウドの採用により、インフラストラクチャの調達と消費は依存関係の連鎖と切り離されます。クラウドモデルでは、テクノロジーチームと製品チームは単なる構築者ではなく、製品の運用者兼所有者となり、調達とデプロイなど、従来は財務および運用チームに割り当てられていたアクティビティのほとんどを担当します。 クラウドリソースのプロビジョニングに必要なものは、ユーザーアカウントと適切なアクセス許可のセットだけです。これは IT および財務リスクを軽減することにもなります。つまり、チームは常に数回のクリックまたは API コールで、アイドル状態または不要なクラウドリソースを停止することができるのです。また、テクノロジーチームがより速くイノベーションを起こすことができるのも、実験を立ち上げては破棄する俊敏性と能力があってこそです。クラウド消費には変動的な性質があるため、資本支出予算と予測の観点から予測可能性に影響することがある一方で、クラウドによって組織は、オーバープロビジョニングのコストを削減し、控えめなアンダープロビジョニングに伴う機会コストも削減できます。 ![\[Diagram showing Technology and Product teams deploying, Finance and Business teams operating, with optimization at the center.\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/images/cost01-bp02-deploy-operate-optimize.png) 主要な財務部門とテクノロジー部門のステークホルダー同士のパートナーシップを確立し、組織の目標の共通理解を深め、クラウドコンピューティングのさまざまな消費モデルにおいて財務上の成功を実現するためのメカニズムを開発します。クラウドジャーニーのすべてのステージにおいて、コストと使用量に関するディスカッションに参加する必要がある組織内の関連するチームは、以下の。 + ** ファイナンシャルリード:** CFO、財務管理者、フィナンシャルプランナー、ビジネスアナリスト、調達、ソーシング、支払担当は、クラウドの消費モデル、購入オプション、月次請求プロセスを理解する必要があります。財務部門は、テクノロジーチームと連携して、IT バリューの事例を作成およびソーシャル化し、テクノロジー支出がビジネスの成果にどのように関連しているかをビジネスチームが理解できるようにする必要があります。このように、技術支出はコストではなく投資と見なされます。クラウド運用にはオンプレミスのオペレーションと比べて根本的な違い (使用量の変動率、従量課金制やティア別課金制、料金モデル、請求明細と使用量情報など) があるため、クラウド利用が調達プロセス、インセンティブ追跡、コスト配分、財務諸表などのビジネス局面に与えるインパクトをファイナンス部門で理解することが不可欠です。 + **テクノロジーリード:** テクノロジーリード (製品およびアプリケーションの所有者を含む) は、財務要件 (予算の制約など) やビジネス要件 (サービスレベルアグリーメントなど) を認識する必要があります。これにより、組織が目指すビジネス目標を達成するワークロードの導入が可能になります。 財務とテクノロジーのパートナーシップには、以下のような利点があります。 + 財務チームとテクノロジーチームは、コストと使用量をほぼリアルタイムで把握できます。 + 財務チームとテクノロジーチームは、クラウドへの支出の変動に対応するための標準となる運用手順を確立します。 + 財務部門のステークホルダーは、コミットメント割引 (リザーブドインスタンスや AWS Savings Plans など) の購入に資金がどう使用されるか、また組織を拡大するためにクラウドがどのように利用されるかに関して、戦略アドバイザーとして行動します。 + 既存の支払いアカウントと調達プロセスは、クラウドとともに使用されます。 + 財務チームとテクノロジーチームは、協力して将来的な AWS のコストと使用量を予測し、組織の予算を調整および構築します。 + 両者の共通言語により組織間のコミュニケーションが向上し、財務の概念への共通理解が得られます。 コストと使用量のディスカッションについて、組織内で関わるべきその他のステークホルダーは以下のとおりです。 + **事業部門オーナー:** 事業部門オーナーは、事業部門と会社全体の両方に方向性を提供できるように、クラウドのビジネスモデルを理解する必要があります。こうしたクラウド知識は成長とワークロード使用量を予測する際に、またリザーブドインスタンスや Savings Plans などの長期購入オプションを検討する際に重要な役割を果たします。 + **エンジニアリングチーム: **エンジニアがクラウド財務管理 (CFM) に取り組むよう促す、コストを意識した企業文化の構築には、財務チームとテクノロジーチームのパートナーシップの確立が欠かせません。CFM や財務業務の実務担当者や財務チームが共通して抱える問題の 1 つは、エンジニアにクラウド上のビジネス全体を理解させ、ベストプラクティスに従わせ、推奨されるアクションを取らせることです。 + **サードパーティー: **サードパーティー (コンサルタントやツールなど) を利用する場合、こうしたサードパーティーが財務目標に適合し、エンゲージメントモデルと投資収益率 (ROI) を通じて、どちらの整合性も実証できるようにします。通常、サードパーティーは自社管理のワークロードのレポーティングと分析を担当したり、自社設計のワークロードのコストを分析したりします。 CFM を導入し、成功させるには、財務、テクノロジー、ビジネスの各チームが協力し、組織全体におけるクラウド費用の伝達と評価の方法を変える必要があります。エンジニアリングチームを巻き込み、あらゆる段階でコストと使用に関する議論に参加させ、ベストプラクティスに従って合意されたアクションを取るよう奨励します。 **実装手順** + **主要なメンバーを定義する: **財務チームとテクノロジーチームのすべての関連メンバーがこの連携に関与していることを確認します。関連する財務メンバーは、クラウドの請求書に関する業務に従事するメンバーです。通常は、CFO、財務コントローラー、財務プランナー、ビジネスアナリスト、購買管理です。テクノロジーチームのメンバーは通常、プロダクトおよびアプリケーションの所有者、テクニカルマネージャー、およびクラウド上に構築するすべてのチームの代表者です。他のメンバーとしては、製品の使用に影響するマーケティングなどのビジネスユニットの所有者、および貴社の目標やメカニズムとの整合性を確保し、報告をサポートするコンサルタントなどのサードパーティーが含まれることがあります。 + **ディスカッションのためのトピックを定義する:** チーム間で共通する、または理解を共有する必要があるトピックを定義します。作成から支払いまでにかかるコストを追います。関連するメンバー、および適用する必要がある組織のプロセスを書き留めます。各ステップまたはプロセスのほか、利用可能な料金モデル、階層化された料金、割引モデル、予算、財務要件などの関連情報を理解します。 + **定期的なミーティングを設定する: **財務とテクノロジーのパートナーシップを構築するために、定期的なコミュニケーションの機会を設け、連携を維持します。グループは目標とメトリクスに照らして定期的に集まる必要があります。一般的なミーティングでは、組織の状態の確認、現在実行中のプログラムの確認、全体的な財務および最適化メトリクスの確認を行います。その後、主要なワークロードが詳細に報告されます。 ## リソース リソース **関連するドキュメント:** + [AWS ニュースブログ](https://aws.amazon.com/blogs/aws/) # COST01-BP03 クラウドの予算と予測を確立する COST01-BP03 クラウドの予算と予測を確立する 既存の組織の予算作成および予測プロセスを調整し、非常に変動しやすいクラウドのコストと使用状況の性質に対応できるようにします。プロセスは、トレンドベースまたはビジネスドライバーベースのアルゴリズム、またはそれらの組み合わせを使用して、動的なものとする必要があります。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 ## 実装のガイダンス 実装のガイダンス お客様は効率性、スピード、俊敏性を求めてクラウドを利用しますが、コストと使用量は大きく変動するものです。コストは、ワークロードの効率性の向上や、新規ワークロードや新機能のデプロイにより削減可能です。ワークロードの効率性が向上したときや、新しいワークロードと機能がデプロイされたときにコストが増加することがあります。ワークロードをスケーリングすると、サービスを提供する顧客が増えますが、その分クラウドの使用量とコストが増加します。リソースは以前より容易にアクセスできるようになります。クラウドの伸縮性は、コストと予測の伸縮性にもつながります。こうした変動を折り込めるように、組織の既存の予算編成プロセスを変える必要があります。 トレンドベースのアルゴリズム (コスト履歴を入力値として使用)、ビジネスドライバーベースのアルゴリズム (新製品の発売や営業地域の拡大など)、またはこの 2 つのアルゴリズムを組み合わせて、既存の予算編成と予測プロセスをより動的なものに調整します。 予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) を使用して、期間、繰り返し、または金額 (固定費または可変費) を指定し、サービス、AWS リージョン、タグなどのフィルターを追加することで、カスタム予算を詳細レベルで設定します。既存予算のパフォーマンスについて常に情報を入手するには、 [AWS Budgets Reports](https://docs.aws.amazon.com/cost-management/latest/userguide/reporting-cost-budget.html) を作成して、自分と関係者に定期的に E メールで送信されるようにスケジュールします。また、 [AWS Budgets アラート](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-best-practices.html) は、実際のコストに基づいて作成することもできます (これは反応型です) し、予測コストに基づいて作成することも可能で、潜在的なコスト超過に対する緩和策を実施する時間を確保することができます。コストまたは使用量が予算額を超えるか、超えると予測された場合、アラートが表示されます。 AWS は、動的な予測と予算編成のプロセスを柔軟に構築できるため、コストが予算の上限を守っているか、あるいは超えているかを常に把握することができます。 予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [AWS Cost Explorer](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-forecast.html) を使用し、過去の支出に基づいて、定義された期間のコストを予測します。AWS Cost Explorer の予測エンジンは、料金タイプ (リザーブドインスタンスなど) に基づいて履歴データをセグメント化し、機械学習とルールベースのモデルの組み合わせを使用して、すべての料金タイプにかかる費用を個別に予測します。予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [AWS Cost Explorer](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-forecast.html) を使用して、過去のコスト (トレンドベース) に適用される機械学習アルゴリズムに基づいて、日次 (最大 3 か月) または月次 (最大 12 か月) のクラウドコストを予測します。 Cost Explorer を使用してトレンドベースの予測が出来たら、 [AWS 料金見積りツール](https://calculator.aws/#/) を使用し、予想される使用量 (トラフィック、1 秒あたりのリクエスト数、必要な Amazon Elastic Compute Cloud (Amazon EC2) インスタンスなど) に基づいて、AWS のユースケースと今後のコストを見積もります。これは、AWS を利用する際に、支出方法のプランニング、コスト節減機会の発見、情報に基づいた意思決定にも役立てることができます。 予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) を使用して、予想外のコストを防止または削減し、イノベーションを遅らせることなく制御を強化します。AWS Cost Anomaly Detection は、高度な機械学習テクノロジーを利用して、異常な支出と根本原因を特定するため、迅速に対応できます。[3 つのシンプルなステップで、](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/)状況に応じて独自のモニターを作成し、異常な支出が検出されたときにアラートを受け取ることができます。構築はビルダーに任せ、AWS Cost Anomaly Detection は支出をモニタリングし、予期せぬ請求のリスクを軽減します。 次のサブセクション「 [Well-Architected コスト最適化の柱の財務とテクノロジーのパートナーシップ」](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/finance-and-technology-partnership.html) セクションで述べられているように、IT、財務、その他の関係者が同じツールやプロセスを使用し、一貫性を保つためのパートナーシップと連携が重要です。予算を変更する必要がある場合、ミーティングの回数を増やすと、それらの変更により迅速に対応できます。 **実装手順** + **既存の予算作成および予測プロセスを更新する: **予算作成プロセスと予測プロセスにおいて、トレンドベース、ビジネスドライバーベース、または両方の組み合わせを採り入れます。 + **アラートと通知を設定する:** AWS Budgets アラートと Cost Anomaly Detection を使用します。 + **主要関係者と定期的なレビューを行う:** 例えば、IT、財務、プラットフォーム、およびその他のビジネス分野の関係者が、ビジネスの方向性と使用状況の変化を認識し、連携を図ります。 ## リソース リソース **関連するドキュメント:** + [AWS Cost Explorer](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-forecast.html) + [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) + [AWS 料金見積りツール](https://calculator.aws/#/) + [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) + [AWS License Manager](https://aws.amazon.com/license-manager/) **関連する例:** + [ローンチ: 使用量ベースの予測が AWS Cost Explorer で使用可能に](https://aws.amazon.com/blogs/aws-cloud-financial-management/launch-usage-based-forecasting-now-available-in-aws-cost-explorer/) + [AWS Well-Architected ラボ: コストと使用量のガバナンス](https://wellarchitectedlabs.com/cost/100_labs/100_2_cost_and_usage_governance/) # COST01-BP04 組織のプロセスにコスト意識を採り入れる COST01-BP04 組織のプロセスにコスト意識を採り入れる コスト意識を高め、透明性を強化し、使用量に影響する新規または既存のプロセスにコストの説明責任を採り入れ、コスト意識に関する既存のプロセスを活用します。従業員のトレーニングにコスト意識の要素を採り入れます。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 ## 実装のガイダンス 実装のガイダンス コスト意識は、組織の新規および既存のプロセスに採り入れる必要があります。他のベストプラクティスの基盤となる前提条件の機能の 1 つです。可能な限り既存のプロセスを再利用し、修正することが推奨されます。これにより、俊敏性と速度への影響を最小化することができます。クラウドのコストをテクノロジーチームと、ビジネスチームおよび財務チームの意思決定者に報告して、コスト意識を高め、効率性についての重要業績評価指標 (KPI) を財務およびビジネス部門関係者向けに確立します。次の推奨事項は、ワークロードにコスト意識を実装するのに役立ちます。 + 変更管理に、変更による財務への影響を数値化するコスト測定が含まれていることを確認します。これは、コスト関連の懸念に積極的に対処し、コスト削減を強調するのに役立ちます。 + コストの最適化が、業務能力の中核をなす要素であることを確認します。例えば、既存のインシデントマネジメントプロセスを活用して、コストと使用量に関する異常値 (コスト超過) の根本原因を調査、特定することができます。 + オートメーションやツールにより、コスト削減とビジネス価値の実現を加速します。導入コストを考える場合、時間や費用の投資を正当化するために、投資収益率 (ROI)の要素を含むように話を組み立てます。 + コミットメントベースの購入オプション、共有サービス、マーケットプレイスでの購入を含むクラウド使用に対してショーバックまたはチャージバックを実施し、最もコストを意識したクラウド消費を促進することで、クラウドのコストを配分します。 + 既存のトレーニングおよび開発プログラムを拡張し、コスト意識向上のためのトレーニングを組織全体で実施します。これには継続的なトレーニングと認定が含まれることをお勧めします。これにより、コストと使用量を自己管理できる組織が育成されます。 + 次のような無料の AWS ネイティブツールを利用します。 [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/)io1[AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/)、および [AWS Budgets Reports](https://aws.amazon.com/about-aws/whats-new/2019/07/introducing-aws-budgets-reports/). 組織が一貫して [クラウド財務管理](https://aws.amazon.com/aws-cost-management/) (CFM) 実践を採用すると、そのような行動は、仕事の進め方や意思決定方法に定着していきます。その結果、新しいクラウドで生まれたアプリケーションを設計するデベロッパーから、これらの新しいクラウド投資の ROI を分析する財務マネージャーまで、よりコストを意識した文化が生まれます。 **実装手順** + ** 関連する組織のプロセスを把握する: **各組織単位は、そのプロセスをレビューし、コストと使用状況に影響を与えるプロセスを把握します。リソースの作成または終了につながるすべてのプロセスは、レビューの対象とする必要があります。インシデント管理やトレーニングなど、ビジネスにおけるコスト認識の維持につながるプロセスを探します。 + **コストを意識した自立的な企業文化を確立する:** すべての関係者がクラウドのコストを理解できるように、変更原因と影響をコストとして認識するようにします。そうすることで、組織がコストを意識したイノベーションの文化を自立的に確立することができます。 + ** コスト意識の要素を採り入れてプロセスを更新する:** 各プロセスは、コスト意識が浸透するように変更されます。このプロセスでは、コストの影響の評価などの追加の事前チェック、またはコストと使用状況の予想された変化が発生したかどうかを検証する事後チェックが必要になる場合があります。トレーニングやインシデント管理などのサポートプロセスは、コストと使用状況の項目を含むように拡張できます。 ご不明な点がありましたら、アカウントチームを通じて CFM のエキスパートにお問い合わせいただくか、以下のリソースや関連ドキュメントをご覧ください。 ## リソース リソース **関連するドキュメント:** + [AWS によるクラウド財務管理](https://aws.amazon.com/aws-cost-management/) **関連する例:** + [効率的なクラウドコスト管理の戦略](https://aws.amazon.com/blogs/enterprise-strategy/strategy-for-efficient-cloud-cost-management/) + [Cost Control Blog Series \$13: How to Handle Cost Shock (コスト管理ブログシリーズ \$13: コストショックの扱い方)](https://aws.amazon.com/blogs/aws-cloud-financial-management/cost-control-blog-series-3-how-to-handle-cost-shock/) + [AWS Cost Management 初心者ガイド](https://aws.amazon.com/blogs/aws-cloud-financial-management/beginners-guide-to-aws-cost-management/) # COST01-BP05 コスト最適化に関して報告および通知する COST01-BP05 コスト最適化に関して報告および通知する AWS Budgets と AWS Cost Anomaly Detection を設定して、目標に対するコストと使用量に関する通知を提供します。定例会議を開催して、このワークロードのコスト効率を分析し、社内にコスト意識を浸透させます。 **このベストプラクティスを活用しない場合のリスクレベル:** 低 ## 実装のガイダンス 実装のガイダンス 組織内のコストと使用量の最適化について、定期的に報告する必要があります。コスト最適化のための専用セッションの運用や、ワークロードの通常の運用レポートサイクルにコスト最適化を盛り込むことも意味があるでしょう。サービスとツールを使用して、コスト節減機会を特定し、実現します。[AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) では、ダッシュボードとレポートを提供します。設定された予算に対するコストと使用量の進行状況を追跡するには、 [AWS Budgets Reports](https://aws.amazon.com/about-aws/whats-new/2019/07/introducing-aws-budgets-reports/). 予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) を使用してカスタム予算を設定し、コストと使用量を追跡し、しきい値を超えた場合は E メールまたは Amazon Simple Notification Service (Amazon SNS) 通知でアラートを受信し、迅速に対応します。[優先予算](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-create.html) 期間を日次、月次、四半期ごと、または年次に設定し、特定の予算限度を設けて、予算しきい値に対する実際または予測されたコストと使用量の進捗状況に関して、常に情報を入手します。また、 [アラート](https://docs.aws.amazon.com/cost-management/latest/userguide/sns-alert-chime.html) と [アクション](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-controls.html) を設定し、アクションがアラートに対して自動的に実行するか、予算目標を超えたときに承認プロセスを通じて実行するようにします。 コストと使用量に関する通知を実装して、コストと使用量の変化が予想外の場合はすばやく対応できるようにします。[AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) では、イノベーションを遅らせることなく、予想外のコストを削減し、管理を強化できます。AWS Cost Anomaly Detection は異常な費用と根本原因を特定するので、予想外の請求のリスクを削減できます。3 つのシンプルなステップで、状況応じて独自のモニターを作成し、異常な費用が検出されたときにアラートを受け取ることができます。 また、 [Amazon Quick](https://aws.amazon.com/quicksight/) と AWS Cost and Usage Report (CUR) のデータを使用して、高度にカスタマイズされ、きめ細かなデータを含んだレポートを提供できます。Amazon Quick では、過去のコストと使用量またはコスト節減機会に関するレポートをスケジュールし、定期的なコストレポート E メールを受信できます。 予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)を使用すると、プロビジョニングされたリソースがコスト最適化のための AWS のベストプラクティスに準拠しているかどうかを確認するためのガイダンスが提供されます。 Savings Plans、リザーブドインスタンス、および Amazon Elastic Compute Cloud (Amazon EC2) の適切なサイズ設計に関する AWS Cost Explorer からのレコメンデーションを含んだレポートを定期的に作成して、定常状態のワークロード、アイドルおよび使用量の少ないリソースに関するコストの削減を開始します。デプロイされているリソースのうち、クラウドの無駄に関する費用を特定し、回収します。クラウドの無駄は、サイズ設定が正しくないリソースが作成されたときや、使用量のパターンが予想とは異なるときに発生します。AWS のベストプラクティスに従って無駄を少なくし、 [クラウドコストを最適化し、](https://aws.amazon.com/aws-cost-management/aws-cost-optimization/) 節減します。 定期的にレポートを作成し、リソースの購入オプションを改善することで、ワークロードの単価を下げることができます。Savings Plans、リザーブドインスタンス、Amazon EC2 スポットインスタンスなどの購入オプションは、耐障害性の高いワークロードのコストを最も低く抑え、関係者 (ビジネス所有者、財務チーム、テクノロジーチーム) がこれらのコミットメントの議論に参加できるようにするものです。 クラウドの総保有コスト (TCO) の削減に役立つ可能性のある機会または新しいリリースの発表を含んだレポートを共有します。新しいサービス、リージョン、機能、ソリューション、またはさらにコスト削減を達成する新しい方法を採用します。 **実装手順** + **AWS Budgets を設定する: **ワークロードのすべてのアカウントで AWS Budgets を設定します。タグを使用して、アカウント全体の支出の予算とワークロードの予算を設定します。 + [Well-Architected ラボ: コストと使用量のガバナンス](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_2_Cost_and_Usage_Governance/README.html) + **コスト最適化に関して報告する: **ワークロードの効率について話し合い、分析する定期的なミーティングを設定します。確立されたメトリクスを使用して、達成されたメトリクスとそれを達成するためにかかったコストを報告します。好ましくない傾向を特定して修正するとともに、組織全体で推進できるような改善傾向を特定します。報告には、アプリケーションチームおよび所有者、財務、および管理の担当者が関与する必要があります。 + [Well-Architected ラボ: 可視化](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_5_Cost_Visualization/README.html) ## リソース リソース **関連するドキュメント:** + [AWS Cost Explorer](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-what-is.html) + [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/) + [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) + [AWS Budgets のベストプラクティス](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-best-practices.html#budgets-best-practices-setting-budgets%3Fsc_channel=ba%26sc_campaign=aws-budgets%26sc_medium=manage-and-control%26sc_content=web_pdp%26sc_detail=how-do-I%26sc_outcome=aw%26trk=how-do-I_web_pdp_aws-budgets) + [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) + [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) + [Amazon S3 分析](https://docs.aws.amazon.com/AmazonS3/latest/userguide/analytics-storage-class.html) + [AWS Cost and Usage Report](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.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/100_5_Cost_Visualization/README.html) + [AWS クラウドコストの最適化を開始する主な方法](https://aws.amazon.com/blogs/aws-cloud-financial-management/key-ways-to-start-optimizing-your-aws-cloud-costs/) # COST01-BP06 コストをプロアクティブにモニタリングする COST01-BP06 コストをプロアクティブにモニタリングする ツールとダッシュボードを実装して、ワークロードのコストをプロアクティブにモニタリングします。通知を受けたときだけコストやカテゴリを見るのではなく、設定されたツールや既存のツールで定期的にコストを見直しましょう。コストをプロアクティブにモニタリングし、分析することで、ポジティブな傾向を把握し、組織全体で推進することが可能になります。 **このベストプラクティスを活用しない場合のリスクレベル:** 低 ## 実装のガイダンス 実装のガイダンス 例外や異常がある場合に限らず、組織内のコストと使用量を事前にモニタリングすることを推奨します。オフィスや職場環境全体を高度に可視化したダッシュボードにより、主な担当者が必要とする情報にアクセスできるようになります。また組織がコスト最適化を重視していることを示すことができます。可視化されたダッシュボードにより、 成功した事例を積極的に推進し、組織全体で実践することができます。 日次または頻繁なルーチンを作成するには、 [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) または [Amazon Quick](https://aws.amazon.com/quicksight/) など、その他のダッシュボードを使用して、コストを確認し、プロアクティブに分析します。AWS サービスの使用量とコストを AWS アカウントレベル、ワークロードレベル、または特定の AWS サービスレベルでグループ化とフィルタリングを使用して分析し、予想通りかどうかを検証します。時間単位、リソース単位の詳細度やタグを使用して、上位リソースの発生コストをフィルタリングし、特定します。また、 [Cost Intelligence Dashboard](https://wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/) という [Amazon Quick](https://aws.amazon.com/quicksight/) ソリューション (AWS ソリューションアーキテクトが構築) を使用して独自のレポートを作成して、予算と実際のコストおよび使用量を比較することもできます。 **実装手順** + **コスト最適化に関して報告する:** ワークロードの効率について話し合い、分析する定期的なミーティングを設定します。確立されたメトリクスを使用して、達成されたメトリクスとそれを達成するためにかかったコストを報告します。ネガティブな傾向を特定して修正し、ポジティブな傾向を特定して組織全体に普及させます。報告には、アプリケーションチームおよび所有者、財務、および管理の担当者が関与する必要があります。 + **コストと使用量について日次の詳細度の [AWS Budgets](https://aws.amazon.com/blogs/aws-cloud-financial-management/launch-daily-cost-and-usage-budgets/) を作成し、有効にすることで、潜在的なコスト超過を防ぐためのタイムリーなアクションを取ることができます。 ** AWS Budgets ではアラート通知を設定できるため、いずれかの予算タイプが事前設定のしきい値を超えた場合に通知を受けることができます。AWS Budgets を活用する最善の方法は、予想されるコストと使用量を限度として設定することです。そうすれば、予算を超えたものは使い過ぎとみなすことができます。 + **コストモニターとして AWS Cost Anomaly Detection を作成します。 ** [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) は、高度な機械学習テクノロジーを使用して、異常な支出と根本原因を特定するため、迅速に対策を講じることができます。評価したい支出セグメント (例えば、個々の AWS サービス、メンバーアカウント、コスト配分タグ、コストカテゴリ) を定義するコストモニターを設定することができ、アラート通知をいつ、どこで、どのように受け取るかを設定することが可能です。各モニターには、ビジネスオーナーや テクノロジーチーム向けの複数のアラートサブスクリプションをアタッチし、各サブスクリプションの名前、コスト影響しきい値、アラート頻度 (個別アラート、日次サマリー、週次サマリー) などを設定します。 + **AWS Cost Explorer を使用するか、AWS Cost and Usage Report (CUR) データを Amazon Quick ダッシュボードに統合して、組織のコストを視覚化します。** AWS Cost Explorer には、使いやすいインターフェイスがあり、AWS のコストと使用量を時系列で可視化し、理解し、管理することができます。最も [Cost Intelligence Dashboard](https://wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/) カスタマイズ可能でアクセスしやすいダッシュボードで、独自のコスト管理、最適化ツールの基礎作りを支援します。 ## リソース リソース **関連するドキュメント:** + [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) + [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) + [日次コストおよび使用量の予算](https://aws.amazon.com/blogs/aws-cloud-financial-management/launch-daily-cost-and-usage-budgets/) + [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) **関連する例:** + [Well-Architected ラボ: 可視化](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_5_Cost_Visualization/README.html) + [Well-Architected ラボ: 高度な可視化](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_5_Cost_Visualization/README.html) + [Well-Architected ラボ: Cloud Intelligence Dashboards](https://wellarchitectedlabs.com/cost/200_labs/200_cloud_intelligence/) + [Well-Architected ラボ: コストの可視化](https://wellarchitectedlabs.com/cost/200_labs/200_5_cost_visualization/) + [Slack による AWS Cost Anomaly Detection アラート](https://aws.amazon.com/aws-cost-management/resources/slack-integrations-for-aws-cost-anomaly-detection-using-aws-chatbot/) # COST01-BP07 新しいサービスリリースに関する最新情報を把握しておく COST01-BP07 新しいサービスリリースに関する最新情報を把握しておく エキスパートや AWS パートナーに定期的に相談して、コストの低いサービスと機能を検討します。AWS のブログやその他の情報ソースを確認します。 **このベストプラクティスを活用しない場合のリスクレベル:** 低 ## 実装のガイダンス 実装のガイダンス AWS は常に新しい機能を追加しているため、最新のテクノロジーを利用して、実験とイノベーションをより迅速に行うことができます。新しい AWS のサービスや機能を実装することでワークロードのコスト効率を改善できる場合があります。新しいサービスと機能のリリースに関する情報を入手するには、 [AWS コスト管理](https://aws.amazon.com/aws-cost-management/)、 [AWS ニュースブログ](https://aws.amazon.com/blogs/aws/)、 [AWS コスト管理ブログ](https://aws.amazon.com/blogs/aws-cloud-financial-management/)、および [AWS の最新情報](https://aws.amazon.com/new/) を定期的に確認してください。「最新情報」では、AWS サービス、機能、リージョン拡大の発表があった際に、その概要をお知らせしています。 **実装手順** + **ブログをサブスクライブする:** AWS ブログのページにアクセスし、最新情報ブログやその他の関連ブログをサブスクライブします。E メールアドレスを記載して、 [通信方法](https://pages.awscloud.com/communication-preferences?languages=english) ページでサインアップできます。 + **AWS ニュースを購読する: **新しいサービスと機能のリリースに関する情報を入手するには、 [AWS ニュースブログ](https://aws.amazon.com/blogs/aws/) と [AWS の最新情報](https://aws.amazon.com/new/) を定期的に確認してください。RSS フィード、または E メールでお知らせやリリースを購読することができます。 + **AWS の値下げをフォローする:** すべてのサービスにおいて定期的な値下げを行うことは、AWS がその規模から得られる経済的な効率性をお客様に還元するための標準的な方法となっています。2022 年 4 月時点で、AWS は 2006 年のサービス提供開始以来、115 回の料金引き下げを行ってきました。料金面の懸念から経営判断を保留しているものがあれば、値下げや新サービス統合後に再度見直すことも可能です。Amazon Elastic Compute Cloud (Amazon EC2) インスタンスも含め、以前の値下げについては、 [AWS ニュースブログの料金引き下げカテゴリを参照してください](https://aws.amazon.com/blogs/aws/category/price-reduction/). + ** AWS のイベントおよび交流: **ローカルの AWS サミットや、地域内の他の組織との交流に参加しましょう。直接参加できない場合は、バーチャルイベントに参加して、AWS のエキスパートや他のお客様のビジネスケースから情報を得るようにしてください。 + ** アカウントチームとのミーティングを設ける: **アカウントチームとの定期的なミーティングを設定し、チームと会い、業界の動向と AWS のサービスについて話し合います。アカウントマネージャー、ソリューションアーキテクト、サポートチームに相談する。 ## リソース リソース **関連するドキュメント:** + [AWS コスト管理](https://aws.amazon.com/aws-cost-management/) + [AWS の最新情報](https://aws.amazon.com/new/) + [AWS ニュースブログ](https://aws.amazon.com/blogs/aws/) **関連する例:** + [Amazon EC2 - IT コストの最適化と削減に取り組んだ 15 年間](https://aws.amazon.com/blogs/aws-cost-management/amazon-ec2-15th-years-of-optimizing-and-saving-your-it-costs/) + [AWS ニュースブログ - 料金引き下げ](https://aws.amazon.com/blogs/aws/category/price-reduction/) # 経費支出と使用量の認識 経費支出と使用量の認識 **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 組織の要件に基づいてポリシーを策定する 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 目標およびターゲットを策定する 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 アカウント構造を実装する 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 グループとロールを実装する 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 コストコントロールを実装する 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 プロジェクトのライフサイクルを追跡する 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 詳細情報ソースを設定する 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 コスト属性カテゴリを特定する 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 組織のメトリクスを確立する 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 請求およびコスト管理ツールを設定する 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 コストと使用状況に組織情報を追加する 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 ワークロードメトリクスに基づいてコストを配分する 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 ライフタイム全体にわたってリソースを追跡する 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 削除プロセスを実装する COST04-BP02 削除プロセスを実装する 孤立したリソースを特定して削除するためのプロセスを実装します。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 ## 実装のガイダンス 実装のガイダンス 組織全体の標準化プロセスで、使用されていないリソースを特定して廃棄します。検索の実行頻度および組織のすべての要件を確実に満たすために、このプロセスではリソースを削除するプロセスを定義する必要があります。 **実装手順** + **削除プロセスを作成して実装する: **ワークロードの開発者や所有者と協力して、ワークロードとそのリソースの削除プロセスを構築します。このプロセスでは、ワークロードが使用中であるかどうか、および各ワークロードリソースが使用中であるかどうかを確認する方法を採り入れる必要があります。このプロセスでは、リソースを削除するために必要なステップを採り入れ、サービスから削除すると同時に、規制要件の遵守を確保する必要もあります。ライセンスやアタッチされたストレージなど、関連するリソースも対象となります。このプロセスでは、削除プロセスが実行されたことをワークロードの所有者に通知する必要があります。 ## リソース リソース **関連するドキュメント:** + [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) + [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) # COST04-BP03 リソースを削除する COST04-BP03 リソースを削除する 定期監査や使用状況の変化などのイベントを契機として、リソースを削除します。通常、削除は定期的に行われ、手動または自動で行われます。 **このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム ## 実装のガイダンス 実装のガイダンス 使用していないリソースを検索する場合は節減額の程度によって検索頻度と投入する労力を決定する必要があるため、コスト発生額の小さいアカウントの分析は、コスト発生額が高額のアカウントよりも頻度を下げるべきです。イベントの検索および廃止は、製品が寿命を迎えた場合や交換する場合など、ワークロードの状態の変化によってトリガーされます。イベントの検索および廃止は、市況の変化や製品終了などの外部イベントによってトリガーされる場合もあります。 **実装手順** + **リソースを削除する: **削除プロセスを使用して、孤立したと識別された各リソースを削除します。 ## リソース リソース **関連するドキュメント:** + [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) + [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) # COST04-BP04 自動的にリソースを削除する 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) # 費用対効果の高いリソース 費用対効果の高いリソース **Topics** + [ # COST 5 サービスを選択する際、どのようにコストを評価すればよいですか? ](w2aac19c13b9b5.md) + [ # COST 6 リソースタイプ、リソースサイズ、およびリソース数を選択する際、コスト目標を達成するにはどうすればよいですか? ](w2aac19c13b9b7.md) + [ # COST 7 コスト削減のために、どのように料金モデルを使用すればよいですか? ](w2aac19c13b9b9.md) + [ # COST 8 データ転送料金はどのように計画すればよいですか？ ](w2aac19c13b9c11.md) # COST 5 サービスを選択する際、どのようにコストを評価すればよいですか? Amazon EC2、Amazon EBS、Amazon S3 は、基盤となる AWS のサービスです。Amazon RDS や Amazon DynamoDB などのマネージドサービスは 、より高レベル、つまりアプリケーションレベルの AWS のサービスです。基盤となるサービスやマネージドサービスを適切に選択することで、このワークロードのコストを最適化できます。例えば、マネージドサービスを使用することで、管理や運用によって発生するオーバーヘッドを削減またはゼロにでき、アプリケーション開発やビジネス上の他の活動に注力できるようになります。 **Topics** + [ # COST05-BP01 組織のコスト要件を特定する ](cost_select_service_requirements.md) + [ # COST05-BP02 このワークロードのすべてのコンポーネントを分析する ](cost_select_service_analyze_all.md) + [ # COST05-BP03 各コンポーネントの詳細な分析を実行する ](cost_select_service_thorough_analysis.md) + [ # COST05-BP04 コスト効率の高いライセンスを提供するソフトウェアを選択する ](cost_select_service_licensing.md) + [ # COST05-BP04 組織の優先順位に従ってコストが最適化されるようにこのワークロードのコンポーネントを選択する ](cost_select_service_select_for_cost.md) + [ # COST05-BP06 異なる使用量について経時的なコスト分析を実行する ](cost_select_service_analyze_over_time.md) # COST05-BP01 組織のコスト要件を特定する COST05-BP01 組織のコスト要件を特定する チームメンバーと協力して、コストの最適化とこのワークロードのその他の柱とのバランス (パフォーマンスや信頼性など) を定義します。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 ## 実装のガイダンス 実装のガイダンス ワークロードのサービスを選択する場合は、組織の優先順位を理解することが重要です。パフォーマンスや信頼性などの Well-Architected の柱と、コストとのバランスが取れているようにします。十分にコスト最適化されたワークロードとは組織の要件に最も適合するソリューションであって、必ずしも最低コストのソリューションとは限りません。組織内のすべてのチームと会合し、製品、ビジネス、技術、財務などの情報を収集します。 **実装手順** + ** 組織のコスト要件を特定する: **製品管理、アプリケーション所有者、開発および運用チーム、管理、財務ロールのメンバーなど、組織のチームメンバーとミーティングを行います。このワークロードとそのコンポーネントに対して Well-Architected の柱に優先順位を付けると、柱が順番に表示されたリストが出力されます。また、それぞれに重み付けを追加することもできます。これにより、柱がどの程度余分に重点化されているか、2 つの柱間の重点度がどの程度類似しているかを示すことができます。 ## リソース リソース **関連するドキュメント:** + [AWS 総保有コスト (TCO) 計算ツール](https://aws.amazon.com/tco-calculator/) + [Amazon S3 ストレージクラス](https://aws.amazon.com/s3/storage-classes/) + [クラウド製品](https://aws.amazon.com/products/) # COST05-BP02 このワークロードのすべてのコンポーネントを分析する COST05-BP02 このワークロードのすべてのコンポーネントを分析する 現在のサイズやコストに関係なく、すべてのワークロードが分析されることを確認します。見直しを行う際には、現在のコストや予想コストなどの潜在的利益を織り込む必要があります。 **このベストプラクティスを活用しない場合のリスクレベル:** 低 ## 実装のガイダンス 実装のガイダンス ワークロードのすべてのコンポーネントについて詳細な分析を実行します。分析コストと、そのライフサイクルで可能と考えられるワークロードの節減額のバランスを取るようにします。コンポーネントの現在の影響、および将来的に与えると考えられる影響を洗い出す必要があります。例えば、提案されたリソースのコストが月額 10 ドルで、予測負荷が月額 15 ドルを超えない場合に、コストを 50% (月額 5 ドル) 削減するために 1 日分の労力を費やすようでは、システムの寿命全体にわたって得られると考えられる利益を超えることになるかもしれません。データに基づくより高速でより効率的な予測を使用すると、このコンポーネントの全体的な成果を最善のものにできます。 ワークロードは時間の経過とともに変化する可能性があり、ワークロードのアーキテクチャや使用方法が変化すると、適切だったサービスの組み合わせが最適ではなくなってしまうことがあります。サービスの選択に関する分析には、現在および将来のワークロードの状態と使用量レベルが組み込まれる必要があります。将来のワークロードの状態や使用量に合わせてサービスを運用すると、今後の変更に必要な労力を軽減または削除できることになり、全体的なコストを削減できます。 [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) および [AWS Cost and Usage Report](https://aws.amazon.com/aws-cost-management/aws-cost-and-usage-reporting/) (CUR) では、PoC (概念実証) または実行中の環境のコストを分析できます。また、 [AWS 料金見積りツール](https://calculator.aws/#/) を使用して、ワークロードのコストを見積もることもできます。 **実装手順** + **ワークロードコンポーネントをリスト化する: **すべてのワークロードコンポーネントのリストを作成します。これは、各コンポーネントが分析されたことを確認するための検証として使用されます。費やされる労力は、組織の優先順位によって定義されたワークロードの重要性を反映している必要があります。リソースをグループ化すると、機能的に効率が向上します (例えば、複数のデータベースがある場合は本番データベースストレージ)。 + **コンポーネントリストに優先順位を付ける:** コンポーネントリストを取得して、労力をかける順で優先順位を付けます。これは通常、コンポーネントのコストが最も高価なものから最も安価なものへ、または組織の優先順位で定義されている重要度の順に並べられます。 + ** 分析を実行する:** リストの各コンポーネントについて、使用可能なオプションとサービスを確認し、組織の優先順位に最適なオプションを選択します。 ## リソース リソース **関連するドキュメント:** + [AWS 料金見積りツール](https://calculator.aws/#/) + [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) + [Amazon S3 ストレージクラス](https://aws.amazon.com/s3/storage-classes/) + [クラウド製品](https://aws.amazon.com/products/) # COST05-BP03 各コンポーネントの詳細な分析を実行する COST05-BP03 各コンポーネントの詳細な分析を実行する 各コンポーネントの、組織にとっての全体的なコストを調べます。運用および管理のコスト、特にマネージドサービスを使用するコストを考慮して総所有コストを調べます。見直しを行う際には、分析に費やされた時間がコンポーネントのコストに比例しているなどの潜在的利益を織り込む必要があります。 **このベストプラクティスを活用しない場合のリスクレベル:** 低 ## 実装のガイダンス 実装のガイダンス 時間短縮を検討して、チームが技術的な負債の返済、イノベーション、付加価値機能に集中できるようにします。例えば、オンプレミス環境からクラウド環境に「リフトアンドシフト」式にできるだけ早急に移行して、最適化は後回しにする必要性が生じる場合があります。ライセンスコストを排除または削減するマネージドサービスを利用して、コスト削減が可能なところを模索することには時間をかけるだけの価値があります。マネージドサービスによってサービス維持に伴う運用上および管理上の負担が軽減されるため、イノベーションに集中できます。さらに、マネージドサービスはクラウドのスケールで運用されるため、トランザクション単位またはサービス単位でコストを削減できます。 通常、マネージドサービスは、十分なキャパシティーを確保するために設定できる属性を備えています。この属性を設定およびモニタリングして、余剰キャパシティーを最小限に抑え、パフォーマンスを最大化する必要があります。AWS マネジメントコンソール や AWS API および SDK を使用して AWS Managed Services の属性を変更し、需要の変化に合わせてリソースのニーズを調整できます。例えば、Amazon EMR クラスターまたは Amazon Redshift クラスターのノード数を増減して、規模をスケールアウトまたはスケールインできます。 また、AWS リソースの複数のインスタンスを圧縮して、高密度に使用することもできます。例えば、単一の Amazon Relational Database Service (Amazon RDS) データベースインスタンスで、複数の小さなデータベースをプロビジョニングできます。使用量が増えたら、スナップショットや復元プロセスを使用して、そのデータベースの 1 つを専用 Amazon RDS データベースインスタンスに移行できます。 マネージドサービスでワークロードをプロビジョニングする際は、サービスキャパシティーの調整要件を理解する必要があります。主な要件としては、時間、労力、通常のワークロードオペレーションへの影響などが一般には考えられます。プロビジョニングされたリソースでは変更が発生するまでの時間が許容され、このために必要なオーバーヘッドをプロビジョニングする必要があります。サービス変更に必要な継続的労力は、システムに統合する API と SDK やAmazon CloudWatchなどのモニタリングツールを使用することで、実質ゼロまで減らすことができます。 [Amazon RDS](https://aws.amazon.com/rds/)io1[Amazon Redshift](https://aws.amazon.com/redshift/)、および [Amazon ElastiCache](https://aws.amazon.com/elasticache/) はマネージドデータベースサービスを提供します。[Amazon Athena](https://aws.amazon.com/athena/)io1[Amazon EMR](https://aws.amazon.com/emr/)、および [Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/) はマネージド型分析サービスを提供します。 [AMS](https://aws.amazon.com/managed-services/) は、エンタープライズのお客様やパートナーに代わって AWS インフラストラクチャを運用するサービスです。コンプライアンスに準拠したセキュアな環境で、ワークロードをデプロイできます。AMS では、エンタープライズクラウド運用モデルとオートメーションを使用して、組織の要件を満たし、クラウド移行を高速化し、継続的な管理コストを削減できます。 **実装手順** + ** 詳細な分析を実行する: **コンポーネントリストを使用して、各コンポーネントを優先度が高いものから処理します。優先度がより高く、より多くのコストがかかるコンポーネントについては、追加の分析を実行し、利用可能なすべてのオプションとその長期的な影響を評価します。優先度の低いコンポーネントの場合、使用状況の変化によってコンポーネントの優先度が変更するかどうかを評価し、かける労力の適切性の分析を実行します。 ## リソース リソース **関連するドキュメント:** + [AWS 総保有コスト (TCO) 計算ツール](https://aws.amazon.com/tco-calculator/) + [Amazon S3 ストレージクラス](https://aws.amazon.com/s3/storage-classes/) + [クラウド製品](https://aws.amazon.com/products/) # COST05-BP04 コスト効率の高いライセンスを提供するソフトウェアを選択する COST05-BP04 コスト効率の高いライセンスを提供するソフトウェアを選択する オープンソースソフトウェアは、ワークロードに多大なコストをもたらすソフトウェアライセンスコストを排除することができます。ライセンスされたソフトウェアが必要な場合は、CPU などの任意の属性に結びついたライセンスは避け、出力または結果に結びついたライセンスを探します。これらのライセンスのコストは、提供するメリットに応じてより密にスケールされます。 **このベストプラクティスが確立されていない場合のリスクレベル:** 低 ## 実装のガイダンス 実装のガイダンス ソフトウェアライセンスのコストは、オープンソースソフトウェアを使用することで削減できます。オープンソースソフトウェアへの変更は、ワークロードサイズが拡大するにつれ、ワークロードコストに大きな影響を与える可能性があります。ライセンスを取得したソフトウェアの利点を総コストと比較して測定し、ワークロードを最適化します。ライセンス変更とその変更がワークロードコストに与える影響をモデリングします。あるベンダーがデータベースライセンスのコストを変更したなら、それがワークロードの全体的な効率にどのような影響を与えるかを調査します。ベンダーの過去の価格アナウンスを検討して、ベンダー製品全体のライセンス変更の傾向を検討してください。ライセンスコストは、ハードウェアごとにスケールするライセンス (CPU バウンドライセンス) など、スループットや使用量とは関係なくスケールされる場合があります。こうしたライセンスは、それに伴う成果が見られないままコストが急増する可能性があるため、避けてください。 **実装手順** + ** ライセンスオプションを分析する: **利用可能なソフトウェアのライセンス条項を確認します。必要な機能を備えたオープンソースのバージョンを探し、ライセンスされたソフトウェアの利点がコストを上回っているかどうかを確認します。有利な条件は、それが提供するメリットに照らして、コストを正当化します。 + ** ソフトウェアプロバイダーを分析する: **ベンダーからの料金またはライセンスの変更履歴を確認します。特定のベンダーのハードウェアまたはプラットフォームで実行することについての懲罰的な条件など、結果に見合わない変更を調べます。また、監査の実行方法や課される可能性のある罰則についても確認します。 ## リソース リソース **関連するドキュメント:** + [AWS 総保有コスト (TCO) 計算ツール](https://aws.amazon.com/tco-calculator/) + [Amazon S3 ストレージクラス](https://aws.amazon.com/s3/storage-classes/) + [クラウド製品](https://aws.amazon.com/products/) # COST05-BP04 組織の優先順位に従ってコストが最適化されるようにこのワークロードのコンポーネントを選択する COST05-BP04 組織の優先順位に従ってコストが最適化されるようにこのワークロードのコンポーネントを選択する すべてのコンポーネントを選択したときのコストを考慮します。これには、アプリケーションレベルのサービスとマネージドサービス (Amazon Relational Database Service ([Amazon RDS](Amazon%20Relational%20Database%20Service%20(Amazon%20RDS))), [Amazon DynamoDB](https://docs.aws.amazon.com/dynamodb/?id=docs_gateway)、Amazon Simple Notification Service ([Amazon SNS](https://docs.aws.amazon.com/sns/?id=docs_gateway))、Amazon Simple Email Service ([Amazon SES](https://docs.aws.amazon.com/ses/?id=docs_gateway)) など) を使用して組織の全体的なコストを削減することが含まれます。サーバーレスやコンテナをコンピューティングに使用します。AWS Lambda、静的ウェブサイト用の Amazon Simple Storage Service ([Amazon S3](https://docs.aws.amazon.com/s3/?id=docs_gateway))、Amazon Elastic Container Service ([Amazon ECS](https://docs.aws.amazon.com/ecs/?id=docs_gateway)) などです。オープンソースソフトウェア、またはライセンス料金のないソフトウェア (コンピューティングワークロード用の Amazon Linux、データベースを [Amazon Aurora](https://docs.aws.amazon.com/rds/?id=docs_gateway)に移行するなど) を使用して、ライセンスコストを最小限に抑えます。 **このベストプラクティスを活用しない場合のリスクレベル:** 低 ## 実装のガイダンス 実装のガイダンス 以下のサーバーレスまたはアプリケーションレベルのサービスを使用できます。 [AWS Lambda](https://aws.amazon.com/lambda/)io1[Amazon Simple Queue Service (Amazon SQS)](https://aws.amazon.com/sqs/)io1 [Amazon SNS](https://docs.aws.amazon.com/sns/?id=docs_gateway)、および [Amazon SES](https://docs.aws.amazon.com/ses/?id=docs_gateway).これらのサービスではリソースを管理する必要がなく、コード実行、キューサービス、メッセージ配信の機能を利用できます。もう 1 つの利点は、使用量に応じてパフォーマンスとコストをスケールするため、コスト配分とコストの帰属が効率的になることです。 サーバーレスの詳細については、 [Well-Architected サーバーレスアプリケーションレンズのホワイトペーパー](https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/welcome.html)を参照してください。 ** 実装手順** + ** 各サービスを選択してコストを最適化する: **優先順位リストと分析を使用して、組織の優先順位に最も合致する各オプションを選択します。 ## リソース リソース **関連するドキュメント:** + [AWS 総保有コスト (TCO) 計算ツール](https://aws.amazon.com/tco-calculator/) + [Amazon S3 ストレージクラス](https://aws.amazon.com/s3/storage-classes/) + [クラウド製品](https://aws.amazon.com/products/) # COST05-BP06 異なる使用量について経時的なコスト分析を実行する COST05-BP06 異なる使用量について経時的なコスト分析を実行する ワークロードは時間の経過とともに変化することがあります。それぞれのサービスまたは機能のコスト効率は、使用レベルによって異なります。各コンポーネントについて予想使用量に基づく経時的な分析を実行することで、ワークロードのコスト効率性がそのライフタイム全体にわたって維持されます。 **このベストプラクティスを活用しない場合のリスクレベル:** 低 ## 実装のガイダンス 実装のガイダンス AWS で新しいサービスや機能がリリースされると、ワークロードに最適なサービスが変化する可能性があります。求められる労力は、潜在的な利点が反映されたものである必要があります。ワークロードレビューの頻度は、組織の要件によって異なります。ワークロードにかなりのコストがかかっている場合、新しいサービスの運用が早いほどコスト削減が最大になるため、レビュー頻度が高い方が有利です。レビューのトリガーとしては、使用パターンの変化も挙げられます。使用量が大幅に変化した場合は、別のサービスを使った方がよい場合もあります。たとえば、データ転送速度が高い場合、Direct Connect サービスのほうが VPN よりも安価で、必要な接続性能を提供できます。サービス変更時に起こりうる影響を予測すると、使用量レベルのトリガーをモニタリングできるため、費用対効果が最も高いサービスを速やかに運用できます。 **実装手順** + ** 予測された使用パターンを定義する: **マーケティングや製品所有者などの組織と協力して、ワークロードに対して期待および予測される使用パターンを文書化します。 + ** 予測された使用量に基づくコスト分析を実行する:** 定義された使用パターンを使用して、これらの各ポイントで分析を実行します。分析作業は、潜在的な結果を反映する必要があります。例えば、使用量の変化が大きい場合は、コストと変更を確認するために詳細な分析を実行する必要があります。 ## リソース リソース **関連するドキュメント:** + [AWS 総保有コスト (TCO) 計算ツール](https://aws.amazon.com/tco-calculator/) + [Amazon S3 ストレージクラス](https://aws.amazon.com/s3/storage-classes/) + [クラウド製品](https://aws.amazon.com/products/) # COST 6 リソースタイプ、リソースサイズ、およびリソース数を選択する際、コスト目標を達成するにはどうすればよいですか? 対象タスクについて適切なリソースサイズおよびリソース数を選択していることを確認します。最もコスト効率の高いタイプ、サイズ、数を選択することで、無駄を最小限に抑えます。 **Topics** + [ # COST06-BP01 コストモデリングを実行する ](cost_type_size_number_resources_cost_modeling.md) + [ # COST06-BP02 データに基づいてリソースタイプ、リソースサイズ、リソース数を選択する ](cost_type_size_number_resources_data.md) + [ # COST06-BP03 メトリクスに基づいて自動的にリソースタイプ、リソースサイズ、リソース数を選択する ](cost_type_size_number_resources_metrics.md) # COST06-BP01 コストモデリングを実行する COST06-BP01 コストモデリングを実行する 組織の要件を特定し、ワークロードとその各コンポーネントのコストモデリングを実行します。さまざまな予測負荷におけるワークロードのベンチマークアクティビティを実行し、コストを比較します。モデリングの際には、潜在的な利点を織り込む必要があります。例えば、費やされた時間がコンポーネントのコストに比例しているなどです。 **このベストプラクティスが確立されていない場合のリスクレベル:** 高 ## 実装のガイダンス 実装のガイダンス ワークロードと各コンポーネントのコストモデリングを実行してリソース間のバランスを把握し、特定のパフォーマンスレベルに応じてワークロード内の各リソースの適切なサイズを見つけます。さまざまな予測負荷におけるワークロードのベンチマークアクティビティを実行し、コストを比較します。モデリングの際には、費やした時間がコンポーネントのコストまたは予想される削減額に比例しているといった潜在的な利点を織り込む必要があります。ベストプラクティスについては、「 *レビュー* 」セクション ( [パフォーマンス効率の柱に関するホワイトペーパー](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/review.html)内) を参照してください。 [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) は、ワークロードの実行におけるコストモデリングに役立ちます。使用履歴に基づき、コンピューティングリソースの正しいサイズ設定に関するレコメンデーションを提供します。これがコンピューティングリソースにとって理想的なデータソースである理由は、リスクレベルに応じて複数のレコメンデーションを作成できる機械学習が使われている無料サービスだからです。また、 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) および [Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) をデータソースとしてカスタムログと併用して、他のサービスやワークロードコンポーネントの適切なサイズ設定のオペレーションを行うこともできます。 コストモデリングのデータとメトリクスに関する推奨事項は以下の通りです。 + モニタリングにはエンドユーザーのエクスペリエンスを正確に反映する必要があります。対象期間に適切な間隔を選択して、平均の変わりに最大値や 99 パーセンタイル値をじっくり見極めます。 + すべてのワークロードのサイクルをカバーするために必要な分析期間の適切な間隔を選択します。たとえば、分析を 2 週間間隔で実行する場合、1 か月サイクルで使用率が高くても見逃す場合があり、過小プロビジョニングにつながる可能性があります。 **実装手順 ** + ** コストモデリングを実行する: **ワークロードまたは概念実証を、テストする特定のリソースタイプとサイズを持つ別のアカウントにデプロイします。テストデータを使用してワークロードを実行し、出力結果のほか、テスト実行時のコストデータを記録します。次に、ワークロードを再デプロイするか、リソースタイプとサイズを変更して、テストを再実行します。 ## リソース リソース **関連するドキュメント:** + [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) + [Amazon CloudWatch の特徴](https://aws.amazon.com/cloudwatch/features/) + [Amazon EC2 Right Sizing によるコスト最適化](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-rightsizing.html) + [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) # COST06-BP02 データに基づいてリソースタイプ、リソースサイズ、リソース数を選択する COST06-BP02 データに基づいてリソースタイプ、リソースサイズ、リソース数を選択する ワークロードとリソースの特性に関するデータに基づいて、リソースのサイズやタイプを選択します。例えば、コンピューティング、メモリ、スループット、書き込み頻度などです。この選択は通常、以前の (オンプレミス) バージョンのワークロード、ドキュメント、ワークロードに関する他の情報ソースを用いて行います。 **このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム ## 実装のガイダンス 実装のガイダンス ワークロードとリソースの特性 (例えば、コンピューティング、メモリ、スループット、書き込み頻度) に基づいて、リソースのサイズやタイプを選択します。この選択は通常、コストモデリング、以前のバージョンのワークロード (オンプレミスバージョンなど)、ドキュメント、ワークロードに関する他の情報ソース (ホワイトペーパー、公開ソリューション) を用いて行います。 **実装手順** + **データに基づいてリソースを選択する:** コストモデリングデータを使用して、予想されるワークロードの使用レベルを選択し、指定したリソースタイプとサイズを選択します。 ## リソース リソース **関連するドキュメント:** + [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) + [Amazon CloudWatch の特徴](https://aws.amazon.com/cloudwatch/features/) + [EC2 Right Sizing によるコスト最適化](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-rightsizing.html) # COST06-BP03 メトリクスに基づいて自動的にリソースタイプ、リソースサイズ、リソース数を選択する COST06-BP03 メトリクスに基づいて自動的にリソースタイプ、リソースサイズ、リソース数を選択する 現在実行しているワークロードからのメトリクスを用いて、コストを最適化する適切なサイズやタイプを選択します。Amazon Elastic Compute Cloud (Amazon EC2)、Amazon DynamoDB、Amazon Elastic Block Store (Amazon EBS) (PIOPS)、Amazon Relational Database Service (Amazon RDS)、Amazon EMR、ネットワークなどのサービスに、適切なスループット、サイジング、ストレージをプロビジョニングします。これは、自動スケーリングなどのフィードバックループまたはワークロードのカスタムコードで行うことができます。 **このベストプラクティスを活用しない場合のリスクレベル:** 低 ## 実装のガイダンス 実装のガイダンス ワークロード内に、実行中のワークロードのアクティブなメトリクスを使用してそのワークロードを変更するフィードバックループを作成します。また、 [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)などのマネージドサービスを使用して、正しいサイズ変更オペレーションを実行できるように設定します。AWS は、 [API、SDK](https://aws.amazon.com/developer/tools/)のほか、最低限の労力でリソースを変更するための機能も提供しています。Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの停止と起動のワークロードをプログラムして、インスタンスサイズやインスタンスタイプを変更できます。これにより、正しいサイズ設定による利点が得られるだけでなく、変更に必要なほぼすべての運用コストを削減することもできます。 一部の AWS のサービスには、 [Amazon Simple Storage Service (Amazon S3) Intelligent-Tiering](https://aws.amazon.com/about-aws/whats-new/2018/11/s3-intelligent-tiering/)などのタイプやサイズの自動選択が組み込まれています。Amazon S3 Intelligent-Tiering では、使用パターンに基づいて、高頻度アクセスと低頻度アクセスの 2 つのアクセスティア間でデータが自動的に移動します。 **実装手順** + ** ワークロードメトリクスを設定する: **ワークロードの主要メトリクスをキャプチャしていることを確認します。これらのメトリクスは、ワークロード出力などのカスタマーエクスペリエンスに関する示唆を提供し、CPU やメモリの使用状況などのリソースのタイプとサイズの違いに合わせて調整されます。 + ** 適切なサイズのレコメンデーションを表示する: **AWS Compute Optimizer の適切なサイズのレコメンデーションを使用して、ワークロードを調整します。 + ** メトリクスに基づいて自動的にリソースタイプとリソースサイズを選択する: **ワークロードメトリクスを使用して、ワークロードリソースを手動または自動的に選択します。AWS Auto Scaling を設定したり、アプリケーション内でコードを実装したりすると、頻繁な変更が要求される場合に必要となる労力を減らすことができるほか、手動プロセスより早く変更を実装できる可能性もあります。 ## リソース リソース **関連するドキュメント:** + [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) + [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) + [Amazon CloudWatch の特徴](https://aws.amazon.com/cloudwatch/features/) + [CloudWatch 準備作業](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/GettingSetup.html) + [CloudWatch カスタムメトリクスの発行](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) + [Cost Optimization: Amazon EC2 Right Sizing](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-rightsizing.html) + [Getting Started With Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html) + [Amazon S3 Intelligent-Tiering](https://aws.amazon.com/about-aws/whats-new/2018/11/s3-intelligent-tiering/) + [Launch an EC2 Instance Using the SDK](https://docs.aws.amazon.com/sdk-for-net/v2/developer-guide/run-instance.html) # COST 7 コスト削減のために、どのように料金モデルを使用すればよいですか? リソースのコストを最小限に抑えるのに最も適した料金モデルを使用します。 **Topics** + [ # COST07-BP01 料金モデルの分析を実行する ](cost_pricing_model_analysis.md) + [ # COST07-BP02 コストに基づいてリージョンを選択する ](cost_pricing_model_region_cost.md) + [ # COST07-BP03 費用対効果の高い条件を提供するサードパーティーの契約を選択する ](cost_pricing_model_third_party.md) + [ # COST07-BP04 このワークロードのすべてのコンポーネントに対して料金モデルを実装する ](cost_pricing_model_implement_models.md) + [ # COST07-BP05 管理アカウントレベルで料金モデル分析を実行する ](cost_pricing_model_master_analysis.md) # COST07-BP01 料金モデルの分析を実行する COST07-BP01 料金モデルの分析を実行する ワークロードの各コンポーネントを分析します。コンポーネントとリソースが長期間実行されるか (コミットメント割引)、動的および短期実行 (スポットインスタンスまたはオンデマンドインスタンス) とするかを決定します。AWS Cost Explorer のレコメンデーション機能を使用して、ワークロードに関する分析を実行します。 **このベストプラクティスが確立されていない場合のリスクレベル:** 高 ## 実装のガイダンス 実装のガイダンス AWS には複数の [料金モデルがあり、](https://aws.amazon.com/pricing/) 組織のニーズに合った最も費用対効果の高い方法でリソースの料金をお支払いいただくことができます。 **実装手順** + ** コミットメント割引の分析を実行する:** アカウントで Cost Explorer を使用して、Savings Plans とリザーブドインスタンスの推奨事項を確認します。必要な割引を適用し、リスクを認識した上で、正しい推奨事項を実装していることを確認するには、 [Well-Architected ラボ](https://wellarchitectedlabs.com/cost/costeffectiveresources/)に従ってください。 + **ワークロードの伸縮性を分析する: **Cost Explorer の時間単位の粒度またはカスタムダッシュボードを使用します。ワークロードの伸縮性を分析します。実行中のインスタンス数の定期的な変更を調べます。短期間のインスタンスはスポットインスタンスまたはスポットフリートの候補です。 + [Well-Architected ラボ: Cost Explorer](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_5_Cost_Visualization/Lab_Guide.html#Elasticity) + [Well-Architected ラボ: コストの可視化](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_5_Cost_Visualization/README.html) ## リソース リソース **関連するドキュメント:** + [リザーブドインスタンスの推奨事項へのアクセス](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-recommendations.html) + [インスタンス購入オプション](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html) **関連動画:** + [Save up to 90% and run production workloads on Spot (最大 90% 節約し、Spot で本番環境のワークロードを稼動)](https://www.youtube.com/watch?v=BlNPZQh2wXs) **関連する例:** + [Well-Architected ラボ: Cost Explorer](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/100_5_Cost_Visualization/Lab_Guide.html#Elasticity) + [Well-Architected ラボ: コストの可視化](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_5_Cost_Visualization/README.html) + [Well-Architected ラボ: 料金モデル](https://wellarchitectedlabs.com/Cost/CostEffectiveResources.html) # COST07-BP02 コストに基づいてリージョンを選択する COST07-BP02 コストに基づいてリージョンを選択する リソースの料金は各リージョンで異なる場合があります。リージョンコストを織り込むことで、このワークロードに対して支払う料金の合計を最低限に抑えることができます。 **このベストプラクティスを活用しない場合のリスクレベル:** ミディアム ## 実装のガイダンス 実装のガイダンス ソリューションを設計する際、ユーザーに近いコンピューティングリソースの場所を探して、レイテンシー低下とデータ主権の強化を図ることが推奨されます。グローバルな利用者のニーズに応えるためには、複数のロケーションを使用する必要があります。コストを最低限に抑えられる地理的ロケーションを選択する必要もあります。 AWS クラウドクラウドインフラストラクチャは、 [リージョンとアベイラビリティーゾーン](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html)を中心に構築されています。リージョンは世界中の物理的場所であり、複数のアベイラビリティーゾーンが配置されています。アベイラビリティーゾーンは 1 つ以上の独立したデータセンターで構成されます。各データセンターは、冗長性のある電源、ネットワーク、接続を備えており、別々の設備に収容されています。 各 AWS リージョンは、地域の市場の条件下で運用されており、リソースの料金はリージョンごとに異なります。世界的に最小料金で稼働できるように、ソリューションのコンポーネントまたは全体を運用する特定のリージョンを選択します。さまざまなリージョンのワークロードのコストを見積もるには、 [AWS 料金見積りツール](https://calculator.aws/#/) を使用します。 **実装手順** + ** リージョンの料金を確認する: **現在のリージョンのワークロードコストを分析します。サービスおよび使用タイプ別の最も高いコストから、利用可能な他のリージョンのコストを計算します。予測される費用削減効果がコンポーネントまたはワークロードの移動コストを上回っている場合は、新しいリージョンに移行します。 ## リソース リソース **関連するドキュメント:** + [リザーブドインスタンスのレコメンデーションへのアクセス](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-recommendations.html) + [Amazon EC2 料金](https://aws.amazon.com/ec2/pricing/) + [インスタンス購入オプション](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html) + [リージョン別の表](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/) **関連動画:** + [Save up to 90% and run production workloads on Spot](https://www.youtube.com/watch?v=BlNPZQh2wXs) # COST07-BP03 費用対効果の高い条件を提供するサードパーティーの契約を選択する COST07-BP03 費用対効果の高い条件を提供するサードパーティーの契約を選択する コスト効率に優れた契約と条件により、これらのサービスのコストが、提供されるメリットに見合ったものとなります。組織に追加のメリットを提供するときに、それに合わせてスケーリングする契約と料金を選択します。 **このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム ## 実装のガイダンス 実装のガイダンス クラウドでサードパーティー製のソリューションまたはサービスを利用する場合、料金構造とコスト最適化の結果を連動させることが重要です。料金は、コスト最適化の結果とサービスの価値に合わせてスケールする必要があります。この一例として、削減率を使用したソフトウェアがあります。削減率 (結果) が高くなるほど請求額も上がるというものです。請求額に合わせてスケールする契約は、特定の請求書のあらゆる部分で結果が得られない限り、ほとんどの場合コストの最適化と連動していません。例えば、Amazon Elastic Compute Cloud (Amazon EC2) の推奨事項を提供し、請求全体のある割合が課金されるソリューションでは、メリットを提供しない他のサービスを利用すると、その分増加します。もう 1 つの例は、管理するリソースのコストの割合に応じて課金されるマネージドサービスです。インスタンスサイズを大きくすると常に管理作業が増えるわけではありませんが、請求額が高くなります。これらのサービス料金設定に、コスト最適化プログラムまたはサービス機能が含まれていることを承知のうえで効率性を向上させます。 **実装手順** + ** サードパーティーの契約と諸条件を分析する:** サードパーティー契約の料金を確認します。さまざまな使用レベルに対応したモデリングを行い、新しいサービスの使用や、ワークロードの増加による現在のサービスの増加など、新たなコストを考慮します。追加コストによってビジネスに必要なメリットが得られるかどうかを判断します。 ## リソース リソース **関連するドキュメント:** + [リザーブドインスタンスの推奨事項へのアクセス](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-recommendations.html) + [インスタンス購入オプション](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html) **関連動画:** + [Save up to 90% and run production workloads on Spot (最大 90% 節約し、Spot で本番環境のワークロードを稼動)](https://www.youtube.com/watch?v=BlNPZQh2wXs) # COST07-BP04 このワークロードのすべてのコンポーネントに対して料金モデルを実装する COST07-BP04 このワークロードのすべてのコンポーネントに対して料金モデルを実装する 永続的に実行されるリソースでは、Savings Plans やリザーブドインスタンスなどのリザーブドキャパシティを利用する必要があります。短期的な使用には、スポットインスタンスまたはスポットフリートを使用するように設定します。オンデマンドインスタンスは、中断することのできない、かつリザーブドキャパシティに対して長時間稼働しない短期ワークロードに対してのみ使用されます (リソースタイプに応じて、期間の 25% から 75%)。 **このベストプラクティスが確立されていない場合のリスクレベル:** 低 ## 実装のガイダンス 実装のガイダンス ワークロードコンポーネントの要件を考慮し、料金のポテンシャルモデルを理解します。コンポーネントの可用性要件を定義します。ワークロードで関数を実行する複数の独立したリソースの有無、ワークロードの継続的に必要となる要件を確認します。デフォルトのオンデマンド料金モデルと他の適用可能なモデルを使用して、リソースのコストを比較します。リソースまたはワークロードコンポーネントで変更可能なものはすべて考慮します。 **実装手順** + **料金モデルを実装する: **分析結果を使用して、Savings Plans (SP) やリザーブドインスタンス (RI) を購入するか、スポットインスタンスを実装します。RI を初めて購入する場合は、リストで上位 5 件または 10 件のレコメンデーションを選択し、翌月または翌々月までの結果をモニタリングして分析します。少数のコミットメント割引を定期的に購入します (例: 2 週間ごと、または 1 か月ごと)。中断可能またはステートレスなワークロードにスポットインスタンスを実装します。 + **ワークロードレビューサイクル:** 特に料金モデルカバレッジを分析するワークロードのレビューサイクルを実装します。ワークロードが必要な範囲に達したら、2～4 週間ごと、または組織の使用状況の変化に応じて、追加のコミットメント割引を購入します。 ## リソース リソース **関連するドキュメント:** + [リザーブドインスタンスの推奨事項へのアクセス](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-recommendations.html) + [EC2 フリート](https://aws.amazon.com/blogs/aws/ec2-fleet-manage-thousands-of-on-demand-and-spot-instances-with-one-request/) + [リザーブドインスタンスの購入方法](https://aws.amazon.com/ec2/pricing/reserved-instances/buyer/) + [インスタンス購入オプション](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html) + [スポットインスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) **関連動画:** + [Save up to 90% and run production workloads on Spot (最大 90% 節約し、Spot で本番環境のワークロードを稼動)](https://www.youtube.com/watch?v=BlNPZQh2wXs) # COST07-BP05 管理アカウントレベルで料金モデル分析を実行する COST07-BP05 管理アカウントレベルで料金モデル分析を実行する Cost Explorer の Savings Plans およびリザーブドインスタンスのレコメンデーションを使用して、コミットメント割引の管理アカウントレベルでの定期的な分析を実行します。 **このベストプラクティスを活用しない場合のリスクレベル:** 低 ## 実装のガイダンス 実装のガイダンス コストモデリングを定期的に実行すると、複数のワークロードにまたがって最適化する機会が確実に得られます。例えば、複数のワークロードでオンデマンドインスタンスを使用している場合、集計レベルでは変更リスクが低くなり、コミットメントベースの割引を運用すると全体的なコストが低くなります。2 週間から 1 か月の定期的なサイクルで分析を実行することを推奨します。これにより、調整のための小口購入が可能になり、ワークロードやコンポーネントの変更に合わせて料金モデルの調整を続けることができます。 コミットメント割引を適用する機会を見つけるために、 [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) を使用します。 スポットのワークロードを実行する機会を見つけるには、使用量全体の 1 時間ごとのビューを使用して、使用量や伸縮性の変化を定期に探します。 **実装手順** + ** コミットメント割引分析を実行する: **アカウントで Cost Explorer を使用して、Savings Plans とリザーブドインスタンスのレコメンデーションを確認します。必要な割引を適用し、リスクを認識した上で、正しいレコメンデーションを実装していることを確認するには、Well-Architected ラボに従ってください。 ## リソース リソース **関連するドキュメント:** + [リザーブドインスタンスのレコメンデーションへのアクセス](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-recommendations.html) + [インスタンス購入オプション](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html) **関連動画:** + [Save up to 90% and run production workloads on Spot](https://www.youtube.com/watch?v=BlNPZQh2wXs) **関連する例:** + [Well-Architected ラボ: 料金モデル](https://wellarchitectedlabs.com/Cost/Cost_Fundamentals/200_3_Pricing_Models/README.html) # COST 8 データ転送料金はどのように計画すればよいですか？ データ転送料金を計画し、モニタリングすることで、これらのコストを最小化するためのアーキテクチャ上の決定を下すことができます。小規模でも効果的なアーキテクチャ変更により、長期的な運用コストを大幅に削減できる場合があります。 **Topics** + [ # COST08-BP01 データ転送モデリングを実行する ](cost_data_transfer_modeling.md) + [ # COST08-BP02 データ転送コストを最適化するコンポーネントを選択する ](cost_data_transfer_optimized_components.md) + [ # COST08-BP03 データ転送コストを削減するサービスを実装する ](cost_data_transfer_implement_services.md) # COST08-BP01 データ転送モデリングを実行する COST08-BP01 データ転送モデリングを実行する 組織の要件を取りまとめ、ワークロードとその各コンポーネントのデータ転送モデリングを実行します。これにより、現在のデータ転送要件に対する最低コストを特定できます。 **このベストプラクティスが確立されていない場合のリスクレベル:** 高 ## 実装のガイダンス 実装のガイダンス ワークロードでデータ転送が行われる場所、転送コスト、およびそれに関連する利点を理解します。これにより、十分な情報に基づいてアーキテクチャ設計上の変更や承諾の決定ができます。たとえば、アベイラビリティーゾーン間でデータをレプリケートするマルチアベイラビリティーゾーンを設定したとします。構造のコストをモデリングし、これが許容可能なコスト (両方のアベイラビリティーゾーンにおけるコンピューティングコストとストレージコストと同様のもの) であると判断されると、必要な信頼性と耐障害性が達成されます。 さまざまな使用量のレベルでコストをモデリングします。ワークロード使用量は経時変化します。また、サービスの種類ごとに異なるレベルで費用対効果が向上する場合があります。 データ転送コストを理解し、モデリングするには、 [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) や [AWS Cost and Usage Report](https://aws.amazon.com/aws-cost-management/aws-cost-and-usage-reporting/) (CUR) を使用します。PoC (概念実証) を設定するか、またはワークロードをテストして、現実的な条件でシミュレートされた負荷を用いてテストを実行します。ワークロードのさまざまな需要に応じてコストをモデルリングできます。 **実装手順** + ** データ転送コストを計算する: **ワークロードのデータ転送コストを計算するには、 [AWS の料金ページ](https://aws.amazon.com/pricing/) を使用します。ワークロードの使用量が増減した場合の、使用量別のデータ転送コストを計算します。ワークロードアーキテクチャに複数のオプションがある場合は、比較のために各オプションのコストを計算します。 + ** コストを結果にリンクする:** 発生したデータ転送コストごとに、ワークロードで達成した結果を指定します。コンポーネント間の転送であればデカップリングのため、アベイラビリティゾーン間の転送であれば冗長性のためかもしれません。 ## リソース リソース **関連するドキュメント:** + [AWS caching solutions](https://aws.amazon.com/caching/aws-caching/) + [AWS の料金](https://aws.amazon.com/pricing/) + [Amazon EC2 の料金](https://aws.amazon.com/ec2/pricing/on-demand/) + [Amazon VPC の料金](https://aws.amazon.com/vpc/pricing/) + [Amazon CloudFront を使用してコンテンツを迅速に配信する](https://aws.amazon.com/getting-started/tutorials/deliver-content-faster/) # COST08-BP02 データ転送コストを最適化するコンポーネントを選択する COST08-BP02 データ転送コストを最適化するコンポーネントを選択する すべてのコンポーネントが選択され、データ転送コストを低減するようアーキテクチャが設計されます。これには、ワイドエリアネットワーク (WAN) 最適化やマルチアベイラビリティゾーン (AZ) 設定などのコンポーネントの使用が含まれます。 **このベストプラクティスを活用しない場合のリスクレベル:** 低 ## 実装のガイダンス 実装のガイダンス データ転送向けのアーキテクチャでは、データ転送コストが最小化されます。このアーキテクチャでは、コンテンツ配信ネットワークを使用してユーザーに近いデータを特定したり、お客様のプレミスと AWS をつなぐ専用ネットワーク接続が使用される場合があります。WAN の最適化やアプリケーションの最適化によって、コンポーネント間で転送されるデータ量を減らすこともできます。 **実装手順** + **データ転送用にコンポーネントを選択する: **データ転送モデリングを使用して、データ転送コストが最も大きい場所や、ワークロードの使用状況が変わった場合の場所に焦点を当てます。データ転送の必要性を排除または削減したり、コストを削減したりする代替アーキテクチャや追加のコンポーネントを探します。 ## リソース リソース **関連するドキュメント:** + [AWS caching solutions](https://aws.amazon.com/caching/aws-caching/) + [Amazon CloudFront を使用してコンテンツを迅速に配信する](https://aws.amazon.com/getting-started/tutorials/deliver-content-faster/) # COST08-BP03 データ転送コストを削減するサービスを実装する COST08-BP03 データ転送コストを削減するサービスを実装する データ転送コストを削減するサービスを実装します。例えば、Amazon CloudFront などのコンテンツ配信ネットワーク (CDN) を使用してエンドユーザーにコンテンツを配信する、Amazon ElastiCache を使用してレイヤーをキャッシュする、AWS への接続用に VPN の代わりに AWS Direct Connect を使用するなどです。 **このベストプラクティスを活用しない場合のリスクレベル:** 低 ## 実装のガイダンス 実装のガイダンス [Amazon CloudFront](https://aws.amazon.com/cloudfront/) は、低レイテンシーかつ高速な転送速度でデータを転送するグローバルなコンテンツ配信ネットワークです。世界中のエッジロケーションでデータをキャッシュすることで、お客様のリソースの負荷を軽減します。CloudFront を使用してレイテンシーを最低限に抑え、世界中の多数のユーザーにコンテンツを配信するための管理労力を軽減できます。 [Direct Connect](https://aws.amazon.com/directconnect/) では、AWS への専用ネットワーク接続を確立できます。このサービスによって、ネットワークコストの削減、帯域幅の増加、インターネット経由の接続よりも安定したネットワーク接続が可能になります。 [Site-to-Site VPN](https://aws.amazon.com/vpn/) を使用すると、プライベートネットワークと AWS グローバルネットワークとの間に安全なプライベート接続を確立できます。迅速かつ簡単な接続とフルマネージド型の伸縮自在なサービスは、小規模なオフィスやビジネスパートナーに最適です。 [VPC エンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/concepts.html) により、プライベートネットワークを利用して AWS のサービス間の接続が可能になり、パブリックデータ転送と [NAT ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) のコストを削減できます。[ゲートウェイ VPC エンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html) では、時間単位の料金は発生せず、Amazon Simple Storage Service (Amazon S3) と Amazon DynamoDB がサポートされます。[インターフェイス VPC エンドポイント](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html) は、 [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-share-your-services.html) によって提供され、時間単位の料金と GB あたりの使用料がかかります。 **実装手順** + ** サービスを実装する: **データ転送モデリングを使用して、最大のコストと最大のボリュームフローがどこにあるかを調べます。AWS のサービスを確認し、転送を減らすか排除するサービス (特にネットワークとコンテンツ配信) があるかどうかを評価します。また、データへの繰り返しのアクセス、または大量のデータがあるキャッシュサービスを探します。 ## リソース リソース **関連するドキュメント:** + [AWS Direct Connect](https://aws.amazon.com/directconnect/) + [AWS の製品を見る](https://aws.amazon.com/) + [AWS caching solutions](https://aws.amazon.com/caching/aws-caching/) + [Amazon CloudFront](https://aws.amazon.com/cloudfront/) + [Amazon CloudFront を使用してコンテンツを迅速に配信する](https://aws.amazon.com/getting-started/tutorials/deliver-content-faster/) # 需要を管理しリソースを供給する 需要を管理しリソースを供給する **Topics** + [ # COST 9 どのように需要を管理し、リソースを供給すればよいですか? ](w2aac19c13c11b5.md) # COST 9 どのように需要を管理し、リソースを供給すればよいですか? 費用とパフォーマンスのバランスが取れたワークロードを作成するには、費用を掛けたすべてのものが活用されるようにし、使用率が著しく低いインスタンスが生じるのを回避します。利用が過剰でも過少でも偏りが生じると、運用コスト (利用過剰によるパフォーマンスの低下) または無駄な AWS 費用 (過剰なプロビジョニング) のいずれかで、組織に悪影響が及びます。 **Topics** + [ # COST09-BP01 ワークロードの需要に関する分析を実行する ](cost_manage_demand_resources_cost_analysis.md) + [ # COST09-BP01 需要を管理するためのバッファまたはスロットルを実装する ](cost_manage_demand_resources_buffer_throttle.md) + [ # COST09-BP03 リソースを動的に供給する ](cost_manage_demand_resources_dynamic.md) # COST09-BP01 ワークロードの需要に関する分析を実行する COST09-BP01 ワークロードの需要に関する分析を実行する ワークロードの需要を経時的に分析します。分析が季節的傾向を考慮し、ワークロードのライフタイム全体にわたる動作条件を正確に反映したものであることを確認します。分析を行う際には、費やされた時間がワークロードのコストに比例しているなどの潜在的利益を織り込む必要があります。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 ## 実装のガイダンス 実装のガイダンス ワークロードの要件を把握します。組織の要件に、リクエストに対するワークロードの応答時間を含める必要があります。応答時間は、需要が管理されているかどうか、または需要を満たすためにリソースの供給が変化するかどうかを判断するために使用できます。 分析には、需要の予測可能性と再現性、需要の変化率、需要の変化量を含める必要があります。分析は、月末処理や休日のピークなどの時季的な変動が組み込まれるように、十分な期間にわたって実行されるようにします。 分析作業では、スケーリングの実装による潜在的な利点が反映されていることを確認します。コンポーネントの予想される合計コスト、ワークロードのライフタイムにおける使用量の増減およびコストの増減に注目します。 ワークロードの需要は [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) または [Amazon Quick](https://aws.amazon.com/quicksight/) を AWS Cost and Usage Report (CUR) またはアプリケーションログとともに使用して、視覚的に分析できます。 **実装手順** + ** 既存のワークロードデータを分析する: **既存のワークロード、以前のバージョンのワークロード、または予測された使用パターンのデータを分析します。ログファイルとモニタリングデータを使用して、顧客がワークロードをどのように使用しているかについての洞察を得ます。一般的なメトリクスは、実際の需要 (1 秒あたりのリクエスト数)、需要率が変化するか異なるレベルとなるタイミング、および需要の変化率です。ワークロードの全サイクルを分析し、月末や年末のイベントなどの季節的な変化のデータを収集します。分析に反映される労力は、ワークロードの特性を反映する必要があります。最大の労力は、需要に最も大きな変化がある価値の高いワークロードに割り当てられる必要があります。需要の変化が最小である低価値のワークロードには、最小の労力を割り当てる必要があります。価値の一般的なメトリクスは、リスク、ブランド認知、収益、ワークロードのコストです。 + ** 外部の影響を予測する: **組織全体において、ワークロードの需要に影響を与え、または変化させる可能性のあるチームメンバーとミーティングを行います。一般的なチームは販売、マーケティング、ビジネス開発です。当該メンバーと協力して、業務のサイクルや、ワークロードの需要を変化させるイベントがあるかどうかを把握します。このデータを使用してワークロードの需要を予測します。 ## リソース リソース **関連するドキュメント:** + [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) + [AWS での Instance Scheduler](https://aws.amazon.com/answers/infrastructure-management/instance-scheduler/) + [Amazon SQS の開始方法](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html) + [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) + [Amazon Quick](https://aws.amazon.com/quicksight/) # COST09-BP01 需要を管理するためのバッファまたはスロットルを実装する COST09-BP01 需要を管理するためのバッファまたはスロットルを実装する バッファリングとスロットリングは、ワークロードの需要を修正し、ピークを滑らかにします。クライアントが再試行を実行するときにスロットリングを実行します。バッファリングは、リクエストを保存し、後日まで処理を延期するために実装します。スロットルとバッファが、クライアントが要求された時間内にレスポンスを受け取るように設計されていることを確認します。 **このベストプラクティスを活用しない場合のリスクレベル:** 低 ## 実装のガイダンス 実装のガイダンス **スロットリング:** 需要元のソースに再試行機能がある場合は、スロットリングを実装できます。現在リクエストを処理できない場合は、後で再試行する必要があることがスロットリングによってソースに通知されます。ソースでは一定時間待機してから、リクエストが再試行されます。スロットリングの運用には、リソースの最大量およびワークロードのコストを制限できるという利点があります。AWS では、 [Amazon API Gateway](https://aws.amazon.com/api-gateway/) を使用してスロットリングを実装できます。スロットリングの実装の詳細については、 [Well-Architected 信頼性の柱のホワイトペーパー](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html) を参照してください。 **バッファベース: **スロットリングと同様に、バッファはリクエスト処理を延期し、アプリケーションが異なる動作速度で実行されていても効果的に通信できるようにします。バッファベースのアプローチでは、キューを使用してプロデューサーからメッセージ (作業単位) を受信します。メッセージはコンシューマーによって読み取られ、処理されるため、コンシューマーのビジネス要件を満たせる動作速度でメッセージを実行できます。プロデューサーがデータの耐久性やバックプレッシャーなどのスロットルの問題に対処する必要があることを心配する必要はありません (コンシューマーの動作が遅いためにプロデューサーが遅くなります)。 AWS でバッファベースのアプローチを実装する際は、複数のサービスから選択できます。[Amazon Simple Queue Service (Amazon SQS)](https://aws.amazon.com/sqs/) は、1 人のコンシューマーが個別のメッセージを読むことができるキューを提供するマネージドサービスです。[Amazon Kinesis](https://aws.amazon.com/kinesis/) は、多数のコンシューマーが同じメッセージを読み取ることができるストリームを提供します。 バッファベースのアプローチで設計する場合は、必要な時間内にリクエストを処理するようにワークロードを設計し、作業の重複リクエストを処理できるようにします。 **実装手順** + ** クライアントの要件を分析する: **クライアントリクエストを分析して、再試行を実行できるかどうかを判断します。再試行を実行できないクライアントの場合、バッファを実装する必要があります。全体的な需要、変化率、および要求される応答時間を分析して、必要なスロットルまたはバッファのサイズを決定します。 + ** バッファまたはスロットルを実装する:** ワークロードにバッファまたはスロットルを実装します。Amazon Simple Queue Service (Amazon SQS) などのキューは、ワークロードコンポーネントにバッファを提供できます。Amazon API Gateway は、ワークロードコンポーネントのためにスロットリングを提供できます。 ## リソース リソース **関連するドキュメント:** + [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) + [AWS での Instance Scheduler](https://aws.amazon.com/answers/infrastructure-management/instance-scheduler/) + [Amazon API Gateway](https://aws.amazon.com/api-gateway/) + [Amazon Simple Queue Service](https://aws.amazon.com/sqs/) + [Amazon SQS の開始方法](https://aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html) + [Amazon Kinesis](https://aws.amazon.com/kinesis/) # COST09-BP03 リソースを動的に供給する COST09-BP03 リソースを動的に供給する リソースを計画的なやり方でプロビジョニングします。これは、自動スケーリングなどの需要ベース、または需要が予測可能でリソースが時間に基づいて提供される時間ベースで行います。これらの手法を使用すると、過剰プロビジョニングやプロビジョニング不足を最小限に抑えることができます。 **このベストプラクティスを活用しない場合のリスクレベル:** 低 ## 実装のガイダンス 実装のガイダンス 専用のインフラストラクチャで [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)AWS API または SDK を使用して [AWS API または SDK](https://aws.amazon.com/developer/tools/).これにより、環境を手動変更していた運用コストがなくなり、その結果、全体的なワークロードコストが削減され、実行速度が向上します。また、ワークロードリソースと需要を常に一致させることができます。 **需要ベースの供給:** クラウドの伸縮性を活用して、需要の変化に対応するリソースを提供します。API やサービス機能を活用すると、アーキテクチャ内のクラウドリソースの量をプログラムで動的に変更できます。これにより、アーキテクチャ内のコンポーネントの規模を変えたり、需要が急増したときにリソースの数を自動的に増加させてパフォーマンスを維持したり、需要が後退したときにキャパシティーを減少させてコストを節減させたりできます。 [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) は、キャパシティーを調整し、安定した予測可能なパフォーマンスを可能な限り低いコストで維持するのに役立ちます。これは、Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、スポットフリート、Amazon Elastic Container Service (Amazon ECS)、Amazon DynamoDB、Amazon Aurora と統合されたフルマネージド型の無料サービスです。 Auto Scaling では、リソースの自動検出によってワークロード内の設定可能なリソースを検出できます。また、パフォーマンス、コスト、または両者のバランスを最適化するためのスケーリング戦略が組み込まれており、予測スケーリングによって定期的に発生する急増に対応することができます。 Auto Scaling では、手動スケーリング、スケジュールに基づくスケーリング、または需要ベースのスケーリングを実装できます。また、 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) のメトリクスとアラームを使用して、ワークロードのスケーリングイベントをトリガーできます。一般的なメトリクスは標準Amazon EC2メトリクスです。CPU 使用率、ネットワークスループット、 [Elastic Load Balancing(ELB) ](https://aws.amazon.com/elasticloadbalancing/)で確認されたリクエストとレスポンスのレイテンシーなどがあります。可能な場合は、カスタマーエクスペリエンスの指標となるメトリクスを使用する必要があります。このメトリクスは一般には、ワークロード内のアプリケーションコードから生成されるカスタムメトリクスです。 需要ベースのアプローチで設計する場合、主に 2 つの点を考慮する必要があります。第 1 に、新しいリソースをどれだけ早くプロビジョニングする必要があるかを理解することです。第 2 に、需要と供給の差異が変動することを理解することです。需要の変動ペースに対処できるようにしておくだけでなく、リソースの不具合にも備えておく必要があります。 [ELB](https://aws.amazon.com/elasticloadbalancing/) は、複数のリソースに需要を分散することで、スケーリングを支援します。運用するリソースが増加したら、ロードバランサーにリソースを追加し需要を分散させます。Elastic Load Balancing では、Amazon EC2 インスタンス、コンテナ、IP アドレス、AWS Lambda 関数がサポートされています。 **時間ベースの供給:** 時間ベースのアプローチでは、リソースのキャパシティーを予測可能な需要、または時間ごとに明確に定義された需要に合わせます。このアプローチは、通常、リソースの使用率に依存せず、リソースが必要な特定の時間にそのリソースを確保します。また、起動手順、およびシステムや一貫性のチェックにより、遅延なくリソースを提供できます。時間ベースのアプローチでは、繁忙期に追加のリソースを投入したり、キャパシティーを拡大したりできます。 スケジュールされた Auto Scaling を使用して、時間ベースのアプローチを実装できます。営業開始時など、特定の時間にスケールアウトまたはスケールインするようにスケジュールできるため、ユーザーがアクセスしたときや需要が発生したときにリソースを利用可能にしておくことができます。 また、 [AWS API や SDK](https://aws.amazon.com/developer/tools/) および [AWS CloudFormation](https://aws.amazon.com/cloudformation/) を使用すると、必要に応じて自動的にプロビジョニングしたり、環境全体を削除したりできます。このアプローチは、所定の営業時間や一定期間にのみ実行される開発環境またはテスト環境に適しています。 API を使用した環境内のリソースサイズのスケーリング (垂直スケーリング) にも対応しています。たとえば、インスタンスのサイズやクラスを変更して、本番稼働ワークロードをスケールアップできます。これを行うには、インスタンスを停止・起動して、別のインスタンスのサイズやクラスを選択します。この手法は、使用中にサイズの拡大、パフォーマンス (IOPS) の調整、ボリュームタイプの変更が可能な Amazon Elastic Block Store (Amazon EBS) Elastic Volumes などのリソースにも適用できます。 時間ベースのアプローチを設計する際は、主に 2 つの点を考慮する必要があります。1 つ目は使用パターンの一貫性についてであり、 第 2 に、パターンを変更した場合の影響です。 予測精度は、ワークロードをモニタリングし、ビジネスインテリジェンスを使用することで高めることができます。使用パターンに大幅な変更がある場合は、時間を調整して予測対象範囲に収まるようにします。 **実装手順** + ** 時間ベースのスケジューリングを設定する: **需要の変化を予測できるため、時間ベースのスケーリングは適切な数のリソースを適時に提供できます。また、リソースの作成と設定が、需要の変化に対応するのに十分ではない場合にも役立ちます。ワークロード分析を活用して、AWS Auto Scaling を使用してスケジュールに基づくスケーリングを設定します。 + ** Auto Scaling を設定する: **アクティブなワークロードメトリクスに基づいてスケーリングを設定するには、Amazon Auto Scaling を使用します。分析を使用して、正しいリソースレベルでトリガーするように Auto Scaling を設定し、ワークロードが要求された時間内にスケールすることを確認します。 ## リソース リソース **関連するドキュメント:** + [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) + [AWS での Instance Scheduler](https://aws.amazon.com/answers/infrastructure-management/instance-scheduler/) + [Getting Started With Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html) + [Amazon SQS の開始方法](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html) + [Amazon EC2 Auto Scaling のスケジュールされたスケーリング](https://docs.aws.amazon.com/autoscaling/ec2/userguide/schedule_time.html) # 継続的最適化 継続的最適化 **Topics** + [ # COST 10 新しいサービスをどのように評価すればよいですか？ ](w2aac19c13c13b5.md) # COST 10 新しいサービスをどのように評価すればよいですか？ AWS では新しいサービスと機能がリリースされるため、既存のアーキテクチャの決定をレビューし、現在でもコスト効率が最も優れているかどうかを確認することがベストプラクティスです。 **Topics** + [ # COST10-BP01 ワークロードレビュープロセスを開発する ](cost_evaluate_new_services_review_process.md) + [ # COST10-BP02 このワークロードを定期的に見直し、分析する ](cost_evaluate_new_services_review_workload.md) # COST10-BP01 ワークロードレビュープロセスを開発する COST10-BP01 ワークロードレビュープロセスを開発する ワークロードレビューの基準とプロセスを定義するプロセスを開発します。レビューを行う際には、潜在的利益を織り込む必要があります。例えば、請求の 10% 以上の価値を持つコアワークロードは四半期ごとにレビューし、10% 未満のワークロードは年に 1 回レビューするなどです。 **このベストプラクティスを活用しない場合のリスクレベル:** 高 ## 実装のガイダンス 実装のガイダンス ワークロードの費用対効果が常に最大になるようにするには、ワークロードを定期的にレビューし、新しいサービス、機能、コンポーネントを実装する機会があるかどうかを把握する必要があります。全体的なコスト削減を達成するには、潜在的なコスト削減量に比例したプロセスを行う必要があります。たとえば、支出全体の 50% を占めるワークロードは、支出全体の 5% を占めるワークロードよりも定期的かつ徹底的にレビューする必要があります。外部要因または変動性を考慮します。ワークロードにより特定の地域、特定の市場セグメントにサービスが提供されていて、その領域での変化が予測される場合、レビュー頻度を高くすることでコスト削減につながる可能性があります。レビューで考慮すべきもう 1 つの要因は、変更を運用する労力です。変更のテストおよび検証に多大なコストがかかる場合は、レビューの頻度を下げる必要があります。 古くなったレガシーコンポーネントやリソースには維持するための長期的なコストがかかることや、新しい機能を実装できないことを考慮します。テストと検証にかかる現在のコストが、提案されている利益を上回っている場合があります。しかし、ワークロードと現在のテクノロジーとのギャップが時間の経過とともに大きくなるにつれて、変更にかかるコストが増加し、結果として巨額のコストになることがあります。たとえば、新しいプログラミング言語に移行するときの費用対効果は現時点で低いとします。しかし、5 年後には、その言語に精通した人材のコストが増加する可能性があります。ワークロードが増加すると、さらに大規模なシステムを新しい言語に移行することになり、結果的にこれまでよりもさらに多大な労力を要します。 ワークロードをコンポーネントに分割し、コンポーネントのコストを割り当て (コストの見積りで可)、各コンポーネントの横に要因 (労力や外部市場など) を一覧表示します。この指標を使用して、各ワークロードのレビュー頻度を決定します。たとえば、ウェブサーバーが高コストで、変更の労力が低く、外部要因が高い場合は、レビュー頻度が高くなります。中央データベースが中程度のコストで、変更の労力が高く、外部要因が低い場合は、レビューの頻度は中程度になります。 **実装手順** + **レビュー頻度を定義する: **ワークロードとそのコンポーネントを確認する頻度を定義します。これは要因の組み合わせであり、組織内のワークロードによって異なる場合があります。また、ワークロード内のコンポーネントによって異なる場合もあります。一般的な要因には、収益またはブランドの観点から評価された組織にとっての重要性、ワークロードの実行にかかる総コスト (運用コストとリソースコストを含む)、ワークロードの複雑さ、変更の実装の容易性、ソフトウェアライセンス契約、ある変更がライセンス違反によるライセンス費用の重大な増加を生じさせるかどうかなどが含まれます。コンポーネントは、ウェブサーバーやデータベース、コンピューティングリソースやストレージリソースなど、機能的または技術的に定義できます。それに応じて要因のバランスをとり、ワークロードとそのコンポーネントのための期間を設定します。例えば、ワークロード全体は 18 か月ごとに、ウェブサーバーは 6 か月ごとに、データベースは 12 か月ごとに、コンピューティングおよび短期ストレージは 6 か月ごとに、長期ストレージは 12 か月ごとに、それぞれレビューすることとできます。 + ** レビューの十分性を定義する: **ワークロードまたはワークロードコンポーネントのレビューに費やされる労力を定義します。レビュー頻度と同様に、これは複数の要因のバランスです。例えば、データベースコンポーネントの分析に 1 週間を、ストレージのレビューに 4 時間を、それぞれ費やすようにすることができます。 ## リソース リソース **関連するドキュメント:** + [AWS ニュースブログ](https://aws.amazon.com/blogs/aws/) + [クラウドコンピューティングのタイプ](https://aws.amazon.com/types-of-cloud-computing/) + [AWS の最新情報](https://aws.amazon.com/new/) # COST10-BP02 このワークロードを定期的に見直し、分析する COST10-BP02 このワークロードを定期的に見直し、分析する 既存のワークロードは、定義されたプロセスごとに定期的に見直されます。 **このベストプラクティスが確立されていない場合のリスクレベル:** 低 ## 実装のガイダンス 実装のガイダンス 新しい AWS のサービスと機能の利点を得るには、ワークロードでレビュープロセスを実行し、必要に応じて新しいサービスや機能を実装する必要があります。例えば、ワークロードを見直して、メッセージングコンポーネントを Amazon Simple Email Service (Amazon SES) に置き換えることができます。これにより、すべての機能を低コストで提供しながら、インスタンスのフリートの運用と維持にかかるコストを削減できます。 **実装手順** + ** ワークロードを定期的に見直す: **定義したプロセスを使用して、指定した頻度でレビューを実行します。各コンポーネントに適正な労力を費やしていることを確認します。このプロセスは、コスト最適化のためにサービスを選択した最初の設計プロセスに似ています。サービスとこのサービスがもたらすメリットを分析します。今回は、長期的なメリットだけでなく、変更を行うコストも考慮します。 + ** 新しいサービスを実装する:** 分析の結果、変更を実施する場合は、まずワークロードのベースラインを実行し、各アウトプットの現在のコストを把握します。変更を実施し、分析を実行して、各アウトプットの新しいコストを確認します。 ## リソース リソース **関連するドキュメント:** + [AWS ニュースブログ](https://aws.amazon.com/blogs/aws/) + [クラウドコンピューティングのタイプ](https://aws.amazon.com/types-of-cloud-computing/) + [AWS の最新情報](https://aws.amazon.com/new/)