

# PERF 2 コンピューティングソリューションはどのように選択すればよいですか?
<a name="w2aac19c11b5b7"></a>

ワークロードにとって最適なコンピューティングソリューションは、アプリケーションの設計、使用パターン、設定に応じて異なります。各アーキテクチャでは、コンポーネントごとに異なるコンピューティングソリューションが使用される可能性があるため、パフォーマンスを向上させるための機能も異なります。アーキテクチャに不適切なコンピューティングソリューションを選択すると、パフォーマンス効率が低下する可能性があります。

**Topics**
+ [PERF02-BP01 使用可能なコンピューティングオプションを評価する](perf_select_compute_evaluate_options.md)
+ [PERF02-BP02 利用可能なコンピューティング設定オプションについて理解する](perf_select_compute_config_options.md)
+ [PERF02-BP03 コンピューティング関連のメトリクスを収集する](perf_select_compute_collect_metrics.md)
+ [PERF02-BP04 適切なサイジングによって必要な設定を決定する](perf_select_compute_right_sizing.md)
+ [PERF02-BP05 利用可能な伸縮性のあるリソースを使用する](perf_select_compute_elasticity.md)
+ [PERF02-BP06 メトリクスに基づいてコンピューティングニーズを再評価する](perf_select_compute_use_metrics.md)

# PERF02-BP01 使用可能なコンピューティングオプションを評価する
<a name="perf_select_compute_evaluate_options"></a>

 インスタンス、コンテナ、関数などのさまざまなコンピューティングオプションを使用することで、ワークロードにどのようなメリットがあるかを理解します。 

 **期待される成果:** 利用できるすべてのコンピューティングオプションを理解することにより、パフォーマンスを高め、不要なインフラストラクチャコストを削減し、ワークロードの維持に必要な運用労力を低減するための機会に気付くことができます。また、新しいサービスや機能をデプロイする際に、市場投入までの時間を短縮できます。 

 **一般的なアンチパターン:** 
+  移行後のワークロードで、オンプレミスで使用していたコンピューティングソリューションをそのまま使用する。 
+  クラウドコンピューティングソリューションや、そうしたソリューションがコンピューティング性能の向上にどのように役立つかについての認識が足りない。 
+  ワークロードの特性により的確に適合する代替のコンピューティングソリューションがあるにもかかわらず、スケーリングやパフォーマンスの要件を満たすために既存のコンピューティングソリューションのサイズを大きくしすぎる。 

 **このベストプラクティスを活用するメリット:** コンピューティング要件を特定し、利用できるコンピューティングソリューションを評価することにより、ビジネスステークホルダーやエンジニアリングチームが、選択したコンピューティングソリューションを使用することの利点や制限を理解できます。選択したコンピューティングソリューションは、ワークロードのパフォーマンス基準に適合している必要があります。主な基準には、処理の必要性、トラフィックパターン、データアクセスパターン、スケーリングの必要性、レイテンシー要件があります。 

 **このベストプラクティスを活用しない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>

 ワークロードにメリットをもたらし、パフォーマンス要件を満たす仮想化、コンテナ化、マネジメントのソリューションを理解します。1 つのワークロードには、複数の種類のコンピューティングソリューションを含めることができます。コンピューティングソリューションにはぞれぞれ、異なる特徴があります。ワークロードのスケールとコンピューティング要件を基に、コンピューティングソリューションを選択し、ニーズを満たすように構成できます。クラウドアーキテクトは、インスタンス、コンテナ、関数の長所と短所を学ぶ必要があります。次の手順では、ワークロードの特性とパフォーマンス要件に合ったコンピューティングソリューションを選択する方法を詳しく説明しています。 


|  **タイプ**  |  **サーバー**  |  **コンテナ**  |  **関数**  | 
| --- | --- | --- | --- | 
|  AWS のサービス  |  Amazon Elastic Compute Cloud (Amazon EC2)  |  Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS)  |  AWS Lambda  | 
|  主な特徴  |  ハードウェアライセンス要件、プレイスメントオプション、またコンピューティングメトリクスに基づくさまざまなインスタンスファミリーの幅広い選択肢のための専用オプションがある  |  デプロイが簡単、環境に一貫性がある、EC2 インスタンス上で運用、スケーリングが可能  |  ランタイムが短い (15 分以下)、メモリおよび CPU の上限は他のサービスほど高くない、マネージドハードウェア層、何百万の同時リクエストに対応してスケーリング  | 
|  一般的なユースケース  |  リフトアンドシフトの移行、モノリシックなアプリケーション、ハイブリッド環境、エンタープライズアプリケーション  |  マイクロサービス、ハイブリッド環境  |  マイクロサービス、イベント駆動型アプリケーション  | 

 

 **実装手順:** 

1.  「 [PERF05-BP06 ネットワーク要件に基づいてワークロードのロケーションを選択する](perf_select_network_location.md)」セクションを評価して、コンピューティングソリューションを配置する場所を選択します。この場所により、使用できるコンピューティングソリューションのタイプが制限されます。

1.  場所の要件とアプリケーション要件に適したコンピューティングソリューションのタイプを特定します。  

   1.  [https://aws.amazon.com/ec2/](https://aws.amazon.com/ec2/) 仮想サーバーインスタンスにはさまざまなファミリーとサイズがあります。またソリッドステートドライブ (SSD)、グラフィック処理ユニット (GPU) などさまざまな機能が使用できます。EC2 インスタンスは、インスタンスの選択において最大の柔軟性を提供します。EC2 インスタンスを起動する場合、指定するインスタンスタイプによって、インスタンスのハードウェアが決まります。インスタンスタイプごとに、コンピューティング、メモリ、ストレージの機能が異なります。インスタンスタイプは、これらの機能に基づいてインスタンスファミリーにグループ分けされます。一般的なユースケースには、エンタープライズアプリケーションの運用、ハイパフォーマンスコンピューティング (HPC)、機械学習アプリケーションのトレーニングおよびデプロイ、クラウドネイティブアプリケーションの運用などがあります。

   1.  [https://aws.amazon.com/ecs/](https://aws.amazon.com/ecs/) はフルマネージド型のコンテナオーケストレーションサービスで、AWS Fargate を使用したサーバーレスインスタンスまたは EC2 インスタンスでクラスターを構成し、コンテナを自動的に実行および管理できるようにします。Amazon ECS は Amazon Route 53、Secrets Manager、AWS Identity and Access Management (IAM)、Amazon CloudWatch などのサービスと併せて使用できます。Amazon ECS は、アプリケーションがコンテナ化されており、エンジニアリングチームが Docker コンテナを好む場合に推奨されます。 

   1.  [https://aws.amazon.com/eks/](https://aws.amazon.com/eks/) は、フルマネージド型の Kubernetes サービスです。AWS Fargate を使って EKS クラスターを実行することもできるため、サーバーのプロビジョニングと管理が不要になります。Amazon EKS の管理は、Amazon CloudWatch、Auto Scaling グループ、AWS Identity and Access Management (IAM)、Amazon Virtual Private Cloud (VPC) などの AWS のサービスとの統合によって簡素化されています。コンテナを使用する場合、EC2 インスタンスまたは AWS Fargate インスタンスのタイプを選択するためにコンピューティングメトリクスを使用するのと同様に、ワークロードに最も適したタイプを選択するためにコンピューティングメトリクスを使用する必要があります。Amazon EKS は、アプリケーションがコンテナ化されており、エンジニアリングチームが Docker コンテナよりも Kubernetes 好む場合に推奨されます。 

   1.  専用のインフラストラクチャで [https://aws.amazon.com/lambda/](https://aws.amazon.com/lambda/) を使用すると、許可されたランタイム、メモリ、CPU のオプションをサポートするコードを実行できます。コードをアップロードするだけで、AWS Lambda がそのコードの実行とスケーリングに必要となるものすべてを管理します。コードは、他の AWS のサービスから自動的にトリガーするように設定するか、直接呼び出すことができます。Lambda は、クラウド用に開発された実行時間の短いマイクロサービスアーキテクチャに推奨されます。  

1.  新しいコンピューティングソリューションを試した後、移行を計画し、パフォーマンスメトリクスを検証します。これは継続的なプロセスです。詳細については、 [PERF02-BP04 適切なサイジングによって必要な設定を決定する](perf_select_compute_right_sizing.md)を参照してください。

 **実装計画に必要な工数レベル:** ワークロードがあるコンピューティングソリューションから別のコンピューティングソリューションに移行する場合は、アプリケーションのリファクタリングに *中* 程度の工数が必要になる可能性があります。   

## リソース
<a name="resources"></a>

 **関連ドキュメント:** 
+  [AWS を使用したクラウドコンピューティング ](https://aws.amazon.com/products/compute/?ref=wellarchitected) 
+  [EC2 インスタンスタイプ ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html?ref=wellarchitected) 
+  [EC2 インスタンスのプロセッサのステート制御 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/processor_state_control.html?ref=wellarchitected) 
+  [EKS コンテナ: EKS ワーカーノード ](https://docs.aws.amazon.com/eks/latest/userguide/worker.html?ref=wellarchitected) 
+  [Amazon ECS コンテナ: Amazon ECS コンテナインスタンス ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_instances.html?ref=wellarchitected) 
+  [関数: Lambda 関数の設定](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html?ref=wellarchitected#function-configuration) 
+  [コンテナに関する規範ガイダンス](https://aws.amazon.com/prescriptive-guidance/?apg-all-cards.sort-by=item.additionalFields.sortText&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%23containers&awsf.apg-rtype-filter=*all&awsf.apg-isv-filter=*all&awsf.apg-product-filter=*all&awsf.apg-env-filter=*all) 
+  [サーバーレスに関する規範ガイダンス](https://aws.amazon.com/prescriptive-guidance/?apg-all-cards.sort-by=item.additionalFields.sortText&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%23serverless&awsf.apg-rtype-filter=*all&awsf.apg-isv-filter=*all&awsf.apg-product-filter=*all&awsf.apg-env-filter=*all) 

 **関連動画:** 
+  [スタートアップ企業向けコンピューティングオプションの選択方法](https://aws.amazon.com/startups/start-building/how-to-choose-compute-option/) 
+  [Optimize performance and cost for your AWS compute (CMP323-R1)](https://www.youtube.com/watch?v=zt6jYJLK8sg) 
+  [Amazon EC2 foundations (CMP211-R2) ](https://www.youtube.com/watch?v=kMMybKqC2Y0&ref=wellarchitected) 
+  [Powering next-gen Amazon EC2: Deep dive into the Nitro system ](https://www.youtube.com/watch?v=rUY-00yFlE4&ref=wellarchitected) 
+  [Deliver high-performance ML inference with AWS Inferentia (CMP324-R1) ](https://www.youtube.com/watch?v=17r1EapAxpk&ref=wellarchitected) 
+  [Better, faster, cheaper compute: Cost-optimizing Amazon EC2 (CMP202-R1) ](https://www.youtube.com/watch?v=_dvh4P2FVbw&ref=wellarchitected) 

 **関連サンプル:** 
+  [Migrating the web application to containers](https://application-migration-with-aws.workshop.aws/en/container-migration.html) 
+  [Run a Serverless Hello World](https://aws.amazon.com/getting-started/hands-on/run-serverless-code/) 

# PERF02-BP02 利用可能なコンピューティング設定オプションについて理解する
<a name="perf_select_compute_config_options"></a>

 各コンピューティングソリューションには、ワークロードの特性をサポートするために使用できるオプションと設定があります。さまざまなオプションがワークロードをどのように補完するか、またアプリケーションにどの設定オプションが最適かをご紹介します。これらのオプションの例には、インスタンスのファミリー、サイズ、機能 (GPU、I/O)、バースト、タイムアウト、関数サイズ、コンテナインスタンス、並行性などがあります。 

 **期待される成果:** CPU、メモリ、ネットワークスループット、GPU、IOPS、トラフィックパターン、データアクセスパターンなどのワークロードの特性を文書化し、ワークロードの特性に合わせてコンピューティングソリューションを設定するために使用されます。これらの各メトリクスと、お客様のワークロードに特化したカスタムメトリクスを記録、監視し、コンピューティング設定を最適化することで、要件に最適に対応します。 

 **一般的なアンチパターン:** 
+  オンプレミスで使用していたコンピューティングソリューションをそのまま使用する。 
+  ワークロードの特性に合ったコンピューティングオプションやインスタンスファミリーを見直さない。 
+  バースト能力を確保するためにコンピューティングを過剰にする。 
+  同じワークロードに対して複数のコンピューティング管理プラットフォームを使用する。 

** このベストプラクティスを確立するメリット:** AWS のコンピューティングサービスをよく理解し、それぞれのワークロードに適したソリューションを決定できるようにしましょう。ワークロードのコンピューティングサービスを選択したら、それらがワークロードのニーズをどの程度満たしているかを迅速に実験することができます。ワークロードの特性に合うように最適化されたコンピューティングソリューションを使用することで、パフォーマンス改善、コスト削減、信頼性向上を実現できます。

 **このベストプラクティスが確立されていない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>

 ワークロードで同じコンピューティングオプションを 4 週間以上使用しており、その特性が今後も変わらないと予想される場合は、 [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) を使用して、コンピューティング特性に基づいた推奨事項を提供することができます。メトリクスが足りない、インスタンスタイプがサポートされていない、特性が変わることが予想されるなどの理由から、AWS Compute Optimizer [を使用できない場合は、負荷テストや](https://docs.aws.amazon.com/compute-optimizer/latest/ug/requirements.html#requirements-ec2-instances) 実験を基にメトリクスを予測する必要があります。  

 **実装手順:** 

1.  EC2 インスタンスで実行していますか、それとも EC2 起動タイプのコンテナで実行していますか。 

   1.  ワークロードで GPU を使用してパフォーマンスを高めることができますか。 

      1.  [高速コンピューティング](https://aws.amazon.com/ec2/instance-types/?trk=36c6da98-7b20-48fa-8225-4784bced9843&sc_channel=ps&sc_campaign=acquisition&sc_medium=ACQ-P|PS-GO|Brand|Desktop|SU|Compute|EC2|US|EN|Text&s_kwcid=AL!4422!3!536392622533!e!!g!!ec2%20instance%20types&ef_id=CjwKCAjwiuuRBhBvEiwAFXKaNNRXM5FrnFg5H8RGQ4bQKuUuK1rYWmU2iH-5H3VZPqEheB-pEm-GNBoCdD0QAvD_BwE:G:s&s_kwcid=AL!4422!3!536392622533!e!!g!!ec2%20instance%20types#Accelerated_Computing) インスタンスとは GPU ベースのインスタンスで、機械学習のトレーニング、推論、ハイパフォーマンスコンピューティング向けに最も高いパフォーマンスを提供します。 

   1.  ワークロードで機械学習推論アプリケーションを実行していますか。 

      1.  [AWS Inferentia (Inf1)](https://aws.amazon.com/ec2/instance-types/inf1/) — Inf1 インスタンスは、機械学習推論アプリケーションをサポートするために構築されています。Inf1 インスタンスを使用すると、画像認識、音声認識、自然言語処理、パーソナライゼーション、不正行為検出といった大規模な機械学習推論アプリケーションを実行できます。モデルは、TensorFlow、PyTorch、MXNet などの一般的な機械学習フレームワークのいずれかで構築し、GPU インスタンスを使用してトレーニングできます。要件に合わせて機械学習モデルをトレーニングしたら、AWS Neuron を使用して Inf1 インスタンスにモデルをデプロイできます。 [AWS Neuron](https://aws.amazon.com/machine-learning/neuron/)は、Inferentia チップの機械学習推論パフォーマンスを最適化するコンパイラー、ランタイム、プロファイリングツールで構成される専用のソフトウェア開発キット (SDK) です。 

   1.  パフォーマンス向上のために、ワークロードを低レベルのハードウェアと統合していますか。  

      1.  [フィールドプログラマブルゲートアレイ (FPGA)](https://aws.amazon.com/ec2/instance-types/f1/) — FPGA を使用することで、最も要求の厳しいワークロードをカスタムハードウェアで加速して実行することができ、ワークロードを最適化することができます。サポートされる、C や Go などの一般的なプログラミング言語や、Verilog や VHDL などのハードウェア指向の言語を利用してアルゴリズムを定義できます。 

   1.  少なくとも 4 週間分のメトリクスがあり、トラフィックパターンとメトリクスが今後もほぼ同じになると予測できますか。 

      1.  予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [Compute Optimizer](https://aws.amazon.com/compute-optimizer/) を使用して、コンピューティング特性に最適なコンピューティング構成に関する機械学習の推奨事項を取得します。 

   1.  ワークロードのパフォーマンスは CPU のメトリクスによって制限されていますか。  

      1.  [コンピューティング最適化](https://aws.amazon.com/ec2/instance-types/?trk=36c6da98-7b20-48fa-8225-4784bced9843&sc_channel=ps&sc_campaign=acquisition&sc_medium=ACQ-P|PS-GO|Brand|Desktop|SU|Compute|EC2|US|EN|Text&s_kwcid=AL!4422!3!536392622533!e!!g!!ec2%20instance%20types&ef_id=CjwKCAjwiuuRBhBvEiwAFXKaNNRXM5FrnFg5H8RGQ4bQKuUuK1rYWmU2iH-5H3VZPqEheB-pEm-GNBoCdD0QAvD_BwE:G:s&s_kwcid=AL!4422!3!536392622533!e!!g!!ec2%20instance%20types#Compute_Optimized) インスタンスは、高性能プロセッサーを必要とするワークロードに適しています。  

   1.  ワークロードのパフォーマンスはメモリのメトリクスによって制限されていますか。  

      1.  [メモリ最適化](https://aws.amazon.com/ec2/instance-types/?trk=36c6da98-7b20-48fa-8225-4784bced9843&sc_channel=ps&sc_campaign=acquisition&sc_medium=ACQ-P|PS-GO|Brand|Desktop|SU|Compute|EC2|US|EN|Text&s_kwcid=AL!4422!3!536392622533!e!!g!!ec2%20instance%20types&ef_id=CjwKCAjwiuuRBhBvEiwAFXKaNNRXM5FrnFg5H8RGQ4bQKuUuK1rYWmU2iH-5H3VZPqEheB-pEm-GNBoCdD0QAvD_BwE:G:s&s_kwcid=AL!4422!3!536392622533!e!!g!!ec2%20instance%20types#Memory_Optimized) インスタンスは大量のメモリを提供し、メモリを集中的に使用するワークロードをサポートします。 

   1.  ワークロードのパフォーマンスは IOPS によって制限されていますか。 

      1.  [ストレージ最適化](https://aws.amazon.com/ec2/instance-types/?trk=36c6da98-7b20-48fa-8225-4784bced9843&sc_channel=ps&sc_campaign=acquisition&sc_medium=ACQ-P|PS-GO|Brand|Desktop|SU|Compute|EC2|US|EN|Text&s_kwcid=AL!4422!3!536392622533!e!!g!!ec2%20instance%20types&ef_id=CjwKCAjwiuuRBhBvEiwAFXKaNNRXM5FrnFg5H8RGQ4bQKuUuK1rYWmU2iH-5H3VZPqEheB-pEm-GNBoCdD0QAvD_BwE:G:s&s_kwcid=AL!4422!3!536392622533!e!!g!!ec2%20instance%20types#Storage_Optimized) インスタンスは、ローカルストレージへの高いシーケンシャルな読み書きアクセス (IOPS) を必要とするワークロード向けに設計されています。 

   1.  ワークロードの特性は、すべてのメトリクスにおいてバランスの取れたニーズを示していますか。 

      1.  ワークロードの CPU にはトラフィックの急上昇に対応するためのバーストが必要ですか。 

         1.  [バーストパフォーマンス](https://aws.amazon.com/ec2/instance-types/?trk=36c6da98-7b20-48fa-8225-4784bced9843&sc_channel=ps&sc_campaign=acquisition&sc_medium=ACQ-P|PS-GO|Brand|Desktop|SU|Compute|EC2|US|EN|Text&s_kwcid=AL!4422!3!536392622533!e!!g!!ec2%20instance%20types&ef_id=CjwKCAjwiuuRBhBvEiwAFXKaNNRXM5FrnFg5H8RGQ4bQKuUuK1rYWmU2iH-5H3VZPqEheB-pEm-GNBoCdD0QAvD_BwE:G:s&s_kwcid=AL!4422!3!536392622533!e!!g!!ec2%20instance%20types#Instance_Features) インスタンスは、コンピューティング最適化インスタンスに似ていますが、コンピューティング最適化インスタンスに見られる固定 CPU ベースラインを超えてバーストできるという点が異なります。 

      1.  [汎用](https://aws.amazon.com/ec2/instance-types/?trk=36c6da98-7b20-48fa-8225-4784bced9843&sc_channel=ps&sc_campaign=acquisition&sc_medium=ACQ-P|PS-GO|Brand|Desktop|SU|Compute|EC2|US|EN|Text&s_kwcid=AL!4422!3!536392622533!e!!g!!ec2%20instance%20types&ef_id=CjwKCAjwiuuRBhBvEiwAFXKaNNRXM5FrnFg5H8RGQ4bQKuUuK1rYWmU2iH-5H3VZPqEheB-pEm-GNBoCdD0QAvD_BwE:G:s&s_kwcid=AL!4422!3!536392622533!e!!g!!ec2%20instance%20types#General_Purpose) インスタンスは、あらゆる特性においてバランスが取れており、さまざまなワークロードをサポートします。 

   1.  コンピューティングインスタンスは Linux で実行されており、ネットワークインターフェイスカードのネットワークスループットによって制限されていますか。 

      1.  「 [パフォーマンスに関する質問 5、ベストプラクティス 2: 使用可能なネットワーク機能を評価する](https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/network-architecture-selection.html) 」を確認し、パフォーマンスのニーズに合った適切なインスタンスのタイプおよびファミリーを特定します。 

   1.  ワークロードは、特定のアベイラビリティゾーンで 1 年間コミットできる、一貫性のある予測可能なインスタンスを必要としますか。  

      1.  [リザーブドインスタンス](https://aws.amazon.com/ec2/pricing/reserved-instances/) を使用すると、特定のアベイラビリティーゾーン内でキャパシティ予約が確定されます。リザーブドインスタンスは、特定のアベイラビリティゾーンでコンピューティング性能が必要な場合に最適です。  

   1.  ワークロードには、専用ハードウェアを必要とするライセンスがありますか。 

      1.  [専有ホスト](https://aws.amazon.com/ec2/dedicated-hosts/) は、既存のソフトウェアライセンスをサポートし、コンプライアンス要件への準拠を支援します。 

   1.  コンピューティングソリューションはバーストし、同期処理が必要ですか。 

      1.  [オンデマンドインスタンス](https://aws.amazon.com/ec2/pricing/on-demand/) では、1 時間または 1 秒単位でコンピューティング性能を利用でき、長期的な契約は必要ありません。このインスタンスは、パフォーマンスのベースラインを超えるようなバースト的なニーズに適しています。 

   1.  コンピューティングソリューションは、ステートレスでフォールト トレラント、かつ非同期ですか。  

      1.  [スポットインスタンス](https://aws.amazon.com/ec2/spot/) では、未使用のインスタンスキャパシティをステートレスでフォールトトレラントなワークロードに活用できます。  

1.  コンテナを [Fargate](https://aws.amazon.com/fargate/)で実行していますか。 

   1.  タスクのパフォーマンスはメモリまたは CPU によって制限されていますか。 

      1.  メモリまたは CPU を調整するために、 [タスクサイズ](https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/capacity-tasksize.html) を使用します。 

   1.  トラフィックパターンのバーストによって、パフォーマンスが影響を受けていますか。 

      1.  トラフィックパターンに合わせるために、 [Auto Scaling](https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/capacity-autoscaling.html) の設定を使用します。 

1.  コンピューティングソリューションは [Lambda](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-features.html)上にありますか。 

   1.  少なくとも 4 週間分のメトリクスがあり、トラフィックパターンとメトリクスが今後もほぼ同じになると予測できますか。 

      1.  予想されるコストと使用状況に合わせたカスタムの予算を設定するには、 [Compute Optimizer](https://aws.amazon.com/compute-optimizer/) を使用して、コンピューティング特性に最適なコンピューティング構成に関する機械学習の推奨事項を取得します。 

   1.  AWS Compute Optimizer を使用するのに十分なメトリクスがありますか。 

      1.  Compute Optimizer を使用するのに必要なメトリクスがない場合は、 [AWS Lambda Power Tuning](https://docs.aws.amazon.com/lambda/latest/operatorguide/profile-functions.html) を使用して最適な設定を選択できます。 

   1.  関数のパフォーマンスはメモリまたは CPU によって制限されていますか。 

      1.  パフォーマンスニーズのメトリクスを満たすように [Lambda メモリ](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-common.html#configuration-memory-console) を設定します。 

   1.  関数が実行時にタイムアウトしていますか。 

      1.  タイムアウトの設定 [を変更します。](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-common.html) 

   1.  関数のパフォーマンスはアクティビティと並行処理のバーストによって制限されていますか。  

      1.  パフォーマンス要件を満たすように [並行処理の設定](https://docs.aws.amazon.com/lambda/latest/dg/configuration-concurrency.html) を行います。 

   1.  関数が非同期で実行され、再試行で失敗していますか。 

      1.  イベントの最大経過時間と最大再試行回数を [非同期設定](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html) で指定します。 

## 実装計画に必要な工数レベル: 
<a name="level-of-effort-for-the-implementation-plan-to-establish-this-best-practice-you-must-be-aware-of-your-current-compute-characteristics-and-metrics.-gathering-those-metrics-establishing-a-baseline-and-then-using-those-metrics-to-identify-the-ideal-compute-option-is-a-low-to-moderate-level-of-effort.-this-is-best-validated-by-load-tests-and-experimentation."></a>

このベストプラクティスを確立するには、現在のコンピューティングの特性とメトリクスを把握している必要があります。こうしたメトリクスを収集し、ベースラインを確立した上で、これらのメトリクスを使用して最適なコンピューティングオプションを特定するには、 *低* ～ *中* 程度の工数が必要です。これは、負荷テストや実験によって検証するのが最善です。 

## リソース
<a name="resources"></a>

 **関連ドキュメント:** 
+  [Cloud Compute with AWS (AWS を使用したクラウドコンピューティング) ](https://aws.amazon.com/products/compute/?ref=wellarchitected) 
+  [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) 
+  [EC2 インスタンスタイプ ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html?ref=wellarchitected) 
+  [EC2 インスタンスのプロセッサのステート制御 ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/processor_state_control.html?ref=wellarchitected) 
+  [EKS コンテナ: EKS ワーカーノード ](https://docs.aws.amazon.com/eks/latest/userguide/worker.html?ref=wellarchitected) 
+  [Amazon ECS コンテナ: Amazon ECS コンテナインスタンス ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_instances.html?ref=wellarchitected) 
+  [Functions: Lambda Function Configuration (関数: Lambda 関数の設定)](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html?ref=wellarchitected#function-configuration) 

 **関連動画:** 
+  [Amazon EC2 foundations (CMP211-R2) ](https://www.youtube.com/watch?v=kMMybKqC2Y0&ref=wellarchitected) 
+  [Powering next-gen Amazon EC2: Deep dive into the Nitro system ](https://www.youtube.com/watch?v=rUY-00yFlE4&ref=wellarchitected) 
+  [Optimize performance and cost for your AWS compute (CMP323-R1) (AWS コンピューティングのパフォーマンスとコストを最適化する) ](https://www.youtube.com/watch?v=zt6jYJLK8sg&ref=wellarchitected) 

 **関連サンプル:** 
+  [Rightsizing with Compute Optimizer and Memory utilization enabled (Compute Optimizer とメモリ使用率を有効にした場合のライトサイジング)](https://www.wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/5_ec2_computer_opt/) 
+  [AWS Compute Optimizer Demo code (AWS Compute Optimizer デモコード)](https://github.com/awslabs/ec2-spot-labs/tree/master/aws-compute-optimizer) 

# PERF02-BP03 コンピューティング関連のメトリクスを収集する
<a name="perf_select_compute_collect_metrics"></a>

コンピューティングリソースのパフォーマンスを理解するには、各種システムの実際の使用率を記録して追跡する必要があります。このデータは、リソース要件についてより正確な判断を行うために使用できます。  

 ワークロードでは、メトリクス、ログ、イベントなどのデータが大量に生成される可能性があります。既存のストレージ、モニタリング、可観測性のサービスが、生成されたデータを管理できるかどうかを判断してください。どのメトリクスがリソースの使用率を反映し、単一のプラットフォーム全体で収集、集計、相関できるかを特定します。このメトリクスは、システム全体を容易に可視化し、パフォーマンス改善の機会と問題を迅速に特定できるよう、すべてのワークロードリソース、アプリケーション、サービスを表している必要があります。

 **期待される成果:** コンピューティング関連のリソースに関係するすべてのメトリクスが、単一のプラットフォーム上で特定、収集、集約されて関連付けが行われ、コストと運用の目標をサポートするために保持が実装されます。 

 **一般的なアンチパターン:** 
+  メトリクスの検索に手動ログファイルのみを使用している。  
+  内部ツールにのみメトリクスを発行している。 
+  一部のモニタリングソフトウェアで記録されるデフォルトのメトリクスのみを使用している。 
+  問題が発生したときにだけメトリクスを確認している。 

 

 **このベストプラクティスを活用するメリット:** ワークロードのパフォーマンスをモニタリングするには、一定期間にわたって複数のパフォーマンスメトリクスを記録する必要があります。これらのメトリクスにより、パフォーマンスの異常を検出できます。また、ビジネスメトリクスに照らし合わせてパフォーマンスを測定することで、ワークロードのニーズを満たしているかどうかを確認できます。 

 **このベストプラクティスを活用しない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>

 コンピューティング関連のメトリクスを特定、収集、集計し、関連付けを行います。Amazon CloudWatch などのサービスを使用すると、実装をより迅速かつ簡単に維持できます。デフォルトで記録されるメトリクスに加えて、ワークロード内のシステムレベルのメトリクスを追加で特定し、追跡します。CPU 使用率、メモリ、ディスク I/O、ネットワークのインバウンドおよびアウトバウンドメトリクスなどのデータを記録し、使用状況レベルやボトルネックを把握します。このデータは、ワークロードのパフォーマンスやコンピューティングソリューションの使用状況を理解するために不可欠です。これらのメトリクスをデータ駆動型のアプローチの一部として使用し、ワークロードのリソースを積極的に調整および最適化します。  

 **実装手順:** 

1.  追跡するのが重要なコンピューティングソリューションメトリクスはどれですか。 

   1.  [EC2 のデフォルトのメトリクス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html) 

   1.  [Amazon ECS のデフォルトのメトリクス](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cloudwatch-metrics.html) 

   1.  [EKS のデフォルトのメトリクス](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/kubernetes-eks-metrics.html) 

   1.  [Lambda のデフォルトのメトリクス](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-access-metrics.html) 

   1.  [EC2 のメモリとディスクのメトリクス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html) 

1.  現在、承認済みのロギングおよび監視ソリューションを使用していますか。 

   1.  [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 

   1.  [AWS Distro for OpenTelemetry](https://aws.amazon.com/otel/) 

   1.  [Amazon Managed Service for Prometheus](https://docs.aws.amazon.com/grafana/latest/userguide/prometheus-data-source.html) 

1.  セキュリティおよび運用の目標に合ったデータ保持ポリシーを特定、構成しましたか。 

   1.  [CloudWatch メトリクスのデフォルトのデータ保持](https://aws.amazon.com/cloudwatch/faqs/#AWS_resource_.26_custom_metrics_monitoring) 

   1.  [CloudWatch Logs のデフォルトのデータ保持](https://aws.amazon.com/cloudwatch/faqs/#Log_management) 

1.  メトリクスおよびログの集計エージェントをどのようにデプロイしますか。 

   1.  [AWS Systems Manager オートメーション](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html?ref=wellarchitected) 

   1.  [OpenTelemetry Collector](https://aws-otel.github.io/docs/getting-started/collector) 

 **実装計画に必要な工数レベル: **すべてのコンピューティングリソースからのメトリクスを特定、追跡、収集、集約し、関連付けるには、 *中* 程度の労力が必要です。 

## リソース
<a name="resources"></a>

 **関連ドキュメント:** 
+  [Amazon CloudWatch のドキュメント](https://docs.aws.amazon.com/cloudwatch/index.html?ref=wellarchitected) 
+  [CloudWatch エージェントを使用して Amazon EC2 インスタンスとオンプレミスサーバーからのメトリクスとログを収集する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html?ref=wellarchitected) 
+  [Accessing Amazon CloudWatch Logs for AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-functions-logs.html?ref=wellarchitected) 
+  [コンテナインスタンスでの CloudWatch Logs の使用](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_cloudwatch_logs.html?ref=wellarchitected) 
+  [カスタムメトリクスをパブリッシュする](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html?ref=wellarchitected) 
+  [AWS の回答: 集中ログ記録](https://aws.amazon.com/answers/logging/centralized-logging/?ref=wellarchitected) 
+  [CloudWatch メトリクスを発行する AWS のサービス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html?ref=wellarchitected) 
+  [AWS Fargate での Amazon EKS のモニタリング](https://aws.amazon.com/blogs/containers/monitoring-amazon-eks-on-aws-fargate-using-prometheus-and-grafana/) 

 

 **関連動画:** 
+  [Application Performance Management on AWS](https://www.youtube.com/watch?v=5T4stR-HFas&ref=wellarchitected) 
+  [モニタリング計画を立てる](https://www.youtube.com/watch?v=OMmiGETJpfU&ref=wellarchitected) 

 

 **関連サンプル:** 
+  [Level 100: Monitoring with CloudWatch Dashboards](https://wellarchitectedlabs.com/performance-efficiency/100_labs/100_monitoring_with_cloudwatch_dashboards/) 
+  [Level 100: Monitoring Windows EC2 instance with CloudWatch Dashboards](https://wellarchitectedlabs.com/performance-efficiency/100_labs/100_monitoring_windows_ec2_cloudwatch/) 
+  [Level 100: Monitoring an Amazon Linux EC2 instance with CloudWatch Dashboards](https://wellarchitectedlabs.com/performance-efficiency/100_labs/100_monitoring_linux_ec2_cloudwatch/) 

# PERF02-BP04 適切なサイジングによって必要な設定を決定する
<a name="perf_select_compute_right_sizing"></a>

 ワークロードのさまざまなパフォーマンス特性と、それらの特性とメモリ、ネットワーク、CPU 使用率との関連を分析します。このデータは、ワークロードのプロファイルに最適なリソースを選択するために使用します。たとえば、メモリ集約型のワークロード (データベースなど) には r ファミリーのインスタンスが最適ですが、バーストするワークロードでは、伸縮自在なコンテナシステムからより多くのメリットを得ることができます。 

 **一般的なアンチパターン:** 
+  すべてのワークロードに対して使用できる最大のインスタンスを選択する。 
+  管理しやすいように、すべてのインスタンスタイプを 1 つのタイプに標準化する。 

 **このベストプラクティスを活用するメリット:** AWS のコンピューティングサービスに精通していれば、さまざまなワークロードに適したソリューションを判断できます。ワークロードのさまざまなコンピューティングサービスを選択したら、それらのコンピューティングサービスを簡単に試し、ワークロードのニーズを満たすのはどれかをすばやく判断できます。 

 **このベストプラクティスを活用しない場合のリスクレベル:** 中 

## 実装のガイダンス
<a name="implementation-guidance"></a>

 適切なサイジングによってワークロード設定を変更する: パフォーマンスと全体的な効率性の両方を最適化するには、ワークロードに必要なリソースを特定します。CPU よりもメモリを必要とするシステムの場合は、メモリ最適化されたインスタンスを選択します。メモリ負荷の高くないデータ処理を実行するコンポーネントの場合は、コンピューティング最適化されたインスタンスを選択します。適切なサイジングを行うことで、ワークロードが要求されたリソースのみを使用しながら、可能な限り最高のパフォーマンスを達成することが可能になります。 

## リソース
<a name="resources"></a>

 **関連ドキュメント:** 
+  [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/)  
+  [AWS を使用したクラウドコンピューティング](https://aws.amazon.com/products/compute/) 
+  [EC2 インスタンスタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) 
+  [ECS コンテナ: Amazon ECS コンテナインスタンス](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_instances.html) 
+  [EKS コンテナ: EKS ワーカーノード](https://docs.aws.amazon.com/eks/latest/userguide/worker.html) 
+  [関数: Lambda 関数の設定](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html#function-configuration) 
+  [EC2 インスタンスのプロセッサのステート制御](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/processor_state_control.html) 

 **関連動画:** 
+  [Amazon EC2 foundations (CMP211-R2)](https://www.youtube.com/watch?v=kMMybKqC2Y0) 
+  [Better, faster, cheaper compute: Cost-optimizing Amazon EC2 (CMP202-R1)](https://www.youtube.com/watch?v=_dvh4P2FVbw) 
+  [Deliver high performance ML inference with AWS Inferentia (CMP324-R1)](https://www.youtube.com/watch?v=17r1EapAxpk) 
+  [Optimize performance and cost for your AWS compute (CMP323-R1)](https://www.youtube.com/watch?v=zt6jYJLK8sg) 
+  [Powering next-gen Amazon EC2: Deep dive into the Nitro system](https://www.youtube.com/watch?v=rUY-00yFlE4) 
+  [スタートアップ企業向けコンピューティングオプションの選択方法](https://aws.amazon.com/startups/start-building/how-to-choose-compute-option/) 
+  [Optimize performance and cost for your AWS compute (CMP323-R1)](https://www.youtube.com/watch?v=zt6jYJLK8sg) 

 **関連サンプル:** 
+  [Rightsizing with Compute Optimizer and Memory utilization enabled](https://www.wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/5_ec2_computer_opt/) 
+  [AWS Compute Optimizer デモコード](https://github.com/awslabs/ec2-spot-labs/tree/master/aws-compute-optimizer) 

# PERF02-BP05 利用可能な伸縮性のあるリソースを使用する
<a name="perf_select_compute_elasticity"></a>

 クラウドは、需要の変化に対応するためのさまざまなメカニズムを通じて、リソースを動的に拡張または縮小する柔軟性を提供します。コンピューティング関連のメトリクスと組み合わせることによって、ワークロードは自動的に変化に対応し、最適な一連のリソースを利用して目標を達成できるようになります。 

 均衡の取れた需要と供給はワークロードコストを最小限に抑えますが、プロビジョニングの時間と個々のリソース障害に対応するために十分な供給を計画する必要もあります。需要は固定的である場合と変動する場合があるため、管理が負担になったり、不相応に多額なコストがかからないようにするためにも、メトリクスと自動化が必要になります。 

 AWS では、さまざまなアプローチで需要と供給を一致させることができます。コスト最適化の柱のホワイトペーパーでは、コストに関して以下のアプローチを使用する方法が説明されています。 
+  需要ベースのアプローチ 
+  バッファーベースのアプローチ 
+  時間ベースのアプローチ 

 ワークロードのデプロイメントで、確実にスケールアップおよびスケールダウンイベントを対処できるようにしてください。スケールダウンイベントのテストシナリオを作成して、ワークロードが期待どおりに動作することを確認します。 

 **一般的なアンチパターン:** 
+  アラームに対応するために手動でキャパシティーを増やす。 
+  スケーリングイベントの後、スケールダウンして元に戻すのではなく、キャパシティーを増加させたままにする。 

 **このベストプラクティスを活用するメリット:** ワークロードの伸縮性を設定してテストすることで、トラフィックの変化に応じたコストの削減、パフォーマンスベンチマークの維持、信頼性の向上を実現できます。本稼働用以外のほとんどのインスタンスは、使用されていないときに停止するべきです。未使用のインスタンスを手動でシャットダウンすることは可能ですが、大規模な場合は実用的ではありません。また、ボリュームベースの伸縮性を活用することもできます。これにより、需要の急上昇時にコンピューティングインスタンスの数を自動的に増やし、需要の減少時にキャパシティーを減らすことによって、パフォーマンスとコストを最適化できます。 

 **このベストプラクティスを活用しない場合のリスクレベル:** 中 

## 実装のガイダンス
<a name="implementation-guidance"></a>

 伸縮性を活用する: 伸縮性は、持っているリソースの供給を、それらのリソースに対する需要と一致させます。インスタンス、コンテナ、関数のいずれにも、伸縮性の仕組みが備わっています。サービスの機能として実装されている場合も、自動スケーリングと組み合わせて実現する場合もあります。アーキテクチャの伸縮性を活用して、あらゆる規模のパフォーマンス要件を満たすために十分なキャパシティーを確保してください。伸縮自在なリソースのスケールアップまたはスケールダウンのメトリクスが、デプロイされているワークロードのタイプに対して検証されていることを確認します。動画トランスコーディングアプリケーションをデプロイしようとする場合、100% の CPU 使用率が想定されるため、プライマリメトリクスにするべきではありません。代替手段として、インスタンスタイプのスケーリングを待機しているトランスコーディングジョブのキューの深さに対して測定することができます。ワークロードのデプロイメントがスケールアップおよびスケールダウンイベントの両方に対処できることを確実にします。ワークロードコンポーネントを安全にスケールダウンすることは、需要があるときにリソースをスケールアップするのと同じくらい重要です。スケールダウンイベントのテストシナリオを作成して、ワークロードが期待どおりに動作することを確認します。 

## リソース
<a name="resources"></a>

 **関連ドキュメント:** 
+  [AWS を使用したクラウドコンピューティング](https://aws.amazon.com/products/compute/) 
+  [EC2 インスタンスタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) 
+  [ECS コンテナ: Amazon ECS コンテナインスタンス](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_instances.html) 
+  [EKS コンテナ: EKS ワーカーノード](https://docs.aws.amazon.com/eks/latest/userguide/worker.html) 
+  [関数: Lambda 関数の設定](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html#function-configuration) 
+  [EC2 インスタンスのプロセッサのステート制御](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/processor_state_control.html) 

 **関連動画:** 
+  [Amazon EC2 foundations (CMP211-R2)](https://www.youtube.com/watch?v=kMMybKqC2Y0) 
+  [Better, faster, cheaper compute: Cost-optimizing Amazon EC2 (CMP202-R1)](https://www.youtube.com/watch?v=_dvh4P2FVbw) 
+  [Deliver high performance ML inference with AWS Inferentia (CMP324-R1)](https://www.youtube.com/watch?v=17r1EapAxpk) 
+  [Optimize performance and cost for your AWS compute (CMP323-R1)](https://www.youtube.com/watch?v=zt6jYJLK8sg) 
+  [Powering next-gen Amazon EC2: Deep dive into the Nitro system](https://www.youtube.com/watch?v=rUY-00yFlE4) 

 **関連サンプル:** 
+  [Amazon EC2 Auto Scaling グループの例](https://github.com/aws-samples/amazon-ec2-auto-scaling-group-examples) 
+  [Amazon EFS のチュートリアル](https://github.com/aws-samples/amazon-efs-tutorial) 

# PERF02-BP06 メトリクスに基づいてコンピューティングニーズを再評価する
<a name="perf_select_compute_use_metrics"></a>

 システムレベルのメトリクスを使用して、ワークロードの経時的な動作と要件を特定します。利用可能なリソースとこれらの要件を比較することによってワークロードのニーズを評価し、ワークロードのプロファイルに最も良く一致するようにコンピューティング環境を変更します。たとえば、時間がたつにつれて、システムが当初の想定よりもメモリ集約型であることがわかる場合があります。このため、別のインスタンスファミリー、またはインスタンスサイズに移行することでパフォーマンスと効率性の両方が向上する可能性があります。 

 **一般的なアンチパターン:** 
+  ワークロードに関する洞察を得るために、システムレベルのメトリクスのモニタリングのみを行う。 
+  ピーク時のワークロード要件に合わせてコンピューティングニーズを設計する。 
+  新しいコンピューティングソリューションに移行する方がワークロードの特性に合っているにもかかわらず、スケーリングやパフォーマンスの要件を満たすためにコンピューティングソリューションのサイズを大きくしすぎる。 

 **このベストプラクティスを活用するメリット:** パフォーマンスとリソース使用率を最適化するには、統合された運用ビュー、リアルタイムの詳細なデータ、履歴参照が必要です。自動ダッシュボードを作成してこのデータを視覚化し、メトリクスの計算を実行して運用と利用に関する洞察を得ることができます。 

 **このベストプラクティスを活用しない場合のリスクレベル:** 低 

## 実装のガイダンス
<a name="implementation-guidance"></a>

 データ駆動型のアプローチを使用してリソースを最適化する: パフォーマンスと効率性を最大限に高めるには、ワークロードから継続的に収集したデータを使用してリソースを調整および最適化します。ワークロードの現在のリソース使用状況におけるトレンドを調べて、ワークロードのニーズにより適合させるために変更を加えることができる場所を特定します。リソースが過剰に使用されると、システムのパフォーマンスが低下します。その一方で、リソースの使用率が低いと、リソースの使用効率が低下し、コストがより高くなります。 

## リソース
<a name="resources"></a>

 **関連ドキュメント:** 
+  [AWS を使用したクラウドコンピューティング ](https://aws.amazon.com/products/compute/?ref=wellarchitected) 
+  [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) 
+  [AWS を使用したクラウドコンピューティング](https://aws.amazon.com/products/compute/) 
+  [EC2 インスタンスタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) 
+  [ECS コンテナ: Amazon ECS コンテナインスタンス](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_instances.html) 
+  [EKS コンテナ: EKS ワーカーノード](https://docs.aws.amazon.com/eks/latest/userguide/worker.html) 
+  [関数: Lambda 関数の設定](https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html#function-configuration) 
+  [EC2 インスタンスのプロセッサのステート制御](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/processor_state_control.html) 

 **関連動画:** 
+  [Amazon EC2 foundations (CMP211-R2)](https://www.youtube.com/watch?v=kMMybKqC2Y0) 
+  [Better, faster, cheaper compute: Cost-optimizing Amazon EC2 (CMP202-R1)](https://www.youtube.com/watch?v=_dvh4P2FVbw) 
+  [Deliver high performance ML inference with AWS Inferentia (CMP324-R1)](https://www.youtube.com/watch?v=17r1EapAxpk) 
+  [Optimize performance and cost for your AWS compute (CMP323-R1)](https://www.youtube.com/watch?v=zt6jYJLK8sg) 
+  [Powering next-gen Amazon EC2: Deep dive into the Nitro system](https://www.youtube.com/watch?v=rUY-00yFlE4) 

 **関連サンプル:** 
+  [Rightsizing with Compute Optimizer and Memory utilization enabled](https://www.wellarchitectedlabs.com/cost/200_labs/200_aws_resource_optimization/5_ec2_computer_opt/) 
+  [AWS Compute Optimizer デモコード](https://github.com/awslabs/ec2-spot-labs/tree/master/aws-compute-optimizer) 