翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Windows ワークロードを適切なサイズに設定する
## 概要:
適切なサイジングは、最も強力なコスト削減ツールの 1 つです。 は、[AWS 最適化とライセンス評価 (AWS OLA)](https://aws.amazon.com/optimization-and-licensing-assessment/) を使用して潜在的なワークロードを確認することから、 を使用して既存のワークロードを確認することまで、適切なサイジング情報を収集するためのさまざまな方法 AWS を提供します[AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/)。
このセクションでは、[AWS Compute Optimizer](https://docs.aws.amazon.com/cost-management/latest/userguide/ce-rightsizing.html) を使用して Amazon EC2 の適切なサイズ設定の機会を特定する方法について説明します。Compute Optimizer は、次のタイプの AWS リソースの過剰プロビジョニングと過少プロビジョニングを防ぐのに役立ちます。
+ [Amazon Elastic Compute Cloud (Amazon EC2)](https://aws.amazon.com/ec2/) インスタンスタイプ
+ [Amazon Elastic Block Store (Amazon EBS) ボリューム](https://aws.amazon.com/ebs/)
+ での [Amazon Elastic Container Service (Amazon ECS)](https://aws.amazon.com/ecs/) サービス AWS Fargate
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) が提供する使用率データに基づく [AWS Lambda](https://aws.amazon.com/lambda/) 関数
## コスト最適化シナリオ
適切なサイズ設定の有効性を測定するのは難しい場合があります。適切なサイズ設定の取り組みは、特定のアプリケーション、チーム、または組織全体に向けられる可能性があるためです。たとえば、数千のインスタンスを に移行し AWS、フリートの 90% が Windows ワークロードで構成される組織を考えてみましょう。組織は Compute Optimizer を使用してフリートを分析し、アカウントおよび AWS リージョン全体で大幅な過剰プロビジョニングを検出できます。その後、[AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) を使用して、複数のメンテナンスウィンドウを通じてフリートのサイズを適切に設定できます。結果として、組織は、フリートの 70% に対して適切なサイズのインスタンスタイプを調整することができ、35% のコスト削減を実現します。
次のダッシュボードは、このサンプル組織が Compute Optimizer の適切なサイズ設定推奨事項を戦略的に実装したことにより、数か月にわたって達成された削減額を示しています。その目的は、契約終了が近づいているコロケーションデータセンターからの停止した移行を再開するために、既存のワークロードを可能な限り効率的に運用することでした。
![\[適切なサイズ設定によるコスト削減\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/dashboard_rightsizing_savings.png)
## コスト最適化の推奨事項
Compute Optimizer を使用してコストを最適化するには、次のステップを実行することをお勧めします。
+ Compute Optimizer を有効にする
+ Windows ノードのメモリメトリクス収集を有効にする
+ Compute Optimizer 推奨事項を使用する
+ 適切なサイズ設定のためにインスタンスにタグを付ける
+ AWS 請求ツールを操作するためにコスト配分タグを有効にする
+ Automation を使用して適切なサイジングレコメンデーションを実装 AWS Systems Manager する
+ 代替のサイズ変更方法を検討する
+ Cost Explorer で前と後のコストを確認する
### Compute Optimizer を有効にする
[Compute Optimizer](https://docs.aws.amazon.com/compute-optimizer/latest/ug/getting-started.html#account-opt-in) は、組織レベルまたは AWS Organizationsの単一アカウントレベルで有効にできます。組織全体の設定では、すべてのメンバーアカウントのフリート全体の新規および既存のインスタンスの継続的なレポートが提供されます。これにより、適切なサイズ設定を、ポイントインタイムアクティビティではなく、繰り返し行うアクティビティにすることができます。
#### 組織レベル
ほとんどの組織にとって、Compute Optimizer を使用する最も効率的な方法は組織レベルです。これにより、マルチアカウントとマルチリージョンの組織への可視性が提供され、レビューのためにデータを 1 つのソースに一元化できます。組織レベルでこれを有効にするには、以下を実行します。
1. [必要なアクセス許可](https://docs.aws.amazon.com/compute-optimizer/latest/ug/security-iam.html)を持つロールを使用して[組織管理アカウント](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html)にサインインし、この組織内のすべてのアカウントにオプトインすることを選択します。組織で、[すべての機能が有効になっている](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org_support-all-features.html)必要があります。
1. 管理アカウントを有効にしたら、アカウントにサインインし、他のすべてのメンバーアカウントを表示して、その推奨事項を参照できます。
**注記**
Compute Optimizer の[委任管理者アカウント](https://docs.aws.amazon.com/compute-optimizer/latest/ug/delegate-administrator-account.html)を設定するのがベストプラクティスです。これにより、最小特権の原則を実践できます。そうすれば、組織全体のサービスへのアクセスを提供しながら、組織の管理アカウントへのアクセスを最小限に抑えることができます。
#### 単一アカウントレベル
コストの高いアカウントをターゲットにしているが、 AWS Organizationsにアクセスできない場合は、そのアカウントとリージョンに対して Compute Optimizer を有効にできます。オプトインプロセスの詳細については、Compute Optimizer ドキュメントの「[Getting started with AWS Compute Optimizer](https://docs.aws.amazon.com/compute-optimizer/latest/ug/getting-started.html)」を参照してください。
### Windows ノードのメモリメトリクス収集を有効にする
メモリメトリクスは、組織内で十分な情報に基づいた適切なサイズ設定の推奨事項を示すために必要な必須メトリクスを Compute Optimizer に提供します。これは、推奨事項を提供する前に CPU、メモリ、ネットワーク、ストレージの分析が行われているためです。
Windows EC2 インスタンスから Compute Optimizer にメモリメトリクスを渡すには、CloudWatch エージェントを有効にし、60 秒ごとにメモリメトリクスを収集するように設定する必要があります。CloudWatch でメモリメトリクスを使用する場合、追加料金はかかりません。
#### CloudWatch エージェントを有効にしてメモリメトリクスを設定する
[ComputeOptimize.yml](https://static.us-east-1.prod.workshops.aws/public/93110159-2ede-4c0c-9767-877c96d68a7e/static/code/wec2/ComputeOptimize.yml) ファイルをダウンロードします。このファイルを使用して、アカウント内のすべてのインスタンスのメモリ収集を有効にできます。テンプレートファイルは、次のコンポーネントを生成します。
+ [AWS Systems Manager パラメータストア](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) – メモリメトリクスの収集に必要な CloudWatch エージェントの設定を保存します。
+ AWS Identity and Access Management [AWS の 管理ポリシー AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/security_iam_service-with-iam.html#managed-policies)がアタッチされた (IAM) ロール – これは Systems Manager Automation ドキュメント用です。
+ [AWS Systems Manager ドキュメント](https://docs.aws.amazon.com/systems-manager/latest/userguide/documents.html) – CloudWatch エージェントをインストールして設定します (既存の CloudWatch 設定を置き換えます)。
+ [AWS Systems Manager ステートマネージャー](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-state.html)の関連付け – これにより、Systems Manager ドキュメントをアカウント内のすべてのインスタンスで実行できます。
**重要**
このテンプレートを実行すると、インスタンスの既存の CloudWatch 設定が上書きされます。
次に、以下の手順を実行します。
1. にサインイン AWS マネジメントコンソール し、[CloudFormation コンソール](https://console.aws.amazon.com/cloudformation/)を開きます。
1. ナビゲーションペインで、[**Stacks**] を選択します。
1. **[スタックの作成]** を選択し、**[既存のリソースを使用 (リソースのインポート)]** を選択します。
1. [**次へ**] を選択します。
1. **[テンプレートソース]** で、**[テンプレートファイルのアップロード]** を選択します。
1. **[ファイル]** を選択して `ComputeOptimize.yml` ファイルをアップロードします。
1. [**次へ**] を選択します。
1. **[スタックの詳細を指定]** ページの **[スタック名]** に、スタックの名前を入力し、**[次へ]** を選択します。
1. **[リソースを識別]** ページで、インポートするリソースの識別子の値を入力します。
1. **[リソースをインポート]** を選択します。
1. スタックがデプロイされたら、**[出力]** タブを選択して、関連付けのキー、値、説明を見つけます。
#### 関連付けの進行状況をモニタリングする
1. CloudFormation スタックのデプロイが完了したら、[Systems Manager コンソール](https://console.aws.amazon.com/systems-manager/)を開きます。
1. ナビゲーションペインで、**[ノード管理]** セクションの **[ステートマネージャー]** を選択します。
1. **[関連付け]** ページで、関連付けの関連付け ID を選択します。
1. [**Execution history (実行履歴の表示)**] タブを選択します。
1. **[実行 ID]** 列で、関連付けの実行 ID を選択します。ステータスは **[成功]** である必要があります。
#### CloudWatch でメトリクスを表示する
メトリクスが CloudWatch に入力されるまで、少なくとも 5 分間待つことをお勧めします。
1. [CloudWatch コンソール](https://console.aws.amazon.com/cloudwatch/)を開きます。
1. ナビゲーションペインで、**[メトリクス]** セクションを展開し、**[すべてのメトリクス]** を選択します。
1. メトリクスが **CWAgent** 名前空間の下に表示されることを確認します。
**注記**
新しいインスタンスに設定を適用するには、関連付けを再実行します。
### Compute Optimizer 推奨事項を使用する
1 つのアカウントと 1 つのリージョン内で適切なサイズ変更を行うことに焦点を当てた例について考えてみましょう。この例では、Compute Optimizer はすべてのアカウントで組織レベルで有効になっています。適切なサイズ設定は破壊的なプロセスであり、ほとんどの場合、数週間にわたるスケジュールされたメンテナンス期間中にアプリケーション所有者が正確に実行するプロセスであるという点に注意してください。
組織の管理アカウント内から Compute Optimizer に移動する場合は (次の手順を参照)、調査するアカウントを選択できます。この例では、`us-east-1` リージョンの 1 つのアカウントで実行されているインスタンスが 6 つあります。6 つのインスタンスすべてが過剰にプロビジョニングされています。目標は、Compute Optimizer からの推奨事項に基づいてインスタンスのサイズを変更することです。
#### 過剰にプロビジョニングされたインスタンスを特定し、推奨事項の詳細をエクスポートする
1. にサインイン AWS マネジメントコンソール し、[Compute Optimizer コンソール](https://console.aws.amazon.com/compute-optimizer/)を開きます。
1. ナビゲーションペインで、**ダッシュボード**を選択してください。
1. **[ダッシュボード]** ページの検索ボックスに、**Region=US East (N. Virginia)** と入力します。次に、**Findings=Over-provisioned** と入力します。これらのフィルタを使用すると、`us-east-1` リージョン内の過剰にプロビジョニングされたインスタンスをすべて表示できます。
1. 過剰にプロビジョニングされた ****EC2 インスタンス****の詳細な推奨事項を確認するには、**EC2 インスタンス**カードまで下にスクロールし、**[推奨事項の表示]** を選択します。
1. **[エクスポート]** を選択し、後で使用するためにファイルを保存します。
1. **[S3 バケット]** には、エクスポートファイルの宛先にする Amazon S3 バケットの名前を入力します。
**注記**
今後のレビューのために推奨事項を保存するには、Compute Optimizer が各リージョンで書き込める S3 バケットが必要です。詳細については、Compute Optimizer ドキュメントの「[Amazon S3 bucket policy for AWS Compute Optimizer](https://docs.aws.amazon.com/compute-optimizer/latest/ug/create-s3-bucket-policy-for-compute-optimizer.html)」を参照してください。
1. **[フィルタをエクスポート]** セクションで、**[組織内のすべてのメンバーアカウントの推奨事項を含める]** チェックボックスを選択します。
1. **[リソースタイプ]** で、**[EC2 インスタンス]** を選択します。
1. **[含める列]** セクションで、**[すべて選択]** チェックボックスを選択します。
1. **[エクスポート]** を選択します。
#### 推奨事項に基づいてインスタンスを選択する
インスタンスの推奨事項は、Compute Optimizer によって収集および分析されたパフォーマンスメトリクスに基づいています。最適なインスタンスを選択するには、インスタンスで実行されているワークロードに注意することが重要です。この例では、最新世代の Amazon EC2 [R6i](https://aws.amazon.com/ec2/instance-types/r6i/)、[R5](https://aws.amazon.com/ec2/instance-types/r5/)、および [T3](https://aws.amazon.com/ec2/instance-types/t3/) インスタンスから選択できることを前提としています。T3 インスタンスはバースト可能で、ネットワーク帯域幅機能は低くなります。R5 インスタンスと R6 インスタンスは、1 時間あたりのコストが同じであり、ほぼ同一です。ただし、R6 インスタンスは、ネットワーク帯域幅容量が大きく、最新世代の Intel プロセッサを搭載しており、R5 と同じコンピューティングフットプリントを提供します。この例では、R6 がサイズ変更に最適なオプションです。
1. [Compute Optimizer コンソール](https://console.aws.amazon.com/compute-optimizer/)で、ナビゲーションバーから **[EC2 インスタンスの推奨事項]** を選択します。このページでは、現在のインスタンスタイプと、置き換える推奨オプションの比較を示します。
1. 適切なサイズを設定するインスタンスの ID を取得するには、 AWS Organizationsの管理アカウントから [Amazon S3 コンソール](https://console.aws.amazon.com/s3/)を開きます。
1. ナビゲーションペインで **[バケット]** を選択し、エクスポートした結果の保存に使用するバケットを選択します。
1. **[オブジェクト]** タブで、オブジェクトリストからエクスポートファイルを選択し、**[ダウンロード]** を選択します。
1. ファイルからインスタンス情報を抽出するには、Microsoft Excel の **[データ]** タブの **[テキストから列へ]** ボタンを使用できます。
**注記**
インスタンス ID は Amazon リソースネーム (ARN) として表されます。必ず区切り文字を「/」に設定して、インスタンス ID を抽出してください。または、スクリプトを記述するか、統合開発環境 (IDE) を使用して ARN をトリミングすることもできます。
1. Excel で、**OVER\$1PROVISIONED** インスタンスのみを表示するように**検出結果**列をフィルタリングします。これらが、適切なサイズ設定の対象となるインスタンスです。
1. 後で簡単にアクセスできるように、テキストエディタでインスタンス ID を保存します。
### 適切なサイズ設定のためにインスタンスにタグを付ける
ワークロードにタグを付けることは、 AWSでリソースを整理するための強力なツールです。タグを使用すると、コストをきめ細かく可視化し、チャージバックを容易にすることができます。 AWS リソースにタグを追加するための戦略と方法の詳細については、「 リソースのタグ付けに関する AWS ホワイトペーパーのベストプラクティス」を参照してください。 [AWS](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)この例では、[AWS タグエディタ](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)を使用して、メンテナンス期間中にサイズ変更の対象となる過剰にプロビジョニングされたインスタンス間でタグ付けを調整することができます。このタグを使用して、変更前後のコストを表示することもできます。
1. にサインイン AWS マネジメントコンソール し、サイズ変更の対象となるインスタンスを含むアカウントの[AWS Resource Groups コンソール](https://console.aws.amazon.com/resource-groups)を開きます。
1. ナビゲーションバーの **[タグ付け]** セクションで、**[タグエディタ] **を選択します。
1. **[リージョン]** で、ターゲットリージョンを選択します。
1. **[リソースタイプ]** で、**[AWS::EC2::Instance]** を選択します。
1. **[リソースを検索]** を選択します。
1. **[リソースの検索結果]** ページで、適切なサイズに設定するインスタンスをすべて選択し、**[選択したリソースのタグを管理する]** を選択します。
1. **[タグを追加]** を選択します。
1. **[タグキー]** には、**Rightsizing** と入力します。**[タグ値]** には、**enabled** と入力します。そして、**[タグの変更を確認して適用する]** を選択します。
**注記**
チームやビジネスユニットなどの追加のメタデータを含めれば、後で Cost Explorer でフィルタリングできます。
ユーザー定義のタグを作成してリソースに適用した後、アクティブ化のためにタグがコスト配分タグページに表示されるまでに最大で 24 時間かかる場合があります。アクティブ化のためにタグを選択した後、タグが有効になるまでにさらに 24 時間かかることがあります。
上級ユーザーは、ターゲットアカウントとリージョン内で [AWS CloudShell](https://console.aws.amazon.com/cloudshell/home) を使用して、複数のインスタンスにタグを付けることができます。例えば、次のようになります。
```
bash
#!/bin/bash
# Set variables
TAG_KEY="rightsizing"
TAG_VALUE="type-m5"
# Get a list of instance IDs
INSTANCE_IDS=$(aws ec2 describe-instances —query "Reservations[].Instances[].InstanceId" —output text)
# Loop through each instance ID and add the tag
for INSTANCE_ID in $INSTANCE_IDS; do
aws ec2 create-tags —resources $INSTANCE_ID —tags Key=$TAG_KEY,Value=$TAG_VALUE
done
```
### AWS 請求ツールを操作するためにコスト配分タグを有効にする
ユーザー定義のコスト配分タグをアクティブ化することをお勧めします。これにより、 AWS 請求ツール (Cost Explorer や など) で **Rightsizing **タグが認識され、フィルタリングできるようになります AWS Cost and Usage Report。これを有効にしない場合、タグフィルタリングオプションとデータは使用できなくなります。コスト配分タグの使用の詳細については、 AWS Billing and Cost Management ドキュメントの「[ユーザー定義のコスト配分タグのアクティブ化](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activating-tags.html)」を参照してください。
1. にサインイン AWS マネジメントコンソール し、 [AWS Billing コンソール](https://console.aws.amazon.com/billing)を開きます。
1. ナビゲーションペインの **[請求]** セクションで、**[コスト配分タグ]** を選択します。
1. **[ユーザー定義のコスト配分タグ]** タブで、**Rightsizing** と入力します。
1. **Rightsizing** タグキーを選択し、**[アクティブ化]** を選択します。
24 時間後、Cost Explorer にタグが表示されます。
### Systems Manager Automation を使用して適切なサイズ設定の推奨事項を実装する
サイズ変更は、インスタンスを停止して開始する必要があるシナリオです。このシナリオでは、メンテナンス期間にこの中断を処理し、独自のサイズ変更を処理するために別のチームが必要になる場合があります。インスタンスタイプを変更する前に、Amazon EC2 ドキュメントの「[Considerations for compatible instance types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-resize.html#resize-ebs-backed-instance-considerations)」を確認してください。
このセクションのステップ例では、[AWS-ResizeInstance](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-resizeinstance.html) という Systems Manager Automation ドキュメントを使用して、アカウントおよびリージョンごとに適切なサイズ設定の推奨事項を実装します。ほとんどの組織はさまざまな目的で異なるインスタンスタイプを必要とするため、このアプローチはほとんどの組織にとって一般的です。同じ `AWS-ResizeInstance` オートメーションドキュメントを使用して、単一アカウントおよびマルチアカウントのデプロイを対象にすることもできます。
1. にサインイン AWS マネジメントコンソール し、[Systems Manager コンソール](https://console.aws.amazon.com/systems-manager/)を開きます。
1. ナビゲーションペインの **[共有リソース]** セクションで、**[ドキュメント]** を選択します。
1. 検索バーに **AWS-ResizeInstance** と入力し、検索結果から **AWS-ResizeInstance** を選択します。
1. [**Execute automation (自動化の実行)**] を選択してください。
1. **[オートメーションランブックを実行する]** ページで、**[シンプルな実行]** を選択します。
1. **[入力パラメータ]** セクションで、**InstanceId** および **InstanceType** と入力します。残りはデフォルト値のままにしておきます。
1. **[実行]** を選択し、********オートメーションがインスタンスタイプを変更するステップを実行するのを待ちます。
### 代替のサイズ変更方法を検討する
起動テンプレートを使用してインスタンスをデプロイする場合は、起動テンプレートを適切なサイズのインスタンスタイプで更新し、インスタンスの更新を実行してインスタンスを適切なサイズのバージョンに置き換えることができます。
複数のアカウントとリージョンで適切なサイズ設定プロセスを使用する場合は、カスタム Systems Manager Automation ドキュメントを作成する必要があります。このドキュメントでは、複数のインスタンスをパラメータとしてフィードし、同じ宛先インスタンスタイプに移行するインスタンスを対象にすることができます (例えば、ソースインスタンスタイプに関係なく、t3a.medium に移行するすべてのインスタンス)。
### Cost Explorer で前と後のコストを確認する
リソースのサイズを適切に設定したら、Cost Explorer を使用し、**[ライトサイジング]** タグを使用して、前と後のコストを表示できます。[リソースタグ](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)を使用してコストを追跡できることを思い出してください。複数のタグレイヤーを使用することで、コストをきめ細かく可視化できます。このガイドで説明する例では、**[ライトサイジング] **タグを使用して、すべてのターゲットインスタンスに汎用タグを適用します。次に、[チーム] タグを使用して、リソースをさらに整理します。次のステップでは、アプリケーションタグを導入して、特定のアプリケーションを運用する際のコストへの影響をさらに示します。
次の図は、組織のタグ構造を示しています。
![\[組織のタグ構造\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/optimize-costs-microsoft-workloads/images/org_tag_structure.png)
運用チームが所有する本番用ウェブサーバーのサイズを適切に設定するビジネスの例を考えてみましょう。Cost Explorer では、**Rightsizing** タグは **enabled** に設定され、**Team** タグは **operations** に設定されています。この例では、適切なサイズ設定作業により、運用コストが 1 時間あたり 0.89 セントから 0.28 セントに削減されます。1 か月あたり 744 時間と仮定すると、適切なサイズ設定の前の年間コストは 7,945.92 USD です。適切なサイズ設定の後、年間コストは 2,499.84 USD に削減されます。これにより、年間ワークロードコストが 68.5% 削減されることになります。これが大規模な組織全体に及ぼす影響を想像してみてください。これはサンプル環境で行われ、インスタンスはほとんどアイドル状態であることに注意してください。本番環境では、10～35% の節約が見込まれます。
次に、エンジニアリングチームが所有する本番用踏み台ホストの適切なサイズ設定の影響について検討します。Cost Explorer では、**Rightsizing** タグは **enabled** に設定され、**Team** タグは **engineering** に設定されています。この例では、適切なサイズ設定作業により、コストが 1 時間あたり 0.75 セントから 0.44 セントに削減されます。1 か月あたり 744 時間と仮定すると、適切なサイズ設定の前の年間コストは 6,696.00 USD です。適切なサイズ設定の後、年間コストは 3,928.32 USD に削減されます。
複数のタグを使用する場合は、データフィルタリングしてコストの詳細まで確認することができます。この例では、**Team** タグによってノイズが削減され、チームレベルで影響を確認できるようになります。**Rightsizing** タグが有効になっているため、そのタグの値が **enabled** になっているインスタンス、または値が存在しないインスタンスをフィルタリングすることもできます。これにより、特に Cost Explorer レベルで管理アカウント (支払者) に表示される場合、適切なサイズ設定作業のグローバルビューを提供できます。このビューでは、すべてのアカウントとインスタンスを表示できます。
**Rightsizing** タグが **enabled** に設定されている単一アカウントレベルでの例について考えてみましょう。 運用コストは 1 時間あたり 1.64 USD から 0.72 USD に減少します。1 か月あたり 744 時間と仮定すると、適切なサイズ設定の前の年間コストは 14,641.92 USD です。適切なサイズ設定の後、年間コストは 6,428.16 USD に削減されます。これにより、このアカウントのコンピューティングコストが 56% 削減されます。
適切なサイズ設定ジャーニーを開始する前に、次の点を考慮してください。
+ AWS には、コスト削減のための多くのオプションがあります。これには、 が移行前にオンプレミスインスタンス AWS を確認する [AWS OLA](https://aws.amazon.com/optimization-and-licensing-assessment/) が含まれます AWS。OLA AWS は、適切なサイジングの推奨事項とライセンスガイダンスも提供します。
+ [Savings Plans](https://aws.amazon.com/savingsplans/) を購入する前に、適切なサイズ設定をすべて完了してください。これにより、Savings Plans コミットメントでの過剰購入を回避できます。
## 推奨事項
次のステップとして以下の手順の実行を推奨します。
1. 既存のランドスケープを確認し、Amazon EBS gp2 ボリュームを gp3 ボリュームに変換することを検討します。
1. [Savings Plans](https://aws.amazon.com/savingsplans/) を確認します。
## その他のリソース
+ [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) (AWS ドキュメント)
+ [AWS リソースのタグ付けのベストプラクティス](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html) (AWS ホワイトペーパー)
+ [AWS Compute OptimizerAWS Trusted Advisor との間でデータを収集する方法 AWS Organizations](https://www.youtube.com/watch?v=ekR6RSgqJ4Q) (YouTube)
+ 「[Optimizing performance and reducing licensing costs: Leveraging AWS Compute Optimizer for Amazon EC2 SQL Server instances](https://aws.amazon.com/blogs/modernizing-with-aws/optimizing-performance-and-reducing-licensing-costs-leveraging-aws-compute-optimizer-for-ec2-sql-server-instances/)」(Microsoft Workloads on AWS ブログ)