"このコンテンツは古いものです。現在、このバージョンの Well-Architected Framework は、次の場所にあります。 https://docs.aws.amazon.com/ja_jp/wellarchitected/2022-03-31/framework/cost-optimization.html

COST 2: 使用状況をどのように管理しますか?

発生コストを適正な範囲内に抑えつつ、目的を確実に達成するためのポリシーとメカニズムを設定します。チェックアンドバランスのアプローチを採用することで、無駄なコストを費やすことなくイノベーションが可能です。

リソース

Control access to AWS Regions using IAM policies
AWS multiple account billing strategy
AWS managed policies for job functions

ベストプラクティス:

改善計画

組織の要件に基づいてポリシーを策定する

  • チームメンバーとのミーティングを設ける : ポリシーを開発するために、組織からすべてのチームメンバーを集め、要件を指定し、適切に文書化します。幅広く開始し、各ステップで最小単位まで継続的に絞り込んでいくという反復型アプローチを採用します。チームメンバーには、組織単位やアプリケーションの所有者など、ワークロードの直接の関係者に加え、セキュリティチームや財務チームなどのサポートグループを含みます。
  • ワークロードの場所を定義する : ワークロードの運用場所 (国や国内のエリアなど) を定義します。この情報は、AWS リージョンとアベイラビリティーゾーンへのマッピングに使用されます。
    Global Infrastructures Regions and AZs
  • サービスとリソースを定義およびグループ化する : ワークロードに必要なサービスを定義します。サービスごとに、タイプ、サイズ、必要なリソースの数を指定します。アプリケーションサーバーやデータベースストレージなどの機能別にリソースのグループを定義します。リソースは複数のグループに属することができます。
    Cloud Products
  • 機能別にユーザーを定義およびグループ化する : ワークロードに関係するユーザーについて、当該ユーザーが誰かまたは組織内での地位に焦点を当てるのではなく、何を行うか、またはどのようにワークロードを使用するかに焦点を当てて定義します。類似したユーザーまたは機能をグループ化します。AWS 管理ポリシーをガイドとして使用できます。
    AWS Managed Policies for Job Functions
  • アクションを定義する : 以前に特定した場所、リソース、およびユーザーを使用して、そのライフタイム (開発、運用、削除) にわたってワークロードの成果を得るために、それぞれが必要とするアクションを定義します。各場所で、グループ内の個々の要素ではなく、グループに基づいてアクションを特定します。開始時には読み取りまたは書き込みを幅広く設定し、それぞれのサービスについて、特定のアクションへと絞り込んでいきます。
    Actions, Resources, and Condition Keys for AWS Services
  • レビュー期間を定義する : ワークロードと組織の要件は、時間の経過とともに変化する可能性があります。ワークロードのレビュースケジュールを定義して、組織の優先順位に合わせた状態を維持します。高頻度のレビューサイクルは通常、セキュリティ要件、コストや使用状況が大きいこと、組織にとって重要性が高いこと、ワークロードの変化量によって特定されます。
  • ポリシーを文書化する : 定義されたポリシーが、組織の必要に応じてアクセス可能であることを確認します。これらのポリシーは、環境へのアクセスを実装、保守、監査するために使用されます。

    • 目標およびターゲットを策定する

  • 予想される使用レベルを定義する : まず、使用レベルに焦点を当てます。アプリケーションの所有者、マーケティング、およびより大きなビジネスチームと協力して、ワークロードに対して予想される使用レベルを把握します。顧客の需要が時間の経過とともにどのように変化するか、季節的な増加やマーケティングキャンペーンによって変化が生じるかどうか、などを考慮します。
  • ワークロードのリソースとコストを定義する : 使用レベルを定義した上で、これらの使用レベルを満たすために必要なワークロードリソースの変化を数値化します。ワークロードコンポーネントのサイズまたはリソースの数を増やしたり、データ転送を増やしたり、特定のレベルでワークロードコンポーネントを別のサービスに変更したりすることが必要な場合があります。これらの主な各ポイントにおけるコストと、使用状況が変更された場合のコストの変化を指定します。
  • ビジネス目標を定義する : 予想される使用量とコストの変化から結果を取得し、これを、予想されるテクノロジーや実行中のプログラムの変化と組み合わせて、ワークロードの目標を策定します。目標は、使用状況、コスト、および両者の関係を対象に含めたものである必要があります。コストは変化するが使用状況に変化がないことが予想される場合は、トレーニングや教育などの機能構築などの組織プログラムが存在していることを確認します。
  • ターゲットを定義する : 定義された目標ごとに、測定可能なターゲットを指定します。目標がワークロードの効率を高めることである場合、ターゲットは、1 ドルあたりのビジネス出力量や、いつ配信されるかなど、改善の量を定量化します。

    • アカウント構造を実装する

  • 分離要件を定義する : 分離の要件は、セキュリティ、信頼性、財務構造など、複数の要因の組み合わせです。各要因を順番に確認し、ワークロードまたはワークロード環境を他のワークロードから分離するかどうかを指定します。セキュリティは、アクセスとデータ要件を確実に守るものです。信頼性は、環境やワークロードが他の環境に影響を与えないように制限を確実に管理するものです。財務構造は、厳格な財務分離と説明責任を確保するものです。分離の一般的な例としては、本番稼働用ワークロードとテストワークロードが別々のアカウントで実行されることや、請求書と請求データをサードパーティー組織に提供できるように別のアカウントを使用することが挙げられます。
  • グループ化要件を定義する : グループ化要件は分離要件を上書きしませんが、管理を支援するために使用されます。分離を必要としない同様の環境またはワークロードをグループ化します。この例としては、1 つ以上のワークロードから複数のテスト環境または開発環境をグループ化することが挙げられます。
  • アカウント構造を定義する : これらの分離およびグループ化を使用して、各グループのアカウントを指定し、分離要件が維持されるようにします。これらのアカウントは、メンバーアカウントまたは連結アカウントです。これらのメンバーアカウントを単一のマスター/支払いアカウントでグループ化することで、使用量を組み合わせて、すべてのアカウントでの従量制割引がより大きくなり、すべてのアカウントに対して単一の請求書が提供されます。請求データを分離し、各メンバーアカウントに請求データの個別のビューを提供することができます。メンバーアカウントが使用状況や請求データを他のアカウントに表示してはならない場合、または AWS から別々の請求書を必要とする場合は、複数のマスター/支払いアカウントを定義します。この場合、各メンバーアカウントは独自のマスター/支払いアカウントを持つことになります。リソースは常にメンバー/連結アカウントに配置する必要があります。マスター/支払いアカウントは、管理のためにのみ使用してください。
    AWS multiple account billing strategy
    Splitting the CUR and Sharing Access

    • グループとロールを実装する

  • グループを実装する : 必要に応じて、組織のポリシーで定義されているユーザーのグループを使用して、対応するグループを実装します。ユーザー、グループ、および認証のベストプラクティスについては、セキュリティの柱を参照してください。
    Well-Architected Security Pillar
    Well-Architected Lab Basic Identity and Access
  • ロールとポリシーを実装する : 組織のポリシーで定義されているアクションを使用して、必要なロールとアクセスポリシーを作成します。ロールとポリシーのベストプラクティスについては、セキュリティの柱を参照してください。
    Well-Architected Security Pillar
    Well-Architected Lab Basic Identity and Access

    • コストコントロールを実装する

  • 使用量に関する通知を実装する : 定義した組織のポリシーを使用して、AWS Budgets を作成し、支出がポリシーを外れた場合に通知を提供するようにします。アカウントごとに 1 つずつ、複数のコスト予算を設定し、アカウントの支出全体について通知するようにします。次に、アカウント内のより小さな単位について、各アカウント内にコスト予算を追加で設定します。これらの単位は、アカウント構造によって異なります。一般的な例としては、AWS リージョン、ワークロード (タグを使用)、または AWS のサービスがあります。E メール配信リストが通知の受取人として設定されており、また、個人の E メールアカウントではないことを確認します。金額を超えたときの実際の予算を設定するか、予測された使用量が通知されたときの予測された予算を使用します。
    Well-Architected Labs: Cost and Usage Governance
  • 使用量の管理を実装する : 定義した組織のポリシーを使用して、IAM ポリシーとロールを実装し、ユーザーが実行できるアクションと実行できないアクションを指定します。AWS ポリシーには、複数の組織ポリシーを含めることができます。ポリシーを定義するのと同じ方法で、幅広く開始し、各ステップでより詳細なコントロールを適用します。サービスの制限も、使用量に対する効果的なコントロールです。すべてのアカウントに正しいサービス制限を実装します。
    Well-Architected Labs: Cost and Usage Governance
    Control access to AWS Regions using IAM policies
    AWS managed policies for job functions

    • プロジェクトのライフサイクルを追跡する

  • ワークロードの確認を実行する : 組織のポリシーで定義されているところに従って、既存のプロジェクトを監査します。監査に費やされる労力の量は、組織のおおよそのリスク、価値、またはコストに比例する必要があります。監査に含めるべき主な領域は、インシデントまたは機能停止の組織に対するリスク、価値、組織への寄与 (収益またはブランドに対する評価で測定)、ワークロードのコスト (リソースおよび運用の合計コストとして測定)、およびワークロードの使用量 (時間単位ごとの組織の成果の数で測定) です。これらの領域がライフサイクルを通じて変化する場合、完全または部分的な削除など、ワークロードの調整が必要です。