[アップデート] Amazon EventBridge Rule がすべてのターゲットタイプの認可に実行ロールを利用できるようになりました

#Amazon EventBridge

#AWS

たかくに

2025.03.12

こんにちは！クラウド事業本部コンサルティング部のたかくに（@takakuni_）です。
Amazon EventBridge Rule がすべてのターゲットタイプの認可に実行ロールを利用できるようになりました
https://aws.amazon.com/jp/about-aws/whats-new/2025/03/amazon-eventbridge-iam-execution-role-all-targets/
 アップデート内容アップデート前まで、以下のリソースを EventBridge のターゲットにする場合、認可には EventBridge の実行ロールを利用できませんでした。
Amazon SQS
Amazon SNS
Lambda
CloudWatch Logs
EventBridge Bus
そのため、ターゲット側のリソースベースポリシーで EventBridge からの API 実行を許可する必要がありました。
 Lambdahttps://dev.classmethod.jp/articles/lambda-resourcebase-policy/#toc-cloudformation
 SNShttps://dev.classmethod.jp/articles/event-bridge-notify-sns/
 SQShttps://repost.aws/ja/knowledge-center/sqs-eventbridge-notification-failures
今回のアップデートで、これらのリソースに対しての認可にも IAM ロールを利用できるようになりました。つまり、すべてのターゲットに対して認可に EventBridge 側の IAM ロールを利用できるようになったということです。
なお、今回のアップデートでターゲットへの認可には EventBridge 側の IAM ロールを利用することが推奨されるようになりました。
!クロスアカウントでターゲットを指定する場合は、引き続きリソースベースポリシーでの認可になります。ご注意ください。
参考：[アップデート]Amazon EventBridgeで別のアカウントのリソースに直接イベントを配信できるようになりました！ | DevelopersIO
 やってみた今回は EventBridge + SNS の組み合わせを試してみたいと思います。
 SNS トピックの作成SNS トピックを作成します。名前や表示名は適当なものを命名します。
トピックポリシーは ベーシック を選択します。
以下のように EventBridge からの認可を特別設定はしません。
topic.json
{
  "Version": "2008-10-17",
  "Id": "__default_policy_ID",
  "Statement": [
    {
      "Sid": "__default_statement_ID",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": [
        "SNS:Publish",
        "SNS:RemovePermission",
        "SNS:SetTopicAttributes",
        "SNS:DeleteTopic",
        "SNS:ListSubscriptionsByTopic",
        "SNS:GetTopicAttributes",
        "SNS:AddPermission",
        "SNS:Subscribe"
      ],
      "Resource": "arn:aws:sns:ap-northeast-1:123456789012:eventbridge-udpate",
      "Condition": {
        "StringEquals": {
          "AWS:SourceOwner": "123456789012"
        }
      }
    }
  ]
}
 EventBridge ルールの作成続いて EventBridge ルールの作成です。こちらも適当な名前を命名します。
今回は Custom イベントパターンを想定して、フィルタリングルールを作成します。detail の event に update! が来た場合に発砲するよう設定します。
{
  "detail": {
    "event": ["update!"]
  }
}
続いてターゲットの選択画面です。新しく 実行ロールを使用 (推奨) が増えています。
この特定のリソースについて新しいロールを作成または、既存のロールを使用の 2 パターンがあります。今回は この特定のリソースについて新しいロールを作成 を指定します。
レビューと作成画面に移ります。問題なければ作成をクリックします。
 イベント送信フィルタパターンに沿った、イベントを送信してみます。
{
  "detail": {
    "event": "update!"
  }
}
サブスクリプション（メールアドレス）宛に通知が飛んできていますね。
 認可部分を確認認可部分を確認してみます。まずは IAM ロールからです。
SNS トピックに飛ばす用のポリシーのみが設定されていますね。
 IAM ポリシーevent_iam.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sns:Publish"
            ],
            "Resource": [
                "arn:aws:sns:ap-northeast-1:123456789012:eventbridge-udpate"
            ]
        }
    ]
}
 信頼関係ポリシーevent_assume.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "events.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}
続いて SNS のトピックポリシーです。
マネジメントコンソールの操作で書きかわっていないか、再度確認します。
確認したところ、書き変わりは発生していませんでした。
 まとめ以上、「Amazon EventBridge Rule がすべてのターゲットタイプの認可に実行ロールを利用できるようになりました」でした。ターゲットごとにリソースベースポリシー、実行ロールの IAM ポリシーと、使い分けが必要だったものが非常にシンプルになりました。新しく作成するものは推奨に乗っかり、タイミング見計らって既存のものも変更できると良いですね。
このブログがどなたかの参考になれば幸いです。
クラウド事業本部コンサルティング部のたかくに（@takakuni_）でした！