5
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AWSリソース自動停止によるコスト削減を目指す

Last updated at Posted at 2025-10-27

はじめに

私は株式会社GENEROSITYのSREです。
組織の重要な課題としてコスト削減に取り組んでいます。

すでにRI(Reserved Instance)は購入済みでしたが、さらなる削減を目指すべく施策を検討しました。
同じようにコスト削減に取り組まれている方々の参考になれば幸いです。

※RI購入など、他にコスト削減に関する過去記事もございますので、併せてご参照ください。
【SRE】AWS運用コストを年間200万削減(見込み)を達成した話

施策実施前の状況と課題

現状

弊社では常時100を超えるAWSアカウントを運用しており、アカウントごとにAWSサービス構成は異なっています。
コスト最適化の観点から、すでにRIは購入済みでした。

課題

さらなるコスト削減を実現するため、以下の課題を解決する必要がありました。

  • 多数のアカウントに対して効果的な施策を展開したい
  • 継続的に効果を発揮できる仕組みを構築したい

課題解決に至るまでの検討プロセス

基本方針の策定

上記2つの課題を解消するため、営業時間外における自動サービス停止によるコスト削減を目指すこととしました。

システム要件の検討

当初は以下の要件でシステム構築を検討していました。

  • 営業時間内(平日9:00-00:00)のサービス自動起動
    • 前後にバッファを設定
  • 営業時間外(平日00:00-9:00、土日祝日)のサービス自動停止
  • 対象サービス:EC2、ECS、RDS(稼働時間に応じた課金体系かつ多くのアカウントで利用されているため)

運用上の課題と追加要件

しかし、実際の運用を想定すると以下の課題が想定されました。

  • 営業時間外でも緊急時にサービス起動が必要な場合への対応
  • 起動・停止状況のリアルタイム把握
  • セキュリティリスクの最小化(誤操作防止、認証情報の適切な管理)

これらを踏まえ、最終的なシステム要件を以下のように策定しました。

  • 営業時間内のサービス自動起動・営業時間外のサービス自動停止
  • 対象サービス:EC2、ECS、RDS
  • Slackコマンドによる手動起動・停止機能
  • 起動・停止結果のSlack通知
  • 各対象アカウント内への分散構築(セキュリティリスク軽減)

システム設計と実装

システムは以下の2種類のAWSアカウントで構成されます。

監視用アカウント

Slackコマンドを受け付け、各監視対象アカウントのシステムを制御する役割を担います。

  • API Gateway: Slackコマンドの受付
  • Lambda: コマンド解析および対象アカウントのStep Functions実行指示

各監視対象アカウント

サービス停止機構を自アカウント内にCDKでデプロイし、独立して動作します。

  • EventBridge Scheduler: 指定時間でのStep Functions実行
  • Step Functions: 以下のタスクを順次実行
    • 営業時間判定
    • 対象サービス(EC2、ECS、RDS)の状態確認
    • サービスの起動または停止実行
    • 結果のSlack通知
  • Lambda: 対象サービスの状態確認および起動・停止処理

システム構成図

監視用アカウント

各監視対象アカウント

スクリーンショット 2025-10-26 19.14.56.png

導入結果と効果

結果として、1アカウントで1ヶ月あたり約 $70.37 = ¥10,753 の削減効果がありました。
これは利用状況により変動する値ですが、仮に継続した期間において複数アカウントへ適用するのであれば、大きな削減につながると考えられます。

しかし、導入前の検討段階で各アカウント管理者へヒアリングを実施しましたが、実際に導入可能だったのは全体の1割未満でした。

導入が進まなかった理由

  • 短期開発案件が多い: 長期運用予定のアカウントが少数
  • 既存の取り組み: 管理者が独自に停止機構を導入済みのケースが存在

反省点と学び

システム構築から運用開始まで、私一人で約1ヶ月の工数を要しました。
そのため、システム構築開始前により詳細な費用対効果の算出を行うべきでした。
導入可能なアカウント数や実際のコスト削減効果を正確に見積もることで、投資判断をより適切に行えたと考えています。
また、各アカウントで既に実施されている取り組みについて、事前により詳細な調査を行うべきでした。
優秀な管理者の方々が既に独自の仕組みを構築されていたことは、素晴らしい取り組みだなと感心しました。

まとめ

技術的に優秀なシステムを構築することも重要ですが、特にSREとしては以下の点が重要であることを学びました。

  • 施策導入プロセスの重要性: 技術面だけでなく、組織への影響や導入可能性を事前に十分検討する
  • 費用対効果の定量的評価: 開発工数と削減効果を適切に比較検討する
  • 既存取り組みの尊重: 各チームの自主的な取り組みを理解し、活かす方向で検討する

さいごに

一方で、適切な状況下では効果的なコスト削減システムを構築できる手法を確立できたと考えています。

同様のコスト削減活動に取り組まれている方々の一助となれば幸いです。
最後までお読みいただき、ありがとうございました!

5
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?