Skip to content

DynamoDB Stream Lambda event source mappings using aws-sdk-java 1.x internally

0

Hello AWS Support!

We received an AWS Health notification about SDK for Java 1.x usage in our account. After investigation via CloudTrail -> CLoudWatch Logs -> Insights, the source seem to be AWS's internal KCL poller for DynamoDB Stream Lambda event source mappings, not our code. Our Lambda functions are Python-based. The user agent in CloudTrail is:

amazon-kinesis-client-library-java-lambda_1.2.1, aws-internal/3 aws-sdk-java/1.12.797

Affected event source mappings include several Lambda functions with DDB triggers.

How to (if applicable) upgrade the internal KCL poller for these event source mappings to a version that uses AWS SDK for Java 2.x?

We tried to recreate (delete + add) the triggers of these lambdas with mixed success - for one case it seemed it worked, but for others it did not.

How do we check:

# CW Logs -> Insights -> "aws-cloudtrail-logs-*"

# Query 0

fields @timestamp, userAgent, userIdentity.arn, sourceIPAddress, eventSource, eventName
| filter userAgent like /aws-sdk-java\/1\./
| sort @timestamp desc
| limit 10000

# Query 1 - Confirmation query for the two fixed Lambdas - expected 0 rows

fields @timestamp, userAgent, userIdentity.arn
| filter userAgent like /leb-kcl/
| filter userIdentity.arn like /NAME-OF-THE-LAMBDA-FUNCTION/
| sort @timestamp desc
| limit 1000

Best Regards, Todor Tanevski

1 Answer
1

Thank you for reaching out about the AWS Health notification regarding SDK for Java 1.x usage in your account.

You've correctly identified that the user agent string amazon-kinesis-client-library-java-lambda_1.2.1, aws-internal/3 aws-sdk-java/1.12.797 indicates that AWS's internal infrastructure is using SDK for Java 1.x to poll your DynamoDB Streams on behalf of your Lambda event source mappings. This is not related to your Python-based Lambda function code.

The internal components that AWS Lambda uses to poll DynamoDB Streams (and other event sources) are managed by AWS and are not directly configurable by customers. You cannot manually upgrade the internal KCL poller version used by these event source mappings.

However, AWS is actively working to migrate these internal components to SDK for Java 2.x. The migration of AWS-managed infrastructure happens automatically as part of AWS's internal upgrade process. Your event source mappings will be migrated by AWS without requiring action on your part.

Regarding your attempts to recreate the event source mappings: while recreating triggers may sometimes result in the new mapping being created on already-upgraded infrastructure, this approach is not guaranteed to work consistently because the migration is happening at the service infrastructure level, not at the individual mapping level.

What you should do:

  1. No immediate action required - AWS will handle the migration of internal components automatically
  2. Monitor your CloudWatch Logs Insights queries - Continue using your queries to track when the migration completes for your event source mappings
  3. Focus on your application code - Ensure any SDK for Java 1.x usage in your own application code or custom Lambda layers is migrated to 2.x

The AWS Health notification is informing you of the usage so you're aware, but for AWS-managed internal components like the Lambda event source mapping pollers, the migration will be handled by AWS as part of the service's infrastructure updates.

If you have concerns about the timeline or need additional clarification about your specific account's migration schedule, you can add correspondence to your existing support case through the AWS Support Center at https://console.aws.amazon.com/support/.
Sources
Find applications using AWS SDK for Java 1.x clients - AWS SDK for Java 2.x

answered a month ago

EXPERT

reviewed a month ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.