I investigated an unexpected AWS SDK for Java 1.x end-of-support notification using Kiro CLI and CloudTrail

Introduction

Recently, I received the following notification on my personal account used as a development environment.

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.

AWS SDK for Java 1.x reached end of support on December 31, 2025. However, I have no recollection of running any applications using the Java SDK in this account. Since I had no idea what could be causing this, I decided to investigate the caller using the AWS Health dashboard and CloudTrail.

Reviewing the Notification

I checked the AWS Health event log.

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

The key points of the notification are as follows.

• API calls using AWS SDK for Java 1.x were detected in the past 16 days
• SDK 1.x reached end of support 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 regions in the Affected Resources tab.

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

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

Investigating CloudTrail with Kiro CLI

Initial Investigation with LookupEvents

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

I made the following request to Kiro CLI.

I received the following notification. I have no idea what could be causing this. Can you investigate the services used and the caller in the Virginia CloudTrail?

(excerpt from notification body)

Kiro CLI used the CloudTrail LookupEvents API to retrieve the latest 3,000 records from us-east-1 and extracted events containing aws-sdk-java/1. in the UserAgent. Only 1 result was detected.

However, 3,000 records were not enough to cover the entire detection period (16 days) mentioned in the notification. I determined that investigating with LookupEvents was inefficient and switched to Athena.

Full Investigation with Athena

To investigate with Athena, you need permission to read CloudTrail logs, as well as permission to create tables in the Glue Data Catalog and write permission to the S3 bucket used for Athena query results output. This time, I switched to credentials that could perform these operations, and then executed from Kiro CLI.

First, I requested the creation of an Athena table.

I want to search CloudTrail logs in us-east-1 with Athena.
Create the necessary table.
Since the log volume may be large, I want to limit the investigation scope by year, month, and day. Set up appropriate partition projection.
Check the S3 bucket and region from the CloudTrail settings.

Kiro CLI used describe-trails to identify the S3 bucket and prefix, 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'
)

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

List the events containing "aws-sdk-java/1." in the UserAgent over the past 16 days.
Organize and report the calling IAM principal, operation name, service, and source IP.

Kiro CLI generated a query with the period limited by 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

Investigation Results

The following events were detected.

Over 95% of the total were CreateLogStream calls by the AWS Chatbot service-linked role. They tended to occur in clusters around UTC 00:02 (JST 09:02), suggesting they are periodic service processing.

The 3 detected event patterns are shown below.

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 detected events contained the aws-internal/3 prefix. After reviewing the role names, session names, and operation details, I determined that these were not cases where user applications were directly using AWS SDK for Java 1.x, but rather calls associated with internal processing on the AWS service side.

Therefore, I concluded that SDK migration is not necessary for this verification account, and decided to take no action at this time.

The basis for judgment for each pattern is as follows.

Pattern 1: AWS Chatbot (107 events)

• Role name AWSServiceRoleForAWSChatbot — a service-linked role automatically created by AWS managed services
• Session name chatbot-logs-management — Chatbot operates CloudWatch Logs for log management purposes
• Occurs in clusters at the same time every day — periodic service processing

Pattern 2: CodeBuild (3 events)

• Session name is AWSCodeBuild — a session name automatically assigned by the CodeBuild service
• GetBucketLocation / CreateLogStream — likely processing associated with S3 artifact verification or log output performed by the CodeBuild service during build execution
• Source IP is a private address (10.195.x.x) — AWS internal network

Pattern 3: Lambda runtime (1 event)

• RetireGrant (KMS) — retirement of a KMS Grant used by the Lambda runtime to decrypt a container image
• The user implementation (kiro-headless-docker) does not contain SDK 1.x; this is an internal operation of the Lambda runtime

Summary

Using Kiro CLI, I was able to proceed through the entire workflow — from checking CloudTrail settings to executing Athena queries and organizing results — in one continuous flow. If you have the opportunity to investigate unexpected AWS Health notifications, please give Kiro CLI a try.

Additional Information (6/5)

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

SDK 1.x Version Transitions Inside AWS

AWS SDK for Java 1.x reached end of support on December 31, 2025, but versions continue to be updated within AWS services even after that.

Reference Links

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