# 20 – 可視性、計画、ガバナンスをもってコストを管理する
**クラウド財務管理 (CFM) をどのように実施すれば、コストを最適化し、コスト意識を維持できるでしょうか。** 開始から運用まで、SAP クラウドインフラストラクチャ予算のコントロールを確立し、ビジネス要件に沿って継続的に使用状況を最適化するには、どうすればよいでしょうか。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/design-principle-20.html)
# ベストプラクティス 20.1 – プロジェクトフェーズにおける消費モデルおよび環境の使用状況を計画する
移行や実装などの多くのプロジェクトでは、段階的アプローチでシステムのデプロイを進めます。サイジングおよび使用状況のプロファイルを確立する安定化期間もあります。柔軟性とオンデマンドインスタンス機能を活用してこの期間のコストを最小限に抑えましょう。
**提案 20.1.1 – 必要な場合のみシステムをデプロイするよう計画する**
リードタイムが短いなら、システムを必要なときだけデプロイするオプションが選べます。短期プロジェクトのシステムの場合は、オンデマンドインスタンスを使用してその期間だけのためにプロジェクトシステムを構築します。
**提案 20.1.2 – 予想される期間と使用状況プロファイルに従って料金オプションを評価する**
プロジェクトの長さと作業時間が料金モデルを左右します。プロジェクトの開始時は、デフォルトでオンデマンド料金モデルを選ぶのが普通です。予算が定義されていること、状況に合わせて安価なオプションに適応できるよう評価されていることを確認します。
**提案 20.1.3 – 使用されていないシステムの保留または廃止を計画する**
プロジェクトがアクティブでなくなっている場合、またはオブジェクトが既にアーカイブされている場合は、インスタンスのシャットダウンを通じて削減できるコストと、廃止を通じて節約できるストレージを検討します。プロジェクトは通常、移行の際にシステムのコピーを複数作成します。システムのシャットダウンは、必ず使用されていないときに行ってください。
# ベストプラクティス 20.2 – 異なる料金アプローチを活用した数年計画のコストモデルを確立する
容量要件の数年計画を確立し、料金モデルをフルに活用して AWS の割引を最大限に利用しましょう。コストのベースラインを設定し、コストを追跡します。柔軟なクラウド料金モデルを利用すれば、インフラストラクチャをビジネス要件の変化に柔軟に合わせることができます。Savings Plans やリザーブドインスタンスの長期契約を結ぶ前に、少なくとも 3 年にわたる SAP システムの使用状況を予想し、計画します。テスト、SAP Quick Sizer の出力、成長予測を参考にして契約プランを検討し、ワークロードに対して最大限の割引を利用できるようにします。
**提案 20.2.1 – 主要なビジネスイベントを理解して容量見積もりを立てる**
SAP ワークロードは、使用パターンや運用時間が既知で、全般に安定しています。SAP システムについて、十分に理解された定常状態の容量ベースラインを確立しましょう。そのために、デプロイ初期の数週間にパフォーマンステストや本番稼働環境のモニタリングを実施します。
定常状態の容量見積もりは、以下を考慮に入れ、少なくとも 3 年の期間を対象として立てます。
+ 合併、買収、資産売却といった大規模なビジネスイベント
+ データストレージの要件やビジネスプロセスの頻度に影響する可能性がある規制の変更
+ 通常のビジネスオペレーションによるデータの成長 (SAP HANA などのインメモリデータベースでは、データがストレージだけでなくコンピューティングのサイジングにも関係するため、特に重要)
+ システムの大規模なアップグレード、交換、廃止
**提案 20.2.2 – 1 年契約と 3 年契約のどちらが適切かを評価する**
SAP ワークロードの中に 3 年契約からメリットを得るものがどれだけあるかを評価し、容量見積もりに基づいて割引を最大限活用します。以下の点を考慮してください。
+ SAP ワークロードのすべてのコンピューティングニーズに対して 3 年契約を使用できるか。
+ ニーズのうち、変化しないと確信が持てるものに対して 3 年契約を使用できるか。 例えば、SAP プライマリアプリケーションサーバー、プライマリデータベースなどです。
+ SAP ワークロードは、AWS 組織の一部で、今後 SAP 容量要件が変化してコンピューティングニーズが減少した場合に組織が超過分の容量を利用することができるか。
+ SAP ワークロードは、AWS 組織の一部で、年中無休 24 時間体制ではない非本番稼働環境のコンピューティング性能を共有することができるか。
+ 中期的な容量の変化が生じた場合、3 年契約を通じて得られるメリットは、容量を使い切れないことによる無駄を上回るか (例えば、短期契約と比較したときの損益分岐点が 20 か月目か)。
+ 短期的に発生するビジネスの大きな変化や置き換えに影響されやすいアプリケーションについて、短期契約 (1 年) を検討できるか。
+ 為替変動を考慮に入れる必要があるか。AWS の料金は (AWS China を除いて) 米ドル (USD) で設定されています。固定された為替レートが望ましい場合は、全額前払いの料金モデルを検討してください。
ワークロードの容量要件に合った契約期間を選び、割引を最大限に活用できるような計画を立てます。
![\[Timeline showing SAP workload capacity allocation over 3 years with different commitment types.\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/images/example-timeline-of-planning-sap-on-aws-compute-commitments.png)
**提案 20.2.3 – コンピューティングタイプを固定して割引を最大限活用するのが適切かを評価する**
SAP ワークロードは、一般に AWS コンピューティングタイプの一部しか使用しません。そのため、特定のコンピューティングファミリーまたは特定のインスタンスタイプを契約することが割引の最大化に適しているかどうかを検討する必要があります。コンピューティングの料金アプローチとして割引率が最も高いのは、EC2 Instance Savings Plans と標準リザーブドインスタンスです。
以下の点を考慮してください。
+ お使いの環境で最も使用頻度が高いコンピューティングタイプを調べ、特定の EC2 Instance Savings Plans または標準リザーブドインスタンスの購入を検討します。例えば、複数の SAP アプリケーションで `m5.xlarge` をアプリケーションサーバーとして使用している場合です。その場合、契約プランを常時使用する可能性が高いので、EC2 の特定の Savings Plan または標準リザーブドインスタンスが適しています。
+ ワークロードの成長やビジネスイベントの発生時に EC2 ファミリーを変更する可能性が高いコンピューティングコンポーネントを特定します。これらのコンポーネントについては、より汎用性の高い Compute Savings Plans またはコンバーティブルリザーブドインスタンスの購入を検討してください。例えば、たった 6 か月後にサイズの増加が原因で EC2 `r5` と `X1e` の間で移行しなければならない SAP HANA データベースがある場合です。それには、短期のコンバーティブルリザーブドインスタンスまたは Compute Savings Plan が適しています。
+ 汎用コンピューティングと特定コンピューティングの料金を比較して損得分岐点を割り出し、それを考慮した上で契約タイプを選択します。例えば、サイジングが 3 年目に変化する場合は、標準リザーブドインスタンスを 3 年分購入する方が、3 年契約のコンバーティブルリザーブドインスタンスを購入するより安い場合があります。また、リザーブドインスタンスの残存期間を AWS リザーブドインスタンスマーケットプレイスで販売してもよいでしょう。
+ インスタンスタイプを変更する前に、AWS マーケットプレイスでプライベートの販売者が出品しているソフトウェアや 1 年サブスクリプションのソフトウェアの使用を確認します。そうすることで、余計なソフトウェアコストの発生を防げます。どちらのプランも、ソフトウェア製品を指定の期間にわたって Amazon EC2 インスタンス上で実行することを約束する代わりに、割引が受けられます。例えば、 `r4.xlarge` インスタンスでソフトウェアを実行する 1 年間のサブスクリプションを購入します。その後、インスタンスタイプを `r5.xlarge` に変更することにしました。サブスクリプションはまだアクティブですが、インスタンスには適用されなくなります。その結果、 `r5.xlarge` 上のソフトウェアに対して追加のオンデマンド料金を払う必要が生じます。年間サブスクリプションの有効期限が切れるのを待ってからインスタンスサイズを変更することを考えてください。
**提案 20.2.4 – Savings Plans とリザーブドインスタンスのどちらが適切か、あるいは両方使用すべきかを評価する**
対象となる SAP ワークロードに適しているなら、Savings Plans とリザーブドインスタンスを併用して異なるモデルからメリットが得られるようにしましょう。契約期間とコンピューティング要件を総合的に判断し、料金モデルを選びます。
Savings Plans とリザーブドインスタンスの違いについては、[コスト最適化]: [ベストプラクティス 18.1 - Amazon EC2 の利用可能な支払いおよび契約オプションを理解する](best-practice-18-1.md) および [Compute Savings Plans and Reserved Instances (Compute Savings Plans とリザーブドインスタンス)](https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html#sp-ris) を参照してください。
[信頼性]: [ベストプラクティス 10.2 - 可用性および容量要件に適したアーキテクチャを選択する](best-practice-10-2.md) .Savings Plans とリザーブドインスタンスのキャパシティ予約の違いおよびトレードオフについて解説しています。
**提案 20.2.5 – 予算および追跡の目的で容量計画をコストモデルに変換する**
Savings Plans、リザーブドインスタンスの選択肢、オンデマンド予算をコスト計画に変換し、少なくとも 3 年にわたる SAP 環境の AWS 支出を見積もります。予算および追跡の目的で、コンピューティング見積もりと他の AWS コストを組み合わせて SAP ワークロードのコストモデルを完成させます。
SAP コストを見積もる際、必ず次のコストを含めます。
+ コンピューティングに不随するストレージのコスト (Amazon EBS ボリュームなど)
+ 共有ファイルストレージのコスト (Amazon EFS、Amazon FSx など)
+ バックアップストレージのコスト (Amazon S3、Amazon S3 Glacier など)
+ ネットワークおよび VPC のコスト (Elastic Load Balancer、NAT ゲートウェイ、Transit Gateway、ネットワークアウトバウンドコスト、Direct Connect、VPN など)
+ 管理およびガバナンスサービスのコスト (CloudWatch の詳細なメトリクス、AWS CloudTrail、AWS Config など)
+ セキュリティサービスのコスト (AWS WAF、Amazon GuardDuty、AWS Shield など)
+ AWS Support のコスト (Business または Enterprise)
+ エンタープライズ割引プログラムまたは従量制割引が利用できないか検討する (担当の AWS アカウントマネージャーに詳細を問い合わせてください)
+ 通貨: AWS の料金は米ドル (USD) で設定されています。請求通貨は選択できます。請求通貨を選択すると、米ドルで計算された請求額が市場で適切な為替レートで選択した通貨に換算されます。
# ベストプラクティス 20.3 – コスト配分、および不正検出などの追跡のために予算とメカニズムを確立する
Well-Architected Framework には、財務管理を実施するための [ガイドライン](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/expenditure-and-usage-awareness.html) があります。クラウドコストに関する予測と、ビジネスニーズに応じた年間、四半期、月間、あるいは 1 日あたりの予算を設定します。使用状況に合わせて定期的に予測に調整を加え、パターンや異常を検出します。アカウント戦略やタグ付け戦略を使ってコスト配分のメカニズムを確立します。
**提案 20.3.1 – コストおよび請求ツールを使用して支出の可視性を高める**
確立された SAP システムでは、使用状況パターンにあまり動きがないのが普通です。永続的に利用するかプロジェクトフェーズ中のみ利用するかにかかわらず、オンデマンド料金モデルを利用する場合は、Amazon EC2 のコストに変動が見られます。データボリューム管理戦略を用意していない場合、Amazon EBS および Amazon S3 のコストは予想より高くなる可能性があります。
支出の可視性を高める目的で使える、セットアップの簡単なツールが、 [AWS Cost Anomaly Detection](https://aws.amazon.com/aws-cost-management/aws-cost-anomaly-detection/) です。このツールを使うと、高度な機械学習 (ML) テクノロジーを通じて異常な支出や根本原因を特定し、対策をとることができます。予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) を使用します。予算アラートを設定して、しきい値を超えた場合に通知が届くようにしましょう。
[AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/?track=costop_bottom) と [AWS Billing and Cost Management](https://docs.aws.amazon.com/account-billing/) は、可視性と分析のためのツールです。
詳細なガイダンスは、Well-Architected Framework [コスト最適化]: [経費支出と使用量の認識](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/expenditure-and-usage-awareness.html) に記載されています。
**提案 20.3.2 – タグを使って支出を分析し、配分する**
支出を分析するには、 [コスト配分タグ](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html#allocation-what) を作成して、個々のアカウント、リソース、ビジネスユニット、SAP 環境ごとに AWS リソースの料金を特定します。作成したコスト配分タグは、AWS 請求レポートに表示され、Cost Explorer で分析できます。コスト配分タグを使用すると、個々の SAP 環境に関連するコストが特定できます。これにより、一時的な環境やプロジェクト環境が不要になった場合など、特定の環境に関連したコストを削減または除外する措置が必要なことを把握できます。コスト配分タグが付いていないリソースを特定するプロセスを用意する必要があります。これらのリソースにコスト配分タグを付けるための措置を実施します。
+ SAP on AWS ブログ: [Tagging recommendations for SAP on AWS (SAP on AWS のタグ付けレコメンデーション)](https://aws.amazon.com/blogs/awsforsap/tagging-recommendations-for-sap-on-aws/)
# ベストプラクティス 20.4 – コスト関連の承認手続きとコントロールを確立する
場合によっては、従来型のコスト評価プロセスをクラウドの使用に向けて適応させる必要があります。適切な財務慣行と財務ポリシーを実施する方法を、 [AWS クラウド財務管理のガイド](https://aws.amazon.com/executive-insights/content/cloud-financial-management-reference-guide)で確認してください。
**提案 20.4.1 – 管理者にコストへの影響について学んでもらう**
コスト最適化に向けて、責任を割り振り、インセンティブを与えるメカニズムを導入します。
**提案 20.4.2 – IAM コントロールを使用してインスタンスのプロビジョニングを特定のユーザーのみに許可する**
アカウントの境界内でリソースタイプと職務に沿った IAM ポリシーを使用し、コストを制御します。例えば、プロジェクトチームに対し、サンドボックスアカウント内での小規模な追加システムの制御を許可する場合があるでしょう。ただしその場合は、さらなる承認プロセスを用意し、本番稼働アカウントでの大きなインスタンスへのアクセスを制限します。
# ベストプラクティス 20.5 – 使用状況を確認し、最適化を図る
SAP ワークロードを定期的に確認し、コスト最適化の機会を特定します。定期的な確認作業では、AWS の請求書と SAP ワークロード予算の間に見られる差異と異常をできるだけなくすこと、SAP クラウドリソースがすべて適切にサイジングされているか、過剰にプロビジョニングされていないかを確認すること、SAP ワークロードのコスト効率の改善につながるような新たな AWS サービスまたは値下げが発表されていないか確認することに焦点を置きます。
**提案 20.5.1 – 使用量が当初の計画より多い場合は追加コストを最小限に抑える**
予期しないビジネスイベントが発生した場合や、さらなるパフォーマンスが必要になった場合、クラウドの使用量が増えて推定コストを超えることがあります。このような変化を分析するときは、新たなコストの最適化を念頭に置きます。変化が持続的なものであれば、Savings Plan の契約またはリザーブドインスタンスを増やすことを検討します。
短期間だけキャパシティを増やす必要がある場合は、オートスケーリングまたはスケジュールされたオンデマンドインスタンス容量を使った水平スケーリング (例えば、SAP アプリケーションサーバーの追加) を行ってコストを最小化することを検討します。
**提案 20.5.2 – SAP ワークロードの使用状況メトリクスを確認し、可能な限り適切なサイジングを行う**
SAP システムを支えるコンポーネントについて、サイジングが適切かを定期的に確認します。CloudWatch メトリクスに基づいて以下の点を検討します。
+ SAP EC2 コンピューティングは適切なサイズか。 CPU またはメモリの使用率が低いか。 小さい EC2 インスタンスサイズに移行できるか。
+ SAP ストレージは適切なサイズか。 プロビジョニングしていながら使用していない超過スペースがないか。 ボリュームサイズを削減できるか。
+ SAP ストレージのパフォーマンスは適切か。 過剰にプロビジョニングされ、削減可能な IOPS または MBps はないか。
+ バックアップとスナップショットは適切に管理されているか。 S3 Standard にあるバックアップコピーが多すぎないか。それを Amazon S3 Infrequently Accessed または Amazon S3 Glacier にアーカイブできないか。
+ 例えば [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) や [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/) のようなツールを使用して最適化の余地がある領域を特定します。SAP 特有のコンピューティングおよびストレージの制限について次で確認します。SAP Note: [1656099 - SAP Applications on AWS: Supported DB/OS and Amazon EC2 products (AWS 上の SAP アプリケーション: サポートされる DB/OS および Amazon EC2 製品)](https://launchpad.support.sap.com/#/notes/1656099) [SAP ポータルへのアクセス権が必要]。
わかったことに基づいて、引き続き SAP ワークロードコンポーネントを定期的にサイジングし、Savings Plans およびリザーブドインスタンスを最大限に使用します。
**提案 20.5.3 – AWS の新しいサービスおよびプランのうち、どれを採用すればさらなるコスト最適化が可能かを理解する**
AWS は、定期的に新しいサービスや値下げを発表しています。少なくとも 1 年に 1 回、新しい SAP on AWS サービスの発表を確認し、自身のアーキテクチャで活用する方法を検討してください。AWS と結んだ Enterprise Support 契約の中でテクニカルアカウントマネージャー (TAM) を割り当てられている場合は、TAM が定期的な新サービスと最適化の検討をお手伝いします。
最新のお知らせとニュースを受け取るため、 [SAP on AWS ブログ](https://aws.amazon.com/blogs/awsforsap/) および [最新情報](https://aws.amazon.com/new/) フィードに登録しましょう。
SAP ワークロードを継続的に最適化する方法については、[運用上の優秀性]: [ベストプラクティス 4.4 - 定期的なワークロードレビューを実行して、回復力、パフォーマンス、俊敏性、コストを最適化する](best-practice-4-4.md) をご覧ください。