ロググループを作って、アプリのログが流れ込むところまでは動いた。ところが「何日残すか」を聞かれて手が止まる、という場面は多いはずです。決めずに進めると、ログは期限なしで増え続けます。かといって短くしすぎると、障害の調査や監査で必要になったときに残っていません。この記事は、その決め方を「見る頻度」と「残す理由」の 2 つの軸で組み立てます。ログの種類は AWS のログの仕組み で、CloudWatch の基本は CloudWatch とは で押さえた前提で進めます。
この記事の結論
- ログの保存は「見る頻度」と「残す理由」の 2 軸で決めます。両方を決めずに初期設定のままにしないことが出発点です。
- CloudWatch Logs の保持期間はロググループごとに設定でき、初期設定は無期限です。期限を過ぎても、削除されるまでに時間差があります。
- すぐ検索・アラームに使う期間は CloudWatch Logs に置き、長く残すだけの分は S3 へ移す考え方が基本です。
- ロググループは「保持・アクセス・監視の設定が同じもの」の単位です。同じ設定にしたいログを同じグループに集めます。
- ログクラスは作成後に変えられず、Infrequent Access では使えない機能があります。決める前に必要な機能を確かめます。
ログの保存は何を決める設計なのか
ログの保存で決めることは、大きく 3 つあります。
- 置き場: CloudWatch Logs に置くのか、S3 へ出すのか。
- 期間: どのくらいの期間、その置き場に残すのか。
- 形: どのグループに分け、どのログクラスで受けるのか。
この 3 つは別々に見えて、1 つの問いにつながっています。「このログは、誰が・どれくらいの頻度で・何のために見るか」です。障害のたびに開くログと、監査の求めがあったときだけ開くログとでは、置き場も期間も変わります。
ログの一生を駅にたとえると、次のようになります。
LIFE OF A LOGログの一生
ログは出る → 調べる → 残す → 消えるの順に置き場を移る
-
出力
アプリや OS がログを書く
-
CloudWatch Logs
検索・集計・アラームに使う期間
-
S3
検索はせず、残すだけの期間
-
削除
残す理由が切れたら消す
最初の駅（出力）と最後の駅（削除）の間に、CloudWatch Logs と S3 という 2 つの置き場があります。すべてのログが 4 駅すべてを通るとは限りません。S3 を通らずに期限で消えるログも、最初から長く残すログもあります。どこで降ろすかを決めるのが、この設計です。
見る頻度で置き場を分ける
CloudWatch Logs は、ログを置くだけでなく使うための置き場です。保存したログに対して、次のようなことができます。
- 語や条件に合うログを探し、Logs Insights で集計する。たとえば特定のステータスのログだけを絞り、パスごとの件数を並べるといった使い方です。
- メトリクスフィルターで、ログに出た語の回数をメトリクスにする。そのメトリクスにアラームを付ければ、通知までつなげられます。
つまり、障害の振り返りや通知に使うログは、CloudWatch Logs に置く価値があります。一方で、検索もアラームもせず、長く残すだけのログは、使わない機能のぶんまで検索向けの置き場に置き続けることになります。この分は S3 へ移す、という考え方です。
| 見る頻度 | 主な用途 | 置き場の考え方 |
|---|---|---|
| 毎日・障害のたび | 調査、アラーム、集計 | CloudWatch Logs |
| 月に数回 | 傾向の確認、定期レビュー | CloudWatch Logs。期間は見直す日数に合わせる |
| ほとんど見ない | 監査や説明の求めへの備え | S3 へ出して保管 |
どのくらいの日数を「毎日」「月に数回」と見るかは、ワークロードごとに違います。表は分け方の軸であって、数字の基準ではありません。
CHECK 4ここまでの確認
検索もアラームにも使わず、長く残すだけのログの置き場の候補は?
答えと解説
答え: 2. S3 に移して保管する
使わない分を検索向けの置き場に置き続けるより、サブスクリプションフィルターなどで S3 へ出す経路が候補になります。「長く残すときの経路」を読み直してください。
保持期間はどう決めるか
CloudWatch Logs の保持期間は、ロググループごとに設定します。そして、作ったままの初期設定は無期限です。放っておけば、何年前のログも残り続けます。
決める材料は 3 つです。
- 調査に要る期間: 障害が起きてから気づくまで、そして原因を探すまでに、どこまでさかのぼる必要があるか。リリースの周期や、問い合わせが来るまでの時間が手がかりになります。
- 守る理由: 監査や契約、社内の規程で、残すことが求められているログか。何年残すべきかは組織と法令で異なるため、この記事では断定しません。要件を確認したうえで、その期間を下限にします。
- 見る頻度: 検索に使う期間は CloudWatch Logs に置き、それを過ぎた分は S3 へ出すか、消すかを決めます。
もう 1 つ、削除の時間差に注意が必要です。期限を過ぎたログは、公式ドキュメントによれば通常は最大 72 時間までかかって削除されます。保持期間を短く変えた直後に、まだ残っているからといって設定の失敗とは限りません。
保持期間を決めずに無期限のまま運用すると、使わないログの保存が増え続けます。反対に短くしすぎると、必要なときに調べられません。このバランスを、図にすると次のとおりです。
KEEP AND SAVE残す長さの天秤
長く残す安心と、増え続けないことを釣り合わせる
長く残す
- 障害の調査で過去にさかのぼれる
- 監査や説明の求めに応える
- 傾向を長い目で比べられる
増やさない
- 保存の量が増え続けない
- 検索に使わない分を高い置き場に置かない
- 不要になったログを持ち続けない
支点は「誰が・どれくらいの頻度で・何のために見るか」
支点が「見る頻度と目的」であることが大切です。「念のため長く」でも「とにかく短く」でもなく、理由をつけて決めます。
CHECK 1ここまでの確認
ロググループを作ったあと、保持期間の設定を何も変えないと、ログはどうなる?
答えと解説
答え: 2. 期限なしで残り続ける
保持期間の初期設定は無期限です。残り続けるのは安心のためではなく初期値のためなので、決めずに放置しないことが要点です。「保持期間はどう決めるか」を読み直してください。
ロググループをどう切るか
ロググループは、ログストリームをまとめる入れ物です。公式ドキュメントでは、保持・監視・アクセスの設定が同じログストリームの集まりとして説明されています。ここから、切り方の原則が出ます。
- 保持期間を変えたいログは、別のグループに分ける。保持期間はグループ単位の設定のためです。
- アクセスできる人を分けたいログも、別のグループに分ける。
- 同じ監視の設定（メトリクスフィルターなど）をかけたいログは、同じグループに集める。
たとえば、アプリの通常ログと、一時的に詳細を出すデバッグ用のログを 1 つのグループに混ぜると、デバッグ用だけ早く消したいときに分けられません。逆に、同じアプリの同じ性質のログを細かく分けすぎると、アラームの設定が増えて管理が重くなります。
次の図は、ログの種類ごとに、置き場と期間をどう決めるかを並べたものです。
WHERE AND HOW LONGログの種類ごとに
ログの種類ごとに、置き場と期間の決め方が変わる
-
アプリ
アプリのログ — 障害調査とアラームに使う
CloudWatch Logs に置く。期間は調査に要る日数から
-
アクセス
アクセスログ — 集計して傾向を見る
直近は Logs Insights、古い分は S3 へ
-
監査
監査につながるログ — 守る理由で決まる
期間は組織と法令の要件から。S3 での長期保管を検討
-
デバッグ
デバッグ用の詳細ログ — 一時的に見る
短い期間で消す。出し続けるかも見直す
期間の数字を図に入れていないのは、組織と法令で違うからです。自分の環境の数字は、調査に要る日数と守る理由から決めます。
CHECK 2ここまでの確認
保持期間を別々にしたいログ同士を、1 つのロググループにまとめてよい?
答えと解説
答え: 2. まとめない。保持期間はロググループ単位の設定である
保持・アクセス・監視の設定は、ロググループ単位で共有されます。期間を分けたいログは別のグループに置きます。「ロググループをどう切るか」を読み直してください。
ログクラスの選び方
ログクラスは、ロググループが受け取るログの扱い方を決める設定です。公式ドキュメントでは、Standard と Infrequent Access などが挙げられています。選ぶときの要点は 2 つです。
- 作成後に変えられない。 ロググループを作る時点で決めます。あとから切り替えたいときは、新しいグループを作ることになります。
- Infrequent Access は取り込みの料金に差がつく一方、使えない機能がある。 サブスクリプションフィルターやメトリクスフィルターなどは、Standard のクラスでのみ使えます。
つまり、「アラームを鳴らしたい」「S3 へ転送したい」ログを Infrequent Access にすると、必要な機能が使えません。安さだけで選ばず、先に使う機能を並べてから選びます。具体的な金額や、どの機能が使えるかの最新の一覧は、公式のドキュメントと料金ページで確認してください。
| 項目 | Standard | Infrequent Access |
|---|---|---|
| 向く使い方 | 検索、アラーム、転送に使うログ | 使う機能が限られるログ |
| サブスクリプションフィルター | 使える | 使えない |
| メトリクスフィルター | 使える | 使えない |
| 作成後の変更 | できない | できない |
CHECK 3ここまでの確認
すでに作ったロググループのログクラスを、後から切り替えられる?
答えと解説
答え: 2. 切り替えられない。作る前に必要な機能で決める
ログクラスは作成後に変更できません。Infrequent Access ではサブスクリプションフィルターやメトリクスフィルターなどが使えないため、先に必要な機能を確かめます。「ログクラスの選び方」を読み直してください。
長く残すときの経路
長く残すだけの分は、S3 へ出します。CloudWatch Logs から外へ出す経路としてよく使われるのが、サブスクリプションフィルターです。ロググループに設定すると、ログが準リアルタイムで Amazon Data Firehose などへ流れ、そこから S3 に配信できます。たとえば、保持期間を超えて 1 年以上の分析をしたいときは、CloudWatch Logs に置き続けるのではなく、この経路で S3 に集めるのが定石です。
この経路には、次の特徴があります。
- 送る先は Kinesis、Firehose、Lambda などで、ログが出るのとほぼ同時に流れます。
- Standard のログクラスのロググループでのみ使えます（前の章のとおり）。
- 複数のアカウントのログも、別のアカウントの送り先に集められます。ログ専用のアカウントを置き、各アカウントのロググループから、その Firehose 経由で S3 に集める形が概観です。
S3 に出したあとは、S3 側で保管の期間を決めます。ここでも「見る頻度」と「守る理由」で決める点は同じです。なお、CloudWatch Logs から S3 へ書き出す別の方法（エクスポート）もありますが、この記事では扱いません。方式ごとの違いと制限は公式のドキュメントで確認してください。
決めたあとの確認
設計は決めたら終わりではありません。次の点を確かめます。
- 期限切れの時間差: 保持期間を変えたあと、削除までに時間差がある。すぐに消えないのは異常ではありません。
- ログが止まっていないか: 転送の経路を作ったあと、S3 に本当に届いているか。サブスクリプションフィルターの設定ミスは、ログが届かないという形で表に出ます。
- 費用の見え方: 保存と取り込みの量が、想定どおりに増えているか。急に増えたロググループがあれば、出し過ぎのログがないかを見直します。
Cloudory 執筆者（AWS 認定 全冠）
ログの保存は、決めておけば静かに働き、決めていなければ静かに膨らみます。最初の一歩は、自分のロググループの保持期間が「無期限」になっていないかを確かめることです。次に、そのログを誰が・どれくらいの頻度で・何のために見るかを一言で書いてみてください。置き場と期間は、その一言から決まります。何を見てどう鳴らすかは、次の 監視の設計 に続きます。
参照ソース
- Amazon CloudWatch Logs ユーザーガイド｜ロググループとログストリームの扱い — ロググループの定義、保持期間の初期設定が無期限であること、期限後の削除までの時間差の根拠（2026年10月時点）
- Amazon CloudWatch Logs ユーザーガイド｜ログクラス — Standard と Infrequent Access の違い、作成後に変更できないこと、使えない機能の根拠
- Amazon CloudWatch Logs ユーザーガイド｜サブスクリプションによるログデータのリアルタイム処理 — サブスクリプションフィルターによる準リアルタイム転送と、Standard クラスのみで使えることの根拠
