AWS不要なリソースの削除を対応したのお話

はじめに

こんにちは。IT業界15年、Web系10年のアラフォーです。

以前エンジニアの仕事を中心にやって来たが、現在スペシャリストとチーム長として働いてます。
昨年の10月から、プロダクトソリューション部に異動し、現在SREチームでSREの取り組みを頑張っています。

SREの施策の一環として、インフラコストの削減を取り組んでいます。
当初、一つAWSのアカウント上で、月額10000ドル超えている状態から、現在月額約3000ドル未満になりました。
対応した内容はほぼ不要なリソースを削除しただけですが、コスト削減する際に、確認観点としてご参考になれば幸いです。

前提

弊社のサービスでは、現在すでに IaC (Infrastructure as Code)を導入しましたが、以前IaCという概念がなかったので、インフラの構築は全てコンソール上で手動で構築してました。
システムリニューアル後、リソースがそのまま残され、無駄なコストが課金されてしまった。
当初のインフラ担当者が既に離任したので、残されたリソースをそもそも削除できるか確認できないため、リソースの利用状況を確認しながらコスト削減を実施しました。

全ての内容ではないが、対応した時の確認観点を重点的にピックアップし、共有させていただきます。

確認観点

VPC

• 不要なNATゲートウェイが存在しているか否か
• 不要なVPCエンドポイントが存在しているか否か

EC2

• 不要なインスタンスがあるか否か
• 不要なLoad Balancerが残ってるか否か
• スケールダウン(イン)できるインスタンスが存在しているか否か
• 夜間や休日に停止可能なインスタンスあるか否か
• 不要なEIPが残っているか否か
• 不要なEBSスナップショットがあるか否か

RDS

• 不要なインスタンスが存在しているか否か
• スケールダウン(イン)できるインスタンスが存在しているか否か
• 夜間や休日に停止可能なインスタンスがあるか否か
• 不要なスナップショットがあるか否か
• バックアップの世代数が適切かどうか

ElastiCache

• 不要なバックアップあるか否か
• スケールダウン(イン)できるインスタンスが存在しているか否か

OpenSearch

• スケールダウン(イン)できるインスタンスが存在しているか否か

S3

• 不要なバケットが存在しているか否か
• ログ系、ライフサイクルなど設定しているか否か
• 不要なバージョニングをしているか否か
• 適切なストレージクラスを選択できているか否か

Cloudwatch

• ログの保持期間の設定が適切か否か
• 不要なダッシュボードが存在しているか否か
• 不要なアラームが存在しているか否か
• 使ってないリージョンが課金されるか否か

Route53

• 不要なHostedZoneが存在しているか否か

EventBridge

• 不要なイベント存在しているか否か

ECS

• タスクのスペック適切になっているか否か

上記の内容を見ると、当たり前の事しかやってないと思いますが、当初、IaC化していないとの事と、担当者が既に離任しているので、リソースの状況を確認し、情報を整理し、他の部署と連携を取りながらコスト削減を実施しました。すごく苦労しました。
こういったゴミ掃除やコスト削減を今後楽に対応できるように、どうすれば良いかのを改めて考えてみました。

対策

環境毎、アカウントを分ける

今回対応したアカウントは、開発環境、検証環境、及び実際にお客様にサービスを提供している本番環境、全て同じのアカウントに構築された。
そのために、今回不要なリソースを削除した時に、そのリソースはどの環境のリソース、削除しても本当に大丈夫かとの確認が少し苦労しました。
もし、環境毎、アカウントを分けていれば、本番環境以外の対応は誤削除してもお客様への影響がないため、対応のスピードが速くなり、判断ももっとシンプルになると思います。

IaC化

冒頭でも伝えましたが、当初まだIaC化の概念が導入されていないため、全て手動対応で構築された。そのため、削除対応した時も、全て手動で行なって、かなり大変な作業になっています。
IaC化することで、リソースの変更をコード上で確認できますし、削除の対応もかなり楽になります。

タグ付け

タグ機能をうまく運用すれば、リソースをカテゴライズし、機能毎分類できます。
また、コストを確認する際に、タグで絞る事ができ、機能毎、どれぐらい料金かかるのも把握しやすくなります。

世代管理を適切に

今回の対象アカウントはかなり長く運用しているので、5年前以上のログやバックアップも残っているし、おそらく、そのログやバックアップも全然使われていない。
もし、最初に世代管理を設定していれば、バックアップの料金もかなり抑えられるし、わざわざゴミ掃除を対応しなくても済みます。

定期的に棚卸し

手動でバックアップしたRDSスナップショットやEC2スナップショットなど、自分で削除しないと、ずっと課金され続けてしまうので、定期的に確認し、不要なバックアップを削除しましょう。

検知の仕組みを導入

AWSコスト異常検出(AWS Cost Anomaly Detection)を導入することで、意図していない利用料の増加を早めに検知することができます。
また、AWS Budgetsを設定することで、AWS利用料金をモニタリングし、予算超えてしまったら通知され、早めに対策を打つことができます。

マインド

自分にとって、一番重要なのは、マインドです。
仕組み上で検知や防ぐ事ができると思いますが、もし最初に構築する際に、過剰なスペックをしないように、一時的に検証で立てたリソースを忘れず削除するように、世代管理をきちんと考えるようにすれば、そもそもこういったゴミ掃除の対応は不要になるかもしれませんね！

最後

今回のAWSコスト削減の対応は、ほぼ不要なリソースの削除を対応しただけですが、意外とそのまま放置してしまったら、無駄に課金され続けてしまうので、きちんと意識しましょう！
AWSコスト削減する際に、ご参考になれば幸いでございます。