概要

こんにちは、インフラエンジニアの加藤です。

社内で行ったAWSのコスト最適化とリソース整理の内容をレポートします。

今回は、AWS Compute Optimizer、AWS Trusted Advisor、Amazon S3 Storage Lensを活用し、不要・過剰リソースの洗い出しから削除までを手動で実施しました。

まずはAWSの公式推奨値や手作業でのチェックを経て「どの部分を仕組み化できそうか」のあたりをつけ、今後はそれをベースに自動化や定期モニタリングの仕組みを構築していく予定です。

本記事では、具体的な実施内容や改善結果とあわせて、今後の自動化・仕組み化に向けた方針をまとめます。

1. 現状確認

過剰なコストが発生している可能性の高い箇所を特定するため、以下の3つのアプローチで調査を行いました。

1-1. AWS Compute Optimizerの確認

稼働中のEC2インスタンスやEBSボリュームの推奨ステータス（最適化可能、過剰プロビジョニングなど）を抽出しました。

1-2. AWS Trusted Advisorの確認

コスト最適化項目を確認し、利用率の低いEC2インスタンスや未使用のEBSボリュームなどを抽出しました。
【注意】Trusted Advisorの網羅性】
Trusted Advisorは非常に便利ですが、あくまでAWSが定義した標準的なルールに基づく推奨事項の提示に留まります。
アカウント内の不要なリソースをすべて完璧に洗い出せるわけではないため、Trusted Advisorの確認だけでなく、独自の基準による調査も組み合わせて実施しました。

また、推奨内容の適用にあたっては、監視メトリクスから平常時・ピーク時双方のリソース使用状況を分析し、性能劣化やリソース枯渇のリスクがないことを検証したうえで実施しました。
変更作業については、段階的な適用を基本方針とし、利用状況の分析結果に基づいてメンテナンス時間帯を選定することで、サービスへの影響を最小化しました。
利用者の多いシステムに対する再起動を伴う変更は、安定運用のため影響の少ない時間帯に実施しました。

1-3. 長期間放置されているリソースの整理

長期放置されているEC2関連リソースとS3バケットの確認を実施しました。
- EC2関係
  - 1年以上前に作成されたまま稼働・利用されていないEC2インスタンス、EBSボリューム、EBSスナップショット、AMIをリストアップし、不要なものを整理しました。
  - AWS Instance Schedulerで利用している既存タグではコスト効率が悪いもの（例：夜間停止後平日日中に再起動してしまうケース）については、新たに「停止のみ」のスケジュール設定を追加しました。
- S3関係
  - S3 Storage LensとS3 APIを活用し、長期間更新のないオブジェクト、不完全なマルチパートアップロードの有無、ライフサイクルルールの設定状況を横断的に確認しました。

2. 実施した最適化作業（手動対応）

「1. 現状確認」で抽出した調査結果に基づき、対象リソースの棚卸しを実施しました。具体的には、スプレッドシートに対象リソース一覧を整理した上で、関係各所のメンバーに対して個別にヒアリングを行い、利用状況および必要性を確認しました。その結果を踏まえ、手動作業にて以下のリソース最適化・整理を実施しました。

2-1. AWS Compute Optimizer / Trusted Advisor に基づく対応

ツールから推奨された「過剰プロビジョニング」や「未使用リソース」のステータスに対し、以下の即効性のある対応を行いました。

インスタンス・EBSの最適化
- 過剰スペックと判定されたEC2インスタンスのタイプ変更（ダウンサイジング）を実施しました。
- EBSボリュームのパラメータ（容量・IOPS・スループット）を実際の利用実績に合わせて最適化しました。
未使用リソースの削除・解放
- コストが発生していた未使用のEBSボリューム・EBSスナップショットやEC2インスタンスを整理し削除しました。

2-2. 独自基準に基づく対応（EC2関連リソース）

Trusted Advisor等では検知しきれない、長期間放置されていたリソースの整理と、今後の無駄を防ぐための設定変更を行いました。

長期未使用リソースのクリーンアップ
- 1年以上前に作成され、運用されていないEC2インスタンス、EBSボリューム、EBSスナップショット、AMIを精査し、不要なものを削除しました。
AWS Instance Schedulerのタグ設定の見直し
- 調査時に停止忘れ対策単体のタグが存在していなかったため、新しく停止用のタグを作成・付与し、自動でインスタンスが停止してコストの無駄遣いを防げる状態にしました。

2-3. 長期間放置されているリソースの整理（S3関連リソース）

S3 Storage LensとS3 APIの調査結果を基に、ストレージコストを削減するための整理を行いました。

オブジェクトの精査と削除
- 長期間更新のなかったバケットやオブジェクトを精査し、不要なリソースを削除しました。
マルチパートアップロードのクリーンアップ
- 蓄積していた「不完全なマルチパートアップロード」をクリーンアップし、無駄なストレージ消費を解消しました。
ライフサイクルルールの更新
- 今後の自動コスト最適化（オブジェクトのGlacierへの移行や自動削除など）を見据え、暫定的なライフサイクルルールを設定・更新しました。

3. 今後に向けた自動化・仕組み化の展望

今回は手動でリソースの棚卸し・整理を実施しましたが、リソースの増加は今後も継続的に発生します。
そのため、同様の課題を繰り返さないよう、運用の仕組み化と自動化を進めていきます。

1. 公式推奨事項の定期確認

AWSのベストプラクティスに沿った継続的な改善を行うため、推奨事項を定期的に収集し、Slackへ通知する仕組みを構築します。

対象は以下を想定しています。

AWS Compute Optimizer の推奨レポート
Trusted Advisor の推奨レポート

人手による定期確認を不要にし、対応漏れの防止や継続的なコスト最適化につなげます。

2. 独自フィルターによる未使用リソース検知

AWSの標準機能だけでは検知できない放置リソースを可視化するため、現場の運用実態に合わせた独自フィルターを作成し、月次でSlackへ通知します。

例えば、今回の棚卸しで利用した基準をもとに、以下のようなリソースを検知対象とします。

作成から1年以上経過したEC2・AMI・EBS・EBS Snapshot
長期間停止状態のEC2
未アタッチのEBS
未参照のAMI・EBS Snapshot

これにより、実運用に即した未使用リソースの早期発見と継続的なコスト削減を実現します。

3. S3運用の標準化と自動化

S3については、ライフサイクル管理の標準化と大量オブジェクト運用時の自動化を進めます。

Infrequent Access や Glacier など適切なストレージクラスへの自動移行
不完全なマルチパートアップロードの自動削除
バケットやプレフィックス単位での保持期間ルールの整理と自動削除

調査を進める中で、S3の分析・整理に関する運用パターンが確認されたため、今後の対応方針として検討を進めています。また、Storage Lens、S3 Inventory、S3 Batch Operationsを組み合わせた手法はAWS公式ブログでも実装例として紹介されており、今後の検討の参考としています。ただし、対象バケットはオブジェクト数が多く、各種分析・調査系サービスの利用コストも発生するため、コスト面も含め慎重に検討する必要があります。
参考：AWS公式ブログ：「Copy objects between any Amazon S3 storage classes using S3 Batch Operations」

まとめ

コスト最適化の提案から始め、まずは簡単に済ませられるものから各ツールの推奨情報も参考にしながら手作業で進めました。実作業を通してシステムの現状や、単なる削除に留まらないリソースのチューニングに関する判断基準を深く学べたことが大きな収穫です。今後は、今回得た知見をもとに自動化や定期通知の仕組み化へと繋げ、さらなる運用効率の向上に貢献していきます。

株式会社エニグモすべての求人一覧

hrmos.co