こんにちは。社会人歴1年目、AWS歴も1年目の新人tknこと髙野です。
今年初めて紅茶のアドベントカレンダーを朝食のお供に買ったのですが、先日何の偶然かお味噌汁とハーブティーという組合せが誕生しました。食の常識を覆す出来事に、朝からとてもよく目が覚めました。アドベントカレンダーは偉大です。。
さて先日、私がとある指令を受けたことからこのブログは始まります。
指令内容
名前が異なっているが、役割が同じAmazon EventBridgeのルールが2つ作成されている(EventRule-a, EventRule-b)。なぜ作成されたのか、どちらが現在使用されているものなのか調査してほしい。
もちろん実際はとても詳細にご説明いただきましたが、、ざっくりお伝えするとこのような指令を受けました。
以下のアーキテクチャ図は私が今回調査した環境を抜粋して表現したものであり、水色の丸で囲まれたEventRuleが今回の調査対象です。
また、調査対象のリソースの特徴・設定は以下の通りです。
- EventRule-a / EventRule-b
- AWS Lambdaの関数のプログラムにより動的に作成されたEventRule
- イベントパターン：AWS CodeCommitのあるブランチへのマージ
- ターゲット：Lambda
- 2つのLambda
- どちらも関数内でAmazon CloudWatch Logsへのログの出力処理あり
この環境を見たとき私は「AWS CloudTrailを見ればとりあえず何か分かるかな？」と単純に考えて調査を進め、行き詰まることになりました…。
そこで今回のブログでは、AWS初心者が上記環境のリソースの作成履歴を調べた際に役立ったログや、ログに含めるべきだと思った情報についてお伝えしたいと思います。
調査で最終的に分かったこと
私の調査方法をご説明する前に、今回の調査で最終的に分かったことをお伝えします。
- 調査対象のEventRule-a/bが作成された日時が分かった（EventRule-aが先、EventRule-bが後）
- EventRule-aと同じ命名規則で作成された他の役割のEventRuleは既に削除されていることが分かった
- EventRule-bの作成日以降に、ルール作成を担うLambda関数のコードを記録するCodeCommitに該当ファイルのマージが見られた
以上の結果より、私は「ルールの作成を担うLambda関数において、命名規則のコードが変更されたことで別名で同じ役割のEventRuleが作成された」という仮説を最有力のEventRule誕生理由としてこの調査を終えることになりました。
最終的に、謎の大解明まで持っていくことができなかったのが悔しいところです。。
著者が躓いた調査環境の特徴
さて、私が躓いたポイントについてお話するにあたり、調査環境の特徴について追加で以下に示します。
- 対象環境の作成は半年以上前に行われており、活発に稼働していた期間も同時期であったことから、デフォルトで保存期間が90日のCloudTrailには情報が残っていなかった
- 対象のEventRuleが監視していたブランチにはマージが行われておらず、EventRule呼び出しのログ自体が残っていなかった
ここですね！このポイントに気づくのに私は多くの時間を使いました。。
AWS初心者ひいてはログ調査初心者でもある私は、最初に環境の作成時期や稼働時期を調べることをせずに、とりあえず色々なログを見る！という行動に突っ走っておりました。その結果、ルールの稼働記録を見るための操作・呼び出しログばかりを探しては見つからずに困惑することになりました。
もし頻繁に稼働しているリソースを調査する場合は、CloudTrailで以下のようなログを中心に調査を進めることができるでしょう。
ここで、対象のEventRuleはどちらも同じイベントパターンであるため、今から動作検証しても両方とも検知・作動してしまいます。そこで私は、EventRuleやLambdaの動作状況に関する調査から、誕生の歴史に関する調査に移ることにしました。
リソース作成履歴の調査に活躍したログ
以下では、リソースの作成履歴を調査する中で役立ったログについてご紹介します。
Amazon CloudWatchのロググループ
ログストリームとは、CloudWatch Logsが取集したログの中で同一のソースをもつログイベントのことであり、ロググループとは「保持、モニタリング、アクセス制御について同じ設定を共有するログストリームのグループ」のことです。（参照：ロググループとログストリームの操作 – Amazon CloudWatch Logs）
今回の調査環境では、EventRuleの作成用とターゲット用のLambdaそれぞれに、CloudWatch Logsへのログの書き込み権限を付与していました。CloudWatch Logsへのログの書き込みに必要な権限は、logs:CreateLogGroup,logs:CreateLogStream,logs:PutLogEventsの3つであり、これらはAWSLambdaBasicExecutionRoleというAWSマネージドポリシーをLambdaに付与することで簡単に実現できます。（参照：AWSLambdaBasicExecutionRole – AWS 管理ポリシー）
上記の権限を付与することで、以下のようにLambda関数がいつ実行されたのかが自動で記録され、EventRuleの作成日時を知ることができました。
また、Lambda関数ではPythonの標準ライブラリであるloggingモジュールを使用して、logger.info(f"event: {json.dumps(event)}")のようにイベント内容を出力することで、以下のようなイベントの詳細な処理内容を確認することができました。
{
"originalEvent": {
"version": "0",
"id": "XXXXXXXX",
"detail-type": "API Call",
"source": "XXXXXXXX",
"account": "123456789012",
"time": "2025-12-15T06:57:58Z",
"region": "ap-northeast-1",
"resources": [],
"detail": {
"eventVersion": "1.0",
"userIdentity": {},
"eventTime": "2025-12-15T06:57:58Z",
"eventSource": "XXXXXXXX",
"eventName": "CreateEventRule",
"awsRegion": "ap-northeast-1",
"sourceIPAddress": "XXXXXXXX",
"userAgent": "XXXXXXXX",
"requestParameters": {/* イベントの処理内容 */},
"requestID": "XXXXXXXX",
"eventID": "XXXXXXXX",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management",
"sessionCredentialFromConsole": "true"
}
},
"createRuleName": "EventRuleFunction"
}
しかし、上記のようなルールログはEventRuleのプロパティなどをもとに出力するものであり、ルール名の情報は反映されません。そこで調査環境では、Lambda関数内にlogger.info(f"EventRule created. : {rule_name}")を追加することで、作成したルール名を含むログを出力していました。このコードが無ければEventRule-aとbどちらの作成日時か正確に判別できなかったため、ログ設計の重要性を感じました。
また、このログをEventRule createdというキーワードでフィルターすることで、各EventRuleの作成日時を時系列順で取得することができ、命名規則が途中からEventRule-a→EventRule-bのように変化していることに気づくことができました。Lambda関数の作者の方に感謝しかありません。。
AWS Config
AWS ConfigとはAWSアカウント内のリソースの設定変更を監視し、記録するサービスです。ConfigはAWSアカウント発行後に一度有効化し、記録する対象リソースを指定することで情報の記録が始まります。
ここでは、リソースタイムラインを確認することで、あるリソースの作成時の構成から現在の構成までの変更履歴を見ることができます。
しかし、ここで注意すべきは必ずしもリソース情報が最も古い地点＝リソースの作成日時とは限らないことです。
リソースタイムラインで確認できるリソースの設定情報の中に、"configurationItemStatus": "ResourceDiscovered"がある場合、それはConfigが対象リソースを初めて検出したことを示します。そのため、Configが有効化される前に作成されたリソースなどは、Configを有効化してリソースが発見された時点で追跡が開始されるため、Configのログをリソース作成日時の根拠とすることは望ましくありません。
一方で、Configの便利な点として削除したリソースの構成履歴も確認できる点が挙げられます。
以下のように削除したリソースも含めて検索できるうえ、存在した期間、変更履歴、削除日などを確認することが可能です。
今回の調査環境では、このリソース履歴においてEventRule-aと同一の命名規則で他の役割をもつEventRuleが全て削除済であることが確認できました。一方で、EventRule-bと同一の命名規則のEventRuleは現役であったことから、EventRule-aが不要な関数である可能性が高いと判断することができました。
調査結果のまとめ
これまでの調査結果より、「EventRule-aはEventRule-bより先に作成された」、「EventRule-aと同様の命名規則のEventRuleは既に全て削除されている」という点から、EventRule-aが不要なEventRuleである可能性が高まりました。
そこで仮説をより強固にするべく、EventRuleを作成するLambda関数の命名規則コードの変遷を追跡しようと、Lambda関数のバージョンやCodeCommitのコミット履歴の確認を試みました。が、、
- Lambda：バージョン履歴なし
- CodeCommit：ある日あるコミットでLambda関数のコード関連ファイルが全て誕生
- ただし、EventRule-b作成日以降に該当ファイルのマージを確認
上記の結果より、「EventRule-aが作成された後に、Lambda関数においてEventRuleの命名規則の変更があり、EventRule-bが作成されてその後使用されている…のではないか？」という結論に終わりました。。
ログに含めるべきだと思った情報
以上の結果より、各リソースにおいてログに含めてあると調査がしやすいのではないかと感じた情報をまとめます。
- EventBridge/Lambda：呼び出し元のリソース名
- 方法1：EventRuleのイベントパターンにおいて、detail-typeにEventRule名を含めた文字列を設定
- 方法2：EventRuleの入力トランスフォーマーで、Lambdaに渡す情報にリソース名を含めるように設定
- CodeCommit：こまめなコミット履歴
EventBridge/Lambdaについては、どちらの手法も動的にEventRuleを作成する調査対象のような環境では適用しやすいうえ、これによりLambdaのCloudWatchロググループにおいて、Lambdaを呼び出したEventRule名を無期限の間確認可能になることが期待できます。
CodeCommitについては、developやmasterなど複数人で共有するブランチでは完成版のコミットを意識する必要があるものの、featureなど一時的／個人的なブランチではこまめにコミットして履歴を残すことで、将来の自身・チームメンバーがコード設計の意図を辿りやすくなることが考えられます。
おわりに
今回、調査を通してログが環境理解にどのように役立つかを身をもって学ぶことができました。今回学んだ”将来環境を引き継ぐ人に向けた開発”の視点を、今後の開発業務に活かしていきたいと思います。
初めてのブログで拙いところも多々あったかと思いますが、いかがでしたでしょうか。
今後、様々なAWSリソースについて学びを深めるとともに、このようなアウトプットのスキルも向上させていきたいと願うばかりです。
最後までお付き合いいただき、誠にありがとうございました。
クリスマス・イブまであと6日、皆さま体調に気を付けてお過ごしください！