この記事は株式会社LIFULLのAdventCalendar2024の25日目の記事です。
メリークリスマス
背景
LIFULLでは、LIFULL HOME'Sをはじめとする多くのサービスで、k8sをベースとして自社で構築している内製PaaSであるKEELを利用しています。
一方で、アプリケーションからインフラまで統合的に管理する目的で、サービス部門でAWSアカウントを保有し開発・保守を続けているケースも存在します。
少しずつKEELへの移管も進めつつ、ビジネスの状況、システムの要件に合わせて、バランスをとっています。
私が現在担当している部門では、全社でもかなり規模の大きなAWSアカウントを管理しています。
平時からコスト削減に取り組んでいるのですが、11月〜12月で大掛かりなコスト削減を進めたので、同じ用にAWSコスト削減される方へ参考となる知見があればと思い、今回やったことを記録がてら書き残します。
3行まとめ
- サービスごとの費用を、時系列で可視化するのが基本であり最重要
- 金額の大きなものから、リソースレベルへ分解し、不要なものは削減する
- AWSの仕様変更、料金体系変更もあるので、定期的に行うのが重要
サービスごとの費用を時系列に可視化
散々言い古されていることですが、まずはCost Explorerからサービスごとの費用を確認します。
Cost Explorerから、CSV形式でDLできるので、Excelなどで好きに分析してみましょう。
私の場合は、過去に連続でコストの低かった4ヶ月を見つけ、それと直近2ヶ月でどの程度コストの変化があったのかを洗い出し、削減対象の候補を絞り込みました。
ここで特記したいのは、VPCのコストが0.29%→2.56%と大きく増えている点です。
直近2ヶ月では全体の2.56%なので、特にコストが大きな領域ではないのですが、もともとの費用感を考えると異常な増え方をしていると言えます（変化率だと887%）。
後述するAWSの仕様変更に気づくきっかけとなったのですが、直近費用において占める割合だけでなく、基準時点を定めたうえで変化量を見るというのは一つ重要な視点かと思います。
サービスレベルの費用をリソースレベルへ分解
AWSの課金体系は基本的にリソース単位での従量課金です。
ですが、すべてのサービスをリソースレベルで分析・検討するのは現実的でありません。
コスト削減にも工数（つまりはコスト）がかかるので、工数対効果を最大化する必要があります。
その観点で、先程のステップを経て注力するサービスを6つに絞り込み、さらに使用タイプごとに同じ分析を行いました。
リソースレベル＝インスタンスレベルで分析できるのがベストとは思うのですが、それはそれでデータ量が増えすぎて扱いづらいので、この粒度くらいがちょうどいいと個人的に思っています。
この分析結果から、コスト削減の具体的なネタを生み出すことができました。
RDSのコスト削減
表で黄色にした部分は、RDSの費用に関する仕様をチーム全体で勘違いしていたことが原因でした。
「RDSは停止していれば費用がかからない」と思い込んでしまっていたのですが、実際には停止していてもストレージ容量に応じて費用がかかります。
EC2が停止していれば費用がかからない、という点からの誤解だったと思うのですが、EC2に関してもインスタンスに紐づくEBSが存在すれば停止していてもRDSと同様コストがかかります。
-
停止した DB インスタンスに対してどのように請求されますか? - Amazon RDS の料金
- データベースを停止している間でも、プロビジョニングされたストレージ (プロビジョンド IOPS を含む) やバックアップストレージ (指定した保持期間内の手動スナップショットや自動バックアップを含む) に対して課金されます。ただし、DB インスタンス時間に対して料金が発生することはありません。
-
Amazon EC2 システムの請求開始と終了のタイミングはいつですか? - Amazon EC2 よくある質問
- 停止後のインスタンスに対して時間単位の使用料金やデータ転送料金が課金されることはありませんが、Amazon EBS ボリュームのストレージについては課金されます。
VPCのコスト削減
表のなかで赤くした部分ですが、こちらが冒頭で触れたVPCコスト増加の正体でした。
2024年2月1日からパブリックIPv4アドレスに対して課金されるようになりました。
-
パブリック IPv4 アドレスの利用に対する新しい料金体系を発表
- 2024 年 2 月 1 日より、特定のサービスに割り当てられているかどうかに関わらず、すべてのパブリック IPv4 アドレスの利用に対して 1 IP アドレスあたり 0.005 USD/時間 が課金されます
これまで気にすることができていなかったのですが、サブネットのIPアドレス指定属性がtrueになっているものが多く、全く利用していないパブリックIPv4アドレスが大量にありました。
最後に
他にも、CloudWatchで保持期間を指定できていないロググループがあったり、もう使われていないリソースがいくつか見つかったりといいお掃除になりました。
平時からコストを意識してはいるのですが、どうしても新規リソースに目が向きがちだったなと反省です。
今回は具体的な解消手段にはあまり触れていないのですが、分析だったり仕様の再確認だったりと、同じような取り組みをされる方の参考になれば幸いです。