こんにちは！小林と申します。この間、九州縦断旅をしたのですがどこに行っても温泉があって毎日のように温泉に入れて幸せでした。つい先日、社内のAWS・GCPのインフラコストの削減施策を担当いたしました。この経験を通じて、コストがどこで発生し、どのようにそれを削減できるかについて深く理解する機会を得ました。そこで、これらの知見を共有し皆さんが同様の課題を抱えてしまった際の参考になることを目指して、今回ブログで紹介させていただきます。

当社では、開発チームがAWSやGCPについて自由に検証できるよう、検証用アカウントを提供しています。しかし、このような自由度の高い環境では、不要なリソースが放置され、それが過剰なコストとなってしまうという問題がありました。特に、高価なインスタンスが利用されていないのにも関わらず、起動し続けられていることがしばしばありました。

これらの問題に対応するため、以下の2つの施策を当初の目標として設定し、コスト削減に取り組みました

利用金額が一定の閾値を超えた場合に、その情報を通知する仕組みを導入し、過剰なリソースの使用を抑制する。
週末や使用が予想されない時間帯に、リソースを自動的に停止する機能を追加し、無駄なコストを削減する。

以上の施策により、リソースの最適化とコスト削減を達成することを目指しました。

調査

実際の取り組みへの着手前に、現状のコストが何に発生しているのかを詳細に調査し、インスタンス以外にもコスト削減の余地がないか探ります。AWSとGCPの両方で調査を実施しました。

AWS のコスト

CostExplorerを利用して施策前のコスト分布を確認しました。たとえば、2023年3月時点の当社のコスト内訳を見ると、EC2インスタンス関連のコスト(EC2インスタンス、EC2その他)が月額コストの50%を占めていることが分かります。したがって、まずはEC2インスタンスに対して今回の施策を適用するのが有効であると推察できます。さらに、「EC2その他」という項目も非常に高額であることが明らかになりました。この項目には、EIP（AWS Eastic IPアドレス）やEBS（Amazon EBS）が含まれます。

EIPやEBSはインスタンスが停止している場合でも課金が発生し続ける特性を持っています。それゆえ、使用されていないEIPやEBSが存在する可能性も考慮に入れるべきです。この結果を踏まえ、AWSについては、インスタンスだけでなくEIP・EBSについても棚卸し等の施策が必要となりそうです。

図1

GCP のコスト

続いて、GCPのコスト状況についても確認します。 GCPについても全体のコストのうち半分ほどがCompute Engine(図2のグラフ青色部分)によって占められています。 AWSと同様にインスタンスに対する削減施策を実施する必要がありそうです。

図2

実施項目

調査結果から、当初の目的であったインスタンスのコスト削減施策が有効であると考えられました。さらに、AWSではEBSの棚卸しも行うことを決定しました。したがって、今回の取り組みは以下の3点となります。

インスタンス自動起動停止の仕組み作り
- 土日にインスタンスを自動で起動・停止できるようにし、インスタンスの管理を容易にする。
インスタンスごとの利用料金を監視・通知
- インスタンスごとの利用料金を算出する仕組みを整え、規定値を超えた場合に通知するシステムを導入する。
EBS(ボリューム)の棚卸しを実施
- あまり使用されていないインスタンスにアタッチされているEBSボリュームを確認し、必要ないものは削除する。

次に、それぞれの取り組みについて詳細を説明します。

インスタンス自動起動停止ツール

まず、インスタンスを自動的に起動・停止する手段について考えてみましょう。 AWSのインスタンス自動起動停止には一般的に、Amazon EventBridge + Lambda、EventBridge Scheduler、またはInstance Schedulerのようなアーキテクチャが用いられます。 GCPではデフォルトでインスタンススケジューラを設定できます。

しかし、これらのアーキテクチャでは、新たにインスタンスを作成するごとにスケジュールを設定する必要があり、これが開発者の負担となってしまいます。理想的には、ユーザがインスタンスを作成した際に、自動的に設定された自動起動・停止される仕組みが欲しいです。そこで今回は、スプレッドシートとGASを用いてインスタンスの自動起動・自動停止するツールを開発し、それを利用することにしました。スプレッドシートを利用する利点としては、ユーザが使い慣れていることと、一覧性があり、管理しやすいという点が挙げられます。

また、今回作成するツールには自動起動・停止するだけでなく、より管理しやすくするため、以下のような機能を追加しました。

インスタンスの利用者名を記載する
- 誰が責任を持ってインスタンスを利用しているのかを明確にする
インスタンスの起動時刻を記載する
- 起動状態で長期間放置されていないかをチェックする
インスタンスタイプを表示する
- 長期間稼働しているインスタンスが高額なものでないかを確認する

ツールの使い方・仕様は、以下の通りです。

定期的に一覧を自動更新する常に最新のインスタンス状況が確認できるようにする
ユーザが手動でインスタンスリストを更新できるようにする追加したばかりのインスタンスについて、手動で更新し、すぐに設定できるようにする
自動起動・自動停止欄にチェックをつけることでそれぞれ定時に自動で実施される
インスタンス作成時のデフォルトでは自動停止のみチェックされるインスタンスの停止忘れによる無駄な課金を防ぐ

以下は作成したツールのイメージです。

図3

最後に、ツールの作成手順を簡単に説明します。

インスタンスを管理するためのIAM/サービスアカウントを作成するただし、アカウントは誰でも利用できる状態になるので、必要最低限の権限のみを付与します。
スプレッドシートとGASを作成するスプレッドシートは図を参照ください。今回、 GASの作成には、以前当社のブログでも紹介されたClaspを利用しました。(参考：リンク)
トリガーを設定する今回GASを起動するトリガーとしては、自動起動(定時にインスタンスを起動する)・自動停止(定時にインスタンスを停止する)・更新(インスタンス一覧を更新する)を用意しました。

インスタンスごとの利用料金を監視・通知

インスタンスごとの利用料金を監視・通知するためにどのような技術を利用したかをAWS・GCPそれぞれ紹介します。

AWS の場合

AWSにおいて、インスタンスごとの利用料金を把握するためには、コスト配分タグの利用が効果的です。設定したタグを利用して、以下のような内訳を確認可能です。ただし、コスト配分タグを利用する際は以下の点に注意してください。

利用できるのはOrganizationsの管理アカウントのみ
タグの有効化には1日程度かかる場合がある
月の途中でタグを付与した場合、その月の残り期間はタグ未付与とみなされる。

次に、コストの通知について説明します。今回は、AWS LambdaとSlackを組み合わせて通知機能を実現しました。具体的な開発方法については、以下の参考記事などをご覧ください。 https://dev.classmethod.jp/articles/notify-slack-aws-billing/

なお、今回設定した通知の閾値は当社での利用額に対して、少し大きめの額で設定しました。あくまで異常な課金の発生を発見するために設定した値となります。

GCP の場合

GCPはAWSと異なり、コスト分配タグのような機能がないため、Compute Engineに設定できるラベルを用いることにしました。ラベル付は、インスタンス自動起動停止ツールのGAS内で自動に行いました。ラベル付された結果は、課金のレポートから確認ができます。ラベル付にはこちらのAPIを利用しました。

EBS 棚卸し

EBS（Elastic Block Store）ボリュームとは、EC2インスタンスに接続され、データを永続的に保存するためのブロックレベルのストレージデバイスです。EC2インスタンスから物理的に分離されているため、インスタンスを停止または終了してもデータは保持されます。EBSボリュームは確保した容量に対して料金が発生します。そのため、長期間使用されていないインスタンスに接続されているEBSボリュームでも、料金は継続的に発生します。

このような背景から、以下の条件を満たすEBSボリュームについては棚卸しを実施しました。

利用されてから1年以上経過していること
容量が100GiB以上であること

具体的な棚卸しの手順は次の通りです。

対象となるEBSボリュームがアタッチされているインスタンスの利用者に連絡をする
EBSボリュームのスナップショットをとる
EBSボリュームをデタッチする　もしくは　インスタンスを削除する
EBSボリュームを削除する

なお、スナップショットを作成しないとデータは完全に復元できなくなります。したがって、データの保持が必要な場合はスナップショットの作成を忘れないようにしてください。

まとめ

結果

EC2インスタンスの利用料金については、月ごとの使用状況により大きく変動するため、7月度は高額になってしまいましたが、5月と6月では施策導入前よりも大幅に低く抑えることができました。また、特にEC2その他のコストについて、EBSの棚卸しとともにEIP（Elastic IP）についても棚卸しを実施した結果、当初の半額程度まで削減できました。 GCPについては、Compute Engineの使用料が一定水準を保っており、大幅なコスト増は抑えられていると言えます。特に注目すべきは、EC2のその他のコストです。これは長期間放置されているとかなり高額になるため、今まで特に組織的に棚卸しをしていなかった分削減効果が大きくなりました。

振り返り

この施策を通じて、ツール自体の効果以上に、それぞれのリソースがどれほどのコストを生じているかを理解し、自分自身でコストに対する意識を持つことができました。さらに、今回の試作を通して運用面での課題も明らかになりました。

定期的な棚卸しの必要性
- 年単位で放置されているようなリソースが存在し、その所在が分からないものもあります。そのため、棚卸しの手順を繰り返し行えるように準備する必要があります。
アカウントの管理方法の課題
- 検証用アカウントを共用する方式では、誰がどのリソースを使用すればよいのか判断が難しいです。これに対する対策として、タグ付けのルール化などが考えられますが、検証用アカウントに多くのルールを設けるとメンバーへの負担が大きくなります。ユーザー個人ごとに検証用アカウントを発行する手段もありますが、管理が複雑化するなどの課題もあります。

また、自身でコスト削減を試みるだけでなく、Trusted Advisorのようなツールを利用する手段も検討できます。

この施策を通じて得られた新たな学びは多いです。今後は、より効率的なコスト管理を実現するために、システムを整備していきたいと思います。