CloudWatch LogsのIAM変更は2027年4月26日から

AWS が CloudWatch Logs の IAM ポリシーの評価方法を、2027年4月26日から変えることを、AWS Health の通知で利用者に知らせています。ロググループの操作を許可するときは「ロググループの ARN」が必須になり、末尾が「:*」のログストリーム形式の ARN だけを書いたポリシーは、一部の操作が許可されなくなります。

Using identity-based policies (IAM policies) for CloudWatch Logs

はてなブックマークのテクノロジーでも、この変更を確かめた技術ブログが話題になりました。期限まではまだ半年近くありますが、Lambda や CodeBuild 用に作られたポリシーが対象になる例も報告されているため、早めに棚卸ししておきたい変更——という位置づけです。

CloudWatch LogsのIAM変更とは？一言でまとめると

一言でいうと、「ロググループの操作にはロググループの ARN を書く」というルールが厳密に適用される変更です。

通知の文面は、AWS の GitHub（awslabs）にある Solutions Constructs チームの Issue で公開されています。そこでは「今はログストリームの ARN でもロググループの操作が許可されるが、変更後は許可されない」と説明されています。

何が変わる？ロググループとログストリームのARN

CloudWatch Logs には、ロググループ（ログの入れ物）と、その中のログストリーム（ログの流れ1本ずつ）という2種類のリソースがあります。AWS のドキュメントでは、それぞれ ARN の形が決まっています。

ドキュメントでは、ポリシーに書く ARN は、その API が認可に使うリソースの種類と一致させる必要があるとされています。たとえば次のように分かれます。

• ロググループで認可される操作（例）: DeleteLogGroup・PutRetentionPolicy・PutSubscriptionFilter・DescribeLogStreams → 末尾の「:*」なしの ARN
• ログストリームで認可される操作（例）: CreateLogStream・PutLogEvents・GetLogEvents → 「:*」付きの ARN

これまでは、「:*」付きの ARN だけを書いても、ロググループの操作まで許可されていました。2027年4月26日からはそれが通らなくなる、というのが今回の変更です。

影響を受けるのはどんなポリシー？

影響を受けるのは、ロググループの操作を、ログストリーム形式の ARN だけで許可している文です。AWS が公開している調べ方（後述）では、次の2つを拾います。

① ロググループの ARN が「:*」で終わる

もっとも多いのがこの形です。たとえば次のような文は、CreateLogStream・PutLogEvents には問題ありませんが、同じ文に入っている CreateLogGroup や DescribeLogStreams は、変更後に許可されなくなります。

{
  "Effect": "Allow",
  "Action": [
    "logs:CreateLogGroup",
    "logs:CreateLogStream",
    "logs:PutLogEvents",
    "logs:DescribeLogStreams"
  ],
  "Resource": "arn:aws:logs:ap-northeast-1:123456789012:log-group:my-app:*"
}

② ARN に「:log-stream:」を含む

特定のログストリームを指す ARN で、ロググループの操作を許可している文も対象です。

③ ログストリームの単位のままの4つは影響なし

通知では、PutLogEvents・GetLogEvents・CreateLogStream・DeleteLogStream の4つはログストリームの単位のままとされています。これらだけを許可している文は、今の「:*」の書き方で問題ありません。

つまり、「ログを書き込むだけ」の文は大丈夫で、ロググループを作る・保持期間を変える・ストリームの一覧を取るといった操作が混ざっている文が要注意です。

AWSからの通知はどこで見られる？

この変更は、AWS Health の Planned Lifecycle Event（計画されたライフサイクルイベント） として通知されています。AWS のユーザーガイドによると、Planned Lifecycle Event は利用者の対応が必要な変更を前もって知らせる仕組みです。

• AWS Health ダッシュボード: カレンダー表示や「影響するリソース」の表示で確認できる
• Amazon EventBridge: イベントを受け取って Slack などに流せる
• AWS Health API: 影響するリソースをプログラムから取得できる

影響するリソースは ARN で示され、通常は対応が必要なものが PENDING、対応済みのものが RESOLVED になります。ただし今回の通知では、影響するリソースの状態は自動では更新されないと書かれています。直したあとは、自分でスクリプトを使って確かめることになります。

あわせて読みたい

サブドメイン乗っ取りとは？AWSで起きる原因と対策【2026年版】

対応方法：今の文は残して、ロググループのARNの文を足す

通知が求めているのは、ログストリームの ARN でロググループの操作を許可している文を、変更の前に直すことです。直し方は、AWS のドキュメントの例（例 3c）と同じく、文を2つに分けるのが基本です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:DescribeLogStreams"
      ],
      "Resource": "arn:aws:logs:ap-northeast-1:123456789012:log-group:my-app"
    },
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents",
        "logs:DescribeLogStreams"
      ],
      "Resource": "arn:aws:logs:ap-northeast-1:123456789012:log-group:my-app:*"
    }
  ]
}

ポイントは2つです。

• 1つ目の文（追加）: ロググループの操作を、末尾の「:*」なしのロググループ ARN で許可する
• 2つ目の文（今のまま）: 既存の「:*」の文は消さずに残す。4つのログストリームの操作には、引き続きこの文が必要

kakakakakku さんのブログに引用されている通知の文面でも、既存の文を残しておくことで、変更がリージョンごとに広がる間も中断なく使えると説明されています（出典）。「書き換える」のではなく「足す」と考えると安全です。

Terraform・CDK・Serverless Framework などでロールを作っている場合は、生成されるポリシーを直すか、ツールの更新を待つことになります（後述の「開発者の反応」を参照）。

確認方法：CloudWatch Logs IAM Policy Validator

AWS は GitHub の aws-samples で、影響するポリシーを探す手順と、変更前後の評価を比べるスクリプトを公開しています。どちらも読み取りだけで、ポリシーは変更しません。

リポジトリ: aws-samples/sample-cloudwatch-logs-iam-policy-validator（GitHub）

① 影響するポリシーを探す（LIST_IMPACTED_POLICIES）

aws iam get-account-authorization-details の結果を jq で調べ、ロググループの ARN が「:*」で終わるもの・「:log-stream:」を含むものを一覧にします。

② 変更前後の評価を比べる（simulate_cloudwatch_logs_policy.py）

ポリシーの JSON をファイルに保存し、ロググループ名を指定して実行します。

python3 simulate_cloudwatch_logs_policy.py policy.json my-app \
    --region ap-northeast-1 --account-id 123456789012

スクリプトは IAM の SimulateCustomPolicy を使い、CloudWatch Logs の各操作をログストリームの ARN とロググループの ARN の両方で試します。結果の LogGroup の列が implicitDeny（暗黙の拒否）なら、その操作は変更後に許可されないという意味です。

kakakakakkuさんが試した手順と結果

技術ブログ「kakakakakku blog」の kakakakakku さんは、個人の検証用の AWS アカウントに AWS Health から通知が届いたことをきっかけに、このスクリプトを試した結果を公開しています（出典）。

• テスト用のロール: ECS のタスクロールを想定したロールを Terraform で作り、「:*」の ARN でロググループとログストリームの操作をまとめて許可した
• 影響するポリシーの洗い出し: jq の手順で、そのロールのほか、Lambda や CodeBuild のサービスロール用に作られたポリシーも見つかった
• 変更前: スクリプトの結果で、CreateLogGroup・PutRetentionPolicy・DescribeLogStreams がロググループの ARN では暗黙の拒否になった
• 変更後: 既存の文を残したまま、ロググループの ARN の文を足したところ、3つの操作がどちらの ARN でも許可された

kakakakakku さんは、洗い出しに使う jq のフィルターがとても複雑だったとも書いています。そのうえで、ロググループ形式とログストリーム形式の ARN をそれぞれ適切に許可しようとまとめています（出典）。

開発者の反応：OSSでも対応が進む

Lambda のロールを自動で作るツールでも、対応の Issue が出ています。

• Serverless Framework: Lambda 用に生成される実行ロールで、CreateLogGroup・TagResource が「:*」の ARN の文に入っているとして、ロググループの ARN の文を足す提案が出ています（出典）
• osls（Serverless Framework のオープンソースのフォーク）: 同じ内容の Issue に対し、メンテナーが v3・v4 の両方で対応済みとコメントしています（出典）

自分で JSON を書いていなくても、ツールが生成したロールが対象になることがあります。使っているツールの Issue やリリースノートも確認しておくと安心です。

注意点：公開の発表はまだ少ない

① What’s New・ドキュメントの更新履歴にはまだ載っていない

2026年11月4日時点では、AWS の What’s New や CloudWatch Logs のドキュメントの更新履歴に、この変更の項目は見当たりません。日付と内容は、AWS Health の通知（AWS の GitHub で公開された文面）にもとづいています。自分のアカウントの AWS Health ダッシュボードで通知の有無を確かめてください。

② AWS 管理ポリシーは洗い出しの対象外

aws-samples の手順は、顧客管理ポリシーとインラインポリシーだけを調べます。AWS 管理ポリシーの扱いは手順に書かれていないため、通知の「影響するリソース」もあわせて確認するのが確実です。

③ 期限の前に壊れるわけではない

変更は2027年4月26日からです。AWS Health のユーザーガイドでも、イベントの開始時刻を「変更の日」として扱うよう書かれています。それまでに文を足しておけば、今の動作は変わりません。

あわせて読みたい

AWS耐量子TLS、Aurora・CloudFrontで拡大【2026年10月】

IT Picks的な所感

今回の変更は、ドキュメントに書かれていた「ARN の形はリソースの種類に合わせる」というルールを、実際の評価でも守らせるものだと受け止めています。kakakakakku さんの検証用アカウントでも、自分で作ったロールのほかに Lambda や CodeBuild 用のポリシーが見つかったように、気づかないうちに対象になっているアカウントは少なくないと思います。

一方で、直し方は文を1つ足すだけで、既存の文を消す必要もありません。AWS が読み取り専用の確認スクリプトまで用意しているのも親切です。期限が近づいてから慌てるより、次にロールを触るタイミングでまとめて足しておくのがよさそうです。

気になるのは、What’s New のような公開の発表がまだ無い点です。通知を見落としたアカウントや、ツールで自動生成したロールが取り残されないよう、AWS からの正式なアナウンスやドキュメントの更新を待ちたいところです。

あわせて読みたい

クラウド無料枠を比較：AWS・GCP・Azure・OCI【2026年版】

よくある質問

Q. Resource を「*」にしているポリシーも直す必要がありますか？

A. aws-samples の洗い出し手順が拾うのは、ロググループの ARN が「:*」で終わるものと「:log-stream:」を含むものです。すべてのリソースを指す「」は、この条件には当てはまりません。迷ったら、確認スクリプトでそのポリシーを試す*と確実です。

Q. PutLogEvents しか使っていないロールも対象ですか？

A. 通知では、PutLogEvents・GetLogEvents・CreateLogStream・DeleteLogStream の4つはログストリームの単位のままとされています。これらだけを許可している文は、今の書き方のままで問題ありません。

Q. 既存の「:*」の文は消してよいですか？

A. 消さないでください。4つのログストリームの操作には「:」の文が必要です。ロググループの ARN の文を足す*形で直します。

まとめ

CloudWatch Logs の IAM ポリシーの変更のポイントをまとめます。

• 変更日：2027年4月26日
• 変わること：ロググループの操作にはロググループの ARN（末尾の「:*」なし）が必要
• 影響を受ける書き方：「:*」や「:log-stream:」の ARN だけでロググループの操作を許可している文
• そのままでよい操作：PutLogEvents・GetLogEvents・CreateLogStream・DeleteLogStream
• 直し方：既存の文は残して、ロググループの ARN の文を足す
• 確認方法：aws-samples の CloudWatch Logs IAM Policy Validator（読み取り専用）
• 通知：AWS Health の Planned Lifecycle Event（What’s New には11月4日時点で未掲載）

まずは AWS Health ダッシュボードで通知が届いていないかを確かめ、届いていれば影響するリソースから順に文を足していきましょう。

IT Picks 編集部

ITツール・Webサービス紹介メディア

IT Picks 編集部。VPS・クラウド・AIツール・SaaSを中心に、実際に検証した情報を届けるITメディアです。「本当に使えるか」を基準に、初心者からエンジニアまで役立つ記事を制作しています。