CloudWatch Eventsは、Amazon EventBridgeの以前の名前です。2019年7月にEventBridgeが発表されたとき、CloudWatch EventsのAPIはそのまま引き継がれ、作成済みのルールは何も変更せずに動き続けています。一方、CLIやIAM、CloudFormationとTerraformのリソース名には旧名が残っており、移行作業が要るのかと迷う原因になっています。本記事では、互換の範囲、旧名が残る箇所の対応表、既存ルールをAWS CLIとboto3で棚卸しする手順、見直すと挙動が変わる設定を整理しました。EventBridge全体の仕組みはAmazon EventBridgeとは？仕組み・料金とCLI・Pythonでの実装手順で扱っています。仕様は2026年10月時点の公式ドキュメントの記載です。
まとめ：CloudWatch EventsはEventBridgeの旧名で既存ルールは作り直し不要
CloudWatch EventsとEventBridgeは別のサービスではありません。EventBridgeはCloudWatch EventsのAPIをそのまま使っており、CloudWatch Eventsの画面で作ったルールは、EventBridgeのコンソールでも同じものとして見えます。違いは、EventBridgeになってからカスタムイベントバス、SaaSのパートナーイベント、スキーマレジストリ、Pipes、Schedulerが加わった点です。新しい機能はEventBridge側にしか追加されません。
移行のために既存ルールを作り直す必要はありません。CLIのaws eventsやTerraformのaws_cloudwatch_event_ruleは、現在のEventBridgeを操作する正式な名前です。見直す価値があるのは中身で、CloudTrailの読み取り専用イベントを拾うルールの状態と、スケジュールされたルールをEventBridge Schedulerへ移すかどうかの2点です。
CloudWatch Eventsの改称経緯とAPI互換が保たれる仕組み
まず、なぜ2つの名前が並んでいるのかを押さえます。経緯が分かると、どこを直す必要がないかも判断できます。
2019年7月11日のEventBridge発表と旧APIの継承
EventBridgeは2019年7月11日のAWSの発表で登場しました。発表文には、EventBridgeがCloudWatch Events APIを利用するため、CloudWatch Eventsの利用者は新しいEventBridgeコンソールとCloudWatchのイベントコンソールの両方から、既存のデフォルトバス・ルール・イベントにアクセスできると書かれています。発表時点の対応は、10のSaaSパートナーと90以上のAWSサービスでした。
データの移し替えは起きていません。同じ仕組みに新しい名前とコンソールが付いた関係です。
後方互換が明言されCloudFormationやAPI呼び出しの変更は不要
AWSのブログUpgrading to Amazon EventBridge from Amazon CloudWatch Eventsは、EventBridgeがCloudWatch Events APIを使い完全な後方互換を持つため、既存のCloudFormationテンプレートやAPI呼び出しを変更する必要はない、と明言しています。利用者の操作は、EventBridgeのコンソールを開くことだけとされています。
同じ記事は、新機能がEventBridge経由でしかリリースされないとも書いています。
デフォルトバス1本の時代から追加されたカスタムバスとスキーマ
CloudWatch Eventsには、各アカウントに1本ずつあるデフォルトバスしかありませんでした。AWSサービスのイベントも自作アプリのイベントも、すべてこのバスに流れます。EventBridgeで加わった主な機能は次のとおりです。
- 自社のワークロード専用に作れるカスタムイベントバス（作成自体は無料）
- ZendeskやDatadogなどのSaaSから届くパートナーイベントバス
- イベントの構造を自動で検出して記録するスキーマレジストリとコードバインディング
- 後年に追加された1対1統合のPipesと、定期実行・1回限りの実行を管理するScheduler
実務で効くのはカスタムバスです。バスを分けると、リソースポリシーでどのアカウントに送らせるかをバス単位で決められます。バスの使い分けと他アカウントへの開き方はEventBridge イベントバスの使い分け：クロスアカウント・リージョン送信のポリシー設定にまとめています。
旧ユーザーガイドとAPIリファレンスはEventBridge側へ転送済み
2026年10月17日に確かめたところ、CloudWatch EventsのユーザーガイドのURLはEventBridgeのユーザーガイドへ転送され、CloudWatch EventsのAPIリファレンスのURLもEventBridgeのAPIリファレンスへ転送されました。古い手順書に行き当たったら、画面名だけが古く、APIの名前と引数は今も同じと読めば足ります。
アラーム通知のCloudWatchイベントとCloudWatch Eventsの区別
名前が似ていて取り違えやすいのが、CloudWatch自身が送るイベントです。Amazon CloudWatchのイベント一覧のとおり、アラームの状態が変わるとCloudWatchはsourceがaws.cloudwatch、detail-typeがCloudWatch Alarm State ChangeのイベントをEventBridgeへ送ります。
{
"source": ["aws.cloudwatch"],
"detail-type": ["CloudWatch Alarm State Change"]
}これは「CloudWatchが発生源のイベント」で、サービス名のCloudWatch Eventsとは別物です。パターンの演算子はEventBridge イベントパターンの書き方で解説しています。
CloudWatch Eventsの旧名が残る操作名とリソース名の対応表
EventBridgeを操作する名前の多くに、CloudWatch Events時代の「events」や「cloudwatch_event」が残っています。どれも現在の正式な名前で、置き換える先はありません。
CLIのaws eventsとIAMのevents:に残る正式名
CLI・IAM・IaC・SDKの層ごとに、現在の操作名と旧名との関係を並べると次のようになります。プレフィックスやリソース名の読み替えは、この対応表で確認できます。
| 層 | 現在の名前の形 | 旧名との関係 |
|---|---|---|
| AWS CLI | aws events | 旧時代から同じ |
| エンドポイント | events.リージョン名 | 同じ |
| IAMアクション | events:アクション名 | 同じ |
| マネージドポリシー | AmazonEventBridge系 | 旧名も残存 |
| CloudFormation | AWS::Events::Rule | 同じ |
| Terraform | aws_cloudwatch_event系 | 同じ |
| boto3 | client(“events”) | 同じ |
| JS SDK v3 | client-eventbridge | 旧名と並存 |
EventBridgeのエンドポイント一覧では、東京リージョンはevents.ap-northeast-1.amazonaws.comです。「events」はEventBridgeのサービス名として今も使われており、events:*で書いた既存のIAMポリシーもそのまま効きます。
CloudWatchEventsFullAccessの権限更新と扱い
EventBridgeのマネージドポリシーの更新履歴によると、2022年12月1日にCloudWatchEventsFullAccessはAmazonEventBridgeFullAccessに、CloudWatchEventsReadOnlyAccessはAmazonEventBridgeReadOnlyAccessに一致するよう更新されました。どちらを付けても権限の範囲は同じです。
IAMの棚卸しで旧名のポリシーが古いものと誤って外されないよう、新しく作るロールからAmazonEventBridge*へ寄せていくのが安全です。ただしAmazonEventBridgeFullAccessにはPipes・スキーマ・Schedulerの操作とiam:PassRoleまで含まれるため、本番のロールにはルールとターゲットの操作だけを並べた自前のポリシーを付けます。ポリシーの種類の違いはAWS IAMとはで整理しています。
CloudFormationとTerraformに残る旧リソース名の対応
CloudFormationでEventBridgeのルールを書くリソースタイプは、AWS::Events::Ruleのままです。EventBusNameでカスタムバスを指定でき、StateにはENABLED・DISABLED・ENABLED_WITH_ALL_CLOUDTRAIL_MANAGEMENT_EVENTSの3値が入ります。テンプレートの書き方はAWS CloudFormationとはで扱っています。
TerraformのAWSプロバイダーにもaws_eventbridge_ruleという名前のリソースは無く、aws_cloudwatch_event_ruleのドキュメントに「EventBridgeは以前CloudWatch Eventsと呼ばれていた。機能は同一」と注記されています。2026年10月15日公開の6.69.1系でも同じ名前です。
resource "aws_cloudwatch_event_rule" "nightly_batch" {
name = "nightly-batch"
description = "毎日 03:00 JST（18:00 UTC）に起動"
schedule_expression = "cron(0 18 * * ? *)"
state = "ENABLED"
}
resource "aws_cloudwatch_event_target" "nightly_batch" {
rule = aws_cloudwatch_event_rule.nightly_batch.name
arn = aws_lambda_function.batch.arn
}古いコードでis_enabled = trueと書いてある場合、この引数は非推奨でstateへの置き換えが案内されています。両方を同時には書けません。schedule_expressionはデフォルトバスのルールにしか使えない点も、カスタムバスへ寄せるときに引っかかります。プロバイダーの認証やバックエンドの設定はTerraformでAWSを構築する手順を参照してください。
JavaScript SDK v3で旧名とEventBridge名が並存
JavaScriptのAWS SDK v3には、@aws-sdk/client-cloudwatch-eventsと@aws-sdk/client-eventbridgeの2つのパッケージがあり、2026年10月17日にnpmのレジストリで確かめた最新版はどちらも3.1152.0でした。
新しく書くコードで選ぶのはclient-eventbridgeです。ドキュメントやサンプルもEventBridgeの名前で探すほうが見つけやすいです。既存コードのclient-cloudwatch-eventsは、依存を更新するついでに揃える程度で足ります。SDK v3のパッケージ構成はAWS SDK for JavaScript v3の使い方で解説しています。
既存ルールをEventBridgeの名前で確かめるCLIとboto3の棚卸し手順
作り直しは不要でも、旧時代のルールが何を動かしているかは把握しておきます。
list-rulesとlist-targets-by-ruleでバスごとのルールを一覧化
AWS CLIでバスの一覧を取り、バスごとのルールと、ルールごとのターゲットを確かめます。--event-bus-nameを省くとデフォルトバスが対象です。
aws events list-event-buses --region ap-northeast-1 --query "EventBuses[].Name" --output text
aws events list-rules --region ap-northeast-1 --event-bus-name default \
--query "Rules[].{Name:Name,State:State,Schedule:ScheduleExpression,Pattern:EventPattern}" \
--output table
aws events list-targets-by-rule --region ap-northeast-1 --event-bus-name default \
--rule nightly-batch --query "Targets[].{Id:Id,Arn:Arn,Role:RoleArn}" --output tableSchedule列に値があるルールはスケジュールされたルール、Pattern列に値があるルールはイベントに反応するルールです。StateがDISABLEDのまま放置されたルールも、この一覧で見つかります。
boto3のclient(“events”)で全バスのルールをCSVへ書き出す
複数のアカウントやリージョンで棚卸しするなら、Pythonで書き出すほうが楽です。boto3のクライアント名も"events"のままです。
import csv
import boto3
client = boto3.client("events", region_name="ap-northeast-1")
def list_all(method, key, **kwargs):
"""NextToken を辿って全件を返す"""
items, token = [], None
while True:
params = dict(kwargs, NextToken=token) if token else kwargs
resp = method(**params)
items.extend(resp.get(key, []))
token = resp.get("NextToken")
if not token:
return items
with open("eventbridge_rules.csv", "w", newline="", encoding="utf-8") as f:
writer = csv.writer(f)
writer.writerow(["bus", "rule", "state", "schedule", "has_pattern", "targets"])
for bus in list_all(client.list_event_buses, "EventBuses"):
for rule in list_all(client.list_rules, "Rules", EventBusName=bus["Name"]):
targets = list_all(client.list_targets_by_rule, "Targets",
Rule=rule["Name"], EventBusName=bus["Name"])
writer.writerow([
bus["Name"], rule["Name"], rule.get("State"),
rule.get("ScheduleExpression", ""), "EventPattern" in rule,
" ".join(t["Arn"] for t in targets),
])実行ロールにはevents:ListEventBuses・events:ListRules・events:ListTargetsByRuleを許可します。schedule列が埋まった行が、Schedulerへの移し替えの検討対象です。クライアントの認証とリトライの設定はboto3とはを参照してください。
移行を機に見直すと挙動が変わるルールの状態とスケジュールの差分
名前を揃える作業は不要でも、CloudWatch Events時代の前提のまま設定を書き足すと、期待どおりに動かない箇所が2つあります。
ENABLEDのルールはCloudTrailの読み取り専用管理イベントに不一致
ルールの状態には、CloudWatch Events時代の「有効・無効」に加えてENABLED_WITH_ALL_CLOUDTRAIL_MANAGEMENT_EVENTSがあります。PutRuleのAPIリファレンスでは、Stateの有効な値はこの3つです。
CloudTrail経由のイベントの項によると、書き込み系の管理イベントは通常のENABLEDで一致しますが、Describe*やGet*のような読み取り専用の管理イベントは、状態をENABLED_WITH_ALL_CLOUDTRAIL_MANAGEMENT_EVENTSにしたルールでしか一致しません。「誰かが機密データを読み出したら通知する」といったルールをENABLEDで作ると、エラーも出ずにターゲットが呼ばれないままになります。
aws events put-rule --region ap-northeast-1 --name detect-secret-read \
--event-pattern file://secret-read.json \
--state ENABLED_WITH_ALL_CLOUDTRAIL_MANAGEMENT_EVENTSCloudTrailのイベントはデフォルトバスにしか届きません。カスタムバスで処理したい場合に必要なのは、デフォルトバスに作る転送用のルールです。読み取り専用イベントを別のバスへ転送するときは、デフォルトバスの転送ルールと送信先バスのルールの両方をこの状態にする必要があります。証跡の設定はCloudTrailとはで解説しています。
スケジュールされたルールはレガシー扱いでSchedulerが推奨
CloudWatch Events時代によく使われた定期実行のルールは、現在のドキュメントでスケジュールされたルール（レガシー）と表記され、EventBridge Schedulerを使うよう勧められています。ルールのcron式の例はすべてUTC+0で書かれており、日本時間で動かすには9時間ずらして書きます。1分より短い間隔は組めません。
EventBridge Schedulerの案内では、スケジュールごとにタイムゾーンを選べ、フレックスタイムウィンドウ、最大再試行回数、1回限りのスケジュールも設定できます。注意点は権限の持ち方で、CLIやSDKでスケジュールを作るときは、ターゲットを呼び出す実行ロールを自分で用意する必要があります。この実行ロールの準備も、既存ルールから移す際の確認対象です。SchedulerのAPIとcron式の書き方はEventBridge SchedulerのAPIにまとめています。
既存ルールを残す条件とSchedulerやカスタムバスへ移す条件の判断基準
ここまでの差分を踏まえて、手を入れるかどうかを決めます。名前を理由にした作り直しはしない、というのが前提です。
改称だけを理由に稼働中の既存ルールを作り直さないための判断基準
CloudWatch Eventsの名前で作られたルールでも、EventBridgeのルールとして正しく動いています。作り直すと増えるのは、IAMポリシーのResourceや監視の設定とずれるリスクだけです。CloudFormationの論理IDやTerraformのリソースアドレスを名前に合わせて書き換えると、差分としては削除と作成になり、切り替えの間にイベントを受けない時間ができます。
手を入れてよいのは、棚卸しで持ち主の分からないルールやDISABLEDのまま残るルールが見つかったときです。不要なものは削除し、残すものはIaCの管理下に入れます。
Schedulerやカスタムバスへ既存ルールを移す条件と見送る場面
次のどれかに当たるなら、既存のルールをSchedulerやカスタムバスへ移します。
- 定期実行を日本時間で管理したい、または1回限りの実行や再試行回数を指定したい（Schedulerへ）
- デフォルトバスのルールが増え、AWSサービスのイベントと自社アプリのイベントが混ざって見通しが悪い（カスタムバスへ）
- 別のアカウントのチームにイベントを渡す必要が出てきた（カスタムバスとリソースポリシー、または新しいCustom Event Busへ）
反対に、毎日1回のバッチをUTCで書いたルールが問題なく動いていて、変更の予定もないなら、移す必要はありません。Schedulerへ移すと実行ロールの作成とスケジュールの検証が増え、得られる差はタイムゾーンの書き方だけになるためです。CloudWatch Events時代から積み上がったルールの整理や、IaCへの取り込み、イベント駆動の構成の見直しはインフラ構築（AWS・Google Cloud・Azure）でご相談いただけます。
よくある質問
CloudWatch EventsとEventBridgeの違いについてよく出る疑問に、公式ドキュメントの記載をもとに答えます。
CloudWatch Eventsのルールは将来使えなくなりますか？
2026年10月時点で確認した公式ドキュメントとAWSのブログには、CloudWatch Eventsで作ったルールやAPIの提供終了の告知は見当たりません。CloudWatch EventsのAPIはEventBridgeのAPIそのものです。ただしスケジュールされたルールはレガシー機能と表記されているため、新しい定期実行はSchedulerで組み、既存のルールは動いている限り残す分け方が無難です。
CloudWatch EventsとEventBridgeで料金は別ですか？
別ではありません。同じサービスなので、料金表もEventBridgeのものだけです。AWSサービスが発行するイベントをデフォルトバスで受ける分は無料で、自作アプリがPutEventsで送るカスタムイベントは件数に応じて課金されます。EC2の状態変化をLambdaに渡すような旧来のルールは、AWSサービスのイベントを扱うため料金が発生しません。課金の単位と64KBの数え方はAmazon EventBridgeの料金で解説しています。
コードではCloudWatchEventsとEventBridgeのどちらのクライアントを使いますか？
新しく書くコードはEventBridgeの名前のクライアントを使います。JavaScript SDK v3なら@aws-sdk/client-eventbridgeで、旧名のパッケージと同じAPIを呼びます。Pythonのboto3はクライアント名が"events"の1つだけで、選ぶ必要はありません。
Terraformにaws_eventbridge_ruleというリソースはありますか？
ありません。TerraformのAWSプロバイダーでEventBridgeのルールを書くリソースはaws_cloudwatch_event_ruleで、ターゲットはaws_cloudwatch_event_target、バスはaws_cloudwatch_event_busです。一方、後から加わったSchedulerはaws_scheduler_schedule、Pipesはaws_pipes_pipeと、後から加わった機能は新しい名前のリソースになっています。
CloudWatchアラームの状態変化をEventBridgeで受けられますか？
受信は可能です。CloudWatchは、アラームの状態が変わるとsourceがaws.cloudwatch、detail-typeがCloudWatch Alarm State Changeのイベントをデフォルトバスへ送ります。このパターンでルールを作り、ターゲットにLambdaやSNSを指定すれば、アラームのアクションとは別の経路で通知や自動対応を組むことが可能です。アラーム名や状態でさらに絞りたい場合は、detailの中のalarmNameやstate.valueをパターンに加えます。
関連記事
- Amazon EventBridgeとは？仕組み・料金とCLI・Pythonでの実装手順、新Custom Event Busとの違いを解説【2026年版】：EventBridge全体の構成要素と新旧バスの比較。
- EventBridge SchedulerのAPI｜cron式・手動実行・上限と料金の実装ガイド：スケジュールされたルールの移し先となるSchedulerの実装。
- EventBridge イベントバスの使い分け：クロスアカウント・リージョン送信のポリシー設定：デフォルトバスからカスタムバスへ分けるときの権限設定。
- EventBridge イベントパターンの書き方：演算子一覧とtest-event-patternでの検証：既存ルールのパターンを読み解くときの構文一覧。
- AWS CloudFormationとは？テンプレートの書き方・スタック操作と更新で消える設定の防ぎ方：AWS::Events::Ruleをテンプレートで管理する前提。
