# 適切なサイジングのための機会の特定
<a name="identifying-opportunities-to-right-size"></a>

 適切なサイジングのための最初のステップは、現在のサービス使用状況をモニタリングおよび分析して、インスタンスのパフォーマンスと使用パターンに関するインサイトを得ることです。十分なデータを収集するには、少なくとも 2 週間 (理想的には 1 か月間) にわたりパフォーマンスを確認し、ワークロードとビジネスピークを把握します。インスタンスのパフォーマンスを定義する最も一般的なメトリクスは、vCPU 使用率、メモリ使用率、ネットワーク使用率、エフェメラルディスク使用率です。これらのメトリクス以外の理由でインスタンスが選択されることはまれですが、テクニカルオーナーが適切なサイジングの取り組みについて確認することが重要です。 

## 適切なサイジングのためのツール
<a name="tools-for-right-sizing"></a>

 次のツールを使用して、コストを評価し、インスタンスの使用状況をモニタリングおよび分析して適切なサイジングを可能にできます。 
+  [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) – CPU 使用率、ネットワークスループット、ディスク I/O を確認し、確認されたピークメトリクスに合った新しい安価なインスタンスタイプを調べることができます。また、[Amazon EC2 使用状況レポート](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/usage-reports.html)を定期的にモニタリングすることもできます。このレポートは 1 日に数回更新され、すべての EC2 インスタンスの詳細な使用状況データを提供します。通常、これには時間と労力が必要になるため、小規模な環境でのみ実現可能です。 
+  [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) – この無料のツールでは、コストと使用量のデータをより詳しく調べて、傾向を識別し、コストの発生要因を特定し、異常を検知できます。これには Amazon EC2 使用状況レポートが含まれているため*、*過去 13 か月間の EC2 インスタンスのコストと使用量を分析できます。 
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/best-practices/) – AWS 環境を検査してアイドル状態のリソースのリソースや使用率の低いリソースを特定し、サービスの使用状況に関するリアルタイムインサイトを提供することで、システムのパフォーマンスと信頼性の向上、セキュリティの強化、コスト削減機会の発見に役立ちます。 
+  CloudHealth、Cloudability、CloudCheckr などのサードパーティーのモニタリングツールも、機会を自動的に特定して代替インスタンスを提案するオプションとなります。これらのツールには、長年の開発努力とお客様からのフィードバックポイントが組み込まれており、追加のコスト管理および最適化機能も備わっています。 

## 適切なサイジングのためのツールを独自に開発するためのヒント
<a name="tips-for-developing-your-own-right-sizing-tools"></a>

 また、パフォーマンスをモニタリングおよび分析するために、独自のツールを開発することもできます。このオプションを検討する場合は、次のガイドラインを参考にしてください。 
+  確認している時間の半分以上実行されたインスタンスに注目します。 
+  リザーブドインスタンスの適用範囲が狭いインスタンスに注目します。 
+  オフになっているリソースを除外します (検索の手間が軽減されます)。 
+  可能な限り、旧世代のインスタンスへの変換は避けます。 
+  削減額がそれ以下では適切なサイジングを検討する価値のない、削減のしきい値を適用します。 
+  新しいインスタンスに切り替える前に、次の条件が満たされていることを確認します。 
  +  新しいインスタンスの vCPU が古いインスタンスの vCPU と等しい、*または*アプリケーションで確認された vCPU が新しいインスタンスの vCPU 容量の 80% 未満である。 
  +  新しいインスタンスのメモリが古いインスタンスのメモリと等しい、*または*アプリケーションで確認されたメモリピークが新しいインスタンスのメモリ容量の 80% 未満である。 

     注意: Amazon CloudWatch にこれらのメトリクスを報告するモニタリングスクリプトを使用して、メモリ使用率メトリクスをキャプチャできます。詳細については、「[Amazon EC2 Linux インスタンスのメモリとディスクのメトリクスのモニタリング](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/mon-scripts.html)」を参照してください。 
  +  新しいインスタンスのネットワークスループットが古いインスタンスのネットワークスループットと等しい、*または*アプリケーションのネットワークピークが新しいインスタンスのネットワーク容量より低い。 

     注意: NetworkIn と NetworkOut の最大値は、1 分あたりのバイト数単位で測定されます。これらのメトリクスをメガビット/秒に変換するには、次の数式を使用します。 

     最大 NetworkIn (または NetworkOut) x 8 (バイトからビットへ) /1024/1024/60 = Mbps 数 
  +  エフェメラルストレージのディスク I/O が 3,000 未満の場合は、[Amazon Elastic Block Store](https://aws.amazon.com/ebs/) (Amazon EBS) ストレージを使用できます。そうでない場合は、エフェメラルストレージを持つインスタンスファミリーを使用します。詳細については、「[Amazon EBS ボリュームのタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)」を参照してください。