はじめに
AWSの学習環境を片付けたあと、次のように不安になることがあります。
- 昨日、本当にEC2を停止したか
- ALBやNAT Gatewayを削除したのはどの操作だったか
- EventBridge SchedulerがEC2停止を実行したか
- コンソール操作なのか、CLI操作なのか
こういうときは AWS CloudTrail のイベント履歴を見ると確認できます。
この記事では、個人学習用AWSアカウントで、EC2停止や削除操作をCloudTrailから追う手順を整理します。
この記事で分かること
- CloudTrail Event historyで見る場所
-
StopInstancesやDeleteNatGatewayなどのイベント名 - AWS CLIで操作履歴を検索する方法
- EventBridge Scheduler実行時に見るポイント
- 90日を超えて残したい場合の考え方
先に結論
CloudTrailで確認するときは、まず次の順番で見ます。
| 確認するもの | 見る内容 |
|---|---|
| Region | 操作したリージョンに切り替える |
| Event history | 直近90日間の管理イベントを見る |
| Event name |
StopInstances などのAPI名で検索する |
| User identity | 誰、どのロール、どのサービスが実行したか |
| Request parameters | 対象インスタンスIDやリソースID |
CloudTrail Event historyは、現在のリージョンで発生した直近90日間の管理イベントを確認する画面です。
Event historyはAWSアカウントでデフォルト有効になっており、Trailを作成しなくても確認できます。Event historyの表示には追加料金はかかりません。
長期保存や全リージョンの監査を本格的に行う場合は、別途TrailやCloudTrail Lakeなどの設計を検討します。
CloudTrailで確認できるのは、AWS APIとして記録された操作です。EC2のOS内で実行したshutdownやAWS側の状態変化など、StopInstances API以外の理由で停止した場合は、StopInstancesが見つからないことがあります。イベントがないことだけで「停止していない」と判断しないでください。
前提
- 対象読者: 自分のAWSアカウントで学習環境の停止・削除履歴を確認したい人
- 使う環境: AWSマネジメントコンソール、AWS CLI
- 必要な権限:
cloudtrail:LookupEvents。実際の権限は所属先の管理者が定めたポリシーに従う - 仕様確認日: 2026-09-07
- 扱う範囲: CloudTrail Event historyでの確認
- 扱わない範囲: 企業監査、証跡保全、SIEM連携、CloudTrail Lakeの詳細設計
用語の短い説明
| 用語 | 短い説明 |
|---|---|
| CloudTrail | AWSアカウント内のAPI操作などをイベントとして記録するサービス |
| Event history | CloudTrailコンソールで直近の管理イベントを確認する画面 |
| Event name |
StopInstances のようなAPI操作名 |
| User identity | 操作したIAMユーザー、ロール、AWSサービスなどの情報 |
| Management event | EC2停止、RDS削除、IAM変更など、AWSリソース管理に関するイベント |
Event historyでできること、できないこと
CloudTrail Event historyは、学習環境の操作確認には十分使いやすいです。
ただし、何でも検索できる画面ではありません。
| できること | 注意点 |
|---|---|
| 直近90日間の管理イベントを確認する | 90日より前を継続保存するならTrailやCloudTrail Lakeを使う |
| リージョン単位で操作履歴を見る | 複数リージョンをまとめて検索する画面ではない |
| Event nameやUser nameなどで検索する | 1回の検索で指定できる属性条件は1つ |
| コンソール、CLI、SDK、APIの操作を見る | データイベント、Insightsイベント、ネットワークアクティビティイベントはEvent historyの対象外 |
個人学習では、まずEvent historyで直近の操作を確認し、長期保管が必要になったらTrailやCloudTrail Lakeを検討する、という順番で十分です。
AWS CLIのlookup-eventsは、既定では管理イベントを検索します。--event-category insightを指定すると、Insightsを有効にしたTrailの直近のInsightsイベントも検索できますが、本記事では扱いません。
CloudTrail Event historyを開く
AWSコンソールで次を開きます。
CloudTrail
-> Event history
最初に確認するのはリージョンです。
東京リージョンでEC2を作ったなら、CloudTrail画面も東京リージョンにします。
画面右上のリージョン:
ap-northeast-1
CloudTrail Event historyは、現在のリージョンで発生したイベントを見るため、リージョン違いに注意します。
EC2、Elastic Load Balancing、NAT Gateway、RDSなどのイベントは、操作したリソースのリージョンで確認します。IAMやAWS STSなどのグローバルサービスには記録リージョンの扱いが異なるものがありますが、本記事の対象外です。
Event nameで検索する
イベント履歴では、フィルターを Event name にして検索します。
| 確認したい操作 | Event name |
|---|---|
| EC2を停止した | StopInstances |
| EC2を起動した | StartInstances |
| EC2を終了した | TerminateInstances |
| ALBを削除した | DeleteLoadBalancer |
| NAT Gatewayを削除した | DeleteNatGateway |
| EBSボリュームを削除した | DeleteVolume |
| EBSスナップショットを削除した | DeleteSnapshot |
| Elastic IPを解放した | ReleaseAddress |
| RDSを停止した | StopDBInstance |
| RDSを削除した | DeleteDBInstance |
CloudTrailの検索では、部分一致ではなく正確なイベント名で探す方が確実です。
たとえばEC2停止なら StopInstances と入力します。
イベント詳細で見るポイント
対象イベントを開いたら、次を見ます。
| 項目 | 見る理由 |
|---|---|
| Event time | いつ操作されたか |
| Event source |
ec2.amazonaws.com など、どのサービスのAPIか |
| User name / User identity | 誰、どのロール、どのサービスが実行したか |
| AWS Region | 操作されたリージョン |
| Source IP address | リクエスト元の手がかり |
| User agent | AWS CLI、SDK、コンソール、AWSサービスなど実行経路の手がかり |
| Request parameters | 対象リソースIDや入力値 |
| Error code | 失敗していないか |
EC2停止なら、requestParameters に対象インスタンスIDが含まれているかを見ます。
Usernameは、IAM Roleの一時認証情報やAWSサービス経由の操作では空になることがあります。その場合はuserIdentity.type、userIdentity.arn、sessionContext.sessionIssuerを確認します。
AWS CLIでStopInstancesを検索する
コンソールだけでなく、AWS CLIでも確認できます。
# 名前付きプロファイルを使う場合の例。使わない場合はこの行を省略する
export AWS_PROFILE="study"
# 操作したリージョンを明示する
REGION="ap-northeast-1"
# 調査対象のAWSアカウントと実行主体を先に確認する
aws sts get-caller-identity \
--query "{Account:Account,Arn:Arn}" \
--output table
# 確認したい期間をISO 8601形式で指定する。この例は日本標準時
START_TIME="2026-09-06T00:00:00+09:00"
END_TIME="2026-09-06T23:59:59+09:00"
# EC2停止イベントを検索する
aws cloudtrail lookup-events \
--region "$REGION" \
--lookup-attributes AttributeKey=EventName,AttributeValue=StopInstances \
--start-time "$START_TIME" \
--end-time "$END_TIME" \
--query "Events[].{Time:EventTime,Event:EventName,User:Username,Source:EventSource}" \
--output table
期待する結果は、指定期間内の StopInstances が表で表示されることです。
詳細なJSONを見たい場合は、1件だけ取り出して jq で整形します。
# CloudTrailEventはJSON文字列なので、jqで見やすくする
aws cloudtrail lookup-events \
--region "$REGION" \
--lookup-attributes AttributeKey=EventName,AttributeValue=StopInstances \
--start-time "$START_TIME" \
--end-time "$END_TIME" \
--max-results 1 \
--no-paginate \
--query "Events[0].CloudTrailEvent" \
--output text | jq .
AWS CLIの時刻型はISO 8601形式に対応し、Zを付けたUTCと+09:00のようなオフセット付き時刻を指定できます。本記事では日本標準時のオフセットを明示しています。CloudTrailイベント内のeventTimeはUTCなので、検索範囲と表示時刻のタイムゾーンを混同しないようにします。
lookup-events は1回の検索で1つの属性条件を指定します。
1ページの返却件数はデフォルト50件、最大50件で、続きがある場合はNextTokenが返ります。AWS CLIは通常、自動でページングします。--no-paginateを付けた例は1ページだけを取得します。
また、検索リクエストはアカウント、リージョンごとに1秒間2回までです。大量に連続実行しないようにします。
EventBridge Schedulerで停止した場合
EventBridge SchedulerのAWS SDKターゲットからEC2のStopInstancesを呼び出した場合、EC2側にはStopInstances管理イベントが記録される想定です。Schedulerはターゲット実行ロールの一時認証情報を使ってAPIを呼び出します。
見るポイントは次です。
| 項目 | 見る内容 |
|---|---|
| Event name | StopInstances |
| Event source | ec2.amazonaws.com |
| User identity |
typeがAssumedRoleで、sessionIssuerがSchedulerの実行ロールか |
| Request parameters | 停止対象のインスタンスID |
| Error code | 権限不足などで失敗していないか |
Schedulerの設定を疑う場合は、EC2の StopInstances とあわせて、EventBridge Scheduler側の設定も確認します。
Amazon EventBridge
-> Scheduler
-> Schedules
-> 対象スケジュール
対象スケジュールが有効か、ターゲットAPIがEC2の StopInstances になっているか、実行ロールに権限があるかを見ます。
削除操作をまとめて確認する
学習環境の片付けでは、複数の削除イベントをまとめて見たいことがあります。
CloudTrailの lookup-events は1回の検索で1つの属性条件を指定するため、シェルで回すと確認しやすいです。
# 学習環境の片付けで見たいイベント名を並べる
EVENT_NAMES=(
DeleteLoadBalancer
DeleteTargetGroup
DeleteNatGateway
DeleteVolume
DeleteSnapshot
ReleaseAddress
DeleteDBInstance
)
# 各イベント名ごとにCloudTrailを検索する
for EVENT_NAME in "${EVENT_NAMES[@]}"; do
echo "=== ${EVENT_NAME} ==="
aws cloudtrail lookup-events \
--region "$REGION" \
--lookup-attributes AttributeKey=EventName,AttributeValue="${EVENT_NAME}" \
--start-time "$START_TIME" \
--end-time "$END_TIME" \
--max-results 50 \
--no-paginate \
--query "Events[].{Time:EventTime,User:Username,Source:EventSource}" \
--output table
# LookupEventsの上限である1秒間2回を超えないよう間隔を空ける
sleep 0.6
done
この例は、イベント名ごとに直近の1ページ、最大50件を確認します。50件を超える結果が必要な場合は自動ページングを使えますが、APIのレート制限と対象期間を確認して実行します。
StopInstancesが見つからない場合
EC2が停止状態でも、CloudTrailにStopInstancesがあるとは限りません。CloudTrail Event historyで確認しているのはAPI操作であり、インスタンスの完全な状態遷移履歴ではないためです。
まず、対象アカウント、リージョン、90日以内、イベント名、時間範囲を確認します。それでも見つからない場合は、EC2の状態遷移理由を確認します。
# 対象インスタンスの現在状態と状態遷移理由を確認する
INSTANCE_ID="i-0123456789abcdef0"
aws ec2 describe-instances \
--region "$REGION" \
--instance-ids "$INSTANCE_ID" \
--query "Reservations[].Instances[].{State:State.Name,Reason:StateTransitionReason}" \
--output table
OS内のshutdown、Spot Instanceの中断、AWS側の予定イベントや障害などが疑われる場合は、OSログ、EC2のステータス、AWS Health Dashboardを確認します。継続監視が必要なら、EC2の状態変更イベントをEventBridgeからCloudWatch Logsなどへ保存する仕組みを事前に用意します。StopInstancesがないことだけで、誰も停止操作をしていないと断定しません。
イベントが表示されない場合は、次を確認します。
| 確認すること | 理由 |
|---|---|
| リージョンが合っているか | Event historyは現在リージョンのイベントを見るため |
| イベント名が正しいか |
StopInstance ではなく StopInstances のように複数形の場合がある |
| 期間が合っているか | UTCまたはオフセット付き時刻の指定と、確認対象のタイムゾーンが合っているか |
| 操作が成功しているか | 失敗イベントには Error code が出る |
| 別アカウントで操作していないか | 学習用と会社用などのプロファイル違い |
操作履歴を見るときの注意点
CloudTrailは、操作の有無を確認するには便利です。
ただし、料金が止まったことを直接保証するものではありません。
イベントが見つかった場合も、APIリクエストが記録されたことと、リソースが最終的に期待状態になったことは分けて確認します。errorCode、errorMessage、レスポンスと、対象リソースの現在状態を併せて見ます。
たとえば、DeleteNatGateway が見つかっても、関連するElastic IP、ルートテーブル、EBS、RDSなどが残っている可能性はあります。
料金の確認は、CloudTrailではなくBillsやCost Explorerで行います。
CloudTrail:
誰が、いつ、何を操作したかを見る
Bills / Cost Explorer:
どのサービスで料金が出ているかを見る
実務で見るポイント
個人学習では、次のように使うと役立ちます。
- 学習終了後に
StopInstancesがあるか確認する - NAT GatewayやALBを削除した日付を確認する
- 料金が出たサービスについて、削除操作が残っているか確認する
- SchedulerやCLIなど、自分が想定した経路で実行されたか確認する
- 90日を超えて残したい操作履歴は、Event historyだけに頼らない
関連記事
- AWS EC2を毎日18時に自動停止する EventBridge Scheduler設定手順
- AWS構築後の確認サービス入門 Network Access Analyzer・IAM Access Analyzer・Configの使い分け
- AWS学習後に消し忘れやすい課金リソース ALB・NAT Gateway・EBS確認（今後公開予定）
参考・確認先
- View event history - AWS CloudTrail
- Working with CloudTrail event history
- lookup-events - AWS CLI Command Reference
- LookupEvents - AWS CloudTrail API Reference
- Common parameter types in the AWS CLI
- CloudTrail record contents
- CloudTrail identity elements
- Identity-based policy examples for AWS CloudTrail
- AWS CloudTrail pricing
- Using universal targets in EventBridge Scheduler
- Identify who stopped, rebooted, or terminated an EC2 instance
- How EC2 instance stop and start works
- StopInstances - Amazon EC2 API Reference
- AWS EC2を毎日18時に自動停止する EventBridge Scheduler設定手順
- 仕様確認日: 2026-09-07
まとめ
- CloudTrail Event historyでは、直近90日間の管理イベントを確認できる
- EC2停止は
StopInstances、NAT Gateway削除はDeleteNatGatewayで探す - リージョン、イベント名、時刻範囲とタイムゾーン、検索属性を間違えると見つからない
-
StopInstancesがない停止は、状態遷移理由、OSログ、AWS側イベントも確認する - CloudTrailは操作履歴、BillsとCost Explorerは料金確認、と役割を分ける
おわりに
CloudTrailは、AWSを学ぶときの「操作の答え合わせ」に使えます。
Wealthy Designでは、クラウド構成やWebシステムを、作るだけでなく運用確認まで含めて改善しています。
会社の取り組みは、会社サイトにまとめています。