はじめに
近年AWSの利用料は円安の影響もあり上昇傾向にあります。
企業が利益を上げるには売上を伸ばすか、コストを削減する必要があります。このコスト削減に大きく貢献できるのが、AWSコスト最適化です。
この記事では難しい話はしません。
コスト最適化の第一歩として私が実際に実践したことを中心にお話できればと思います。
ぜひ最後までご覧ください。
AWSコスト最適化の進め方（理想）
コスト最適化は、CFMフレームワークに従って実践することが推奨とされています。
Cloud Financial Management (CFM)フレームワーク
しかし、上記フレームワークを実践するには多くのステークホルダーの協力や組織的な体制構築が不可欠です。
そこで、私はCFMフレームワークの中でも特に即効性が期待できる「クイックウィン最適化」から着手することにしました。
クイックウィン最適化
クイックウィン最適化とは短期間かつ、アーキテクチャに変更を伴わない方法となります。
例を以下に記載します
- インスタンスサイズの適正化
- 未使用リソースの削除
- 稼働時間の見直し
中でもお客様の環境ではEBSボリュームの利用料が高いことがわかっていたので、EBSボリュームにフォーカスして最適化を実践することにしました。
不要EBSボリュームの削除
調査
まずは不要なEBSボリュームをリストアップすることから始めました。
リストアップする条件としては以下となります
- Statusが「Stopped」になっているEC2インスタンス
- AvailableなEBSボリューム
まず1つ目のStatusが「Stopped」になっているEC2インスタンスは、計画的に「Stopped」になっている場合は問題ありません。
しかし、使用しなくなったEC2が「Stopped」で残っているケースもあります。
この場合EC2に対しては利用料はかかりませんが、アタッチされているEBSボリュームに対しては利用料がかかります。
EBSボリュームはプロビジョニングされたストレージ容量に対して課金されるためです。
そのため、使用しなくなったEC2がある場合はアタッチされているEBSボリュームを削除する必要があります。
次に2つ目のAvailableなEBSボリュームは、どのリソースに対してもアタッチされてないものになります。
後にアタッチする予定があるのであれば問題ありませんが、そうでなければ削除する必要があります。
CloudShellでリストアップ
- Statusが「Stopped」になっているEC2インスタンス
aws ec2 describe-instances --filters "Name=instance-state-name,Values=stopped" --query 'Reservations[*].Instances[*].[State.Name, InstanceId, PrivateDnsName]' --output text > stopped_instances_hostname_id.txt
- AvailableなEBSボリューム
aws ec2 describe-volumes --filters Name=status,Values=available --output table --query 'Volumes[*].{VolumeId:VolumeId,Size:Size,VolumeType:VolumeType,AvailabilityZone:AvailabilityZone,CreateTime:CreateTime}' > ec2_status_volumes.csv
なるべく楽にリストアップしたかったので、CloudShellでコマンドを実行しました。
削除作業
リストアップしたリソース一覧をインフラ担当者に提出し、削除可否をヒアリングします
削除可能のリソースのみ手順を作成し、削除作業を実施しました。
※手順は環境によって異なりますので割愛します
EBSボリュームタイプ変更
EBSボリュームタイプをgp2 → gp3に変更します
gp2とgp3の料金は以下となります
- gp2 月あたり約0.10/GB
- gp3 月あたり約0.08/GB
移行すれば約20％のコスト最適化が可能となります
※一部移行できないケースもありますので、制約条件は以下を参照してください
https://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/modify-volume-requirements.html
調査
調査は「Compute Optimizer 」を使用すると楽にできます。
レコメンデーションにEBSボリュームがあるのでそこを選択するだけで様々な情報が表示されます。
この中から最適化されていないかつ、ボリュームタイプが「汎用SSD（gp2）」を参照します
※以下画像は例であり、すべて最適化されています
gp2 → gp3に変更する際の推奨パラメーターも表示されるので、この情報をリストアップしインフラ担当者にヒアリングを実施します。
変更作業
インフラ担当者にヒアリングを実施し、変更可能なEBSボリュームのみ変更していきます。
こちらも詳細な手順は割愛しますが、主な作業手順は以下となります。
- 事前にバックアップを作成
- コンソールからパラメーターを記載しgp2 → gp3に変更
- 動作確認
ダウンタイムは発生せずオンラインでの実行が可能です。
ボリュームサイズが大きいと時間はかかりますが、作業自体はとても簡単です。
削減効果
まず最適化を実施したリソースは以下となります
- 不要なEBSの削除：292リソース
- EBSボリュームタイプ変更：15リソース
以下に対象アカウントのコストと使用状況レポートを添付します
コストの大半を占めていた「EC2 その他」が大幅に削減され、月額だと約33万円削減されていることがわかります。
※EC2 その他はEBS、Elastic IP、Load Balancersが含まれます
まとめ
コスト最適化は実施したその日から積み重ねで効果を発揮します。
そのため、まずは素早く着手できそうなクイックウィン最適化から実践しました。
AWSコスト最適化をしたいけど何から始めたらいいかわからない方に、この記事が参考になれば幸いです。
簡単30秒