【AWSコスト管理】無限に増えていたCloudWatch LogsをServeless Frameworkの設定で保持期間を決めコスト削減

AWS初心者の頃に開発を始めた社内向けサービスにおいて、運用が１年以上経過してどんどん利用も増えてきました。

そして、開発当初は知識不足であった項目や何もわからずぽちぽち設定していた項目のいくつかがネックになってくることが増えてきました。

今回は、API Lambdaのアクセスログとして、利用していたCloudWatch Logsのコスト圧縮に取り組みました。

現状のコスト感と課題

運用しているアプリケーションはバックエンドをAWSで構築しており、S3バケットで静的ホスティング、ApiGateway × LambdaによるAPI構成、DBにRDSを利用しているwebアプリケーションです。

具体的なコストは公開を控えますが、月々のコストの割合は以下のようになっていました。

開発しているアプリケーションは、国内で稼働している社内向けサービスなので、そこまでアクセスが多いわけでもないです。

現時点で、コストで一番重荷になっているのは、インスタンスを立てる必要がRDSです。
DB自体は、RDBMSの方が使い勝手が良かったですし、インスタンス台がほぼ固定でかかることは許容するとしていました。ただ、キャッシュ使ったりインデックス貼ったりとやれることはまだまだたくさんあると思います。

さて、そんな運用サービスのコスト管理ですが、社内向けでも利用が増えてくることで、もう一つ重荷になってきているサービスが出てきました。

それが、CloudWatch Logs（図上、紫）です。

月々のコストを見るとわかる通り、これまでのログが積み重なっていくので、cloudWatch Logsのコストだけが純増していることがわかります。

このままでは、RDSのコストとCloudWatchのコストが逆転してしまう！！！？

こう思ったのが、コスト圧縮しようと思った要因です。

そもそもCloudWatch Logs必要なのか

API Lambdaと紐づけているCloudWatchの開発しているプロジェクトの使い方では、APIがたたかれるたびにログを取り、CognitoからどのユーザーがAPIをたたいたのかを確認していました。

また、エラーロガーとしても機能させており、エラー時に開発者に通知などの対応もできていなかったので、エラー時はCloudwatchLogsを参照して、エラー要因を特定していました。

今回の利用であれば、アクセスログとエラーの処理のためのログとなるため、保持しておくことが必要でもなく、エラー解消した後は、不要になるものばかりです。

Serverless FramworksでのLogs設定

今回のバックエンドは、Serveless Framwoksを利用しています。

これまでの運用としては、Lambdaに対して、CloudWatchの許可ポリシーを付与していますが、ログを残すかどうかの設定などは特にしていませんでした。

そこで、今回、ServelessFrameworkでAPI GatewayとLambdaの定義に対して、ログの保持期間の設定を追記していきます。

Lambdaを作成するときに設定しておきたいオプション

Serverless Framworksを利用してAPI GatewayとLambdaを作成することは非常に簡単ですが、ランタイムやメモリ・タイムアウトといった一般的に設定する項目とほかに設定しておきたい項目があることがわかりました。

Lambdaのバージョン管理については、以下の記事でエントリーしてますので、参考にしてみてください。

Digital Wave Chronicle

ServerlessFrameworkでAWS Lambdaを構築しているとバージョン管理がいつの間にか圧迫していた | Digital Wa… 仕事で用いているAWSアカウントでLambdaのストレージが上限いっぱいとなった。既に上限緩和申請しているが、これでは、この後の作業に支障が出るので対応していく。 原因と…

さて、CloudWatch Logsの設定ですが、デフォルトのままでログをどんどん残してくれるので便利ですが、Logsの保存期間やアーカイブの保存先などを設定しておかないと後々、今回のように金額が嵩んできます。

保存期間を設定する

今回は、開発時の取得ログの確認や、バグが生じたときのエラー発見を主として使用しているため、過去分をずっと残す必要はありません。

Serverless Frameworkではログ保存の期間を簡単に設定できます。

serverless.ymlファイルのprovider設定で、logを残す期間（今回は30日）を設定するだけ。

Lambda関数ごとに設定もできるよですが、今回は一律で設定しました。

provider:
  logRetentionInDays: 30

たったこれだけで、ログの保持期間が設定できます。

また、現状すでにこの期間より前となっているログはデプロイした後、削除されていることも確認できました。

改善されたコスト感

開発・運用しているアプリケーションが徐々にアクセスが増えてきてますので、単純に比較はできませんが、logの保持期間を変更してから以下のように、コストグラフが劇的に下がっているわけではありませんが、横ばい程度になってきたかと思います。

おわりに

CloudWatch Logsは、高いと聞いてはいたけど、利用が少ない分ではあまりそのことを実感できませんでした。

サービス運用から1年経過すると積もり積もって、毎月一律で上がっていることが確認できました。

今回の設定変更でclouodWatch Logsのコストが一気に落とすことができました。

ただ、これでもサービス拡大すると増えていくことが予測されますので、必要なエラーログ通知のためのサービスとして利用して、エラーログ自体は、CloudWatchからではなく、S3に移行させていこうと考えています。

AWS設計スキルアップガイド──サービスの選定から、システム構成、運用・移行の設計まで

監修:株式会社BFT, 著:佐野 夕弥, 相馬 昌泰 他

口コミを見る

Amazon

楽天市場

Yahooショッピング

ポチップ