Infrequent Access ログクラスというログ出力料金の救世主が現れたかもしれないので触ってみた。
初めに
re:invent 2023 で発表されたAmazon CloudWatch Logsの新しいログクラスである
Infrequent Access ログクラス が高くつきがちなCloudWatchへのログ出力料金を改善してくれそうだったので軽く触ってみました。
結論
PutLogEventsが半額になる。
閲覧はほぼすることが無いが、保存が必要なログ（監査ログ等）についてはかなり有用なものであると言えることが分かりました。
Infrequent Access ログクラスとは
低頻度アクセスログクラスでは、すべてのログを 1 か所にまとめ、コスト効率の高い方法でログの取り込み、クエリ、保存を行うことで、CloudWatch を使用して包括的なオブザーバビリティソリューションを構築できます。低頻度アクセスは、標準ログクラスよりも 1 GB あたりの取り込み価格が 50% 低くなります。標準ログクラスが提供するライブテール、メトリック抽出、アラーム、またはデータ保護などの高度な機能を必要としないお客様向けに、カスタマイズされた機能セットを提供します。低頻度アクセスでも、取り込み、ストレージ、および CloudWatch Logs Insights を使用して詳細に分析できるフルマネージド型のメリットを享受できます。
メリット
とにかくPutLogEventsの費用が半分
請求書でみるとこんな感じ
デメリット
- 運用に関するログのtailingと、ログからのメトリクスの抽出、異常検出、機密データの保護、リアルタイムのログ分析などの高度な分析機能が使えない。
- ログの確認方法も運用が変わる。
どんなログが適しているか？
AWSからの説明にもありましたが、以下の系統のログが適しているように思います。
ログ取ってますよ ということ自体が大事なものに向いています。
- 監査ログとかアクセスログとか
- ぶっちゃけ見ないけど、保持はしとかないとダメだよね。系
触ってみた
後から変更できないので、Log Group作成時にログクラスを選択します。
これも記載がありましたが、いろいろなものがサポートされていませんでした。
LogStream自体の見た目は普通でした。
Logの確認方法は変更あり
Logの確認方法が「ログのインサイト」になっていた。
ログストリームの一覧を選択してログを見ようとするとインサイトに遷移する。
少しの優しさで、対象のストリームにフィルターがかかっているので、「クエリの実行」を
するだけで少しログが見える。（少しだけ。
※注意点
ログの時間範囲もきちんと検索対象に入ってしまっているため、該当ログが存在する時間帯を
メトリクスの対象とするように準備が必要。
例えば
15時時点で11時台のログを3時間の範囲で検索しようとしたら結果を取れなかった。。
対象ログが存在するはずの期間に絞ってあげるとログを見ることができました。
小技
・インサイトのクエリについて
AWSのユーザーガイドは ここ
ログストリームを選択した際に表示されるデフォルトのクエリに対して
sort は asc に
limit は削除してしまった方が読みやすいです。
改めてまとめ
とにかくログを”残しておくこと”が大事で、追加開発コストやログ保持コスト的な意味で低コストにしておきたい場合にはこれが有効に思える。
→ここに突っ込んで、ライフサイクルで消えていくような形が良さそう。
課題になること
- ログインサイトがあまり普及していないと思われるので、マニュアル等で利用方法を
まとめておく必要がある。 - DataDog等でログを閲覧していた場合に設定のし直しの必要が発生する。
一方で、うまく利用できることが分かれば、全てのLogのログクラスを変更してDataDog側で
工夫することで意外と料金のかかるLog部分の料金を改善できるかもしれません。
（ここは検証できていないので要検証です。すみません。）
Discussion