AWS SDK for Java1.xの利用状況をデータイベントOFFでも調べられるか試してみた

こんにちは、せーのです。

今日は AWS SDK for Java 1.x のサポート終了通知をきっかけに、「CloudTrail の管理イベントだけでは見えない SDK 利用をどうやって洗い出すか」を実験してみた話を書いてみたいと思います。

想定読者とゴール

• AWS Health から「AWS SDK for Java 1.x を使っているようです」と言われたが、CloudTrail の検索だけではスッキリしない方
• CloudTrail の 管理イベント と データイベント の違いがなんとなく分かっているつもりだけど、「通知内容と手元のログのズレ」をうまく説明できない方

この記事を読み終わると、次のようなことが説明できるはずです。

• data events を ON にすると aws-sdk-java/1. が CloudTrail に出てくる典型パターン
• data events を 有効化していなかった期間 に、同じような利用があったかどうかを「別の証跡」から疑う・確認する方法
• 「開発部門にソースを聞けばよい」で終わらせず、CloudTrail や既存ログで IAM ロールと API 種別 を絞り込んでから相談する、という流れ

ざっくり結論

先にざっくり結論を書いておきます。

まず、AWS SDK for Javaを使っているかどうかは、基本はCloudTrailを読んで、Athenaでクエリをかければ見つかります。

https://dev.classmethod.jp/articles/kiro-cli-investigate-sdk-java-1x-notification/

Java なんて使った記憶がない、という方は大抵が「AWS の別のサービスが内部で使っている」というパターンです。ただ、次のようなケースもあります。

• CloudTrail の 管理イベント だけを見ていると、S3 や DynamoDB の「中身だけ触る」 Java アプリは、SDK 1.x を使っていても そもそも記録されていない 場合があります
• data events を ON にすればそういった利用も CloudTrail に載りますが、過去分は増えません
• data events を OFF のまま過去を振り返るには、API ごとに別の証跡が必要です
  • S3 なら Server Access Logs（既に有効なら User-Agent に aws-sdk-java/1. が出る）
  • それ以外は、最終的には ソース / dependency tree / 成果物 / アプリログ の棚卸しに戻る

この記事では、まず CloudTrail の管理イベント vs データイベントの違いと、「data events ON なら見えるパターン / OFF でも疑えるパターン」を表に整理します。そのうえで、実際に自分の検証環境で S3 だけ触る Java アプリ を動かしてみて、

• data events を OFF にした状態では管理イベント側に何も出てこない
• data events を ON にすると aws-sdk-java/1. が data events 側に出てくる

という挙動を確かめていきます。

CloudTrail の管理イベントとデータイベント (おさらい)

まずは用語を揃えておきます。

• 管理イベント (management events):
  • 例: CreateBucket, ListBuckets, DescribeInstances, CreateLogStream など
  • デフォルトで CloudTrail に記録され、コンソールの Event history からも見えます
  • 「リソースの作成・設定・一覧」を表すことが多い
• データイベント (data events):
  • 例: S3 GetObject / PutObject, Lambda Invoke, DynamoDB の item-level 操作 など
  • デフォルトでは 記録されません（「Logging data events」ドキュメントの通り、別途有効化が必要）
  • 「オブジェクトやレコードへの実アクセス」を表します

AWS 公式ドキュメントでは次のように整理されています。

• Logging data events – AWS CloudTrail
• Logging management events – AWS CloudTrail

違いをざっくり言うと、

管理イベントは「家を建てる・間取りを変える話」、データイベントは「建てた家の中で誰がどの部屋に出入りしたか」というイメージです。

Java SDK 1.x が S3 や DynamoDB の 中身だけ触っている 場合は、家の中の話なので、管理イベントだけを見ていると「そもそも記録されていなかった」ということが起こります。

data events ON / OFF で見えるもの・見えないもの

今回整理したいのは、「data events を ON にしたら見えるパターン」と、「OFF のままでも疑える・確認できるパターン」です。

実験と公式ドキュメント、過去の調査経験をもとに、ざっくり次のような表になりました。

違いを整理すると、

data events ON で初めて見えるのは「オブジェクトやレコードへの実アクセス」系であり、OFF のまま過去の実行実績を追えるのは、その API に対応した 別ログ (S3 access logs など) が既にあった場合だけです。

それ以外のケースでは、「過去の実行実績」を諦めて、ソースコードや成果物の棚卸しで 利用有無そのもの を判断することになります。

実験メモ: 管理イベント側に見えた Java SDK 1.x

本題は「管理イベントに出ないのに data events で見える」パターンですが、その前提として「管理イベント側にちゃんと出ている」パターンも確認しておきます。

検証環境の CloudTrail では、次のような Athena クエリを実行しました。

SELECT
  eventtime,
  eventsource,
  eventname,
  useridentity.arn,
  useragent
FROM sdkv1_investigation.cloudtrail_logs_20260616
WHERE useragent LIKE '%aws-sdk-java/1.%'
  AND useragent NOT LIKE '%aws-internal/%'
ORDER BY eventtime DESC
LIMIT 20;

抜粋すると、次のような行が 1 件見つかりました。

eventtime              eventsource       eventname   arn                                                              useragent
---------------------  ----------------  ----------  ---------------------------------------------------------------  ---------------------------------------------------------------------------
2026-06-16T07:07:49Z  s3.amazonaws.com  ListBuckets arn:aws:sts::XXXXXXXXXXXX:assumed-role/cm-seino.tsuyoshi/...     [aws-sdk-java/1.12.788 Linux/... java/17.0.19 ...]

• Java SDK 1.x (aws-sdk-java/1.12.788) からの ListBuckets 管理 API 呼び出し が、CloudTrail 管理イベントに普通に記録されています。
• suzuki.ryo さんの記事で出てきた AWS Chatbot の CreateLogStream と同じ、「管理 API を呼んでいる SDK 利用」のパターンです。

この記事で扱いたいのは、むしろその逆のケース――つまり、

• 通知は来ている
• 管理イベント検索ではそれらしい aws-sdk-java/1. が全く出てこない

というパターンです。ここから先は「なぜそうなるのか」と「data events を ON / OFF それぞれで何ができるか」を見ていきます。

Step 1: 管理イベントで aws-sdk-java/1. を探す

まずは王道のパターンとして、CloudTrail の管理イベントから aws-sdk-java/1. の痕跡を探します。

Athena の例はこんな感じです。

SELECT
  useridentity.arn,
  sourceipaddress,
  eventsource,
  eventname,
  awsregion,
  useragent,
  eventtime
FROM cloudtrail_logs
WHERE useragent LIKE '%aws-sdk-java/1.%'
  AND useragent NOT LIKE '%aws-internal/%'
ORDER BY eventtime DESC
LIMIT 100;

集計版もあると、呼び出し元候補の整理がしやすくなります。

SELECT
  useridentity.arn,
  sourceipaddress,
  eventsource,
  eventname,
  regexp_extract(useragent, 'aws-sdk-java/([0-9.]+)', 1) AS sdk_version,
  min(eventtime) AS first_seen,
  max(eventtime) AS last_seen,
  count(*) AS calls
FROM cloudtrail_logs
WHERE useragent LIKE '%aws-sdk-java/1.%'
  AND useragent NOT LIKE '%aws-internal/%'
GROUP BY 1,2,3,4,5
ORDER BY last_seen DESC;

CloudTrail を CloudWatch Logs に配信している環境なら、短期間の調査は Logs Insights の方が手軽なこともあります。

fields userIdentity.type, userIdentity.arn, eventSource, awsRegion,
       eventName, eventType, eventTime, userAgent, sourceIPAddress
| filter userAgent like /aws-sdk-java\/1\./
| filter userAgent not like /aws-internal\//
| sort eventTime desc

スキャン量に応じて課金されるので、時間範囲は絞ってください。

ここでヒットした場合は、

• userIdentity.arn から どの IAM ユーザー / ロールが呼んでいるか
• eventSource / eventName から どのサービス・どの API か
• sourceIPAddress から どこから呼ばれていそうか

を手がかりに、「どの実行基盤 (Lambda / ECS / EC2 / バッチサーバーなど)」なのかを絞り込んでいきます。

逆に まったくヒットしなかった 場合は、「使っていない」と言いたくなりますが、まだ早いです。ここからが本題です。

Step 2: data events を ON にしたら見えるパターンを疑う

管理イベント検索が 0 件だったときに、まず疑うべきなのは「そもそも管理イベントに載らない API だけを使っていないか」です。

典型的には、先ほどの表の #1 と #2 のパターンです。

• S3 の GetObject / PutObject だけを叩くバッチ
• DynamoDB の GetItem / Query だけを叩く Web API

こういったアプリは、リソース作成 (CreateBucket / CreateTable) などを一切行わず、データプレーンだけを触っていることがあります。その場合、

• data events を ON にすれば GetObject / PutObject / GetItem などのイベントに aws-sdk-java/1. が見える
• data events を OFF のままでは、CloudTrail にはそもそも何も残っていない

という状態になります。

data events を ON にするかどうかはコストとの相談ですが、少なくとも「なぜ管理イベント検索が 0 件でも通知が来るのか」の説明には、このパターンを押さえておく必要があります。

Step 3: data events OFF のまま疑える・確認できるもの

では、data events を有効化していなかった期間について、「それでも何かできないか」を見ていきます。

S3: Server Access Logs があれば勝ち筋がある

S3 については、CloudTrail data events とは別に Server Access Logs という仕組みがあります。

• 既に access logs を吐き出しているバケットがあれば、過去分を含めて S3 リクエストの User-Agent を確認できます
• Athena でテーブルを作っておけば、次のようなクエリで aws-sdk-java/1. を探せます

SELECT
  requester,
  remoteip,
  operation,
  key,
  requestdatetime,
  useragent,
  count(*) AS calls
FROM s3_access_logs
WHERE useragent LIKE '%aws-sdk-java/1.%'
GROUP BY 1,2,3,4,5,6
ORDER BY requestdatetime DESC;

これでヒットすれば、

• どのバケット / プレフィックスに対して
• どのクライアント (IP や IAM ロール) から
• どのくらいの頻度で

SDK 1.x のリクエストが飛んでいるかを把握できます。

それ以外のサービス: ログがなければ諦めて棚卸しへ

一方で、DynamoDB や Lambda Invoke などについては、S3 access logs に相当する「外付けのサーバーアクセスログ」がありません。

• data events OFF 期間については、実際にどのくらい呼ばれていたか を後から復元することはできません
• できるのは、「ソース / dependency / 成果物 / アプリログ」の棚卸しで「SDK 1.x を含んだデプロイ物がどこかに残っていないか」を見ることだけです

ここは少しモヤッとするところですが、「実行実績」と「利用有無」を分けて考えるしかありません。

Step 4: ソース / 依存関係 / 成果物 / ログの棚卸し

CloudTrail だけでは足りないので、あとは地道な棚卸しです。CloudTrail で IAM ロールと API 種別 が分かったあと、どのコードやデプロイ物に SDK 1.x が残っているかを突き合わせる、という流れになります。

ソースコードを検索する

リポジトリが手元にあるなら、まずは全文検索からです。

rg "import com.amazonaws" .
rg "aws-java-sdk" .
rg "<groupId>com.amazonaws</groupId>" .

rg がなければ grep -R でも構いません。

grep -R "import com.amazonaws" .
grep -R "aws-java-sdk" .
grep -R "<groupId>com.amazonaws</groupId>" .

com.amazonaws は Java SDK 1.x の重要な手がかりです。ただし aws-lambda-java-core のように、SDK 本体ではないライブラリも同じプレフィックスを使います。ヒットしたら artifactId が aws-java-sdk-* かどうかまで確認してください。

Maven / Gradle の依存関係を見る

ソースに直接書いていなくても、推移依存で SDK 1.x が入っていることがあります。

Maven:

mvn dependency:tree -Dincludes=com.amazonaws

Gradle:

./gradlew dependencies --configuration runtimeClasspath | grep "com.amazonaws"

見たい出力例はこんな感じです。

com.amazonaws:aws-java-sdk-s3:jar:1.12.746:compile
com.amazonaws:aws-java-sdk-core:jar:1.12.746:compile

直接依存 (direct dependency) なのか、別ライブラリ経由の推移依存 (transitive dependency) なのかを分けて見ます。推移依存の場合は、親ライブラリの更新や exclude 設定を検討することになります。

JAR / WAR / EAR / Lambda zip を検査する

ソースが古い・失われている・本番だけ別成果物、というケースでは、デプロイ済みの成果物を見る方が早いこともあります。

uber-jar:

jar -tf myapp.jar | grep 'com/amazonaws/sdk/versionInfo.properties'
unzip -p myapp.jar com/amazonaws/sdk/versionInfo.properties

Lambda zip:

unzip -l function.zip | grep 'aws-java-sdk'
unzip -l function.zip | grep 'com/amazonaws/sdk/versionInfo.properties'

WAR:

unzip -l app.war | grep 'WEB-INF/lib/.*aws-java-sdk'

versionInfo.properties が見つかれば、中身でバージョンまで確認できます。

platform=java
version=1.12.xxx

ソースがなくても成果物から SDK 1.x を見つけられる、というのがポイントです。WAR や Lambda zip では WEB-INF/lib/ や lib/ 配下にネスト JAR があるので、トップレベルだけ grep して見落とさないように注意してください。

コンテナイメージを検査する

ECS / EKS / EC2 上でコンテナを動かしている場合は、実際に動いているイメージを見るのが速いです。

docker pull example/myapp:latest
docker run --rm --entrypoint sh example/myapp:latest -c \
  "find / -name '*aws-java-sdk*.jar' 2>/dev/null | head -100"

JAR の中まで見る例:

docker run --rm --entrypoint sh example/myapp:latest -c \
  "find / -name '*.jar' 2>/dev/null | xargs -I{} sh -c 'unzip -l \"{}\" 2>/dev/null | grep -q \"com/amazonaws/sdk/versionInfo.properties\" && echo \"{}\"'"

本番イメージを pull する権限がない場合は、CI の成果物や SBOM があればそちらを確認します。

アプリログを検索する

SDK 1.12.767 以降は、起動時に次のような非推奨警告を出します。

The AWS SDK for Java 1.x is no longer supported

ローカルログ:

grep -R "The AWS SDK for Java 1.x" /var/log/myapp/

CloudWatch Logs Insights:

fields @timestamp, @logStream, @message
| filter @message like /The AWS SDK for Java 1.x/
| sort @timestamp desc

あくまで「あればラッキー」な補助線です。古い SDK では警告が出ないので、ヒットしなかったから未使用、とは言えません。

状況別の判断表

ここまでの調査結果を、次の表で整理すると迷いにくいです。

Step 5: data events を ON にするかどうか

ここまでで、

• 管理イベントだけ見ていると見落とすパターン
• data events OFF でも、S3 access logs や棚卸しでできること・できないこと

を整理しました。最後に、「じゃあ data events を ON にするかどうか」の話です。

範囲と期間を決める

CloudTrail data events はイベント数ベースで課金されます。2026-06-16 時点の CloudTrail Pricing では、

• $0.10 / 100,000 events

という料金です。高頻度な S3 / DynamoDB / Lambda を全アカウント・全リージョンで一気に有効化すると、請求が膨らみやすいです。

調査目的であれば、次のように 範囲と期間を決めて 有効化するのが現実的だと感じています。

• 通知に書かれている Affected region だけ
• SDK 1.x の疑いがある S3 バケットだけ
• GetObject / PutObject など必要な API だけ
• まずは 1 業務サイクル (1〜2 週間) だけ
• 調査後に無効化するか、恒久監査方針に移すか決める

特定 S3 バケットの GetObject / PutObject だけを観測する、という考え方の例です。

[
  {
    "Name": "Investigate specific S3 object access",
    "FieldSelectors": [
      { "Field": "eventCategory", "Equals": ["Data"] },
      { "Field": "resources.type", "Equals": ["AWS::S3::Object"] },
      { "Field": "eventName", "Equals": ["GetObject", "PutObject"] },
      { "Field": "resources.ARN", "StartsWith": ["arn:aws:s3:::example-bucket/"] }
    ]
  }
]

本番 trail に selector を足す前に、対象リソース・Read/Write のどちらが必要か・期間・費用感を必ず確認してください。

コストの目安

調査前にざっくり試算しておくと、関係者への説明がしやすくなります。以下は概算です（Athena $5/TB、CloudWatch Logs 配信 $0.25/GB も含む）。

S3 保存料やリージョン差は別途かかります。高トラフィックバケットで Read/Write 両方を無期限に ON にするのは、調査目的としては避けた方が無難です。

data events で見えたらどうするか

data events を限定的に ON にした結果、

• GetObject / PutObject / Invoke などの data events に aws-sdk-java/1. が出てきた

のであれば、

1. userIdentity.arn / sourceIPAddress / eventSource / eventName から、実行基盤 (Lambda / ECS / バッチサーバー等) を特定
2. その実行基盤に対応するリポジトリや成果物を棚卸し
3. どのアプリ / ライブラリが SDK 1.x に依存しているかを一覧にする

という流れで、移行計画を立てていくことになります。

まとめ

改めて整理すると、今回のポイントは次の 3 つです。

• CloudTrail の管理イベントだけを見ていると、S3 や DynamoDB の中身だけ触る Java アプリ は SDK 1.x を使っていても「そもそも記録されていない」ことがある
• data events を ON にすればそういった利用も見えるが、過去分は増えない。S3 に限っては Server Access Logs が「後追い用の救済策」になり得るが、それ以外はコードと成果物の棚卸しに戻る
• 「開発部門に聞く」の前に、CloudTrail や既存ログで IAM ロールと API 種別 を絞り込んでおくと、「どのアプリをいつまでにどう直すか」という話がだいぶ建設的になる

AWS Health から SDK 1.x の通知が来たときに、「CloudTrail の管理イベントを aws-sdk-java/1. で検索してヒットしなかったから未使用です」とは、もう言えません。

代わりに、

「管理イベント側には出ていませんでしたが、S3 の data events / access logs / ソース / 成果物 / ログを組み合わせて、これこれこういう範囲には SDK 1.x が残っていそうです」

と説明できるようになっていれば、ひとまずは十分かな、と思っています。どうぞ参考にしてみてください。