はじめに
AWSのコスト最適化を実施する場合、大きく分けると①リソースの最適化と②アーキテクチャ最適化の２種類があります。本記事において、リソースの最適化はサイジング、削除、一部設定変更など、現在のシステムを大きく変更しないものとし、使用するAWSサービスが変わるなど大きな変更があるものをアーキテクチャ最適化と呼称します。本記事ではリソースの最適化に絞ってお伝えします。
概要
リソースの最適化のなかでよく取り上げられる（1）未使用リソースの停止・削除、（2）リソースのサイジング、（3）リソースの設定変更（サイジングを除く）について本記事では記載をします。リソースの最適化を推進していくうえでのポイントとしては、CostOptimizationHubやInstanceSchedulerなどコスト削減策を実施するうえでAWSが提供しているAWSサービスやソリューションを積極的に活用し、着実に、素早く成果を得ることだと考えています。
不要リソースの削除
- 未使用リソースの停止・削除
特に学習環境やサンドボックス環境において、不要になったリソースは無いでしょうか。CostOptimization Hubでは未使用リソースなどを表示してくれるので、そちらを確認いただくと良いと思います。また、CostOptimization Hubでは表示されませんが、不要なElastic IPなどが無いかも合わせて棚卸するとよさそうです。 - ユーザの棚卸
Amazon Quick Sight、Amazon Q Developerでは使用するユーザ単位で料金が発生するため、ユーザの定期的な棚卸が必要です。- Quick Sight
利用状況を簡単に把握できるこちらがソリューションとして提供されています。 - Q Developer
Q Developer ユーザーアクティビティレポートをオンにすることで、各ユーザのメトリクスの収集が可能です。ただし、本レポートに保存されているUserIdはIAM Identity CenterのUserIdが保存されているため、必要に応じてマッピングしながら各ユーザに関して確認、整理していくことになります。
※Amazon Q Developerのページから[セッティング]>[Amazon Q Developerの使用アクティビティ]>[Qデベロッパーユーザーアクティビティレポート]でレポートの作成を有効化できます。
- Quick Sight
- リソースのスケジュール起動・停止
例えば開発環境は営業時間（土日停止、平日は9時間稼働）のみの稼働に抑えれば、1/3程度に抑えることが可能です。リソースのスケジュール起動停止は①SSMやLambdaなどを用いて自前で実装、もしくは②AWSが提供しているInstance Schedulerの選択肢があります。要件上特に問題なければクロスアカウント・クロスリージョンで簡単にデプロイできるInstance Schelduerがおすすめです。- SSM + Event Bridge + Step Functions
- 小規模な場合や、要件上Instance Schedulerの導入が難しい場合はSSMとEventBridgeでスケジュールによる起動停止が可能です。EC2についてはデフォルトでSSM Runbookが提供されていますが、DBやECSについてはRunbookの作成が必要です。
-
Instance Scheduler
- AWSが提供しているソリューションです。クロスアカウント、クロスリージョンでスケジュールによる起動停止が可能です。CloudFormationが提供されており、簡単にデプロイ可能です。
- SSM + Event Bridge + Step Functions
- ストレージのライフサイクル
データライフサイクルに基づいてストレージのライフサイクルを設定することで、データを適切なアクセス層に移し、不要なデータを削除します。注意するべきポイントとしては、Amazon EFSはマネジメントコンソールから推奨の設定でEFSファイルシステムを構築した場合、デフォルトでライフサイクルが設定されるという点です。 - ログローテーション
CloudWatchLogsの保存期間はデフォルトで無期限です。適切なタイミングでS3に格納する、不要なログは削除するなどの対策が必要です。また、Fluentdなどを使用して必要な情報だけCloudWatchLogsに送信するなど、CloudWatchLogsに投入するデータ量についても考慮するとよさそうです。
リソースのサイジング
- インスタンスサイズの最適化
既に安定しているワークロードであればComputer optimizerが提案してくれるため、その案を元に精緻化を進めることが可能です。 - リザーブドインスタンス（RI）/Saving Plans(SP)の導入
RIやSPについては詳細をわかりやすく解説している記事を参考に、導入を検討いただければと思います。Amazon Cloud Frontにもリザーブドキャパシティが存在しますが、AWSとの個別契約が必要です。
リソースの設定変更
- VPCエンドポイント
ゲートウェイ型とインターフェース型の両方をサポートしているDynamoDBとS3については追加料金が発生しないゲートウェイ型エンドポイントの採用できないか、要件を確認いただければと思います。各エンドポイントの詳細と特徴についてはこちらが非常にわかりやすく、勉強になりました。 -
Amazon EBS gp3への移行
既存のpg2ボリュームよりも低い料金で利用することが可能です。ただし、ケースによってはインスタンスの再起動が必要になる場合などもあるようなので、制約事項、検討事項を確認しながら、開発環境などでの検証が必要です。
②アーキテクチャ最適化
マイクロサービスアーキテクチャやコンテナ化など、クラウドネイティブなアーキテクチャに既存のアーキテクチャを変更していくことになります。
最後に
アーキテクチャの最適化は時間がかかりますが、クラウドネイティブなアーキテクチャを浸透させることによってコストだけではなく、運用の効率向上など波及的にさまざまな効果が得られます。そのため、リソースの最適化によって短期間で一定の成果を挙げつつ、アーキテクチャ最適化の浸透活動を長い目で取り組むことが重要です。また、リソースの最適化を行う際には、Cost Explorerを用いて自分たちの組織でインパクトが大きいかどうかと、対応策を実施するための工数などを鑑みたうえで、優先順位をつけて最適化策を実施していくことになると思います。