I Investigated an Unexpected AWS SDK for Java 1.x End-of-Support Notification Using Kiro CLI and CloudTrail

Introduction

The other day, 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 had 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 reviewed the notification body and scope of impact on the event details 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 no security patches or bug fixes will 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 affected resources were in us-east-1.

Investigating CloudTrail with Kiro CLI

Initial Investigation with LookupEvents

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

I made the following request to Kiro CLI:

I received the following notification. I have no recollection of this usage. Is it possible to investigate the services used and the caller in CloudTrail in Virginia?

(excerpt from the 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 event was detected.

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

Full Investigation with Athena

To investigate with Athena, in addition to permissions to read CloudTrail logs, you need permissions to create tables in Glue Data Catalog and write permissions to the S3 bucket used as the Athena query result destination. This time, I switched to credentials that allowed these operations and ran the queries from Kiro CLI.

First, I asked it to create 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 range by date. Please configure appropriate partition projection.
Check the S3 bucket and region from the CloudTrail settings.

Kiro CLI identified the S3 bucket and prefix using 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'
)

Once the table was created, I asked it to run the search.

List 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.

More than 95% of all events were CreateLogStream by the AWS Chatbot service-linked role. They tended to occur in clusters around UTC 00:02 (JST 09:02), suggesting periodic processing by the service.

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 made as part of AWS service internal processing.

Therefore, I concluded that no SDK migration action was needed for this verification account and decided to take a wait-and-see approach.

The rationale 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 operating CloudWatch Logs for log management purposes
• Occurring in clusters at the same time each day — periodic processing by the service

Pattern 2: CodeBuild (3 events)

• Session name is AWSCodeBuild — a session name automatically assigned by the CodeBuild service
• GetBucketLocation / CreateLogStream — appears to be processing associated with S3 artifact verification and 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 the KMS Grant used by the Lambda runtime to decrypt a container image
• The user implementation (kiro-headless-docker) does not include SDK 1.x; this is an internal operation of the Lambda runtime

Summary

By using Kiro CLI, I was able to proceed through the entire workflow — from checking CloudTrail configuration to executing Athena queries and organizing results — in a single continuous flow. If you have an opportunity to investigate an unexpected AWS Health notification, please give Kiro CLI a try.

Additional Information (6/5)

The same AWS_SDK_PLANNED_LIFECYCLE_EVENT notification arrived for another account as well, so I investigated one year of CloudTrail logs using 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 in AWS Internal Usage

AWS SDK for Java 1.x reached end of support on December 31, 2025, but versions have continued to be updated inside AWS services since then.

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