# 費用対効果の高いリソース
**Topics**
+ [COST 5. サービスを選択するときは、どのようにコストを評価するのですか?](cost-05.md)
+ [COST 6. コストターゲットに合わせて、リソースタイプ、リソースサイズ、およびリソース数を選択するには、どうすればよいですか?](cost-06.md)
+ [COST 7. 料金モデルは、コスト削減のためにどのように使用するのですか?](cost-07.md)
+ [COST 8. データ転送料金はどのように計画するのですか?](cost-08.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-BP05 組織の優先順位に従ってコストが最適化されるようにこのワークロードのコンポーネントを選択する](cost_select_service_select_for_cost.md)
+ [COST05-BP06 異なる使用量について経時的なコスト分析を実行する](cost_select_service_analyze_over_time.md)
# COST05-BP01 組織のコスト要件を特定する
チームメンバーと協力して、コストの最適化とこのワークロードのその他の柱とのバランス (パフォーマンスや信頼性など) を定義します。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
ほとんどの組織で、情報技術 (IT) 部門は複数の小さなチームから構成されており、抱える議題や注力分野は、所属メンバーの専門分野とスキルを反映してそれぞれに異なります。組織全体の目標、優先事項、目的を把握し、各部門や各プロジェクトがそうした目標にどのように貢献しているかを理解する必要があります。人員、設備、技術、資材、外部サービスなど、すべての重要なリソースを分類しておくことは、組織の目標を達成し、包括的な予算計画を立てるうえで不可欠です。こうした体系的なアプローチでコストを特定し、把握することが、組織にとって現実的で健全なコスト計画を立てるための基本です。
ワークロードのサービスを選択する場合は、組織の優先順位を理解することが重要です。コスト最適化と、AWS Well-Architected フレームワークの他の柱 (パフォーマンスや信頼性など) とのバランスを図ります。このプロセスは、組織の目標、市況、業務のダイナミクスの変化を反映するために、体系的かつ定期的に実施する必要があります。十分にコスト最適化されたワークロードとは組織の要件に最も適合するソリューションであって、必ずしも最低コストのソリューションとは限りません。製品、ビジネス、技術、財務など、組織内のすべてのチームと会合し、情報を収集します。競合する利益または代替アプローチ間のトレードオフの影響を評価し、重点領域を決定するか、一連のアクションを選択する際に十分な情報に基づいて意思決定を下せるようにします。
例えば、新しい機能の市場投入までの時間を短縮することは、コストの最適化よりも重視されることがあります。または、非リレーショナルデータ用にリレーショナルデータベースを選択すれば、データ型に合わせて最適化されたデータベースに移行してアプリケーションを更新するよりも、システムの移行が簡素化されます。
### 実装手順
+ **組織のコスト要件を特定する:** 製品管理、アプリケーション所有者、開発および運用チーム、管理、財務ロールのメンバーなど、組織のチームメンバーとミーティングを行います。このワークロードとそのコンポーネントに対して、Well-Architected の柱に優先順位を付けます。柱を順番に並べたリストを作成してください。また、それぞれの柱に重みを付け、その柱が他の柱よりどの程度重視されているかや、2 つの柱の重点度がどの程度類似しているかを示すことができます。
+ **技術的負債に対処し、文書化する:** ワークロードのレビュー中に、技術的負債に対処します。バックログ項目を文書化して、後日、リファクタリングやリアーキテクティングで最適化を進めることを目標に、ワークロードを保持します。生じたトレードオフを他のステークホルダーに明確に伝えることが大切です。
## リソース
**関連するベストプラクティス:**
+ [REL11-BP07 可用性の目標と稼働時間のサービスレベルアグリーメント (SLA) を満たす製品を設計する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_service_level_agreements.html)
+ [OPS01-BP06 トレードオフを評価する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_priorities_eval_tradeoffs.html)
**関連ドキュメント:**
+ [AWS 総保有コスト (TCO) 計算ツール](https://aws.amazon.com/tco-calculator/)
+ [Amazon S3 ストレージクラス](https://aws.amazon.com/s3/storage-classes/)
+ [AWS クラウド製品](https://aws.amazon.com/products/)
# COST05-BP02 ワークロードのすべてのコンポーネントを分析する
現在のサイズやコストに関係なく、すべてのワークロードが分析されることを確認します。見直しを行う際には、現在のコストや予想コストなどの潜在的利益を織り込む必要があります。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
組織にビジネス価値をもたらすべく設計されたワークロードコンポーネントには、さまざまなサービスが含まれる場合があります。コンポーネントごとに、ビジネスニーズに対応する特定の AWS クラウドサービスを選択できます。何が選択されるかは、それらのサービスに関する知識や使用経験などの要因によって違ってきます。
「[COST05-BP01 組織のコスト要件を特定する](https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/cost_select_service_requirements.html)」で説明されているように組織の要件を特定したら、ワークロード内のすべてのコンポーネントを徹底的に分析します。現時点と今後予測されるコストとサイズを考慮して、各コンポーネントを分析します。分析のコストを、ワークロードのライフサイクル全体で削減が見込まれる額と比較検討してください。対象となるワークロードのコンポーネントをすべて分析するための労力が、そのコンポーネントの最適化により見込まれる節約額や改善に見合っていなければなりません。例えば、提案されたリソースのコストが月額 10 USD で、予測負荷が月額 15 USD を超えない場合に、コストを 50% (月額 5 USD) 削減するために 1 日分の労力を費やすようでは、システムの寿命全体にわたって得られると考えられる利益を超えることになるかもしれません。データに基づくより高速でより効率的な予測を使用すると、このコンポーネントの全体的な成果を最善のものにできます。
ワークロードは時間の経過とともに変化する可能性があり、ワークロードのアーキテクチャや使用方法が変化すると、適切だったサービスの組み合わせが最適ではなくなってしまうことがあります。サービスの選択に関する分析には、現在および将来のワークロードの状態と使用量レベルが組み込まれる必要があります。将来のワークロードの状態や使用量に合わせてサービスを運用すると、今後の変更に必要な労力を軽減または削除できることになり、全体的なコストを削減できます。例えば、最初は EMR Serverless の使用が適しているかもしれません。ただし、そのサービスの使用量が増えてきたら、EC2 の EMR に移行することで、ワークロードの該当コンポーネントのコストを削減できる可能性があります。
[AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) および AWS Cost and Usage Report ([CUR](https://aws.amazon.com/aws-cost-management/aws-cost-and-usage-reporting/)) では、概念実証 (PoC) または実行中の環境のコストを分析できます。[AWS 料金見積りツール](https://calculator.aws/#/) を使用してワークロードのコストを見積もることもできます。
技術チームがワークロードを見直すためのワークフローを作成します。このワークフローはシンプルなものにし、必要なステップをすべて網羅することで、チームがワークロードの各コンポーネントとその料金を理解できるようにします。組織はこのワークフローに従い、またそれを各チームの特定のニーズに基づいてカスタマイズできます。
1. **ワークロードに使用されている各サービスを一覧表示する:** これは良い出発点です。現在使用されているすべてのサービスと、コストの発生源を特定します。
1. **これらのサービスの料金体系を理解する:** 各サービスの[料金モデル](https://aws.amazon.com/pricing/)を理解します。AWS の各サービスには、使用量、データ転送、機能に固有の料金などの要因に基づくさまざまな料金モデルがあります。
1. **予期しないワークロードコストがあり、予想される使用量やビジネス成果と一致しないサービスに着目する:** AWS Cost Explorer または AWS Cost and Usage Report を使用して、外れ値やコストが価値や使用量に比例しないサービスを特定します。最適化にかける労力に優先順位を付けるには、コストとビジネス成果を相関付けることが重要です。
1. **AWS Cost Explorer、CloudWatch Logs、VPC フローログ、Amazon S3 ストレージレンズを使用して、これらの高コストの根本原因を把握する:** これらのツールは、高コストの診断に役立ちます。各サービスは、使用量とコストの確認と分析に役立つ異なる観点を提供します。例えば、Cost Explorer は全体的なコスト傾向の特定に役立ち、CloudWatch Logs は運用に関するインサイトを提供します。また、VPC フローログは IP トラフィックを表示し、Amazon S3 ストレージレンズはストレージ分析に有用です。
1. **AWS Budgets を使用して、サービスまたはアカウントの特定金額の予算を設定する:** 予算の設定は、積極的なコスト管理方法です。AWS Budgets を使用して、カスタム予算しきい値を設定し、コストがそのしきい値を超えたときにアラートを受け取ります。
1. **請求および使用状況アラートを送信するように Amazon CloudWatch アラームを設定する:** コストと使用状況メトリクスのモニタリングとアラートを設定します。CloudWatch アラームを使用すると特定のしきい値を超えたときに通知できるため、介入の応答時間を短縮できます。
現在の属性に関係なく、すべてのワークロードコンポーネントを戦略的に見直すことで、時間の経過に伴う着実な強化とコスト削減を促進します。このレビュープロセスに費やす労力は、それに見合う効果が得られるか慎重に検討したうえで、決める必要があります。
### 実装手順
+ **ワークロードコンポーネントを一覧する:** ワークロードのコンポーネントのリストを作成します。このリストを使用して、各コンポーネントが分析されたことを確認します。費やされる労力は、組織の優先順位によって定義されたワークロードの重要度に見合うものにする必要があります。効率向上のために、リソースを機能別にグループ化します (複数のデータベースがある場合は本番データベースストレージなど)。
+ **コンポーネントリストを優先順位付けする:** コンポーネントリストを取得して、労力をかける順で優先順位を付けます。これは通常、コンポーネントのコストが最も高価なものから最も安価なものへ、または組織の優先順位で定義されている重要度の順に並べられます。
+ **分析を実行する:** リストの各コンポーネントについて、使用可能なオプションとサービスを確認し、組織の優先順位に最適なオプションを選択します。
## リソース
**関連ドキュメント:**
+ [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/)
+ [AWS クラウド 製品](https://aws.amazon.com/products/)
**関連動画:**
+ [AWS コスト最適化シリーズ: CloudWatch](https://www.youtube.com/watch?v=6imTJUGEzjU)
# COST05-BP03 各コンポーネントの詳細な分析を実行する
各コンポーネントの、組織にかかる全体的なコストを調べます。運用および管理のコスト、特にクラウドプロバイダーが提供するマネージドサービスを使用するコストを考慮して、総保有コストを計算します。レビューを行う際には、潜在的利益 (分析に費やされた時間がコンポーネントのコストに比例しているなど) を織り込む必要があります。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
時間短縮を検討して、チームが技術的な負債の返済、イノベーション、付加価値機能、ビジネスの差別化要素の構築に集中できるようにします。例えば、データベースをできるだけ迅速にオンプレミス環境からクラウドにリフトアンドシフト (リホストともいいます) して、後で最適化する必要がある場合です。AWS でマネージドサービスを利用して、ライセンスコストの排除または削減を模索することには、時間をかけるだけの価値があります。AWS のマネージドサービスによって、OS のパッチ適用やアップグレードなど、サービス維持に伴う運用上および管理上の負担が軽減されるため、イノベーションとビジネスに集中できます。
マネージドサービスはクラウド規模で運用されるため、トランザクションまたはサービス単位でコストを削減できます。アプリケーションのコアアーキテクチャを変更せずに、具体的なメリットを生み出すための潜在的最適化作業を行うことができます。例えば、[Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds/) などの Database as a Service プラットフォームに移行するか、アプリケーションを [AWS Elastic Beanstalk](https://aws.amazon.com/elasticbeanstalk/) などのフルマネージドプラットフォームに移行することで、データベースインスタンスの管理に要する時間を短縮したいと考えているとします。
通常、マネージドサービスは、十分なキャパシティを確保するために設定できる属性を備えています。この属性を設定およびモニタリングして、余剰キャパシティを最小限に抑え、パフォーマンスを最大化する必要があります。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/)、[Amazon Redshift](https://aws.amazon.com/redshift/)、[Amazon ElastiCache](https://aws.amazon.com/elasticache/) はマネージドデータベースサービスを提供しています。[Amazon Athena](https://aws.amazon.com/athena/)、[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 マネージドリソースと比較します。例えば、Amazon EC2 インスタンスで実行しているデータベースをレビューし、Amazon RDS (AWS マネージドサービス) を使用した場合と比較したり、Amazon EMR を、Amazon EC2 で Apache Spark を実行する場合と比較したりします。セルフマネージドワークロードから AWS のフルマネージドワークロードに移行する際は、オプションを慎重に研究してください。考慮すべき最も重要な 3 つの要因は、使用する[マネージドサービスのタイプ](https://aws.amazon.com/products/?&aws-products-all.q=managed)、[データの移行](https://aws.amazon.com/big-data/datalakes-and-analytics/migrations/)に使用するプロセス、[AWS 責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)の理解です。
## リソース
**関連ドキュメント:**
+ [AWS 総保有コスト (TCO) 計算ツール](https://aws.amazon.com/tco-calculator/)
+ [Amazon S3 ストレージクラス](https://aws.amazon.com/s3/storage-classes/)
+ [AWS クラウド 製品](https://aws.amazon.com/products/)
+ [AWS 責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)
**関連動画:**
+ [Why move to a managed database?](https://www.youtube.com/watch?v=VRFdc-MVa4I)
+ [What is Amazon EMR and how can I use it for processing data?](https://www.youtube.com/watch?v=jylp2atrZjc)
**関連する例:**
+ [マネージドデータベースに移行すべき理由](https://aws.amazon.com/getting-started/hands-on/move-to-managed/why-move-to-a-managed-database/)
+ [Consolidate data from identical SQL Server databases into a single Amazon RDS for SQL Server database using AWS DMS](https://aws.amazon.com/blogs/database/consolidate-data-from-identical-sql-server-databases-into-a-single-amazon-rds-for-sql-server-database-using-aws-dms/)
+ [Amazon Managed Streaming for Apache Kafka (Amazon MSK) にデータを大規模に提供する](https://aws.amazon.com/getting-started/hands-on/deliver-data-at-scale-to-amazon-msk-with-iot-core/?ref=gsrchandson)
+ [Migrate an ASP.NET web application to AWS Elastic Beanstalk](https://aws.amazon.com/getting-started/hands-on/migrate-aspnet-web-application-elastic-beanstalk/?ref=gsrchandson&id=itprohandson)
# COST05-BP04 コスト効率の高いライセンスを提供するソフトウェアを選択する
オープンソースソフトウェアは、ワークロードに多大なコストをもたらすソフトウェアライセンスコストを排除することができます。ライセンスされたソフトウェアが必要な場合は、CPU などの任意の属性に結びついたライセンスは避け、出力または結果に結びついたライセンスを探します。これらのライセンスのコストは、提供するメリットに応じてより密にスケールされます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
「オープンソース」は、ソフトウェア開発の文脈で生まれた用語であり、ソフトウェアが特定の無料配布基準に準拠しているという意味です。オープンソースソフトウェアは、誰でも検査、変更、拡張できるソースコードで構成されています。組織はビジネス要件、エンジニアのスキル、予測される使用状況、その他の技術的な依存関係を踏まえて、ライセンスコストを最小限に抑えるため、AWS でオープンソースソフトウェアを使用することを検討できます。言い換えれば、ソフトウェアライセンスのコストは、[オープンソースソフトウェア](https://aws.amazon.com/what-is/open-source/)を使用することで削減できます。オープンソースソフトウェアへの変更は、ワークロードサイズが拡大するにつれ、ワークロードコストに大きな影響を与える可能性があります。
ライセンスを取得したソフトウェアで得られる効果を、ワークロードの最適化にかかる総コストに照らして測定してください。ライセンス変更とその変更がワークロードコストに与える影響をモデリングします。あるベンダーがデータベースライセンスのコストを変更したなら、それがワークロードの全体的な効率にどのような影響を与えるかを調査します。ベンダーの過去の価格アナウンスを検討して、ベンダー製品全体のライセンス変更の傾向を検討してください。ライセンスコストは、ハードウェアごとにスケールするライセンス (CPU バウンドライセンス) など、スループットや使用量とは関係なくスケールされる場合があります。こうしたライセンスは、それに伴う成果が見られないままコストが急増する可能性があるため、避けてください。
例えば、Linux オペレーティングシステムを搭載した Amazon EC2 インスタンスを us-east-1 で運用する場合、Windows で実行する別の Amazon EC2 インスタンスを運用する場合と比較して約 45% のコスト削減になります。
[AWS 料金見積りツール](https://calculator.aws/) では、Amazon RDS インスタンスや各種データベースエンジンなど、ライセンスオプションが異なるさまざまなリソースのコストを包括的に比較できます。さらに、AWS Cost Explorer では、既存のワークロード (特にライセンスがさまざまに異なるワークロード) のコストを有益な視点で検討できます。ライセンス管理のために、[AWS License Manager](https://aws.amazon.com/license-manager) はソフトウェアライセンスを監督および処理するための合理化された方法を提供します。お客様は、AWS クラウドでお好みのオープンソースソフトウェアをデプロイして運用できます。
### 実装手順
+ **ライセンスオプションを検討する:** 利用可能なソフトウェアのライセンス条項を確認します。必要な機能を備えたオープンソースバージョンを探し、ライセンスされたソフトウェアの利点がコストを上回っているかどうかを調べます。好条件があれば、ソフトウェアのコストに見合う利点が得られます。
+ **ソフトウェアプロバイダーを分析する:** ベンダーからの料金またはライセンスの変更履歴を確認します。特定のベンダーのハードウェアまたはプラットフォームで実行することについての懲罰的な条件など、結果に見合わない変更を調べます。また、監査の実行方法や課される可能性のある罰則についても確認します。
## リソース
**関連ドキュメント:**
+ [Open Source at AWS](https://aws.amazon.com/opensource/)
+ [AWS 総保有コスト (TCO) 計算ツール](https://aws.amazon.com/tco-calculator/)
+ [Amazon S3 ストレージクラス](https://aws.amazon.com/s3/storage-classes/)
+ [AWS クラウド製品](https://aws.amazon.com/products/)
**関連する例:**
+ [オープンソースブログ](https://aws.amazon.com/blogs/opensource/)
+ [AWS オープンソースブログ](https://aws.github.io/)
+ [最適化とライセンス評価](https://aws.amazon.com/optimization-and-licensing-assessment/)
# COST05-BP05 組織の優先順位に従ってコストが最適化されるようにこのワークロードのコンポーネントを選択する
ワークロードのすべてのコンポーネントを選択したときのコストを考慮します。これには、アプリケーションレベルのサービスとマネージドサービス、またはサーバーレス、コンテナ、イベント駆動型アーキテクチャを使用して、全体のコストを削減することが含まれます。オープンソースソフトウェアやライセンス料金がかからないソフトウェア、または代替品を使用して、支出を最小限に抑えます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
すべてのコンポーネントを選択する際は、サービスのコストとオプションを考慮します。これには、アプリケーションレベルのサービスとマネージドサービスである、[Amazon Relational Database Service](https://aws.amazon.com/rds/) (Amazon RDS)、[Amazon DynamoDB](https://aws.amazon.com/dynamodb/)、[Amazon Simple Notification Service](https://aws.amazon.com/sns/) (Amazon SNS)、[Amazon Simple Email Service](https://aws.amazon.com/ses/) (Amazon SES) を使用して組織の全体的なコストを削減することが含まれます。
コンピューティングにはサーバーレスやコンテナを使用します。[AWS Lambda](https://aws.amazon.com/lambda/) や静的ウェブサイト用の [Amazon Simple Storage Service](https://aws.amazon.com/s3/) (Amazon S3) などです。可能であればアプリケーションをコンテナ化し、[Amazon Elastic Container Service](https://aws.amazon.com/ecs/) (Amazon ECS) や [Amazon Elastic Kubernetes Service](https://aws.amazon.com/eks/) (Amazon EKS) などの AWS マネージドコンテナサービスを使用します。
オープンソースソフトウェア、またはライセンス料金のないソフトウェア (コンピューティングワークロード用の Amazon Linux、データベースを Amazon Aurora に移行するなど) を使用して、ライセンスコストを最小限に抑えます。
[Lambda](https://aws.amazon.com/lambda/)、[Amazon Simple Queue Service (Amazon SQS)](https://aws.amazon.com/sqs/)、[Amazon SNS](https://aws.amazon.com/sqs/)、[Amazon SES](https://aws.amazon.com/ses/) などのサーバーレスまたはアプリケーションレベルのサービスを使用できます。これらのサービスではリソースを管理する必要がなく、コード実行、キューサービス、メッセージ配信の機能を利用できます。もう 1 つの利点は、使用量に応じてパフォーマンスとコストをスケールインするため、コスト配分とコストの帰属が効率的になることです。
[イベント駆動型アーキテクチャ](https://aws.amazon.com/what-is/eda/)は、サーバーレスサービスで使用することもできます。イベント駆動型アーキテクチャはプッシュベースであるため、イベントはルーターで発生してもオンデマンドで取得されます。この方法では、イベントをチェックするために定期的にポーリングする費用が発生しません。つまり、ネットワーク帯域幅の消費を抑え、CPU 使用率は低く、アイドルなフリートキャパシティは少なくなり、SSL/TLS ハンドシェイクも減ります。
サーバーレスの詳細については、[Well-Architected サーバーレスアプリケーションレンズのホワイトペーパー](https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/welcome.html)を参照してください。
### 実装手順
+ **各サービスを選択してコストを最適化する:** 優先順位リストと分析を使用して、組織の優先順位に最も合致する各オプションを選択します。需要に合わせてキャパシティを増やすのではなく、より低いコストでより優れたパフォーマンスを得られる可能性がある他のオプションを検討します。例えば、AWS 上のデータベースに対する予想されるトラフィックを見直す必要がある場合、インスタンスサイズを増やす、または Amazon ElastiCache サービス (Redis または Memcached) を使用してデータベースにキャッシュメカニズムを提供することを検討します。
+ **イベント駆動型アーキテクチャを評価する:** サーバーレスアーキテクチャを使用すると、分散マイクロサービスベースのアプリケーション向けにイベント駆動型アーキテクチャを構築することもできます。これを利用すると、スケーラブルで回復性が高く、迅速かつコスト効果の高いソリューションを構築できます。
## リソース
**関連ドキュメント:**
+ [AWS 総保有コスト (TCO) 計算ツール](https://aws.amazon.com/tco-calculator/)
+ [AWSサーバーレス](https://aws.amazon.com/serverless/)
+ [イベント駆動型アーキテクチャとは](https://aws.amazon.com/what-is/eda/)
+ [Amazon S3 ストレージクラス](https://aws.amazon.com/s3/storage-classes/)
+ [AWS クラウド製品](https://aws.amazon.com/products/)
+ [Amazon ElastiCache (Redis OSS)](https://aws.amazon.com/elasticache/redis)
**関連する例:**
+ [イベント駆動型アーキテクチャの導入](https://aws.amazon.com/blogs/compute/getting-started-with-event-driven-architecture/)
+ [イベント駆動型アーキテクチャ](https://aws.amazon.com/event-driven-architecture/)
+ [Amazon ElastiCache (Redis OSS) を使用して 100 倍効率よく Statsig を実行する方法](https://aws.amazon.com/blogs/database/how-statsig-runs-100x-more-cost-effectively-using-amazon-elasticache-for-redis/)
+ [AWS Lambda 関数を使用するためのベストプラクティス](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html)
# COST05-BP06 異なる使用量について経時的なコスト分析を実行する
ワークロードは時間の経過とともに変化することがあります。それぞれのサービスまたは機能のコスト効率は、使用レベルによって異なります。各コンポーネントについて予想使用量に基づく経時的な分析を実行することで、ワークロードのコスト効率性がそのライフタイム全体にわたって維持されます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
AWS で新しいサービスや機能がリリースされると、ワークロードに最適なサービスが変化する可能性があります。求められる労力は、潜在的な利点が反映されたものである必要があります。ワークロードレビューの頻度は、組織の要件によって異なります。ワークロードにかなりのコストがかかっている場合、新しいサービスの運用が早いほどコスト削減が最大になるため、レビュー頻度が高い方が有利です。レビューの開始要因には、使用パターンの変化も挙げられます。使用量が大幅に変化した場合は、別のサービスを使った方がよい場合もあります。
データを AWS クラウドに移動する必要がある場合、AWS が提供するバリエーション豊かな製品やパートナーツールを選択して、データセットを移行できます。データセットは、ファイル、データベース、マシンイメージ、ブロックボリューム、あるいはテープバックアップであっても構いません。例えば、大量のデータを AWS に対して入出力する場合や、エッジでデータを処理する場合、AWS の目的別デバイスのいずれかを使用して、コスト効果が高い方法でペタバイト規模のデータをオフラインで移動できます。別の例としては、より速いデータ転送速度が必要な場合、VPN よりも、ビジネスに必要な安定した接続性能を提供する直接接続サービスの方が安価な場合があります。
さまざまな使用状況において繰り返したコスト分析を基にして、スケーリングアクティビティをレビューします。結果を分析して、複数のインスタンスタイプと購入オプションを使用したインスタンスの追加に合わせてスケーリングポリシーを調整できるかを確認します。設定をレビューして、最小限を削減してもユーザーリクエストを処理できる (ただしより小さなフリートサイズで) かを確認し、予想される高需要を満たすためにリソースを追加します。
組織のステークホルダーと話し合い、[AWS Cost Explorer の](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-forecast.html)予測機能を使用してサービス変更の潜在的な影響を予測し、時間の経過とともにさまざまな使用状況のコスト分析を行います。AWS Budgets、CloudWatch 請求アラーム、AWS Cost Anomaly Detection を使用して使用状況レベルのトリガーをモニタリングし、最もコスト効果が高いサービスをなるべく迅速に特定して実装します。
**実装手順**
+ **予測された使用パターンを定義する:** マーケティングや製品所有者などの組織と協力して、ワークロードに対して期待および予測される使用パターンを文書化します。これまでと今後両方のコストと使用量の増加についてビジネス上の関係者と話し合い、増加がビジネス要件に沿ったものであることを確認します。自社の AWS リソースを使用するユーザーが増える日、週、月を特定します。そのタイミングで既存のリソースのキャパシティを増やすか追加サービスを導入して、コストを削減しパフォーマンスを向上させる必要があります。
+ **予測された使用量に基づきコスト分析を実行する:** 定義された使用パターンを使用して、それらの各ポイントで分析を実行します。分析作業は、潜在的な結果を反映する必要があります。例えば、使用量の変化が大きい場合は、コストと変化を確認するために詳細な分析を実行する必要があります。つまり、コストが増えていれば、ビジネスにおける使用量も同様に増えているはずです。
## リソース
**関連ドキュメント:**
+ [AWS 総保有コスト (TCO) 計算ツール](https://aws.amazon.com/tco-calculator/)
+ [Amazon S3 ストレージクラス](https://aws.amazon.com/s3/storage-classes/)
+ [AWS クラウド製品](https://aws.amazon.com/products/)
+ [Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [クラウドへのデータ移行](https://aws.amazon.com/cloud-data-migration/)
+ [AWS Snow Family](https://aws.amazon.com/snow/)
**関連動画:**
+ [AWS OpsHub for Snow Family](https://www.youtube.com/watch?v=0Q7s7JiBCf0)
# 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-BP04 共有リソースの使用を検討する](cost_type_size_number_resources_shared.md)
# COST06-BP01 コストモデリングを実行する
組織の要件 (ビジネスニーズや既存のコミットメントなど) を特定して、ワークロードとその各コンポーネントのコストモデリング (全体コスト) を実行します。予測されたさまざまな負荷のワークロードに対してベンチマークアクティビティを実行し、コストを比較します。モデリングの際には、潜在的な利点を織り込む必要があります。例えば、費やされた時間がコンポーネントのコストに釣り合っているなどです。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
ワークロードと各コンポーネントのコストモデリングを実行してリソース間のバランスを把握し、特定のパフォーマンスレベルに応じてワークロード内の各リソースの適切なサイズを見つけます。コストの考慮事項を理解すると、計画されたワークロードのデプロイにおける価値実現の成果評価時に、組織のビジネスケースや意思決定プロセスがわかります。
予測されたさまざまな負荷のワークロードに対してベンチマークアクティビティを実行し、コストを比較します。モデリングの際には、費やした時間がコンポーネントのコストまたは予想される削減額に比例しているといった潜在的な利点を織り込む必要があります。このプロセスのベストプラクティスについては、[AWS Well-Architected フレームワークのパフォーマンス効率の柱に関するレビューセクション](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/review.html)を参照してください。
例えば、コンピューティングリソースで構成されているワークロードのコストモデリングを作成するときは、[AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) がワークロード実行のためのコストモデリングに役立ちます。使用履歴に基づき、コンピューティングリソースの正しいサイズ設定に関するレコメンデーションを提供します。CloudWatch エージェントが Amazon EC2 インスタンスにデプロイされていることを確認し、AWS Compute Optimizer 内でより正確な推奨事項を得ることができるメモリメトリクスを収集します。リスクレベルに応じて複数のレコメンデーションを作成できる機械学習が使われている無料サービスであるため、コンピューティングリソースにとって理想的なデータソースです。
他のサービスやワークロードコンポーネントのサイズ適正化のために、カスタムログをデータソースとして使用できるサービスは、[AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)、[Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)、[Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) など[複数](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-right-sizing/identifying-opportunities-to-right-size.html)あります。リソースをチェックして使用率が低いリソースにフラグを立てる AWS Trusted Advisor は、リソースのサイズを適正化しコストモデリングを作成するのに役立ちます。
コストモデリングのデータとメトリクスに関する推奨事項は以下のとおりです。
+ モニタリングはユーザーエクスペリエンスを正確に反映する必要があります。対象期間に適切な間隔を選択して、平均の変わりに最大値や 99 パーセンタイル値をじっくり見極めます。
+ すべてのワークロードのサイクルをカバーするために必要な分析期間の適切な間隔を選択します。例えば、分析を 2 週間間隔で実行する場合、1 か月サイクルで使用率が高くても見逃す場合があり、過小プロビジョニングにつながる可能性があります。
+ 既存のコミットメント、他のワークロード用に選択された料金モデル、イノベーションを迅速化しコアビジネスバリューに集中する能力を考慮し、計画されたワークロードに対して適切な AWS サービスを選択します。
**実装手順**
+ **リソースのコストモデリングを実行する:** ワークロードまたは概念実証を、テストする特定のリソースタイプとサイズを持つ別のアカウントにデプロイします。テストデータを使用してワークロードを実行し、出力結果のほか、テスト実行時のコストデータを記録します。その後、ワークロードを再デプロイするか、リソースタイプとサイズを変更して、テストをもう一度実行します。コストモデリングの際には、これらのリソースで使用する可能性のある製品のライセンス料と、これらのリソースをデプロイおよび管理する推定運用 (作業またはエンジニア) コストを含めます。一定期間 (時間単位、日次、月次、年次、三年次) のコストモデリングを考慮します。
## リソース
**関連ドキュメント:**
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [適切なサイジングのための機会の特定](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-right-sizing/identifying-opportunities-to-right-size.html)
+ [Amazon CloudWatch の特徴](https://aws.amazon.com/cloudwatch/features/)
+ [コスト最適化: Amazon EC2 の適切なサイジング](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ce-rightsizing.html)
+ [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/)
+ [AWS Pricing Calculator](https://calculator.aws/#/)
**関連する例:**
+ [ Perform a Data-Driven Cost modeling ](https://aws.amazon.com/blogs/mt/how-to-use-aws-well-architected-with-aws-trusted-advisor-to-achieve-data-driven-cost-optimization/)
+ [計画している AWS リソース構成のコストを見積もる方法を教えてください。](https://aws.amazon.com/premiumsupport/knowledge-center/estimating-aws-resource-costs/)
+ [Choose the right AWS tools](https://www.learnaws.org/2019/09/27/choose-right-aws-tools/)
# COST06-BP02 データに基づいてリソースタイプ、リソースサイズ、リソース数を選択する
ワークロードとリソースの特性に関するデータに基づいて、リソースのサイズやタイプを選択します。例えば、コンピューティング、メモリ、スループット、書き込み頻度などです。この選択は通常、以前の (オンプレミス) バージョンのワークロード、ドキュメント、ワークロードに関する他の情報ソースを用いて行います。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
Amazon EC2 では、さまざまなユースケースに合わせて、CPU、メモリ、ストレージ、ネットワークキャパシティのレベルが異なる、幅広いインスタンスタイプを選択肢として用意しています。インスタンスタイプごとに CPU、メモリ、ストレージ、ネットワーク機能の組み合わせが異なるため、プロジェクトに適したリソースの組み合わせを柔軟に選択できます。どのインスタンスタイプにもサイズが複数用意されており、ワークロードの需要に基づいてリソースを調整できます。必要なインスタンスタイプを判断するには、インスタンスで実行する予定のアプリケーションまたはソフトウェアのシステム要件に関する詳細情報を収集する必要があります。これらの詳細には、次の内容を含める必要があります。
+ オペレーティングシステム
+ CPU コア数
+ GPU コア
+ システムメモリ (RAM) の容量
+ ストレージタイプとスペース
+ ネットワーク帯域幅要件
コンピューティング要件の目的と必要なインスタンスを明らかにしたうえで、さまざまな Amazon EC2 インスタンスファミリーを検討します。次のインスタンスタイプファミリーが提供されています。
+ 汎用
+ コンピューティング最適化
+ メモリを最適化
+ ストレージの最適化
+ 高速コンピューティング
+ HPC 最適化
特定の Amazon EC2 インスタンスファミリーが達成できる特定の目的とユースケースの詳細については、「[AWS インスタンスタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)」を参照してください。
お客様のニーズに最適な特定のインスタンスファミリーとインスタンスタイプを選択するには、システム要件の収集が不可欠です。インスタンスタイプ名は、ファミリー名とインスタンスサイズで構成されます。例えば、t2.micro インスタンスは T2 ファミリーに属するマイクロサイズです。
ワークロードとリソースの特性 (例えば、コンピューティング、メモリ、スループット、書き込み頻度) に基づいて、リソースのサイズやタイプを選択します。この選択は通常、コストモデリング、以前のバージョンのワークロード (オンプレミスバージョンなど)、ドキュメント、ワークロードに関する他の情報ソース (ホワイトペーパー、公開ソリューション) を用いて行います。AWS 料金見積りツールやコスト管理ツールを使用すれば、十分な判断材料を基にインスタンスのタイプ、サイズ、構成を決定できます。
### 実装手順
+ **データに基づいてリソースを選択する:** コストモデリングのデータを使用して、予測されるワークロードの使用レベルを選択し、指定されたリソースタイプとサイズを選択します。コストモデリングデータに基づいて、インスタンスに求められるデータ転送速度を考慮しつつ、仮想 CPU の数、総メモリ (GiB)、ローカルインスタンスストアボリューム (GB)、Amazon EBS ボリューム、ネットワークパフォーマンスレベルを決定します。常に詳細な分析と正確なデータに裏付けられた選択を行い、パフォーマンスの最適化とコスト管理の効率化を両立させましょう。
## リソース
**関連ドキュメント:**
+ [AWS インスタンスタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)
+ [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)
**関連動画:**
+ [Selecting the right Amazon EC2 instance for your workloads](https://www.youtube.com/watch?v=q5Dn9gcmpJg)
+ [Right size your service](https://youtu.be/wcp1inFS78A)
**関連する例:**
+ [It just got easier to discover and compare Amazon EC2 instance types](https://aws.amazon.com/blogs/compute/it-just-got-easier-to-discover-and-compare-ec2-instance-types/)
# COST06-BP03 メトリクスに基づいて自動的にリソースタイプ、リソースサイズ、リソース数を選択する
現在実行しているワークロードからのメトリクスを用いて、コストを最適化する適切なサイズやタイプを選択します。コンピューティング、ストレージ、データ、ネットワーキングなどのサービスに対して、適切なスループット、サイジング、ストレージのプロビジョニングを行います。これは、自動スケーリングなどのフィードバックループまたはワークロードのカスタムコードで行うことができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
ワークロード内に、実行中のワークロードのアクティブなメトリクスを使用してそのワークロードを変更するフィードバックループを作成します。適切なサイジング操作を実行するように設定した [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) などのマネージドサービスを使用できます。AWS には、[API、SDK](https://aws.amazon.com/developer/tools/)、最小限の労力でリソースを変更することができる機能も用意されています。Amazon EC2 インスタンスの停止と起動のワークロードをプログラムして、インスタンスサイズやインスタンスタイプを変更できます。これにより、適切なサイジングによる利点が得られるだけでなく、変更に必要なほぼすべての運用コストを削減することもできます。
AWS サービスの中には、[Amazon Simple Storage Service Intelligent-Tiering](https://aws.amazon.com/about-aws/whats-new/2018/11/s3-intelligent-tiering/) のようにタイプやサイズを自動で選べる機能が組み込まれているものもあります。Amazon S3 Intelligent-Tiering では、使用パターンに基づいて、高頻度アクセスと低頻度アクセスの 2 つのアクセスティア間でデータが自動的に移動します。
**実装手順**
+ **ワークロードのメトリクスを設定してオブザーバビリティを高める:** ワークロードの主要なメトリクスを取得します。これらのメトリクスは、ワークロード出力などのカスタマーエクスペリエンスに関する示唆を提供し、CPU やメモリの使用状況などのリソースのタイプとサイズの違いに合わせて調整されます。コンピューティングリソースの場合、パフォーマンスデータを分析して Amazon EC2 インスタンスのサイズを適切に設定します。アイドル状態のインスタンスと利用率の低いインスタンスを特定します。検索する主なメトリクスは、CPU 使用率とメモリ使用率です (例えば、「[Rightsizing with AWS Compute Optimizer and Memory Utilization Enabled](https://www.wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/5_ec2_computer_opt/)」で説明されているように、90% の時間で 40% の CPU 使用率)。4 週間の最大 CPU 使用率およびメモリ使用率が 40％未満のインスタンスを特定します。これらのインスタンスは、コスト削減のために適切なサイズを設定する必要があります。Amazon S3 などのストレージリソースでは、[Amazon S3 ストレージレンズ](https://aws.amazon.com/getting-started/hands-on/amazon-s3-storage-lens/)を使用できます。これにより、さまざまなカテゴリにわたる 28 のメトリクスをバケットレベルで表示でき、デフォルトでダッシュボードに 14 日間の履歴データを表示できます。Amazon S3 ストレージレンズのダッシュボードは、要約、コスト最適化、またはイベントごとにフィルタリングして特定のメトリクスを分析できます。
+ **適切なサイジングの推奨事項を表示する:** AWS Compute Optimizer の適切なサイジングの推奨事項を使用するか、コスト管理コンソールで Amazon EC2 の適切なサイジングツールを使用するか、リソースの適切なサイジングでワークロードを調整する AWS Trusted Advisor を確認します。さまざまなリソースの適切なサイジングを行うときは、[適切なツール](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-right-sizing/identifying-opportunities-to-right-size.html)を使用して、Amazon EC2 インスタンス、AWS ストレージクラス、Amazon RDS インスタンスタイプのいずれであれ、[適切なサイジングのガイドライン](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-right-sizing/identifying-opportunities-to-right-size.html)に従うことが重要です。ストレージリソースには、Amazon S3 ストレージレンズを使用できます。これにより、オブジェクトストレージの使用状況、アクティビティの傾向を可視化し、コストを最適化してデータ保護のベストプラクティスを適用するための実用的な推奨事項を作成できます。[Amazon S3 ストレージレンズ](https://aws.amazon.com/getting-started/hands-on/amazon-s3-storage-lens/)が組織全体のメトリクスの分析から取得した、状況に応じた推奨事項を使用することで、ストレージを最適化する手順をすぐに実行することができます。
+ **メトリクスに基づいて自動的にリソースタイプとサイズを選択する:** ワークロードメトリクスを使用して、ワークロードリソースを手動でまたは自動で選択します。コンピューティングリソースの場合、AWS Auto Scaling を設定したり、アプリケーション内でコードを実装したりすると、頻繁な変更が要求される場合に必要となる労力を減らすことができるほか、手動プロセスより早く変更を実装できる可能性もあります。1 つの Auto Scaling グループ内で、オンデマンドインスタンスとスポットインスタンスのフリートを起動してオートスケールできます。スポットインスタンスの使用で割引を受けるだけでなく、リザーブドインスタンスまたは Savings Plan を使用して、通常のオンデマンドインスタンス コストの割引料金を受け取ることができます。これらの要素をすべて組み合わせることで、Amazon EC2 インスタンスのコスト削減を最適化し、アプリケーションに必要なスケールとパフォーマンスを判断できます。また、[Auto Scaling グループ (ASG)](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-instance-type-requirements.html) で[属性ベースのインスタンスタイプ選択 (ABS)](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-asg-instance-type-requirements.html) 戦略を使用すると、vCPU、メモリ、ストレージなどの属性セットとしてインスタンスの要件を表現できます。新世代のインスタンスタイプがリリースされたら自動的にこれを使用し、Amazon EC2 スポットインスタンスにより、これまでよりも広い範囲のキャパシティにアクセスすることができます。Amazon EC2 Fleet と Amazon EC2 Auto Scaling が指定した属性に適合するインスタンスを選択して起動するため、手動でインスタンスタイプを選択する必要がなくなります。ストレージリソースでは、[Amazon S3 Intelligent-Tiering](https://aws.amazon.com/s3/storage-classes/intelligent-tiering/) および [Amazon EFS Infrequent Access](https://aws.amazon.com/efs/features/infrequent-access/) 機能を使用できます。この機能を使用すると、データアクセスパターンが変更されても、パフォーマンスに影響を与えたり、運用オーバーヘッドを発生させたりすることなく、ストレージクラスを自動的に選択してストレージコストを自動的に削減できます。
## リソース
**関連ドキュメント:**
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [AWS での適切なサイジング](https://aws.amazon.com/aws-cost-management/aws-cost-optimization/right-sizing/)
+ [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)
+ [Amazon EC2 Auto Scaling の使用を開始する](https://docs.aws.amazon.com/autoscaling/ec2/userguide/GettingStartedTutorial.html)
+ [Amazon S3 Storage Lens](https://aws.amazon.com/getting-started/hands-on/amazon-s3-storage-lens/)
+ [Amazon S3 の新しいストレージクラス、S3 Intelligent-Tiering を発表](https://aws.amazon.com/about-aws/whats-new/2018/11/s3-intelligent-tiering/)
+ [Amazon EFS 低頻度アクセス](https://aws.amazon.com/efs/features/infrequent-access/)
+ [SDK で Amazon EC2 インスタンスを起動する](https://docs.aws.amazon.com/sdk-for-net/v2/developer-guide/run-instance.html)
**関連動画:**
+ [Right Size Your Services](https://www.youtube.com/watch?v=wcp1inFS78A)
**関連する例:**
+ [Amazon EC2 Fleet 用自動スケーリングでの属性ベースのインスタンスタイプ選択](https://aws.amazon.com/blogs/aws/new-attribute-based-instance-type-selection-for-ec2-auto-scaling-and-ec2-fleet/)
+ [スケジュールされたスケーリングを使用して Amazon Elastic Container Service を最適化しコストを削減する](https://aws.amazon.com/blogs/containers/optimizing-amazon-elastic-container-service-for-cost-using-scheduled-scaling/)
+ [Amazon EC2 Auto Scaling での予測スケーリング](https://aws.amazon.com/blogs/compute/introducing-native-support-for-predictive-scaling-with-amazon-ec2-auto-scaling/)
+ [Amazon S3 ストレージレンズでコストを最適化し、使用状況を可視化する](https://aws.amazon.com/getting-started/hands-on/amazon-s3-storage-lens/)
# COST06-BP04 共有リソースの使用を検討する
複数のビジネスユニットに組織レベルでデプロイ済みのサービスについては、リソースの使用率を高め、総保有コスト (TCO) を削減するために共有リソースの使用を検討してください。共有リソースの使用は、既存のソリューションを使用するか、コンポーネントを共有する、あるいはその両方を行うことで管理とコストを一元化できるコスト効率の高いオプションです。アカウント境界の内側、または専用のアカウントでモニタリング、バックアップ、接続性などの一般的な機能を管理します。また、標準化の実装、重複の削減、複雑さの軽減もコストの削減につながります。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
複数のワークロードが同じ機能を果たす場合は、既存のソリューションと共有コンポーネントを使用して管理を改善し、コストを最適化します。セキュリティのベストプラクティスと組織の規制に従うことでクラウドコストを軽減できるように、本稼働の対象外となるデータベースサーバーやディレクトリサービスなどの既存のリソース (特に共有リソース) を使用することを検討してください。最適な価値実現と効率化を実現するには、消費が活発なビジネスの適正分野にコストを配分することが重要です (ショーバックとチャージバックを使用する) 。
*ショーバック*とは、消費者、ビジネスユニット、総勘定元帳勘定、責任を負うその他のエンティティなどの帰属カテゴリにクラウドコストを分類するレポートを指します。ショーバックの目的は、チーム、ビジネスユニット、または個人に、各自が消費したクラウドリソースのコストを示すことです。
*チャージバック*とは、特定の財務管理プロセスに適した戦略に基づいて、中央のサービスの支出を各コストユニットに割り当てることです。お客様の場合、チャージバックは、1 つの共有サービスアカウントで発生したコストを、お客様の報告プロセスに適したさまざまな財務コストカテゴリに請求します。チャージバックメカニズムを確立することで、さまざまなビジネスユニット、製品、チームで発生したコストを報告できます。
ワークロードは、重大または重大ではないに分類できます。この分類に基づいて、重大度の低いワークロードには一般的な設定の共有リソースを使用します。コストをさらに最適化するには、専有サーバーを重大なワークロード専用に確保します。複数のアカウント間でリソースの共有やプロビジョニングを行うことで、リソースを効率的に管理できます。開発環境、テスト環境、本番環境が分かれていても、安全に共有を行うことが可能であり、組織構造を損なうことはありません。
コンテナ化されたアプリケーションのコストと使用状況の理解を深めて最適化するには、分割コスト配分データを使用します。これにより、アプリケーションによる共有コンピューティングリソースとメモリリソースの消費状況に基づいてアプリケーションコストを個々のエンティティに配分できます。分割コスト配分データを使用することで、Amazon Elastic Container Service (Amazon ECS) または Amazon Elastic Kubernetes Service (Amazon EKS) で実行されているコンテナワークロードでタスクレベルのショーバックとチャージバックを実現できます。
分散型アーキテクチャの場合は、共有サービス VPC を構築します。これにより、各 VPC のワークロードで必要な共有サービスに一元的にアクセスできます。これらの共有サービスには、ディレクトリサービスや VPC エンドポイントなどのリソースを含めることができます。管理オーバーヘッドとコストを削減するには、各 VPC にリソースを構築する代わりに、一元的な場所からリソースを共有します。
共有リソースを使用すると、運用コストの節約、リソース使用率の最大化、一貫性の向上につながります。マルチアカウント設計では、一部の AWS のサービスを一元的にホストし、1 つのハブ内で複数のアプリケーションとアカウントを使用してアクセスすることでコストを節約できます。[AWS Resource Access Manager (AWS RAM)](https://aws.amazon.com/ram/) を使用することで、[VPC サブネットや AWS Transit Gateway アタッチメント](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-vpc)、[AWS Network Firewall](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-network-firewall)、[Amazon SageMaker AI Pipelines](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html#shareable-sagemaker) など、他の一般的なリソースを共有することができます。マルチアカウント環境の場合、AWS RAM でリソースを作成したら、それを他のアカウントと共有します。
組織は、共有コストに効果的にタグ付けし、コストの大部分がタグ付けされていない、または配分されていないといったことがないよう確認する必要があります。共有コストが効果的に配分されず、共有コストの管理責任を誰も負わない場合、共有クラウドのコストは悪循環に陥る可能性があります。リソース、ワークロード、チーム、または組織レベルのどこでコストが発生しているのかを把握しておく必要があります。これを把握することで、コスト発生場所での実際の価値を達成したビジネス成果と比較して理解することができます。最終的に、組織はクラウドインフラストラクチャの共有によってコスト削減のメリットを享受します。クラウド支出を最適化するために、共有クラウドリソースのコスト配分を奨励してください。
### 実装手順
+ **既存のリソースを評価する:** ワークロードに類似のサービスを使用する既存のワークロードを確認します。ワークロードのコンポーネントに応じて、ビジネスロジックや技術的要件で許容される場合は、既存のプラットフォームを検討します。
+ **AWS RAM でリソース共有を使用し、適宜制限を適用する:** AWS RAM を使用して、組織内の他の AWS アカウントとリソースを共有します。リソースを共有する場合、複数のアカウントでリソースを重複する必要がないため、リソースメンテナンスの運用負担を最小限に抑えることができます。またこのプロセスにより、作成したリソースをアカウント内のロールやユーザーの他、他の AWS アカウントとも安全に共有することができます。
+ **リソースにタグを付ける:** コストレポートの対象候補となるリソースにタグを付け、コストカテゴリ内で分類します。コスト配分用にこうしたコスト関連のリソースタグを有効にすると、AWS リソースの使用状況を可視化できます。コストと使用状況の可視性に関して適切な度合いの詳細度を定めることに重点を置き、コスト配分レポートと KPI 追跡によってクラウドの消費行動に影響を与えます。
## リソース
**関連するベストプラクティス:**
+ [SEC03-BP08 組織内でリソースを安全に共有する](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_permissions_share_securely.html)
**関連ドキュメント:**
+ [What is AWS Resource Access Manager?](https://docs.aws.amazon.com/ram/latest/userguide/what-is.html)
+ [AWS Organizations で使用できる AWS サービス](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services_list.html)
+ [共有可能な AWS リソース](https://docs.aws.amazon.com/ram/latest/userguide/shareable.html)
+ [AWS コストと使用状況レポート (CUR) クエリ](https://catalog.workshops.aws/cur-query-library/en-US)
**関連動画:**
+ [AWS Resource Access Manager - granular access control with managed permissions](https://www.youtube.com/watch?v=X3HskbPqR2s)
+ [How to design your AWS cost allocation strategy](https://pages.awscloud.com/aws-cfm-talks-how-to-design-your-AWS-cost-allocation-strategy-01122022.html)
+ [AWS Cost Categories](https://www.youtube.com/watch?v=84GYnBBM0Cg)
**関連する例:**
+ [共有サービスのチャージバック方法: An AWS Transit Gateway の例](https://aws.amazon.com/blogs/aws-cloud-financial-management/gs-chargeback-shared-services-an-aws-transit-gateway-example/)
+ [How to build a chargeback/showback model for Savings Plans using the CUR](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-to-build-a-chargeback-showback-model-for-savings-plans-using-the-cur/)
+ [Using VPC Sharing for a Cost-Effective Multi-Account Microservice Architecture](https://aws.amazon.com/blogs/architecture/using-vpc-sharing-for-a-cost-effective-multi-account-microservice-architecture/)
+ [Improve cost visibility of Amazon EKS with AWS Split Cost Allocation Data](https://aws.amazon.com/blogs/aws-cloud-financial-management/improve-cost-visibility-of-amazon-eks-with-aws-split-cost-allocation-data/)
+ [AWS 分割コスト配分データにより Amazon ECS および AWS Batch のコストの可視性を向上する](https://aws.amazon.com/blogs/aws-cloud-financial-management/la-improve-cost-visibility-of-containerized-applications-with-aws-split-cost-allocation-data-for-ecs-and-batch-jobs/)
# COST 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 料金モデルの分析を実行する
ワークロードの各コンポーネントを分析します。コンポーネントとリソースを長期間実行するか (コミットメント割引)、動的に短期間実行するか (スポットまたはオンデマンド) を決定します。コスト管理ツールのレコメンデーションを使用して、ワークロードに対して分析を行います。これらのレコメンデーションにビジネスルールを適用して、高いリターンを実現します。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
AWS には複数の[料金モデル](https://aws.amazon.com/pricing/)があり、組織のニーズに合い、製品に応じた最も費用対効果の高い方法でリソース料金を支払うことができます。チームと協力して最適な料金モデルを決定します。可用性に基づいて決定すると、複数のオプションを組み合わせた料金モデルになることもよくあります
**オンデマンドインスタンス**では、実行しているインスタンスに応じて、コンピューティングまたはデータベース容量に対して時間単位または秒単位 (最小 60 秒) で支払うことができます。長期契約や前払いは不要です。
**Savings Plans** は、1 年または 3 年の期間で一定の使用量 (USD/時間、で計算) をコミットメントする代わりに、Amazon EC2、Lambda、AWS Fargate を低料金で利用できる柔軟な料金モデルです。
**スポットインスタンス**は、予備のコンピューティング容量を時間単価の割引価格 (オンデマンド価格の最大 90% オフ) でリクエストできる Amazon EC2 の料金の仕組みです。前払いのコミットメントはありません。
**リザーブドインスタンス**では、容量に対する前払いにより、最大 75% の割引を受けることができます。詳細については、「[予約によるコストの最適化](https://docs.aws.amazon.com/whitepapers/latest/how-aws-pricing-works/aws-cost-optimization.html)」を参照してください。
本稼働、品質、開発の各環境に関連するリソースに Savings Plans を含めることもできます。また、サンドボックスリソースは必要なときにのみ電源が入るため、その環境内のリソースにオンデマンドモデルを選択することもできます。Amazon [スポットインスタンス](https://docs.aws.amazon.com/whitepapers/latest/how-aws-pricing-works/amazon-elastic-compute-cloud-amazon-ec2.html#spot-instances)を使用して Amazon EC2 のコストを削減したり、[Compute Savings Plans](https://docs.aws.amazon.com/whitepapers/latest/how-aws-pricing-works/amazon-elastic-compute-cloud-amazon-ec2.html#savings-plans) を使用して Amazon EC2、Fargate、Lambda のコストを削減したりします。[AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) レコメンデーションツールは、Saving Plans によるコミットメント割引の機会を提供します。
過去に Amazon EC2 の[リザーブドインスタンス](https://aws.amazon.com/aws-cost-management/aws-cost-optimization/reserved-instances/?track=costop)を購入している場合、あるいは組織内でコスト配分を実施している場合、今後も当面の間は Amazon EC2 リザーブドインスタンスをご利用いただけます。ただし、より柔軟にコストを節約するため、いずれは Savings Plans を使用する戦略に切り替えることが推奨されます。AWS Cost Management の Savings Plans (SP) レコメンデーションは、更新することでいつでも新しい Savings Plans レコメンデーションを作成できます。リザーブドインスタンス (RI) を使用すると、Amazon RDS、Amazon Redshift、Amazon ElastiCache、Amazon OpenSearch Service のコストを削減できます。Savings Plans とリザーブドインスタンスには、全額前払い、一部前払い、前払いなしの 3 つのオプションがあります。AWS Cost Explorer RI および SP 購入レコメンデーションで提供されたレコメンデーションを使用します。
スポットのワークロードを実行する機会を見つけるには、使用量全体の 1 時間ごとのビューを使用して、定期的に生じる使用量や伸縮性の変化を探します。スポットインスタンスは、フォールトトレラントで柔軟性があるさまざまなアプリケーションに使用できます。これには、ステートレスウェブサーバー、API エンドポイント、ビッグデータアプリケーションや分析アプリケーション、コンテナ化されたワークロード、CI/CD、その他柔軟性の高いワークロードなどがあります。
Amazon EC2 および Amazon RDS インスタンスを、使用していないとき (就業後や週末) にオフにできるかを分析します。このアプローチによって、24 時間 365 日使用する場合と比較して、70% 以上のコストを削減できます。特定の時間にのみ使用できるようにする必要がある Amazon Redshift クラスターがある場合は、そのクラスターを一時停止して、後で再開できます。Amazon Redshift クラスターや Amazon EC2 および Amazon RDS インスタンスが停止すると、コンピューティングに対する請求が停止され、ストレージ料金のみが適用されます。
[オンデマンドキャパシティ予約](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservations-pricing-billing.html) (ODCR) は料金割引ではないことに注意してください。インスタンスをリザーブドキャパシティで実行しているかどうかにかかわらず、オンデマンドの場合と同等の料金がキャパシティ予約に課金されます。キャパシティ予約は、実行する予定のリソースに対して十分な容量を提供する必要がある場合に、検討します。ODCR は不要になればキャンセルできるため、長期コミットメントと結びつける必要はありませんが、Savings Plans またはリザーブドインスタンスが提供する割引のメリットを受けることもできます。
**実装手順**
+ **ワークロードの伸縮性を分析する: **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://aws.amazon.com/pricing/enterprise/)では、ニーズに最適な契約を調整できます。長期コミットメントの場合は、リザーブド料金割引、特定のインスタンスタイプに対するリザーブドインスタンスまたは Savings Plans、インスタンスファミリー、AWS リージョン、アベイラビリティーゾーンを検討します。
+ **コミットメント割引分析を実行する:** アカウントで Cost Explorer を使用して Savings Plans とリザーブドインスタンスのレコメンデーションを確認します。必要な割引を適用し、リスクを認識したうえで、正しいレコメンデーションを実装していることを確認するには、[Well-Architected ラボ](https://wellarchitectedlabs.com/cost/costeffectiveresources/)に従ってください。
## リソース
**関連ドキュメント:**
+ [リザーブドインスタンスのレコメンデーションへのアクセス](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-recommendations.html)
+ [インスタンス購入オプション](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html)
+ [AWS エンタープライズ](https://aws.amazon.com/pricing/enterprise/)
**関連動画:**
+ [Save up to 90% and run production workloads on 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 コストに基づいてリージョンを選択する
リソースの料金は各リージョンで異なる場合があります。リージョンによるコストの差異を特定し、レイテンシー、データレジデンシー、データ主権に関する要件を満たす場合にのみ、よりコストの高いリージョンにデプロイします。リージョンコストを織り込むことで、このワークロードに対して支払う料金の合計を最低限に抑えることができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
[AWS クラウドインフラストラクチャ](https://aws.amazon.com/about-aws/global-infrastructure/)はグローバルで、[世界中の複数の場所](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html)でホストされ、AWS リージョン、アベイラビリティーゾーン、ローカルゾーン、AWS Outposts、Wavelength Zone を中心に構築されています。リージョンとは世界中の物理的な場所であり、各リージョンは、AWS が複数のアベイラビリティーゾーンを設置している地理的に離れた地域です。各リージョン内の複数の独立した場所であるアベイラビリティーゾーンは、1 つ以上の独立したデータセンターで構成されています。各データセンターは、冗長性のある電源、ネットワーク、接続を備えています。
各 AWS リージョンは現地マーケットの条件内で運用されており、土地代、回線代、電気代、税金などのコストが異なるため、リソース料金は各リージョンで異なります。世界的に最小料金で稼働できるように、ソリューションのコンポーネントまたは全体を運用する特定のリージョンを選択します。[AWS 見積りツール](https://calculator.aws/#/)を使用して、ロケーションタイプ (リージョン、Wavelength ゾーン、ローカルゾーン) とリージョンごとにサービスを検索し、さまざまなリージョンでワークロードのコストを見積もります。
ソリューションを設計する際、ユーザーに近いコンピューティングリソースの場所を探して、レイテンシー低下とデータ主権の強化を図ることが推奨されます。ビジネス、データプライバシー、パフォーマンス、セキュリティの要件に基づいて、地理的場所を選択します。エンドユーザーが世界中にいるアプリケーションの場合は、複数の場所を使用します。
データプライバシー、セキュリティ、ビジネス要件に義務がない場合は、AWS のサービスの料金がより安価なリージョンを使用して、ワークロードをデプロイします。例えば、デフォルトのリージョンが アジアパシフィック (シドニー)(`ap-southwest-2`) であり、他のリージョンを使用するにあたっての制約 (データプライバシー、セキュリティなど) がない場合、重要ではない (開発とテスト) Amazon EC2 インスタンスを米国東部 (バージニア北部)(`us-east-1`) リージョンにデプロイすると、コストを抑えることができます。
![\[コンプライアンス、レイテンシー、コスト、サービスと機能を含むさまざまなリージョンを示す図。\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/images/region-feature-matrix.png)
前述のマトリックス表から、他のリージョンに比べてレイテンシーが低く、サービスが利用可能で、コストが最も低いリージョンであるため、このシナリオではリージョン 6 が最適なオプションであることがわかります。
## 実装手順
+ **AWS リージョンの料金を確認する:** 現在のリージョンのワークロードコストを分析します。サービスおよび使用タイプ別の最も高いコストから、利用可能な他のリージョンのコストを計算します。予測される費用削減効果がコンポーネントまたはワークロードの移動コストを上回っている場合は、新しいリージョンに移行します。
+ **複数のリージョンにデプロイする場合の要件を確認する:** ビジネス要件と義務 (データプライバシー、セキュリティ、パフォーマンス) を分析して、複数リージョンを使用すべきでない制約があるかどうかを確認します。単一リージョンを使用するよう制限する義務がない場合は、複数のリージョンを使用します。
+ **必要なデータ転送を分析する:** リージョンを選択するときは、データ転送コストを考慮します。データは顧客とリソースの近くに置いてください。データ転送が最小限でデータの流れがよい、よりコストの低い AWS リージョンを選択します。データ転送のビジネス要件に応じて、[Amazon CloudFront](https://aws.amazon.com/cloudfront/)、[AWS PrivateLink](https://aws.amazon.com/privatelink/)、[AWS Direct Connect](https://aws.amazon.com/directconnect/)、[AWS Virtual Private Network](https://aws.amazon.com/vpn/) を使用することで、ネットワークコストの削減、パフォーマンスの向上、セキュリティの強化を実現できます。
## リソース
**関連ドキュメント:**
+ [リザーブドインスタンスのレコメンデーションへのアクセス](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)
**関連する例:**
+ [一般的なアーキテクチャでのデータ転送コストの概要](https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/)
+ [グローバルデプロイにおけるコストの考慮事項](https://aws.amazon.com/blogs/aws-cloud-financial-management/cost-considerations-for-global-deployments/)
+ [ワークロードに応じたリージョンを選択する際の注意点](https://aws.amazon.com/blogs/architecture/what-to-consider-when-selecting-a-region-for-your-workloads/)
# COST07-BP03 費用対効果の高い条件を提供するサードパーティーの契約を選択する
コスト効率に優れた契約と条件により、これらのサービスのコストが、提供されるメリットに見合ったものとなります。組織に追加のメリットを提供するときに、それに合わせてスケールする契約と料金を選択します。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
クラウド環境のコスト管理に役立つさまざまな製品が流通しています。こうした製品は、ターゲットとなる顧客の要件に応じて、コストガバナンスやコスト可視化を重視したものや、コスト最適化を重視したものなど、機能面で違いが見られる場合があります。効果的なコスト最適化とガバナンスの鍵を握る要因の 1 つは、料金モデルが適正で、必要な機能が揃った適切なツールを使用することです。製品ごとに料金モデルは異なります。毎月の請求総額の一定の割合を支払うものもあれば、実際の節約額の一定の割合を支払うものもあります。必要な分だけ支払う従量課金制が理想的です。
クラウドでサードパーティーのソリューションやサービスを利用する場合は、期待する成果に合わせて料金体系を選ぶことが重要です。料金は、コスト最適化の結果とサービスの価値に合わせてスケールする必要があります。例えば、実際に節約できたコストの一部を支払う成功報酬型ソフトウェアの場合、節約率 (成果) が上がるほど、請求額も高くなります。支出負担が増えるに従い、支払う金額も増えるライセンス契約は、コスト最適化の点で必ずしも最適解とは限りません。ただし、請求書のあらゆる項目で優遇を受けられる場合、こうした変動料金が妥当なケースもあるかもしれません。
例えば、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](https://www.youtube.com/watch?v=BlNPZQh2wXs)
# COST07-BP04 このワークロードのすべてのコンポーネントに対して料金モデルを実装する
永続的に実行されるリソースでは、Savings Plans やリザーブドインスタンスなどのリザーブドキャパシティを利用する必要があります。短期的な使用には、スポットインスタンスまたはスポットフリートを使用するように設定します。オンデマンドインスタンスは、リザーブドキャパシティに対して長時間稼働しない、中断することのできない短期ワークロードに対してのみ使用します (リソースタイプに応じて、期間の 25% から 75%)。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
コスト効率を上げるために、AWS は過去の使用状況に基づいて確約利用 (コミットメント) のレコメンデーションをいくつか提示します。これらのレコメンデーションを参考にして、実際に節約できるコストと、そのコミットメントの活用法を理解できます。これらのサービスをオンデマンドまたはスポットで利用することも、一定期間の利用を確約してリザーブドインスタンス (RI) や Savings Plans (SP) でオンデマンドコストを削減することもできます。ワークロードを最適化するには、各ワークロードコンポーネントや複数の AWS サービスだけでなく、該当するサービスのコミットメント割引、購入オプション、スポットインスタンスについても理解する必要があります。
ワークロードのコンポーネントの要件を検討し、これらのサービスのさまざまな料金モデルを理解しましょう。これらのコンポーネントの可用性要件を定義します。ワークロードで関数を実行する複数の独立したリソースの有無、経時的に必要となるワークロード要件を確認します。デフォルトのオンデマンド料金モデルと他の適用可能なモデルを使用して、リソースのコストを比較します。リソースまたはワークロードコンポーネントで変更可能なものはすべて考慮します。
例えば、AWS のこのウェブアプリケーションアーキテクチャを検討してみましょう。このワークロードのサンプルは、Amazon Route 53、AWS WAF、Amazon CloudFront、Amazon EC2 インスタンス、Amazon RDS インスタンス、ロードバランサー、Amazon S3 ストレージ、Amazon Elastic File System (Amazon EFS) など、複数の AWS サービスで構成されています。これらのサービスをそれぞれ見直し、さまざまな料金モデルでコストをどれくらい削減できるのかを確認する必要があります。RI または SP を利用できるものもあれば、オンデマンドでしか利用できないものもあります。次の図からわかるように、AWS の一部のサービスは利用を確約し、RI または SP を使用できます。
![\[リザーブドインスタンスと Savings Plans を使用してコミットされた AWS サービスのチャート\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/images/ri-sp-services.png)
### 実装手順
+ **料金モデルを実装する:** 分析結果を使用して、Savings Plans またはリザーブドインスタンスの購入、スポットインスタンスの実装を行います。コミットメントの初回購入時には、リストの上位 5 件または 10 件のレコメンデーションを選択し、翌月または翌々月までの結果をモニタリングして分析します。このプロセスは AWS Cost Management Console が案内してくれます。コンソールから RI または SP のレコメンデーションを確認し、その内容 (タイプ、支払い、期間) をカスタマイズし、時間単位の確約利用料 (1 時間あたり 20 USD など) を確認して、カートに追加します。割引は、対象となる使用量に自動的に適用されます。コミットメント割引で定期的に少量を購入します (例: 2 週間ごとまたは 1 か月ごと)。中断可能またはステートレスなワークロードにスポットインスタンスを実装します。最後に、Amazon EC2 オンデマンドインスタンスを選択し、残りの要件にリソースを割り当てます。
+ **ワークロードレビューサイクル:** 特に料金モデルカバレッジを分析するワークロードのレビューサイクルを実装します。ワークロードが必要なカバレッジを達成したら、部分的に (数か月ごと)、または組織の使用状況の変化に応じて、追加のコミットメント割引を購入します。
## リソース
**関連ドキュメント:**
+ [Savings Plans のレコメンデーションについて](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-recommendations.html)
+ [リザーブドインスタンスのレコメンデーションへのアクセス](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-recommendations.html)
+ [リザーブドインスタンスの購入方法](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)
+ [他の AWS サービスの予約モデル](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-reservation-models/reservation-models-for-other-aws-services.html)
+ [Savings Plans がサポートするサービス](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-services.html)
**関連動画:**
+ [Save up to 90% and run production workloads on Spot](https://www.youtube.com/watch?v=BlNPZQh2wXs)
**関連する例:**
+ [Savings Plans を購入する前に考慮すべきことは何ですか?](https://repost.aws/knowledge-center/savings-plans-considerations)
+ [Cost Explorer を使用して支出と使用量を分析する方法](https://repost.aws/knowledge-center/cost-explorer-analyze-spending-and-usage)
# COST07-BP05 管理アカウントレベルで料金モデル分析を実行する
請求やコスト管理ツールをチェックして、コミットメントや予約を利用した推奨割引を確認し、管理アカウントレベルで定期的に分析を実行します。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
コストモデリングを定期的に実行すると、複数のワークロード全体を最適化する機会が得られます。例えば、複数のワークロードでオンデマンドインスタンスを使用している場合、集計レベルでは変更リスクが低くなり、コミットメントベースの割引を運用すると全体的なコストが低くなる場合があります。2 週間から 1 か月の定期的なサイクルで分析を実行することを推奨します。これにより、調整のための小口購入が可能になり、ワークロードやコンポーネントの変更に合わせて料金モデルの調整を続けることができます。
[AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) のレコメンデーションツールを使用して、管理アカウントでコミットメント割引を適用する機会を見つけます。管理アカウントレベルでのレコメンデーションは、リザーブドインスタンス (RI) または Savings Plans (SP) を持つ AWS 組織内のすべてのアカウントの使用量を考慮して計算されます。また、割引共有が有効になったときに計算され、アカウント全体で節約を最大化できるコミットメントを推奨します。
管理アカウントレベルでの購入は、多くの場合、最大限の節約を目指して最適化されますが、特定の連結アカウントでの利用に最初に割引を適用したい場合など、連結アカウントレベルで SP を購入することを検討する状況もあります。メンバーアカウントの推奨事項は、独立した各アカウントでの削減を最大化するために、個人アカウントレベルで計算されます。アカウントが RI と SP の両方のコミットメントを所有している場合、それらは次の順序で適用されます。
1. ゾーン RI
1. 標準 RI
1. コンバーティブル RI
1. Instance Savings Plan
1. Compute Savings Plan
管理アカウントレベルで SP を購入した場合、割引率の高い順に節約が適用されます。管理アカウントレベルの SP は、すべての連結アカウントを調べて、割引が最も高いところに節約を適用します。節約が適用される場所を制限したい場合は、連結アカウント単位で Savings Plan を購入すると、そのアカウントが対象となるコンピューティングサービスを実行しているときはいつでも、割引が最初に適用されます。アカウントが対象となるコンピューティングサービスを実行していない場合、割引は同じ管理アカウントにある他の連結アカウント間で分配されます。割引共有はデフォルトでオンになっていますが、必要に応じてオフにできます。
一括請求ファミリーでは、Savings Plans は、まず所有者アカウントの使用に適用され、次に他のアカウントの使用に適用されます。これは共有が有効になっている場合にのみ発生します。Savings Plans は、削減率が最も高いものがまず適用されます。削減率が等しい使用が複数ある場合、Savings Plans は、Savings Plans の割合が最も低い使用にまず適用されます。Savings Plans は、残りの使用量がなくなるか、コミットメントが使い果たされるまで引き続き適用されます。残りの使用はオンデマンド価格で課金されます。AWS コスト管理の Savings Plans レコメンデーションを更新して、いつでも新しい Savings Plans レコメンデーションを作成できます。
インスタンスの柔軟性を分析すると、レコメンデーションに沿ってコミットできます。コストモデリングを作成するにあたって、さまざまなリソースオプションの可能性を含めたワークロードの短期コストを分析し、AWS 料金モデルの分析を行い、それらをビジネス要件に合わせて、総保有コストと[コスト最適化](https://docs.aws.amazon.com/whitepapers/latest/how-aws-pricing-works/aws-cost-optimization.html)の機会を明らかにします。
### 実装手順
**コミットメント割引分析を実行する**: アカウントで Cost Explorer を使用して、Savings Plans とリザーブドインスタンスのレコメンデーションを確認します。Savings Plan のレコメンデーションを理解し、月次費用の見積もりと月次節約額の見積もりを行っていることを確認します。管理アカウントレベルでのレコメンデーションを確認します。レコメンデーションは、アカウント間で最大限の節約を実現するために、RI または Savings Plans の割引共有が有効になっている AWS 組織内におけるすべてのメンバーアカウントの使用量を考慮して計算されます。Well-Architected ラボに従って、必要な割引を適用し、リスクを認識したうえで、正しいレコメンデーションを実装していることを確認します。
## リソース
**関連ドキュメント:**
+ [AWS の料金のしくみはどのようになっていますか?](https://aws.amazon.com/pricing/?nc2=h_ql_pr_ln)
+ [インスタンス購入オプション](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html)
+ [Savings Plans の概要](file:///Users/mergenf/Documents/WELL%20ARCHITECTED/COST%20OPT%20PILLAR/phase3a/COST06/•%09https:/docs.aws.amazon.com/savingsplans/latest/userguide/sp-overview.html)
+ [Saving Plan recommendations](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-recommendations.html)
+ [リザーブドインスタンスのレコメンデーションへのアクセス](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-recommendations.html)
+ [Saving Plans 推奨事項を理解する](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-recommendations.html)
+ [AWS の使用に Savings Plans が適用される仕組み](https://docs.aws.amazon.com/savingsplans/latest/userguide/sp-applying.html)
+ [組織の一括請求 (コンソリデーティッドビリング) 全体に適用される Savings Plan の料金には、どのようなメリットがありますか?](https://aws.amazon.com/premiumsupport/knowledge-center/savings-plans-consolidated-billing/)
+ [共有リザーブドインスタンスと Savings Plans の割引の有効化](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/ri-turn-on-process.html)
**関連動画:**
+ [Save up to 90% and run production workloads on Spot](https://www.youtube.com/watch?v=BlNPZQh2wXs)
**関連する例:**
+ [Savings Plans を購入する前に考慮すべきことは何ですか?](https://aws.amazon.com/premiumsupport/knowledge-center/savings-plans-considerations/)
+ [ローリング Savings Plans を使用してコミットメントのリスクを軽減する方法](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-can-i-use-rolling-savings-plans-to-reduce-commitment-risk/)
+ [スポットインスタンスの使用が適切なケース](https://docs.aws.amazon.com/whitepapers/latest/cost-optimization-leveraging-ec2-spot-instances/when-to-use-spot-instances.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 データ転送モデリングを実行する
組織の要件を取りまとめ、ワークロードとその各コンポーネントのデータ転送モデリングを実行します。これにより、現在のデータ転送要件に対する最低コストを特定できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
クラウドでソリューションを設計する際、習慣的にオンプレミスのデータセンターを使用してアーキテクチャを設計してしまったり、知識が不足していたりするせいで、データ転送料金を見落としがちです。AWS のデータ転送料金は、送信元、送信先、トラフィック量によって決まります。設計段階からこれらの料金を織り込めば、コスト削減につながる可能性があります。総保有コスト (TCO) を正確に見積もるには、ワークロードにおけるデータ転送の発生箇所、転送コスト、関連するメリットを把握することがきわめて重要です。これにより、十分な情報に基づいてアーキテクチャ設計上の変更や承諾の決定ができます。例えば、アベイラビリティーゾーン間でデータをレプリケートするマルチアベイラビリティーゾーンを設定したとします。
ワークロードでデータを転送するサービスコンポーネントをモデリングし、これが、求められる信頼性と耐障害性を実現するために許容されるコストであるか (両方のアベイラビリティーゾーンのコンピューティングとストレージに支払うのと同様であるか) を判断します。さまざまな使用量レベルでコストをモデリングします。ワークロード使用量は経時的に変化します。また、サービスの種類ごとに異なるレベルで費用対効果が向上する場合があります。
データ転送をモデリングする際は、取り込まれるデータの量と転送元を考慮します。また、処理されるデータ量と、必要なストレージやコンピューティングのキャパシティについても検討してください。モデリング中は、ワークロードのアーキテクチャに則したネットワークのベストプラクティスに従い、見込まれるデータ転送コストを最適化します。
AWS 料金見積りツール を使用して、特定の AWS サービスのコストの見積りと、予想されるデータ転送を確認できます。ワークロードを (テスト目的で、または実稼働前の環境で) 既に実行している場合は、[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 リージョン内の転送、AWS サービスへの転送、インターネットへの転送など)?
+ [AWS リージョン内のデータ転送](https://docs.aws.amazon.com/cur/latest/userguide/cur-data-transfers-charges.html#data-transfer-within-region)
+ [AWS リージョン間のデータ転送](https://docs.aws.amazon.com/cur/latest/userguide/cur-data-transfers-charges.html#data-transfer-between-regions)
+ [インターネットへのデータ転送](https://docs.aws.amazon.com/cur/latest/userguide/cur-data-transfers-charges.html#data-transfer-out-internet)
+ **データ分類を特定する:** このデータ転送のデータ分類は何ですか? データの種類は? データの大きさは? データ転送の頻度は? 機密データですか?
+ **使用する AWS サービスまたはツールを特定する:** このデータ転送にはどの AWS サービスを使用しますか? プロビジョニング済みのサービスを別のワークロードに使用できますか?
+ **データ転送コストを計算する:** 以前に作成したデータ転送モデリングの [AWS 料金](https://aws.amazon.com/pricing/)を使用して、ワークロードのデータ転送コストを計算します。ワークロードの使用量が増減した場合の、使用量別のデータ転送コストを計算します。ワークロードアーキテクチャに複数のオプションがある場合は、比較のために各オプションのコストを計算します。
+ **コストを結果にリンクする:** 発生したデータ転送コストごとに、ワークロードで達成した結果を指定します。コンポーネント間の転送であればデカップリングのため、アベイラビリティーゾーン間の転送であれば冗長性のためかもしれません。
+ **データ転送モデルを作成する:** すべての情報を収集したら、複数のユースケースやさまざまなワークロードの基準となる、データ転送の概念モデルを作成します。
## リソース
**関連ドキュメント:**
+ [AWS キャッシュソリューション](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/)
+ [データ転送料金について](https://docs.aws.amazon.com/cur/latest/userguide/cur-data-transfers-charges.html)
**関連動画:**
+ [Monitoring and Optimizing Your Data Transfer Costs](https://www.youtube.com/watch?v=UjliYz25_qo)
+ [S3 Transfer Acceleration](https://youtu.be/J2CVnmUWSi4)
**関連する例:**
+ [一般的なアーキテクチャでのデータ転送コストの概要](https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/)
+ [ネットワークに関する AWS 規範ガイダンス](https://aws.amazon.com/prescriptive-guidance/?apg-all-cards.sort-by=item.additionalFields.sortDate&apg-all-cards.sort-order=desc&awsf.apg-new-filter=*all&awsf.apg-content-type-filter=*all&awsf.apg-code-filter=*all&awsf.apg-category-filter=categories%23network&awsf.apg-rtype-filter=*all&awsf.apg-isv-filter=*all&awsf.apg-product-filter=*all&awsf.apg-env-filter=*all)
# COST08-BP02 データ転送コストを最適化するコンポーネントを選択する
すべてのコンポーネントを選択し、データ転送コストを低減するようにアーキテクチャを設計します。これには、ワイドエリアネットワーク (WAN) 最適化やマルチアベイラビリティーゾーン (AZ) 設定などのコンポーネントの使用が含まれます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
データ転送を念頭に置いたアーキテクチャでは、データ転送コストを最小限に抑えることができます。このアーキテクチャでは、コンテンツ配信ネットワークを使用してユーザーに近いデータを特定したり、お客様のプレミスと AWS をつなぐ専用ネットワーク接続を使用したりする場合があります。WAN の最適化やアプリケーションの最適化によって、コンポーネント間で転送されるデータ量を減らすこともできます。
AWS クラウドとの間やその内部でデータを転送する場合、データ転送を最適化する適切な AWS サービスを選択するために、さまざまなユースケース、データの性質、利用可能なネットワークリソースに基づいて転送先を把握することが不可欠です。AWS は、多様なデータ移行要件に対応する幅広いデータ転送サービスを提供しています。組織内のビジネスニーズに基づいて、適切な[データストレージ](https://aws.amazon.com/products/storage/)と[データ転送](https://aws.amazon.com/cloud-data-migration/)オプションを選択します。
ワークロードアーキテクチャを計画または確認するときは、次の点を考慮してください。
+ **AWS 内の VPC エンドポイントを使用する:** VPCエンドポイントにより、VPC とサポートされている AWS サービス間のプライベート接続が可能になります。これにより、データ転送コストが発生する可能性のある公開インターネットの使用を回避できます。
+ **NAT ゲートウェイを使用する:** [NAT ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)を使用して、プライベートサブネット内のインスタンスがインターネットまたは VPC 外のサービスに接続できるようにします。NAT ゲートウェイの背後にあるリソースのうち、最大量のトラフィックを送信しているリソースのアベイラビリティーゾーンが NAT ゲートウェイと同じかどうかを確認します。違う場合は、そのリソースと同じアベイラビリティーゾーンに新しい NAT ゲートウェイを作成し、AZ 間のデータ転送料金を削減します。
+ **AWS Direct Connect を使用する:** Direct Connect は公開インターネットをバイパスして、オンプレミスネットワークと AWS との間にプライベート接続を直接確立します。インターネットを介して大量のデータを転送するよりも、この方が高コスト効率で確実です。
+ **リージョンの境界をまたぐデータ転送は回避する:** 通常、(特定のリージョンから別のリージョンへの) AWS リージョン 間のデータ転送には、料金が発生します。複数のリージョンをまたいで転送する場合は、慎重に検討したうえで決断してください。詳細については、「[マルチリージョンシナリオ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/multi-region-scenarios.html)」を参照してください。
+ **データ転送をモニタリングする:** Amazon CloudWatch と [VPC フローログ](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)を使用して、データ転送とネットワークの使用状況に関する詳細情報をキャプチャします。VPC 内でネットワークインターフェイスとの間を行き来するネットワークトラフィックについて、IP アドレスや範囲などの、キャプチャされた情報を分析します。
+ **ネットワーク使用状況を分析する:** AWS Cost Explorer、CUDOS Dashboard、CloudWatch など、測定とレポートのためのツールを使用して、ワークロードのデータ転送コストを把握します。
### 実装手順
+ **データ転送用のコンポーネントを選択する:** [COST08-BP01 データ転送モデリングを実行する](cost_data_transfer_modeling.md) で説明したデータ転送モデリングを使用して、データ転送コストが最も大きい場所や、ワークロードの使用状況が変わった場合の場所に焦点を当てます。データ転送の必要性を排除または削減 (またはコストを削減) する代替アーキテクチャや追加のコンポーネントを探します。
## リソース
**関連するベストプラクティス:**
+ [COST08-BP01 データ転送モデリングを実行する](cost_data_transfer_modeling.md)
+ [COST08-BP03 データ転送コストを削減するサービスを実装する](cost_data_transfer_implement_services.md)
**関連ドキュメント:**
+ [クラウドへのデータ移行](https://aws.amazon.com/cloud-data-migration/)
+ [AWS キャッシュソリューション](https://aws.amazon.com/caching/aws-caching/)
+ [Amazon CloudFront でコンテンツ提供を高速化する](https://aws.amazon.com/getting-started/tutorials/deliver-content-faster/)
**関連する例:**
+ [一般的なアーキテクチャでのデータ転送コストの概要](https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/)
+ [AWS ネットワーク最適化のヒント](https://aws.amazon.com/blogs/networking-and-content-delivery/aws-network-optimization-tips/)
+ [Apache Parquet 形式の VPC フローログでパフォーマンスを最適化し、ネットワーク分析のコストを削減する](https://aws.amazon.com/blogs/big-data/optimize-performance-and-reduce-costs-for-network-analytics-with-vpc-flow-logs-in-apache-parquet-format/)
# COST08-BP03 データ転送コストを削減するサービスを実装する
データ転送コストを削減するサービスを実装します。例えば、エッジロケーションやコンテンツ配信ネットワーク (CDN) を使用してエンドユーザーにコンテンツを配信する、アプリケーションサーバーまたはデータベースの前にキャッシュレイヤーを構築する、クラウドへの接続に VPN ではなく専用ネットワーク接続を使用するなどです。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
ネットワークデータ転送の使用量を最適化するのに役立つさまざまな AWS サービスがあります。ワークロードのコンポーネント、種類、クラウドアーキテクチャにもよりますが、これらのサービスはクラウド上でのトラフィックの圧縮、キャッシュ、共有、分散に役立ちます。
+ [Amazon CloudFront](https://aws.amazon.com/cloudfront/) は、低レイテンシーかつ高速の転送速度でデータを転送する、グローバルなコンテンツ配信ネットワークです。世界中のエッジロケーションでデータをキャッシュすることで、お客様のリソースの負荷を軽減します。CloudFront を使用することで、レイテンシーを最低限に抑え、世界中の多数のユーザーにコンテンツを配信するための管理労力を軽減できます。経時的に使用量を増やす予定がある場合、[Security Savings Bundle](https://aws.amazon.com/about-aws/whats-new/2021/02/introducing-amazon-cloudfront-security-savings-bundle/?sc_channel=em&sc_campaign=Launch_mult_OT_awsroadmapemail_20200910&sc_medium=em_whats_new&sc_content=launch_ot_ot&sc_country=mult&sc_geo=mult&sc_category=mult&sc_outcome=launch) を使用すると、CloudFront の使用量を最大 30% 節約できます。
+ [AWS 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/userguide/vpc-endpoints.html)により、プライベートネットワークを利用した AWS サービス間の接続が可能になり、パブリックデータ転送と [NAT ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)のコストを削減できます。[ゲートウェイ VPC エンドポイント](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-gateway.html)では時間単位の料金は発生せず、Amazon S3 と Amazon DynamoDB がサポートされています。[インターフェイス VPC エンドポイント](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html)は [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-service.html) により提供され、時間単位の料金と GB あたりの使用料が発生します。
+ [NAT ゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)にはスケーリングと管理機能が組み込まれており、スタンドアロンの NAT インスタンスとは異なりコストを節約できます。NAT ゲートウェイはトラフィックの多いインスタンスと同じアベイラビリティーゾーンに配置し、Amazon DynamoDB または Amazon S3 にアクセスが必要なインスタンスでは VPC エンドポイントを使用して、データ転送とデータ処理コストを削減することを検討してください。
+ エッジ AWS Snow Family デバイス ([Snowball Edge](https://aws.amazon.com/snowcone/)、[Snowball Edge](https://aws.amazon.com/snowball/)、および [Snowmobile](https://aws.amazon.com/snowmobile/)) で、データを収集し処理するコンピューティングリソースを持つ [AWS Snow Family](https://aws.amazon.com/snow/) デバイスを使用すると、ペタバイト規模のデータをコスト効率よく、オフラインで AWS クラウド に移動できます。
### 実装手順
+ **サービスを実装する:** データ転送モデリングを使用し、VPC フローログを確認して、サービスとワークロードタイプに基づいて適切な AWS ネットワークサービスを選択します。最大のコストと最大のボリュームフローがどこにあるかを調べます。AWS のサービスを確認し、転送を減らすか排除するサービス (特にネットワークとコンテンツ配信) があるかどうかを評価します。また、データへの繰り返しのアクセス、または大量のデータがあるキャッシュサービスを探します。
## リソース
**関連ドキュメント:**
+ [AWS Direct Connect](https://aws.amazon.com/directconnect/)
+ [AWS の製品を見る](https://aws.amazon.com/)
+ [AWS キャッシュソリューション](https://aws.amazon.com/caching/aws-caching/)
+ [Amazon CloudFront](https://aws.amazon.com/cloudfront/) \$1
+ [AWS Snow Family](https://aws.amazon.com/snow/)
+ [Amazon CloudFront Security Savings Bundle](https://aws.amazon.com/about-aws/whats-new/2021/02/introducing-amazon-cloudfront-security-savings-bundle/)
**関連動画:**
+ [Monitoring and Optimizing Your Data Transfer Costs](https://www.youtube.com/watch?v=UjliYz25_qo)
+ [AWS コスト最適化シリーズ: CloudFront](https://www.youtube.com/watch?v=k8De2AfAN3k)
+ [NAT ゲートウェイのデータ転送料金を削減するにはどうすればよいですか?](https://www.youtube.com/watch?v=hq4KtPRezus)
**関連する例:**
+ [共有サービスのチャージバック方法: An AWS Transit Gateway の例](https://aws.amazon.com/blogs/aws-cloud-financial-management/gs-chargeback-shared-services-an-aws-transit-gateway-example/)
+ [Athena クエリと QuickSight を使用してコストと使用状況レポートから AWS データ転送の詳細を深く理解する](https://aws.amazon.com/blogs/networking-and-content-delivery/understand-aws-data-transfer-details-in-depth-from-cost-and-usage-report-using-athena-query-and-quicksight/)
+ [一般的なアーキテクチャでのデータ転送コストの概要](https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/)
+ [AWS Cost Explorer でデータ転送コストを分析する](https://aws.amazon.com/blogs/mt/using-aws-cost-explorer-to-analyze-data-transfer-costs/)
+ [Amazon CloudFront の各種機能で AWS アーキテクチャのコストを最適化する](https://aws.amazon.com/blogs/networking-and-content-delivery/cost-optimizing-your-aws-architectures-by-utilizing-amazon-cloudfront-features/)
+ [NAT ゲートウェイのデータ転送料金を削減するにはどうすればよいですか?](https://aws.amazon.com/premiumsupport/knowledge-center/vpc-reduce-nat-gateway-transfer-costs/)