はじめに
AWSで特定の操作をトリガーに自動処理を実行したい時、AWS CloudTrailとAmazon EventBridgeの組み合わせが便利ですよね。例えば、「Amaozn S3バケットにファイルがアップロードされたらAWS Lambdaを起動する」といったよくある構成です。
しかし、EventBridgeルールを設定したのに、なぜか全く反応しない… という経験はありませんか？私も先日この問題に直面し、しばらく頭を悩ませていました。
結論から言うと、その原因はCloudTrailの「証跡（トレイル）」が作成されていなかったことでした。
この記事では、同じ問題でつまずく方や、ハマってしまう方が減るように、この事象の原因と解決策を解説します。
CloudTrailの証跡（トレイル）とは？
CloudTrailの証跡（Trail）とは、AWSアカウント内で行われた操作やAPIコールの履歴（イベント）を、継続的に記録し、指定したストレージに保存するための設定です。
CloudTrailはデフォルトでも過去90日間のイベントを「イベント履歴」として確認できますが、それだけでは不十分な場合があります。そこで証跡が役に立ちます。
証跡を作成することで、以下のことが可能になります。
- イベントの長期保存:
イベントログをAmazon S3バケットにファイルとして自動的に配信・保存します。これにより、90日を超えてログを保管でき、セキュリティ監査やコンプライアンスの要件（例: 「誰が、いつ、何をしたか」を長期間追跡する）を満たすことができます。 - リアルタイムなイベント連携:
オプションで、イベントをAmazon CloudWatch LogsやAmazon EventBridgeにリアルタイムで配信できます。これにより、特定の操作をトリガーにしたアラート通知や、自動修復アクションなどを実行する仕組みを構築できます。
簡単に言うと、「イベント履歴」が短期的な確認用であるのに対し、「証跡」は監査や分析、他サービスとの連携のためにイベントを恒久的に記録・配信するための仕組みと言えます。
何が起きていたか？
まずは、実際に起きた事象を整理します。
- やりたかったこと:
特定のS3バケットへのGetObjectアクションを検知して、EventBridgeルールをトリガーする。 - 設定したルール:
以下のようなイベントパターンを持つEventBridgeルールを作成。
{
"source": ["aws.s3"],
"detail-type": ["AWS API Call via CloudTrail"],
"detail": {
"eventSource": ["s3.amazonaws.com"],
"eventName": ["GetObject"],
"requestParameters": {
"bucketName": ["my-bucket"]
}
}
}
- 発生した問題:
実際にS3バケットからファイルをダウンロードしても、EventBridgeルールが反応しない。EventBridgeのメトリクスを確認しても、ルールのInvocations（呼び出し回数）はゼロのまま。
なぜルールは反応しなかったのか？
EventBridgeの設定は間違っていませんでした。問題はそのイベントの発生源であるCloudTrail側にありました。
AWSアカウントを有効にすると、CloudTrailは自動で有効になり、過去90日間の管理イベント（例: EC2インスタンスの起動、IAMユーザーの作成など）を「イベント履歴」で確認できます。
しかし、EventBridgeがCloudTrailのAPIイベントをイベントバスで受け取るためには、「イベント履歴」とは別に、「証跡（Trail）」を作成して、イベントを継続的にS3バケットやCloudWatch Logsに配信する必要があります。
特に、S3オブジェクトレベルのAPI呼び出しのようなデータイベントや、異常なアクティビティを検知するInsightsイベント、ネットワークアクティビティイベントは、デフォルトでは記録されません。これらを記録し、EventBridgeへ連携するには、証跡で明示的に有効化する必要があります。（管理イベントのみデフォルトで有効）
今回のケースでは、GetObjectというデータイベントを検知しようとしていたにもかかわらず、そのイベントを記録・配信するための証跡が存在しなかったため、EventBridgeまでイベントが届いていなかった、というわけです。
解決策：CloudTrailの証跡を作成する
解決策はCloudTrailの証跡を正しく設定することでした！
- AWSマネジメントコンソールでCloudTrailのサービスページを開きます。
- 左側のナビゲーションペインから[証跡] を選択し、[証跡の作成] をクリックします。（コンソールで作成する場合、デフォルトで全リージョンを対象とするマルチリージョンの証跡が作成されます）
- 「証跡名」を入力し、「ストレージの場所」として、ログを保存するS3バケットを指定します。新規作成も可能です。（必要に応じてストレージを暗号化）
- [CloudWatch Logs – オプション] セクションで、CloudWatch Logsへの配信を有効にします。これにより、ログの検索やモニタリングが容易になります。（おすすめ）
- [ログイベントの選択 – イベント] セクションで、監視したいイベントタイプを選択します。今回はS3のGetObjectを検知したいので、「データイベント」を選択します。 [データイベント] セクションで、リソースタイプを選択します。今回はS3なので、S3にチェックを入れます。
- 設定内容を確認し、[証跡の作成] をクリックします。
これで、指定したAPIイベントがCloudTrailによって記録され、EventBridgeへS3のGetObjectデータイベントが流れるようになります。
この設定後、再度S3からファイルをダウンロードしたところ、無事にEventBridgeルールがトリガーされ、ターゲットが実行されることを確認できました。
まとめ
EventBridgeでCloudTrailのイベントを扱う際は、EventBridge側の設定だけでなく、その前提となるCloudTrailの「証跡」が正しく設定されているかを確認することが重要です。
Point 1: EventBridgeでCloudTrailイベントを検知するには「証跡」が必須。
Point 2: データイベント、Insightsイベントは、証跡で明示的に有効化しないと記録されない。
Point 3: トラブルの際は、まずCloudTrailの証跡設定と、CloudWatch Logsにログが出力されているかを確認しよう！
単純な設定漏れですが、意外と見落としがちなポイントです。この記事が、皆さんのスムーズなAWS開発の一助となれば幸いです。
簡単30秒