【アップデート】 Amazon CloudWatch Logs が Intelligent-Tiering に対応しました
こんにちは！クラウド事業本部のおつまみです。
みなさん、Amazon CloudWatch Logs 使っていますか？アプリケーションやインフラのログを集約する定番サービスですが、長期保存するログが積み上がってストレージコストが気になってきた、という方も多いのではないでしょうか。
これまでは、古いログを別のストレージ（S3 など）に退避したり、保持期間で機械的に削除したりと、コストとログの可用性のバランスに悩まされる場面がありました。
今回のアップデートで、CloudWatch Logs 自身がアクセスパターンに応じてログを自動的に低コストな層へ振り分けてくれる Intelligent-Tiering が登場しました！
早速確認してみよう！とのことで、今回は概要とポイントについてご紹介します。
3行まとめ
- CloudWatch Logs がアクセスパターンに応じてログを 3 つのストレージ層（Standard / Infrequent Access / Archive Instant Access）に自動分類するようになった
- どの層にあってもクエリ体験は変わらず、ミリ秒レベルの低レイテンシで検索・分析できる
- 有効化はアカウント単位・リージョン単位でワンクリック、機能の有効化やティア移行に追加料金はなし
アップデートにより何が嬉しくなったのか
Amazon CloudWatch Logs は、アプリケーションやシステムのログを一元的に収集・保管・検索できるサービスです。
これまで、高頻度で発生する大量のログを長期間保持しようとすると、ストレージコストが膨らみがちでした。そのため、以下のような運用でコストを抑える工夫が必要でした。
- 古いログを S3 などの別ストレージにエクスポートして退避する
- 保持期間を短く設定して自動削除する
- ログ量そのものをフィルタして減らす
しかしこれらは、別ストレージの管理コストが増えたり、いざ調査したいときに退避先を探して取り込み直す手間が発生したりと、運用負荷や調査速度とのトレードオフがありました。
今回のアップデートにより、以下のメリットがあります。
- ログを CloudWatch Logs にネイティブなまま低コスト化できる: 別ストレージへの退避が不要になり、複数ストレージソリューションを管理するオーバーヘッドがなくなる
- どの層でも同じクエリ体験: 低コスト層に移動したログも、Standard 層と同じミリ秒レベルの低レイテンシで検索できる
- 運用者が何もしなくてよい: アクセスパターンに応じて自動でティアが切り替わるため、手動での移行作業が不要
- 調査（MTTR）の短縮: すべてのログを 1 つのツールで検索・分析・アラートできるため、平均復旧時間（MTTR）の短縮が期待できる
3 つのストレージ層
Intelligent-Tieringでは、ログデータがアクセスパターンに応じて次の 3 つの層に自動分類されます。どの層にあってもクエリ体験は同じというのが大きな特徴です。
| ストレージ層 | 移行条件 | ストレージ単価（東京リージョン） | 特徴 |
|---|---|---|---|
| Standard（デフォルト） | 新規取り込み時／アクセスされている間 | 0.033 USD/GB（圧縮後） | 低レイテンシ・高スループット。クエリ・エクスポート・Live Tail・ログ取得すべてに対応 |
| Infrequent Access | 30 日連続でアクセスなし | 0.0198 USD/GB（圧縮後、Standard 比約 40% 減） | Standard と同じクエリレイテンシ・スループットで、ストレージコストが低い |
| Archive Instant Access | 90 日連続でアクセスなし | 0.0066 USD/GB（圧縮後、Standard 比約 80% 減） | 他の層と同じミリ秒レベルのクエリレイテンシで、最も低いストレージコスト |
※ 上記単価はアジアパシフィック（東京）リージョンの保存（アーカイブ）料金で、いずれも圧縮後のデータ量に対する 1GB あたりの月額です。料金はリージョンや時期により変動するため、最新かつ正確な値は必ず料金ページでご確認ください。
新しく取り込まれたログはすべて Standard 層からスタートします。アクセスされないまま 30 日経つと Infrequent Access 層へ、さらに 90 日経つと Archive Instant Access 層へと自動的に移動していきます。
そして、古いデータにアクセスすると、そのログイベントは自動的に Standard 層に昇格し、30 日間そこに留まります（アクセスのたびにタイマーはリセットされます）。
「アクセス」とみなされる操作
以下の操作でログイベントを読み取ると、低コスト層にあったデータが Standard 層に戻ります。
- クエリによる読み出し:
StartQuery（CloudWatch Logs Insights）でのクエリ - ログイベントのフィルタ・取得:
FilterLogEvents/GetLogEventsによるログイベントの読み取り - エクスポート:
CreateExportTaskによる S3 へのエクスポート
有効化の方法
Intelligent-Tieringは、アカウント単位・リージョン単位で有効化します。有効化すると、そのリージョン内のアカウント配下のすべてのロググループに適用されます。
なお、S3 の Intelligent-Tiering のようにバケット（ロググループ）単位で個別に設定することはできません。「このロググループだけ有効化する」「このロググループは Standard のまま残す」といった指定はできず、有効化するとリージョン内の全ロググループが対象になる点に注意してください。
必要な IAM 権限
| 権限 | 用途 |
|---|---|
logs:PutStorageTierPolicy |
アカウントのストレージティアを設定・変更する |
logs:GetStorageTierPolicy |
現在のストレージティアを取得する（コンソールからの有効化にも必要） |
CloudWatchLogsFullAccess を持つユーザーは両方の権限を持っています。CloudWatchLogsReadOnlyAccess を持つユーザーは logs:GetStorageTierPolicy を持っています。
コンソールから有効化
CloudWatch コンソールの左メニューから セットアップ > 設定 を開き、ログ タブの インテリジェント階層化 セクションを表示します。有効化前はステータスが「無効化」になっています。
「インテリジェント階層化を有効にする」のトグルをオンにすると、設定が更新され、ステータスが「有効化」に変わります。
AWS CLI から有効化
CLI から有効化する場合は put-storage-tier-policy を使います。
aws logs put-storage-tier-policy --storage-tier INTELLIGENT_TIERING
無効化して Standard に戻す場合は次の通りです。Standard に戻すと、アカウント配下のすべてのロググループが Standard ストレージ料金で課金されます。
aws logs put-storage-tier-policy --storage-tier STANDARD
なお現在の設定を確認するには get-storage-tier-policy を使います。有効化されていれば storageTier が INTELLIGENT_TIERING と返ってきます。
aws logs get-storage-tier-policy
なおロググループのログクラスはスタンダードのまま変わっていませんでした。
おそらく30日何も起こらないと、Infrequent Accessに変更されるのでしょう。
注目ポイント
どの層でもクエリ体験が変わらない
このアップデートで一番うれしいのは、低コスト層に移動してもクエリ体験が Standard 層とまったく同じという点です。
従来のように S3 へ退避してしまうと、いざ調査したいときに取り込み直しやフォーマット変換が必要でした。Intelligent-Tieringであれば、90 日以上アクセスのないログでも Archive Instant Access 層にネイティブに残っており、CloudWatch Logs Insights から普段どおりミリ秒レベルのレイテンシで検索できます。インシデント調査などで過去ログをさかのぼりたいときに、探し回らなくてよいのは大きな安心感です。
本当にクエリのレイテンシーがないかは現時点で確認できなかったため、別途ブログにしたいと思います。
層ごとのストレージ量をメトリクスで可視化できる
Intelligent-Tieringを有効化すると、ロググループごとの層別ストレージ量を示すメトリクスが発行されます。
| 項目 | 値 |
|---|---|
| 名前空間 | AWS/Logs |
| メトリクス名 | StoredBytes |
| ディメンション | LogGroupName、StorageType（Standard / Infrequent_Access / Archival_Instant_Access） |
このメトリクスを使えば、層別のストレージ内訳をダッシュボードで可視化したり、層ごとのサイズにアラームを設定したり、コスト最適化の進み具合を追跡したりできます。
なお、このメトリクスは 1 日 1 回発行されるため、ティア移行がリアルタイムに反映されるわけではない点には注意してください。
S3 保存との比較
これまで「CloudWatch Logs は高いから古いログは S3 に退避する」という運用がよく採用されてきました。今回のアップデートを機に、S3 標準ストレージと保存単価を比べてみます。
まず S3 標準（東京リージョン）の保存料金は次の通りです。
| 容量帯 | 単価 |
|---|---|
| 最初の 50 TB/月 | 0.025 USD/GB |
| 次の 450 TB/月 | 0.024 USD/GB |
| 500 TB/月以上 | 0.023 USD/GB |
単価だけを並べると、S3 標準（0.025 USD/GB）は CloudWatch Logs の Standard（0.033 USD/GB）より安く見えます。しかし、ここには 課金対象のデータ量の違いがあります。
- CloudWatch Logs: 保存料金は 圧縮後（gzip）のデータ量に対して課金される
- S3: 保存料金は 非圧縮の実データ量に対して課金される（自分で圧縮して保存すれば別）
CloudWatch Logs のログは取り込み時に圧縮され、一般的に元のサイズの 15% 程度になると言われています。仮に圧縮率を 15% として、同じ「元ログ 1GB」あたりの実質コストに換算すると次のようになります。
| ストレージ | 単価 | 元ログ 1GB あたりの実質コスト（圧縮率 15% 換算） |
|---|---|---|
| S3 標準 | 0.025 USD/GB（非圧縮） | 約 0.025 USD |
| CW Logs Standard | 0.033 USD/GB（圧縮後） | 約 0.005 USD |
| CW Logs Infrequent Access | 0.0198 USD/GB（圧縮後） | 約 0.003 USD |
| CW Logs Archive Instant Access | 0.0066 USD/GB（圧縮後） | 約 0.001 USD |
このように、同じ量の元ログで比べると、CloudWatch Logs にネイティブ保存したほうがむしろ安くなるケースが多いです。Intelligent-Tieringで Archive Instant Access 層まで落ちれば、その差はさらに広がります。
そもそも「CloudWatch Logs は高い」と言われてきた主因は、保存料金ではなく取り込み（Ingestion）料金の方です
実際、CloudWatch Logs の初回取り込みは S3 への書き込みと比べて桁違いに高く、両者のコスト差の大部分はここから生まれています。
以下の記事では、CloudWatch Logs の取り込み料金が S3 の書き込みと比べていかに高いか、具体的な単価で丁寧に比較されています。
つまり、保存料金だけを見て「S3 の方が安い」と判断すると本質を見誤りやすく、コスト差の主戦場はあくまで取り込み側にあります。
保存だけで見れば CloudWatch Logs は圧縮効果で十分に競争力があり、今回のアップデートで保存コストがさらに下がったことで、「保存の安さのために S3 へ退避する」という動機は以前より薄れたと言えます。
一方で、そもそも取り込み量・取り込み料金を抑えたいのであれば、S3 へ退避するより ログの書き込み先を最初から S3 にするアーキテクチャを検討するほうが効果的なケースもあります。
CloudWatch Logs にネイティブ保存して Intelligent-Tiering で保存コストを最適化するか、そもそも取り込み経路から見直すか、ログの用途（リアルタイム監視が必要か、長期アーカイブが主目的か）で使い分けるのがよいでしょう。
※ 圧縮率はログの内容によって変わるため、上記はあくまで目安です。S3 は BI ツール・データレイク連携や、Glacier Deep Archive による超長期・超低コストのアーカイブといった別の強みもあるため、要件に応じた使い分けは引き続き有効です。
利用時の注意点
有効化はアカウント単位・リージョン単位で全ロググループに適用される
特定のロググループだけを対象にする、といった細かい指定はできません。有効化したリージョン内のすべてのロググループが対象になるため、影響範囲を理解したうえで有効化してください。
頻繁にアクセスするログはコスト削減効果が出にくい
Intelligent-Tieringは「アクセスされないログ」を低コスト層に移すしくみです。定常的にクエリ・監視しているログはずっと Standard 層に留まるため、削減効果が出るのは主に長期保存目的のアクセス頻度の低いログです。まずは StoredBytes メトリクスで層別の内訳を確認するのがおすすめです。
クエリのレイテンシーは変わらないが、アクセスすると低コスト層のログは Standard 層に戻る
低コスト層に移動しても、クエリのレイテンシー（ミリ秒レベル）やクエリ単価（スキャンしたデータ量あたりの料金）は Standard 層と変わりません。ここは S3 Glacier のような取り出しに時間がかかるアーカイブとは異なり、"Archive Instant Access" の名の通り即時にアクセスできます。
一方で注意したいのがストレージ料金の挙動です。低コスト層のログにクエリ（StartQuery）・フィルタ（FilterLogEvents / GetLogEvents）・エクスポート（CreateExportTask）でアクセスすると、対象のログイベントは自動的に Standard 層に昇格し、30 日間そこに留まります（アクセスのたびにタイマーがリセットされます）。
つまり「クエリした瞬間に追加料金がかかる」のではなく、「クエリしたことで、そのログの保存単価が低コスト層から Standard に戻る」という形でコストに影響します。コールドなログを繰り返し調査すると、その間は Standard ストレージ料金で課金される点は押さえておきましょう。
利用できないリージョンがある
執筆時点では、中東（バーレーン）・中東（UAE）を除くすべての AWS 商用リージョンで利用可能です。対象リージョンで使うワークロードかどうかを確認してください。
まとめ
今回は Amazon CloudWatch Logs のIntelligent-Tieringをご紹介しました。
アクセスパターンに応じてログを自動的に低コスト層へ振り分けてくれるうえ、どの層にあっても同じクエリ体験を維持できるため、「コストは抑えたいけれど、いざというときにすぐ調べたい」というログ運用の悩みにきれいに応えてくれるアップデートです。機能の有効化やティア移行に追加料金がかからないのも導入しやすいポイントですね。
長期保存しているログのコストが気になっている方は、まず対象リージョンで有効化して StoredBytes メトリクスで層別の内訳を眺めてみてはいかがでしょうか。
最後までお読みいただきありがとうございました！
どなたかのお役に立てれば幸いです。
以上、おつまみ（@AWS11077）でした！
