今回の対象

CloudWatch Metrics と CloudWatch Logs が対象です。

CloudWatch Metrics

Metricsですがカスタムメトリクスはほとんど使っていないので取得系の費用が主な対象となります。

本番環境のアカウントは、削減の余地がほとんどないので、ステージング用のアカウントを対象に実施しました。

絶対額は小さいのですが、節約系の積み上げなので、簡単にできることはしっかりとやっておく、です。

ステージング環境用のAWSアカウントのCloudWatchの費用をCost Explorerのby Usage typeでみてみると

で、MetricStreamUsageと、GMD-Metrics がかなり大きいことがわかります。

これらは、監視で利用しているDatadogとNew Relic Infrastructureのメトリクス取り込みによるものが大きいと考えられます。

元はステージング環境では

Datadog : Streamによるメトリクス取り込みでほぼ全サービス
New Relic Infrastructure : APIによるメトリクス取り込みでほぼ全サービス

となっていましたが、AWSサービスの監視ではDatadogをメインで使っており、New Relic Infrastructureはほとんど利用していなかったことと、Datadogでもステージング環境なのでStreamでの取り込みまでは必要なかったので、以下に変更しました

Datadog : APIによるメトリクス取り込みでほぼ全サービス
New Relic Infrastructure : APIによるメトリクス取り込みでEC2などの主要なサービスのみ

この結果、

となり、およそ10万円/月くらいは削減できました

CloudWatch Logs

CloudWatch Logsは、まず保存容量が多い順に見てみると、上位は

RDSの監査ログ
VPCフローログ
いくつかのLambdaのログ

このあたりがTB級でした。

削減の作戦としては

保持設定をしていないものが多かったので、可能なら設定する
そもそもログをなくせないか
なくせないにしてもログの量を減らせないか

を上位のものに対してやっていく、です

RDSの監査ログについては、以前はCloudWatch Logs経由でS3に保管していたのですが、高負荷時に取りこぼすことがあるのと、S3に保管するのにつかうFirehoseがかなり高い、ということがあり、以前にRDSから直接S3に定期的に出力するように変更していたので、CloudWatch Logsに残っているログは設定変更前のもののみでした。よって保持設定を行うことで削減ができました。

VPCフローログについては、SIEMにログを転送するためにCloudWatch Logsに出力させていました。SIEM導入当初はCloudWatch LogsからのLambda経由しかSIEMがサポートしていなかったのですが、改めて調べてみると現在はS3から直接取り込むことが出来るようになっていました。S3から直接取り込む方法に変更することで、VPCフローログをCloudWatch LogsからS3への出力に変更できるだけでなく、SIEMに送るためのLambdaも削減できて、Lambdaのログもなくなって一石三鳥になりました。

Lambdaのログですが、実は一番大きかったものが、前述のVPCフローログをSIEMに転送するLambdaのものでした。ログ自体は基本的な内容しか吐いていなかったのですが、とにかく実行回数が多かったのが効いていました。

他には、VPCフローログとは別に、各サーバのログをLogstashでS3に収集したものを、更にS3からSIEMに転送するためのLambdaが、サイズ上限超えた際にS3に入っているログの本文を出力してそれがとんでもない大きさになっていました。ログ自体はS3に保管されているのでS3のObject名だけを出力すれば十分なので、変更しました。

他にも出力が過剰なものがいくつかあったので、削減を行いました

あとは、保持設定については、工数が少ないので、保存容量が多いものに限らず、広範囲に設定しました

結果はこんなところです（Cost ExplorerよりCloudWatch をby Usage type）

APN1-DataProcessing-Bytes(取り込み), APN1-VendedLog-Bytes(主にVPCフローログの取り込み), APN1-TimedStorage-ByteHrs(ストレージ)が大きく下がりました