Investigating an Unexpected AWS SDK for Java 1.x End-of-Support Notice Using Kiro CLI and CloudTrail

Introduction

Recently, my personal account, which I use as a development environment, received the following notification.

Our records indicate that one or more applications in this account made AWS API calls using the AWS SDK for Java 1.x within the last 16 days.

Support for the AWS SDK for Java 1.x ended on December 31, 2025. However, I have no recollection of running any application that uses the Java SDK in this account. Since I had no idea what was behind it, I decided to investigate the caller using the AWS Health dashboard and CloudTrail.

Checking the notification

I checked the AWS Health event log.

It was recorded as AWS_SDK_PLANNED_LIFECYCLE_EVENT. I checked the notification body and the scope of impact on the event details screen.

The key points of the notification are as follows.

• API calls using the AWS SDK for Java 1.x were detected in the past 16 days
• Support for SDK 1.x ended on December 31, 2025
• Existing applications will continue to work, but security patches and bug fixes will not be provided
• Migration to SDK 2.x is recommended

I checked the affected region in the Affected Resources tab.

[
  {
    "entityValue": "us-east-1",
    "awsAccountId": "xxxxxxxxxxxx",
    "lastUpdatedTime": "2026-06-03T01:10:49.723Z",
    "statusCode": "PENDING"
  }
]

I found that resources in us-east-1 were the target.

Investigating CloudTrail with Kiro CLI

Initial investigation with LookupEvents

I had already authenticated to the target account with aws login and granted Kiro CLI read permissions for AWS.

I made the following request to Kiro CLI.

次の案内が届きました。利用に心当たりがありません。バージニアのCloudTrailで、利用サービス、実行元などの調査は可能？

（通知本文の抜粋）

Kiro CLI used the CloudTrail LookupEvents API to retrieve the most recent 3,000 events from us-east-1 and extracted the events whose UserAgent contained aws-sdk-java/1.. Only one event was detected.

However, 3,000 events did not cover the entire detection period of the notification (16 days). I judged that investigating with LookupEvents was inefficient and switched to Athena.

Main investigation with Athena

To investigate with Athena, in addition to permission to read CloudTrail logs, you need permission to create tables in the Glue Data Catalog and permission to write to the S3 bucket used for Athena query results. This time, I switched to credentials that allow these operations and ran it from Kiro CLI.

First, I asked it to create the Athena table.

us-east-1 の CloudTrail ログを Athena で検索したい。
必要なテーブルを作成して。
ログの容量が多い可能性があるので、年月日で調査範囲は限定したい。適切なパーティション投影を設定して。
S3 バケット、リージョンは CloudTrail 設定から確認して。

Kiro CLI identified the S3 bucket and prefix with describe-trails and created a table with partition projection.

CREATE EXTERNAL TABLE cloudtrail_logs_use1 (
  eventVersion STRING,
  userIdentity STRUCT<
    type: STRING, principalId: STRING, arn: STRING,
    accountId: STRING, invokedBy: STRING, accessKeyId: STRING,
    userName: STRING,
    sessionContext: STRUCT<
      attributes: STRUCT<mfaAuthenticated: STRING, creationDate: STRING>,
      sessionIssuer: STRUCT<type: STRING, principalId: STRING, arn: STRING, accountId: STRING, userName: STRING>,
      ec2RoleDelivery: STRING, webIdFederationData: MAP<STRING, STRING>
    >
  >,
  eventTime STRING, eventSource STRING, eventName STRING,
  awsRegion STRING, sourceIPAddress STRING, userAgent STRING,
  errorCode STRING, errorMessage STRING,
  requestParameters STRING, responseElements STRING,
  additionalEventData STRING, requestId STRING, eventId STRING,
  readOnly STRING,
  resources ARRAY<STRUCT<arn: STRING, accountId: STRING, type: STRING>>,
  eventType STRING, apiVersion STRING, recipientAccountId STRING,
  serviceEventDetails STRING, sharedEventID STRING, vpcEndpointId STRING,
  tlsDetails STRUCT<tlsVersion: STRING, cipherSuite: STRING, clientProvidedHostHeader: STRING>
)
PARTITIONED BY (`year` STRING, `month` STRING, `day` STRING)
ROW FORMAT SERDE 'org.apache.hive.hcatalog.data.JsonSerDe'
STORED AS INPUTFORMAT 'com.amazon.emr.cloudtrail.CloudTrailInputFormat'
OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'
LOCATION 's3://cm-members-cloudtrail-xxxxxxxxxxxx/AWSLogs/xxxxxxxxxxxx/CloudTrail/us-east-1/'
TBLPROPERTIES (
  'projection.enabled' = 'true',
  'projection.year.type' = 'integer',
  'projection.year.range' = '2020,2026',
  'projection.month.type' = 'integer',
  'projection.month.range' = '1,12',
  'projection.month.digits' = '2',
  'projection.day.type' = 'integer',
  'projection.day.range' = '1,31',
  'projection.day.digits' = '2',
  'storage.location.template' = 's3://cm-members-cloudtrail-xxxxxxxxxxxx/AWSLogs/xxxxxxxxxxxx/CloudTrail/us-east-1/${year}/${month}/${day}',
  'classification' = 'cloudtrail'
)

Now that the table was created, I continued by requesting a search.

過去16日間で UserAgent に "aws-sdk-java/1." を含むイベントの一覧を出して。
呼び出し元の IAM プリンシパル、操作名、サービス、ソースIP を整理して報告して。

Kiro CLI generated a query that restricted the period using partitions, and executed it.

SELECT
  eventtime, eventsource, eventname,
  useridentity.arn AS principal,
  useragent, sourceipaddress
FROM cloudtrail_logs_use1
WHERE useragent LIKE '%aws-sdk-java/1.%'
  AND (
    (year = '2026' AND month = '05' AND day >= '18')
    OR (year = '2026' AND month = '06')
  )
ORDER BY eventtime DESC

Results

The following events were detected.

Over 95% of the total was CreateLogStream by the AWS Chatbot service-linked role. They tend to occur in a batch around 00:02 UTC (around 09:02 JST), which appears to be a periodic process of the service.

Here are the three patterns of detected events.

Pattern 1: AWS Chatbot (107 events)

{
  "eventtime": "2026-06-03T00:02:39Z",
  "eventsource": "logs.amazonaws.com",
  "eventname": "CreateLogStream",
  "principal": "arn:aws:sts::xxxxxxxxxxxx:assumed-role/AWSServiceRoleForAWSChatbot/Assuming-ServiceRole-For-AWSChatbot-chatbot-logs-management",
  "useragent": "aws-internal/3 aws-sdk-java/1.12.797 Linux/5.10.253-286.1015.amzn2.x86_64 OpenJDK_64-Bit_Server_VM/17.0.18+9-LTS java/17.0.18 kotlin/2.2.21 vendor/Amazon.com_Inc. cfg/retry-mode/standard cfg/auth-source#unknown m/P exec-env/AWS_Lambda_java17",
  "sourceipaddress": "3.134.xx.xxx"
}

Pattern 2: CodeBuild (3 events)

{
  "eventtime": "2026-05-20T15:53:30Z",
  "eventsource": "s3.amazonaws.com",
  "eventname": "GetBucketLocation",
  "principal": "arn:aws:sts::xxxxxxxxxxxx:assumed-role/kiro-headless-codebuild-role/AWSCodeBuild",
  "useragent": "[aws-internal/3 aws-sdk-java/1.12.797 Linux/5.10.253-253.1015.amzn2int.x86_64 OpenJDK_64-Bit_Server_VM/21.0.11+10-LTS java/21.0.11 scala/2.12.19 kotlin/2.3.21 vendor/Amazon.com_Inc. cfg/retry-mode/standard cfg/auth-source#unknown m/P]",
  "sourceipaddress": "10.195.xx.xxx"
}

Pattern 3: Lambda runtime (1 event)

{
  "eventtime": "2026-05-20T15:46:34Z",
  "eventsource": "kms.amazonaws.com",
  "eventname": "RetireGrant",
  "principal": "arn:aws:sts::xxxxxxxxxxxx:assumed-role/kiro-headless-lambda-role/kiro-headless-docker",
  "useragent": "aws-internal/3 aws-sdk-java/1.12.797 Linux/5.10.252-285.992.amzn2.x86_64 OpenJDK_64-Bit_Server_VM/17.0.18+9-LTS java/17.0.18 kotlin/1.8.22 vendor/Amazon.com_Inc. cfg/retry-mode/standard cfg/auth-source#STSAssumeRoleCredentialsProvider m/P,T exec-env/AWS_Lambda_java17",
  "sourceipaddress": "52.90.xx.xxx"
}

Identifying the cause

All of the detected events contained the aws-internal/3 prefix. After checking this together with the role names, session names, and operations, I concluded that these were not calls made directly by a user application using the AWS SDK for Java 1.x, but calls resulting from internal processing on the AWS service side.

Therefore, I judged that no SDK migration is needed for this test account, and decided to leave it as is this time.

The reasoning for each pattern is as follows.

Pattern 1: AWS Chatbot (107 events)

• Role name AWSServiceRoleForAWSChatbot — a service-linked role automatically created by an AWS managed service
• Session name chatbot-logs-management — Chatbot operates CloudWatch Logs for log management purposes
• Occurs in a batch around the same time every day — a periodic process of the service

Pattern 2: CodeBuild (3 events)

• The session name is AWSCodeBuild — a session name automatically assigned by the CodeBuild service
• GetBucketLocation / CreateLogStream — appear to be processing associated with S3 artifact checks and log output performed by the CodeBuild service during build execution
• The SourceIP is a private address (10.195.x.x) — AWS internal network

Pattern 3: Lambda runtime (1 event)

• RetireGrant (KMS) — retiring a KMS Grant that the Lambda runtime used to decrypt the container image
• The user implementation (kiro-headless-docker) does not include SDK 1.x, so this is an internal operation of the Lambda runtime

Conclusion

Using Kiro CLI, I was able to proceed through a single flow from checking the CloudTrail settings to running Athena queries and organizing the results. If you ever need to investigate an AWS Health notification you don't recognize, give Kiro CLI a try.

Additional information (6/5)

Another account received the same AWS_SDK_PLANNED_LIFECYCLE_EVENT notification, so I investigated a year's worth of CloudTrail logs with Athena. As a result, all detected events had the aws-internal/3 prefix — they were internal processing by AWS services.

SDK 1.x version trends inside AWS

Support for the AWS SDK for Java 1.x ended on December 31, 2025, but inside AWS services the version continues to be updated even after that.

References

https://aws.amazon.com/blogs/developer/announcing-end-of-support-for-aws-sdk-for-java-v1-x-on-december-31-2025/

https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/migration-find-apps-using-v1.html