AWS Well-Architected Framework 入門：持続可能性の柱を Compute Optimizer + リソース棚卸しで実践してみた

はじめに

こんにちは。クラスメソッドオペレーションズの藤瀨です。

Well-Architected Framework ハンズオンシリーズの第 7 回です。

• 第 1 回 Well-Architected Framework の概要
• 第 2 回 オペレーショナルエクセレンスの柱
• 第 3 回 セキュリティの柱
• 第 4 回 信頼性の柱
• 第 5 回 パフォーマンス効率の柱
• 第 6 回 コスト最適化の柱

今回は「持続可能性（Sustainability）」の柱を扱います。他の 5 つの柱と比べると、2021 年に追加された比較的新しい柱で、環境負荷を抑えるためにリソースを無駄なく使うという視点が特徴です。

この記事では、以下の 2 点を筆者が作成したハンズオンを実践しながら体験します。

• AWS Compute Optimizer でリソースの使用状況を分析し、適正サイジングの推奨事項を確認する
• 放置しがちな未使用リソースを棚卸しする

本記事では、任意の手順を除いて新規にリソースを作成しないため、追加のコストは原則として発生しません。Compute Optimizer の標準機能自体に追加料金はかかりませんが、分析対象として EC2 インスタンスなどを継続稼働させる場合は、そのリソースの通常料金が発生します。

持続可能性とは

改めてこの柱の中身を整理しておきます。公式ドキュメントでは、持続可能性は「エネルギー消費と効率など環境への影響に着目し、リソース使用量を削減するための直接的な行動を導き出す視点」と説明されています。

この柱には 6 つの設計原則があります。

• 影響を理解する: ワークロードの影響を測定し、将来の影響もモデル化する
• 持続可能性の目標を設定する: トランザクション当たりの必要リソースを減らすなど、長期的な目標を立てる
• 使用率を最大化する: 適切なサイジングと効率的な設計で、ハードウェアの稼働効率を高める
• より効率的なハードウェアやソフトウェアの新製品を予測して採用する: パートナーや AWS 側の改善を継続的に取り込めるよう柔軟に設計する
• マネージドサービスを使用する: 多くの顧客で共有されるマネージドサービスを使い、全体のリソース必要量を減らす
• クラウドワークロードのダウンストリームの影響を軽減する: 自社サービスの利用に必要なエネルギーやデバイスの負荷を減らす

今回のハンズオンでは、この中でも「使用率を最大化する」という設計原則を中心に体感していきます。Compute Optimizer で適正サイジングの可能性を確認するとともに、使用率が低い、または使用されていないリソースを棚卸しします。

未使用リソースの棚卸しは、持続可能性の柱における以下のベストプラクティスにも関連します^[1]。

• SUS03-BP02: 使用率が低い、またはまったく使用しないワークロードのコンポーネントを削除またはリファクタリングする

具体的な手順

大まかな手順は以下のとおりです。

1. Compute Optimizer を有効化する
2. 推奨事項を確認する
3. 未使用リソースを洗い出す

前提条件

• 検証用に用意した AWS アカウントで実施し、本番環境では行わないこと
• 本記事の内容および画面表示は、公開直前に実際に確認した時点の AWS マネジメントコンソールの情報に基づくこと（コンソールの UI や項目名は更新される場合があります）
• 料金・節約額の表示には Cost Explorer の有効化が必要なこと
• 任意手順では EC2 と EBS の料金が発生すること

① Compute Optimizer を有効化する

AWS マネジメントコンソール上部の検索ボックスで Compute Optimizer を検索してクリックします。
初めて利用する場合は、Compute Optimizer のオプトイン画面が表示されます。内容を確認し、「オプトイン」または「Compute Optimizer を有効にする」を選択します。

この後の手順では、Compute Optimizer から EC2 インスタンスの推奨事項を確認します。

ただし、EC2 インスタンスの推奨事項を生成するには、過去 14 日間のうち少なくとも 30 時間分の CloudWatch メトリクスが必要です。また、必要なメトリクスが蓄積されたあとも、分析が完了して推奨事項が表示されるまで最大 24 時間かかる場合があります。

そのため、十分なメトリクスが残っている EC2 インスタンスが存在する場合は、そのインスタンスを確認してみましょう。
もしそのような EC2 インスタンスがなく、Compute Optimizer の推奨事項を確認したい方向けに、新しく EC2 インスタンスを起動して推奨事項を生成する方法の一例も紹介します。

② 推奨事項を確認する

Compute Optimizer のナビゲーションから「EC2 インスタンス」を選択します。

推奨事項を生成できる EC2 インスタンスがある場合は、インスタンスごとに分析結果が表示されます。
判定には以下の 3 つがあります^[3]。

• オーバープロビジョニング: 実際の使用状況に対して、リソースが過剰に割り当てられている可能性がある
• 最適化済み: 現在のリソース構成が、使用状況に対して適切と判断されている
• アンダープロビジョニング: 現在のリソースでは、性能が不足する可能性がある

上記「推奨事項を表示させるための EC2 インスタンス作成手順」で EC2 インスタンスを作成してから十分な時間が経過したのち、Compute Optimizer で推奨事項を確認したところ、以下のように「最適化済み」と表示されていました。

この結果からだけだと、現在の構成に問題がないように見えます。
しかし、インスタンス ID をクリックして詳細画面に移ると、以下の画面の通り「この EC2 インスタンスはアイドル状態です。」というメッセージが上部に表示され、不要な場合は削除するようにとの記載があります。

Compute Optimizer は、上記の 3 つの判定とは別に、対象リソースがアイドル状態かどうかも判定してくれます^[4]。
今回作成した EC2 インスタンスの場合は、「デフォルトの 14 日間のルックバック期間において、CPU 使用率のピークが 5% 未満であり、ネットワーク I/O が 5 MB/日未満」のときにアイドル状態と判断されます。
この場合の推奨アクションは、画面上でも確認できたように「このインスタンスが本当に必要かどうかを確認し、不要であれば削除を検討」とあります。
なお、リソースがアイドル状態かどうかは、Compute Optimizer の「アイドル状態のリソース」という項目からも確認できます。

このように、推奨事項が「最適化済み」となっている場合でも、アイドル状態となっており不要な場合は削除というアクションが必要になることもあるとわかりました。

また、レコメンデーションの詳細画面下部には、「適切なサイズ設定のオプション」という項目があります。

「現在」の行には、今回作成した EC2 インスタンスのインスタンスタイプである t3.small が表示されています。
表の右上の「CPU アーキテクチャの詳細設定」で「Graviton（aws-arm64）」を選択すると、「オプション 1」として t4g.small が提示され、約 20.62% の節約機会があることを確認できました。

推奨事項が「最適化済み」であるにもかかわらず、別のインスタンスタイプが表示されているため、一見すると矛盾しているように思えるかもしれません。
現在使用している t3.small は x86 アーキテクチャを採用しているのに対し、t4g.small は Arm ベースの AWS Graviton プロセッサを採用しています。つまり、これは同じ small サイズのまま、よりコスト効率の高い CPU アーキテクチャへ移行する場合の選択肢です。

「最適化済み」は、現在のインスタンスがワークロードの性能要件を満たし、オーバープロビジョニングとも判定されていないことを示します。CPU アーキテクチャとして「Graviton（aws-arm64）」を選択することで、現在のインスタンスと Graviton ベースの候補との料金および性能面の比較が別途表示されているというわけです。

なお、t3.small から t4g.small への移行では CPU アーキテクチャが変わるため、通常のインスタンスタイプ変更と同じように、そのまま置き換えられるとは限りません。実際に移行する場合は、以下のような項目が Arm64 に対応しているか確認する必要があります。

• 使用する AMI
• OS やミドルウェア
• アプリケーションとライブラリ
• 独自にビルドしたバイナリ
• 使用しているコンテナイメージ

今回の結果は、「現在のサイズに問題はないものの、より効率的なハードウェアへ移行できればコストを削減できる可能性がある」と読み取れます。

同時に、上述の通りこの EC2 インスタンスはアイドル状態とも判定されており、インスタンスの削除を検討するよう推奨されています。そのため、実際のワークロードでは、まずインスタンス自体が必要かを確認し、必要であれば Graviton への移行を検討する、という順序で判断するのがよいでしょう。

また、その他の推奨事項が表示された場合にも、すぐにインスタンスタイプを変更する必要があるとは限りません。Compute Optimizer の推奨事項は、あくまで過去のメトリクスに基づく判断材料です。

実際に変更する場合は、以下の点も考慮します。

• 一時的な負荷上昇が発生しないか
• 今後アクセス数が増加する予定はないか
• CPU 以外のメモリやネットワークがボトルネックになっていないか
• インスタンスタイプの変更がアプリケーションに影響しないか
• 可用性や復旧時間などの要件を満たせるか

持続可能性のためにリソースを削減する場合でも、必要な性能や信頼性を損なわないことが前提です。

③ 未使用リソースを洗い出す

続いて、これまでのハンズオンで作成したリソースを含め、不要なリソースの消し忘れがないか確認します。

対象の AWS Support プランを契約している場合は、前回のブログの手順③で見た通り、AWS Trusted Advisor の「コスト最適化」カテゴリから、以下のような項目を確認できます。

• アイドル状態のロードバランサー
• 関連付けのない Elastic IP アドレス
• 使用率の低い EC2 インスタンス
• 使用率の低い EBS ボリューム

Trusted Advisor のコスト最適化チェックは、AWS Support プランによって利用できる範囲が異なることに注意してください。

リソースの棚卸しの際には、以下の AWS 公式ブログも参考になります。
https://aws.amazon.com/jp/blogs/compute/10-things-you-can-do-today-to-reduce-aws-costs/

繰り返しになりますが、不要なリソースを見つけた場合もすぐに削除するのではなく、以下を確認します^[5]。

• 本当に使用されていないか
• バックアップや災害対策のために必要ではないか
• 削除した場合に復元できるか
• システムの性能や信頼性に影響しないか
• 所有者や作成目的を確認できるか

未使用リソースを削除することは、コスト削減だけでなく、管理対象の削減やセキュリティリスクの低減にもつながります^[6]。

使用したサービスと料金の考え方

今回使用したサービスと料金の考え方は以下のとおりです。

Compute Optimizer を有効化すること自体に追加料金はかかりません。ただし、有料機能である拡張インフラストラクチャメトリクスを有効にした場合や、CloudWatch のカスタムメトリクスを収集した場合は、別途料金が発生する可能性があります。
また、推奨事項を生成するために EC2 インスタンスを継続稼働させる場合は、EC2、EBS、パブリック IPv4 アドレスなどの通常料金が発生します。

クリーンアップ

検証が終わったら、以下の項目を確認してリソースを片付けてください。

• Compute Optimizer は有効化したままでも、標準機能については追加料金がかからないため、無効化は任意です
• Compute Optimizer の推奨事項を生成するために EC2 インスタンスを起動した場合は、インスタンスを終了（削除）してください
• 棚卸しで見つかった未使用の EC2 インスタンス、Elastic IP アドレス、EBS ボリューム、EBS スナップショット、ロードバランサーなどが不要であれば削除または解放します
• 使用した可能性のある別リージョンにもリソースが残っていないか確認します

リソースを削除する前に、必要なデータや設定が残っていないか確認してください。

おわりに

このブログでは、Compute Optimizer での適正サイジング分析と、未使用リソースの棚卸しを通じて、持続可能性の柱を体感しました。

これは、持続可能性の柱の設計原則である「使用率を最大化する」と、ベストプラクティスである「使用率が低い、またはまったく使用しないワークロードのコンポーネントを削除またはリファクタリングする」に関連する内容です。

Compute Optimizer に表示される節約見積額は、環境負荷を直接表すものではありません。しかし、使用率が低いリソースや過剰なキャパシティを発見するための一つの指標になります。
必要な性能や信頼性を維持しながらプロビジョニング量を減らすことは、コストと環境負荷の両面での改善につながる可能性があることを実感しました。

引き続き、次回はシリーズ最終回として、これまでの環境を AWS Well-Architected Tool でセルフレビューする予定です。

最後までお読みいただきありがとうございました！

クラスメソッドオペレーションズ株式会社について

クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、 IT・AI をフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイトをぜひご覧ください。
※2026 年 1 月 アノテーション㈱から社名変更しました。

参考リンク

• Sustainability Pillar
• Sustainability: Design principles
• Sustainability: Definition
• AWS Compute Optimizer の開始方法
• リソースの要件
• コスト最適化（Trusted Advisor チェックリファレンス）