翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
適切なサイズの Windows ワークロード
概要
適切なサイジングは、最も強力なコスト削減ツールの 1 つです。 は、AWS 最適化とライセンス評価 (AWS OLA)
このセクションでは、 AWS Compute Optimizerを使用して Amazon EC2の適切なサイジングの機会を特定する方法について説明します。Compute Optimizer は、次のタイプの AWS リソースのオーバープロビジョニングとアンダープロビジョニングを防ぐのに役立ちます。
-
での Amazon Elastic Container Service (Amazon ECS)
サービス AWS Fargate -
AWS Lambda
Amazon CloudWatch が提供する使用率データに基づく 関数
コスト最適化シナリオ
適切なサイジングの有効性を測定するのは難しい場合があります。これは、適切なサイジングの取り組みを特定のアプリケーション、チーム、または組織全体に向けることができるためです。例えば、数千のインスタンスを に移行し AWS、フリートの 90% が Windows ワークロードで構成されている組織を考えてみましょう。組織は Compute Optimizer を使用してフリートを分析し、アカウントと 全体で大幅なオーバープロビジョニングを検出できます AWS リージョン。その後、AWS Systems Manager 自動化を使用して、複数のメンテナンスウィンドウを通じてフリートのサイズを適正化できます。その結果、組織はフリートの 70% で適切なサイズのインスタンスタイプを調整し、35% のコスト削減を実現します。
次のダッシュボードは、この例の組織が Compute Optimizer の適切なサイジングレコメンデーションを戦略的に実装したため、数か月にわたって達成された削減額を示しています。その目的は、コロケーションデータセンターから契約の終了が近づいているため、既存のワークロードをできるだけ効率的に運用することです。

コスト最適化の推奨事項
Compute Optimizer を使用してコストを最適化するには、次のステップを実行することをお勧めします。
-
Compute Optimizer を有効にする
-
Windows ノードのメモリメトリクス収集を有効にする
-
Compute Optimizer の推奨事項を使用する
-
適切なサイジングのためのインスタンスのタグ付け
-
コスト配分タグが AWS 請求ツールと連携できるようにする
-
AWS Systems Manager 自動化を使用して適切なサイジングのレコメンデーションを実装する
-
別のサイズ変更方法を検討する
-
Cost Explorer で前後のコストを確認する
Compute Optimizer を有効にする
Compute Optimizer は、組織レベルまたは単一アカウントレベルで有効にできます AWS Organizations。組織全体の設定では、すべてのメンバーアカウントのフリート全体の新規および既存のインスタンスの継続的なレポートが提供されます。これにより、適切なサイジングをアクティビティではなく繰り返しアクティビティ point-in-timeにすることができます。
組織レベル
ほとんどの組織にとって、Compute Optimizer を使用する最も効率的な方法は組織レベルです。これにより、マルチアカウントおよびマルチリージョンで組織を可視化し、レビューのためにデータを 1 つのソースに一元化できます。これを組織レベルで有効にするには、次の操作を行います。
-
必要なアクセス許可を持つロールを使用して Organizations 管理アカウントにサインインし、この組織内のすべてのアカウントにオプトインすることを選択します。組織で、すべての機能が有効になっている必要があります。
-
管理アカウントを有効にすると、アカウントにサインインし、他のすべてのメンバーアカウントを表示して、そのレコメンデーションを参照できます。
注記
Compute Optimizer の委任管理者アカウントを設定するのがベストプラクティスです。これにより、最小特権の原則を適用できます。これにより、組織全体のサービスへのアクセスを提供しながら、組織の管理アカウントへのアクセスを最小限に抑えることができます。
単一アカウントレベル
コストの高いアカウントをターゲットにしているが、 にアクセスできない場合は AWS Organizations、そのアカウントとリージョンで Compute Optimizer を有効にできます。オプトインプロセスの詳細については、Compute Optimizer ドキュメントの「 の開始 AWS Compute Optimizer方法」を参照してください。
Windows ノードのメモリメトリクス収集を有効にする
メモリメトリクスは、組織内で十分な情報に基づいた適切なサイジングのレコメンデーションを行うために必要な必須メトリクスを Compute Optimizer に提供します。これは、レコメンデーションを提供する前に CPU、メモリ、ネットワーク、ストレージの分析が行われているためです。
Windows EC2インスタンスから Compute Optimizer にメモリメトリクスを渡すには、 CloudWatch エージェントを有効にし、60 秒ごとにメモリメトリクスを収集するように設定する必要があります。でメモリメトリクスを使用する場合、追加料金はかかりません CloudWatch。
CloudWatch エージェントを有効にしてメモリメトリクスを設定する
ComputeOptimize.yml
-
AWS Systems Manager パラメータストア – メモリメトリクスの収集に必要な CloudWatch エージェントの設定を保存します。
-
AWS Identity and Access Management (IAM) ロールと AWS の マネージドポリシー AWS Systems Managerがアタッチされている – これは Systems Manager Automation ドキュメント用です。
-
AWS Systems Manager ドキュメント – エージェントをインストールして設定します CloudWatch (既存の CloudWatch 設定を置き換えます)。
-
AWS Systems Manager ステートマネージャーの関連付け – これにより、Systems Manager ドキュメントをアカウント内のすべてのインスタンスで実行できるようになります。
重要
このテンプレートを実行すると、インスタンスの既存の CloudWatch 設定が上書きされます。
次に、以下の手順を実行します。
-
にサインイン AWS Management Console し、 CloudFormation コンソール
を開きます。 -
ナビゲーションペインで、[Stacks] を選択します。
-
[スタックの作成] を選択し、[既存のリソースを使用 (リソースのインポート)] を選択します。
-
[Next (次へ)] を選択します。
-
テンプレートリソースで、テンプレートファイルをアップロードを選択します。
-
ファイルを選択し、
ComputeOptimize.yml
ファイルをアップロードします。 -
[Next (次へ)] を選択します。
-
スタックの詳細を指定 ページのスタック名にスタックの名前を入力し、次へを選択します。
-
リソースの特定 ページで、インポートするリソースの識別子値を入力します。
-
リソースのインポートを選択します。
-
スタックがデプロイされたら、出力タブを選択して、関連付けのキー、値、説明を見つけます。
関連付けの進行状況をモニタリングする
-
CloudFormation スタックのデプロイが完了したら、Systems Manager コンソール
を開きます。 -
ナビゲーションペインのノード管理セクションで、ステートマネージャーを選択します。
-
関連付けページで、関連付けの関連付け ID を選択します。
-
[Execution history (実行履歴の表示)] タブを選択します。
-
実行 ID 列で、関連付けの実行 ID を選択します。ステータスは Success である必要があります。
でメトリクスを表示する CloudWatch
メトリクスが入力されるまで少なくとも 5 分間待つことをお勧めします CloudWatch。
-
CloudWatch コンソール
を開きます。 -
ナビゲーションペインで、メトリクスセクションを展開し、すべてのメトリクスを選択します。
-
メトリクスがCWAgent名前空間の下に表示されることを確認します。
注記
新しいインスタンスに設定を適用するには、関連付けを再実行します。
Compute Optimizer の推奨事項を使用する
1 つのアカウントと 1 つのリージョン内で適切なサイジング変更を行うことに焦点を当てた例を考えてみましょう。この例では、Compute Optimizer はすべてのアカウントで組織レベルで有効になっています。適切なサイジングは破壊的なプロセスであり、ほとんどの場合、数週間にわたるスケジュールされたメンテナンスウィンドウ中にアプリケーション所有者が正確に実行することに注意してください。
組織の管理アカウント内から Compute Optimizer に移動する場合 (次の手順を参照)、調査するアカウントを選択できます。この例では、 us-east-1
リージョンの 1 つのアカウントで 6 つのインスタンスが実行されています。6 つのインスタンスはすべて過剰にプロビジョニングされます。目標は、Compute Optimizer からの推奨事項に基づいてインスタンスのサイズを変更することです。
過剰にプロビジョニングされたインスタンスを特定し、レコメンデーションの詳細をエクスポートする
-
にサインイン AWS Management Console し、Compute Optimizer コンソール
を開きます。 -
ナビゲーションペインで、ダッシュボードを選択します。
-
ダッシュボードページの検索ボックスに、リージョン=米国東部 (バージニア北部) と入力します。次に、「検出結果 = 過剰プロビジョニング」と入力します。これらのフィルターを使用すると、
us-east-1
リージョン内のオーバープロビジョニングされたインスタンスをすべて表示できます。 -
過剰にプロビジョニングされた EC2インスタンスの詳細なレコメンデーションを確認するには、EC2インスタンスカードまで下に スクロールし、レコメンデーションの表示を選択します。
-
エクスポート を選択し、後で使用するためにファイルを保存します。
-
S3 バケットには、エクスポートファイルの送信先とする Amazon S3 バケットの名前を入力します。
注記
今後のレビューのためにレコメンデーションを保存するには、Compute Optimizer が各リージョンで に書き込むことができる S3 バケットが必要です。詳細については、Compute Optimizer ドキュメントの「 の Amazon S3 バケットポリシー AWS Compute Optimizer」を参照してください。
-
フィルターのエクスポートセクションで、組織内のすべてのメンバーアカウントのレコメンデーションを含めるチェックボックスをオンにします。
-
リソースタイプで、EC2インスタンスを選択します。
-
含める列セクションで、すべて選択チェックボックスをオンにします。
-
[エクスポート] を選択します。
レコメンデーションに基づいてインスタンスを選択する
インスタンスのレコメンデーションは、Compute Optimizer によって収集および分析されたパフォーマンスメトリクスに基づいています。最適なインスタンスを選択するには、インスタンスで実行されているワークロードに注意することが重要です。この例では、最新世代の Amazon EC2 R6i
-
Compute Optimizer コンソール
で、ナビゲーションバーからEC2インスタンスのレコメンデーションを選択します。このページでは、現在のインスタンスタイプと置き換える推奨オプションの比較を示します。 -
適切なサイズのインスタンスの ID を取得するには、管理アカウントから Amazon S3 コンソール
を開きます AWS Organizations。 -
ナビゲーションペインでバケットを選択し、エクスポートした結果の保存に使用するバケットを選択します。
-
オブジェクトタブで、オブジェクトリストからエクスポートファイルを選択し、ダウンロードを選択します。
-
ファイルからインスタンス情報を抽出するには、Microsoft Excel のデータタブのテキストから列へのボタンを使用します。
注記
インスタンスIDsは Amazon リソースネーム () として表されますARNs。必ず区切り文字を「/」に設定し、インスタンス ID を抽出します。または、スクリプトを記述するか、統合開発環境 (IDE) を使用して をトリミングすることもできますARN。
-
Excel では、検出結果列をフィルタリングして OVER_PROVISIONED インスタンスのみを表示します。これらは、適切なサイジングをターゲットとするインスタンスです。
-
後で簡単にアクセスできるように、インスタンスをテキストエディタIDsに保存します。
適切なサイジングのためにインスタンスにタグを付ける
ワークロードにタグを付けることは、 でリソースを整理するための強力なツールです AWS。タグを使用すると、コストをきめ細かく可視化し、チャージバックが容易になります。 AWS リソースにタグを追加するための戦略と方法の詳細については、 AWS 「 AWS リソースのタグ付けのベストプラクティス」を参照してください。この例では、AWS タグエディタを使用して、メンテナンスウィンドウ中にサイズ変更の対象にする過剰にプロビジョニングされたインスタンス全体のタグ付け調整を行うことができます。このタグを使用して、変更前後のコストを表示することもできます。
-
にサインイン AWS Management Console し、サイズ変更の対象となるインスタンスを含むアカウントのAWS Resource Groups コンソール
を開きます。 -
ナビゲーションバーのタグ付けセクションで、タグエディタを選択します。
-
リージョンで、ターゲットリージョンを選択します。
-
リソースタイプで、 を選択します AWS::EC2::Instance。
-
[リソースを検索] を選択します。
-
リソース検索結果ページで、適切なサイズにするすべてのインスタンスを選択し、選択したリソースのタグの管理を選択します。
-
[タグを追加] を選択します。
-
タグキーには、「ライツサイジング」と入力します。タグ値には、有効と入力します。次に、「確認」を選択し、タグの変更を適用します。
注記
チームやビジネスユニットなどの追加のメタデータを含めると、後で Cost Explorer でフィルタリングできます。
ユーザー定義タグを作成してリソースに適用した後、アクティベーションのためにタグがコスト配分タグページに表示されるまでに最大 24 時間かかる場合があります。アクティベーションのためにタグを選択した後、タグがアクティブになるまでにさらに 24 時間かかる場合があります。
上級ユーザーの場合、ターゲットアカウントとリージョンAWS CloudShell
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 や など AWS Cost and Usage Report) で Rightsizing タグが認識され、フィルタリングできるようになります。これを有効にしない場合、タグフィルタリングオプションとデータは使用できなくなります。コスト配分タグの使用については、 ドキュメントの AWS Billing and Cost Management 「ユーザー定義のコスト配分タグのアクティブ化」を参照してください。
-
にサインイン AWS Management Console し、 AWS Billing コンソール
を開きます。 -
ナビゲーションペインの請求セクションで、コスト配分タグを選択します。
-
ユーザー定義のコスト配分タグタブで、「ライツサイジング」と入力します。
-
適切なサイズ設定タグキーを選択し、アクティブ化を選択します。
24 時間後、タグが Cost Explorer に表示されます。
Systems Manager Automation を使用して適切なサイジングレコメンデーションを実装する
サイズ変更は、インスタンスを停止して開始する必要があるシナリオです。このシナリオでは、メンテナンスウィンドウでこの中断を処理し、独自のサイズ変更を処理するために異なるチームが必要になる場合があります。インスタンスタイプを変更する前に、Amazon EC2ドキュメントの「互換性のあるインスタンスタイプの考慮事項」を確認してください。
このセクションのステップ例では、AWS-ResizeInstance という Systems Manager Automation ドキュメントを使用して、アカウントとリージョンごとに適切なサイジングの推奨事項を実装します。このアプローチは、ほとんどの組織で一般的です。ほとんどの組織では、目的別に異なるインスタンスタイプが必要です。同じAWS-ResizeInstance
オートメーションドキュメントを使用して、単一アカウントおよびマルチアカウントのデプロイをターゲットにすることもできます。
-
にサインイン AWS Management Console し、Systems Manager コンソール
を開きます。 -
ナビゲーションペインの共有リソースセクションで、ドキュメントを選択します。
-
検索バーに AWS-ResizeInstance と入力し、検索結果から AWS-ResizeInstance を選択します。
-
[オートメーションを実行] を選択します。
-
オートメーションランブックの実行ページで、シンプル実行を選択します。
-
「入力パラメータ」セクションにInstanceId「」と「」と入力しますInstanceType。残りのデフォルト値はそのままにしておきます。
-
実行を選択し、オートメーションがインスタンスタイプを変更するステップを実行するのを 待ちます。
別のサイズ変更方法を検討する
起動テンプレートを使用してインスタンスをデプロイする場合は、起動テンプレートを適切なサイズのインスタンスタイプで更新し、インスタンスの更新を実行してインスタンスを適切なサイズのバージョンに置き換えることができます。
複数のアカウントとリージョンで適切なサイジングプロセスを使用する場合は、カスタム Systems Manager Automation ドキュメントを作成する必要があります。このドキュメントでは、複数のインスタンスをパラメータとしてフィードし、ターゲットインスタンスを同じ送信先インスタンスタイプに移行できます (たとえば、ソースインスタンスタイプに関係なく、t3a.medium に移行するすべてのインスタンス)。
Cost Explorer で前後のコストを確認する
リソースのサイズを適切に設定したら、Cost Explorer を使用して、適切なサイズ設定タグを使用してコストの前後に表示できます。リソースタグを使用してコストを追跡できることを思い出してください。複数のタグレイヤーを使用することで、コストをきめ細かく可視化できます。このガイドで説明する例では、ライツサイジングタグを使用して、すべてのターゲットインスタンスに汎用タグを適用します。次に、チームタグを使用してリソースをさらに整理します。次のステップでは、アプリケーションタグを導入して、特定のアプリケーションを運用する際のコストへの影響をさらに示します。
次の図は、組織のタグ構造を示しています。

運用チームが所有する本番稼働用ウェブサーバーのサイズを適切に設定するビジネスの例を考えてみましょう。Cost Explorer では、ライツサイジングタグは有効に設定され、チームタグは オペレーションに設定されます。この例では、適切なサイジング作業により、運用コストが 1 時間あたり 0.89 セントから 0.28 セントに削減されます。1 か月あたり 744 時間と仮定すると、適切なサイジング前の年間コストは 7,945.92 USD です。適切なサイズ設定を行うと、年間コストは 2,499.84 USD に削減されます。これにより、年間ワークロードコストが 68.5% 削減されます。これを大規模な組織全体に与える影響を想像してみてください。これはサンプル環境で行われ、インスタンスは主にアイドル状態であることに注意してください。本稼働環境では、10~35% の節約ができます。
次に、エンジニアリングチームが所有する本番稼働用踏み台ホストの適切なサイジングの影響を検討します。Cost Explorer では、ライツサイジングタグは有効に設定され、チームタグはエンジニアリングに設定されます。この例では、適切なサイジング作業により、1 時間あたり 0.75 セントから 0.44 セントのコストを削減します。1 か月あたり 744 時間と仮定すると、適切なサイジング前の年間コストは 6,696.00 USD です。適切なサイズ設定を行うと、年間コストは 3,928.32 USD に削減されます。
複数のタグを使用する場合は、データを詳細なコスト詳細に絞り込むことができます。この例では、チームタグはノイズを減らし、チームレベルで影響を表示できるようにします。ライツサイジングタグが有効になっているため、そのタグの値が有効なインスタンスまたは値が存在しないインスタンスをフィルタリングすることもできます。これにより、特に Cost Explorer レベルで管理アカウント (支払者) で表示した場合、適切なサイジング作業をグローバルに表示できます。このビューでは、すべてのアカウントとインスタンスを表示できます。
Rightizing タグが有効に設定されている単一アカウントレベルでの例を考えてみましょう。 運用コストは 1 時間あたり 1.64 USD から 1 時間あたり 0.72 USD に減少します。1 か月あたり 744 時間と仮定すると、適切なサイジング前の年間コストは 14,641.92 USD です。適切なサイズ設定を行うと、年間コストは 6,428.16 USD に削減されます。これにより、このアカウントのコンピューティングコストが 56% 削減されます。
適切なサイジングジャーニーを開始する前に、次の点を考慮してください。
-
AWS には、コスト削減のための多くのオプションがあります。これには AWS OLA
が含まれます。 は、移行する前にオンプレミスインスタンス AWS を確認します AWS。では、適切なサイジングに関する推奨事項とライセンスガイダンス AWS OLAも提供されます。 -
Savings Plans
を購入する前に、適切なサイジングをすべて完了してください。これにより、Savings Plans コミットメントでの購入超過を回避できます。
レコメンデーション
次のステップを実行することをお勧めします。
-
既存のランドスケープを確認し、Amazon gp2 EBS ボリュームを gp3 ボリュームに変換することを検討してください。
-
Savings Plans
を確認します。
追加リソース
-
AWS Compute Optimizer
(AWS ドキュメント) -
AWS リソースのタグ付けのベストプラクティス (AWS ホワイトペーパー)
-
(YouTube) AWS Compute OptimizerAWS Trusted Advisor との間でデータを収集する方法 AWS Organizations
-
パフォーマンスの最適化とライセンスコストの削減: Amazon EC2 SQL Server インスタンス AWS Compute Optimizer の活用
( AWS ブログの Microsoft ワークロード)