はじめに
所属しているプロジェクトにて CloudWatch の費用が高い！という話題になりました。
CloudWatch ログは、一定期間経ったら削除しているのになぜだろう？ログのストレージ量とは別の何かかかな？という状況でした。
ということで、この時に確認した CloudWatch のどのサービスで費用がかかっているのか？どのロググループが要因なのか？について確認するべきポイントと手順を紹介します。確認した結果から、削減可能なものかを判断し、可能なものなら対応するという流れになります。
それでは、実際に確認していきましょう！
Billingページでどのサービスに費用がかかっているか確認しよう！
まず Billing ページにて CloudWatch の明細を見ます。
「DataProcessing-Bytes」の費用がダントツで一番多くかかっていました。
AWSのページを見ると、「DataProcessing-Bytes」は 「CloudWatch Logs」 のサービスとあります。
この「CloudWatch Logs」のサービスに費用がかかっていることが分かりました。
やはりログが関連しているようです。
さらに上記ページを見ると、DataProcessing-Bytes のイベントは「PutLogEvents」となっています。これは、CloudWatch へデータを取り込んだイベントということで、料金ページの「収集（データの取り込み）」の部分ですね。なるほど、「保存」でなく「データ取り込み」の方だったのか。
定期的にログを削除していたとしても、そもそも CloudWatch へデータを取り込んだところに費用がかかっているのですね。
一ヶ月でCloudWatch へ取り込まれたデータの合計量が多いロググループこそ、費用が高い要因だ！
ということで確認しましょう！
一ヶ月で取り込まれたデータの合計量が多いロググループを確認しよう！
手順はナレッジページにあります。
ロググループに取り込まれているデータ量は「IncomingBytes メトリクス」で確認できます。IncomingBytes メトリクスは、CloudWatch のロググループに取り込まれているデータ量を、ほぼリアルタイムで示しています。
この IncomingBytes メトリクスから、一ヶ月で取り込まれたデータの合計量が多いものを確認することで、どのロググループが DataProcessing-Bytes の費用としてかかっているか判断できます。
それでは、実際に確認しましょう。
- IncomingBytes メトリクスの確認
CloudWatchコンソール画面のメニューから「すべてのメトリクス」を選択します。
メトリクス一覧から、「ログ」を選択します。
次に「ロググループメトリクス」を選択します。
出力された一覧からメトリクス名「IncommingBytes」のものをすべてチェック入れ、「IncommingBytes」メトリクスの値を表示します。
- 各ロググループの一ヶ月の合計を確認
上記で「IncommingBytes」メトリクスにしぼって表示ができました。デフォルトだと期間が5分など短くなっているので、期間を一ヶ月（30日）にしてその合計を確認します。
「グラフ化してメトリクス」タブに移り、統計を「合計」、期間を「30日」に設定します。
「グラフのオプション」タブに移り、合計値を確認したいのでウィジェットタイプを「数値」に設定します。
上部にあるグラフ描画箇所の期間設定の「カスタム」を選択します。
左上にある絶対値タブクリックすると、カレンダーが表示されるので、一ヶ月間を選択して「適用」を押下します。
確認しやすくするために、合計が多い順に並べ替えます。
数式メニューをクリックし、「並べ替え」→「合計で並べ替え」を選択し、結果を降順で並べ替えます。
すると、合計が高いもの順に結果が出力されます。
- 合計が一番多いロググループを確認
上記の結果を見てみると、
/aws/rds/cluster/{クラスター名}/general
/aws/rds/cluster/{クラスター名}/audit
となっていました。このRDSのログが他と比べてかなりデータ量が多かったです。
このRDSの「general（一般ログ）」、「audit（監査ログ）」が、一ヶ月で結構なデータ量で、このログを CloudWatch へ取り込んでいることこそ、費用がかかっている要因だと分かりました。ふー。
調査結果から費用削減として実施したこと
この結果から対応として、合計が一番多かったRDSの一般ログ、監査ログの CloudWatch エクスポート自体を止めて、費用削減を行いました。
プロジェクトでは、この一般ログ、監査ログは運用保守でも監視していない情報だったのと、CloudWatch への取り込みを止めても、RDSのコンソール画面から参照できるため、削減可能なものと結論に至ったからです。
クラスター設定にて、「ログのエクスポート」の「監査ログ（audit）」と「全般ログ（general）」のチェックを外し、エクスポートを止めました。
その結果、CloudWatchの費用は、なんと「5分の１」になりました！
おわりに
いかがでしたでしょうか？
CloudWatch が高いとなった時、この手順にて CloudWatch のどのサービスで費用がかかっているのか、そして、どのロググループが要因になっているかを確認することで、費用削減できる箇所を判断し対応することができました。
今回は、ログサービスの PutLogEvents、ロググループはRDSの一般ログと監査ログという結果で、このログのCloudWatchエクスポートを止めることで費用削減ができましたね。
CloudWatchでは見ていないログに、結構な費用がかかっていたという結果でした。
とほほ、、、＞＜
