ふたつの観点で AWS のコストを最適化する
2024年09月11日 水曜日
CONTENTS
クラウドソリューション部の荒木です。今回は AWS 環境の管理者が知っておきたい、AWS のコストのお話です。
AWS のコスト最適化について
コスト最適化は、コスト削減と似て非なるものです。クラウドアーキテクチャの主要な概念やベストプラクティスが提供されている AWS Well-Architected Framework では、不要なコストの回避や適切なリソースタイプとサイジングの選択によって、システムコストの最小化とビジネス成果の達成を図る旨が解説されています。この記事では、アプローチの起点となる 2 つの観点と、それぞれのアプローチをサポートする AWS サービスをご紹介します。
観点①：リソースの削除/停止によるコスト削減
（当たり前の話ですが）ひとつめの観点は「不要なリソースを洗い出して削除/停止する」というアプローチです。ほとんどの組織では AWS アカウントの利用ルールを定めて運用されていると思います。しかし、検証の自由度を確保する反面で、不要になったリソースや自動で作成されたリソースの削除忘れが放置されてしまうことは往々にして起こります。
- 念のため取得したインスタンスやボリュームのスナップショットのコストが “ちりつも” で発生し続けている
- AWS 環境で複数人が作業しているため、個別のリソースの利用状況や要否が把握しきれない
という状況をご存じの方も多いのではないでしょうか。このような事態を避けるには、定期的に棚卸を行い、不要リソースを削除/停止する対応が必要です。
観点②：リソースのコストパフォーマンス最適化
ふたつめの観点は「システムに必要なリソースを過不足なく調達する」というものです。AWS では日々新たに、より低価格で高性能なリソースタイプが発表されます。そのため、設計時には最善だった選択も、運用期間の経過に伴い最適でなくなっていく可能性が多分にあります。クラウドに構築されたシステムは、リソースタイプが最適な種類であるか、という確認と調整を定期的に実施していく必要があります。
- システムは、確保したリソースをうまく使い切れているでしょうか？
- インスタンスのメモリや CPU、ボリュームのサイズや IOPS のスペックは、システムの稼働に最適でしょうか？
この観点で改善を行うには、システムのメトリクスから稼働状況を読み取り、サイジングの余剰や不足のインサイトを得て、より適したリソースタイプを比較検討する必要があります。
「削除/停止」と「最適化」のそれぞれをサポートする AWS サービス
上記のいずれのアプローチも、改善箇所の検出や判断をマンパワーで解決しようとするとなかなか大変です。そこで、AWS ではこれらの作業に便利なサービスを提供しています。
リソースの削除/停止：AWS Trusted Advisor で不要なリソースを検出する
AWS Trusted Advisor は、数ある AWS サービスの中でも古くから提供されているサービスです。個別の AWS アカウントに対して「コスト最適化」「パフォーマンス」「セキュリティ」「耐障害性」「サービスの制限」「運用上の優秀性」の観点で（つまり AWS Well-Architected Framework のベストプラクティスをもとに）評価し、推奨事項を提供します。コスト最適化のチェック項目ではアカウント内のリソースやメトリクスを分析し、「これ本当に必要ですか？」というアドバイスを提示してくれます。
チェック項目の一例を挙げると、コスト削減につながる事項が多いことがわかります。（以下は有料プランの項目を含んでいます）
- CPU 使用率の低い Amazon EC2 インスタンスを特定し、停止もしくは削除の検討を推奨する
- 停止したままの Amazon EC2 を特定し、削除の検討を推奨する
- 活用されていない Amazon EBS ボリュームを特定して、削除やダウンサイジングを推奨する
- リソースに関連付けられていない Elastic IP Address を特定し、開放の検討を推奨
- アイドル状態のロードバランサーを特定し、アクティブ化（Amazon EC2 の登録）の検討や削除を推奨する
AWS Trusted Advisor は他の AWS サービスと比べると特殊な料金体系となっており、 AWS アカウントのサポートプラン の一部として提供されています。サポートプランのグレードによって提供される機能が異なりますが、利用自体に料金は発生しません。無料のサポートプランでも一部の機能を利用できます。
AWS Trusted Advisor の使い方
AWS Trusted Advisor がどのように使えるのか、有料プランを利用しているマネジメントコンソールで確認してみます。
各カテゴリーごとのチェック項目が評価され、推奨アクションの優先度で分類されています。
一例として、チェック項目の詳細を見てみます。利用頻度の低い Amazon EBS ボリュームに対して、スナップショットの作成と削除の検討が推奨されています。対象となるボリュームも個別にピックアップされており、ID のリンクから詳細画面に直接飛べるので、効率的に確認することができます。
こちらもチェック項目の一例です。リソースに関連付けられていない EIP をピックアップしてくれています。（マスキングで隠れていますが）IP アドレスのリンクから詳細を確認し、不要であればアドレスを開放することでコストが削減できます。
このように、AWS Trusted Advisor は AWS Well-Architected Framework のベストプラクティスに沿った推奨事項を提示してくれます。また、コスト最適化以外の観点でもチェックしてくれるので、例えば「アカウントのセキュリティ状況の改善箇所を知りたいが、サービス全体のベストプラクティスは追いきれない」というような場合などにも強力なサポートを得ることができます。
リソースの最適化：AWS Compute Optimizer でインサイトを比較検討する
AWS Compute Optimizer は、コストとワークロードパフォーマンスの最適化をサポートするサービスです。使用中のリソースの Amazon CloudWatch メトリクスを集計し、人工知能と機械学習による分析によって、サイジングの過不足やコスト効率の改善が期待されるリソースタイプを推奨してくれます。
分析対象としてサポートされているサービスは、執筆時点で以下になります。
- Amazon EC2 インスタンス
- Amazon EC2 オートスケーリンググループ
- Amazon EBS ボリューム
- AWS Lambda 関数
- コンテナサービスの Amazon ECS と AWS Fargate
- Amazon RDS DB インスタンスとストレージ
- Amazon EC2 の商用ソフトウェアライセンス
AWS Compute Optimizer は無料で利用することができます。一部有料の機能として、Amazon CloudWatch メトリクスの集計（ルックバック期間）をデフォルトの 14 日間から最大 93 日まで拡張することができます。
AWS Compute Optimizer の使い方
AWS Compute Optimizer についても使いかたを確認してみます。といっても特に必要な操作はありません。マネジメントコンソールでサービス画面に遷移すると、ダッシュボードでサマリーを表示してくれます。左ペインで各サービスを選択し、詳細が確認できます。
Amazon EC2 に対する推奨事項を見てみます。起動中の t3.large インスタンスの利用状況から、置き換えが推奨されるインスタンスタイプのオプションが表示されています。このオプションは最大 3 つまで表示され、価格の差だけでなく、置き換えた場合にパフォーマンス要件を満たさない可能性のリスクや、移行にかかる労力レベルなども提示してくれます。また、このインスタンスで使用している Amazon EBS ボリュームに関しても、サイジングが過剰であることを検出していました。
推奨インスタンスを見比べてみました。オプション 1 のインスタンスタイプに置き換えた場合、 現行のインスタンスタイプとほとんど変わらない CPU 使用率でワークロードを処理できると予想され、かつオプションのなかで最大の節約額が見込まれるようです。
オプション 2 では CPU 使用率が大きく低減すると予想されています。節約額はオプション 1 より若干劣りますが、システムの需要が今後伸びる見込みであれば、この選択肢が最もバランスが良いように思われます。
オプション 3 も CPU 使用率が大きく低減すると予想されていますが、節約額はオプションの中で最も低い見込みとなりました。
このように、現在起動中のインスタンスメトリクスに対して推奨インスタンスに変更した場合のメトリクス推移も併せて提示してくれるため、スペック値だけの比較や感覚的な指標よりも具体的なデータで選定を進めることができます。システムが今後どのように利用されていくか、という想定があれば、より効率的に検討を進めることができそうです。
今回は検証環境で動いているリソースが少なかったため Amazon EC2 のみのご紹介でしたが、Amazon ECS や AWS Fargate でも同様に CPU やメモリサイズの推奨を受け取ることができます。また AWS Lambda では、メモリサイズの推奨やそれに伴う実行時間の比較などをもとに推奨事項を受け取ることができます。
2024/09/13 追記：ご紹介したインスタンスタイプの比較ですが、 a シリーズ（t3a）と g シリーズ（r6g、r7g、t4g など）は CPU アーキテクチャが異なるため、移行する場合はインスタンス上のソフトウェアを再度コンパイルすることを検討する必要があります（リファレンスはこちらです）。また、CPU アーキテクチャのほか、ハイパーバイザーやネットワークインターフェースなど、推奨されるインスタンスのプラットフォームが現行のインスタンスと異なる場合は、レコメンデーションの「プラットフォームの違い」の項で確認することができます。情報不足をお詫びいたします。
おわりに
リソースの「削除/停止」と「最適化」の観点から、AWS のコスト最適化をサポートするサービスについてご紹介しました。記事の編集にあたり、コスト最適化とは利用している AWS 環境のコストとパフォーマンスのバランスを最適化すること、また最適化させ続ける取り組みなのだな、と理解できました。この記事が少しでもどなたかのお役に立ちましたら幸いです。