CloudWatch Logs Intelligent Tiering を Organizations 配下に一括有効化してみた
こんにちは
財布には アーカイブする 中身なし
運用イノベーション部のかわいです。
9月に入り涼しくなりましたね。
少し前ですが、2026年7月に 以下 CloudWatch Logs のアップデートがありました。
以下のブログで詳しく解説されていますが、今回のアップデートで、CLoudWatch Logs がアクセス頻度に応じてログを自動的に3階層のストレージクラスに分類してくれるようになりました。今のところコスト面でもメリットしかなく、有効化しない手はないと思います。やったねたえちゃん！
有効化の注意点としては、上記ブログにも記載のある通り、
アカウント単位・リージョン単位で有効化します。有効化すると、そのリージョン内のアカウント配下のすべてのロググループに適用されます。
なので、「このロググループでは無効にして、こっちでは有効化」みたいな細かい設定はできません。が、あんまりユースケースは思いつかないので、一律で問題ないかなと思います。
本記事では、Organizations 環境で CloudFormation StackSets から OU に対して一括有効化する方法の検証を実施したので紹介します。
前知識など
前述の通り、有効化はアカウントxリージョン単位のみになります。
使用する API は PutStorageTierPolicy のみ、パラメータも storageTier のみなのですごくシンプルです。
また、中東リージョンのバーレーンUAEは対象外のため指定不可です。
使用するテンプレート
以下のAWS::Logs::StorageTierPolicy がシンタックスとして用意されているので、こちらを使います。
今回使用したテンプレートは以下。すごくシンプルに収まります。
出力に何を実施したかがわかるよう Outputsを追加していますが、こちらは任意です。
AWSTemplateFormatVersion: "2010-09-09"
Description: "Enable CloudWatch Logs Intelligent Tiering at account level"
Resources:
LogsStorageTierPolicy:
Type: AWS::Logs::StorageTierPolicy
Properties:
StorageTier: INTELLIGENT_TIERING
Outputs:
AppliedAccountId:
Description: "AWS account ID the storage tier policy was applied to"
Value: !GetAtt LogsStorageTierPolicy.AccountId
適用までのおおまかな流れ
組織全体に適用する場合、以下のような流れになります。
1.委任管理者（今回はAudit）から スタックセットを作り、OU 単位で流す
2.各アカウントで aws logs get-storage-tier-policy を叩いて確認する
※管理Payerのみ、通常のCFnスタックから個別に有効化する（後述）
おまけ）なぜ管理Payerだけ個別対応なのか
サービスマネージドの CloudFormation StackSets は、管理Payer自身にはスタックを流しません。
CloudFormation doesn't deploy stacks to the management account, even if that account is part of your organization or belongs to an organizational unit (OU).
上記からも、スタックセットではなく、通常のスタックから設定を流します。
（手順はほぼ同じ）
検証
今回は Audit アカウントを CloudFormation 委任管理者として指定し、Auditアカウントから実施します。
スタックセットの作成
まず、CloudFormation から StackSets を作成します。
CloudFormation メニューに遷移し、【StackSets】から【スタックセットを作成】をクリックします。
以下のように、上述のテンプレートファイルをアップロードします。
適用する OU やリージョンを選択し、次に進みます。
※OU を個別に指定する際は、Organizations から各IDを確認しておきます。
その他はだいたいデフォルトでokなので、流します。
▼成功しました
ちなみに、上記テンプレートのOutputsを付与しておけば、以下のようにメモが残せます。
適用されたか確認する
どこでもいいので、今回適用対象のアカウントに移動します。
CLoudWatch ロググループ一覧からは確認できないので、CloudShell等から以下で確認します。
aws logs get-storage-tier-policy --region ap-northeast-1
{
"storageTier": "INTELLIGENT_TIERING",
"lastUpdatedTime": 1789691046625 # エポックミリ秒なので実際は 2026/9/18 9:24:06（JST）
}
これで有効化が確認できました。
適用はアカウント単位になるので、上記のように INTELLIGENT_TIERING に切り替わっていることが確認できればOKです。
（通常はSTANDARD等が返ります。）
まとめ的な
今回、Organizations 配下への CloudWatch Logs Intelligent Tiering の有効化を、CloudFormation StackSets から検証しました。
テンプレートはシンプルな1リソースだけで済むので、導入は容易です。
留意点として、管理アカウントに対してはサービスマネージドのスタックセットが使えないので、通常スタックで対応する必要があります。
また、階層移行はすぐに走らないため、1ヶ月程度ラグが出てきます。
（Infrequent Access へ落ちるのは30日連続未アクセスのロググループ）
ただ、ログ容量によっては保存料金などが大幅に改善できる可能性があるため、特にアカウント数の多い組織では有効化にしない手はないと思います。
この記事が運用管理者の方のヒントになれば幸いです。
完
参考
