It seems like you still have to have both SDK v1 and SDK v2 on your classpath.

For example, looking at the Lambda Java documentation you can see that all imports still start with com.amazonaws (SDK v1) and not software.amazon (SDK v2).

One of the examples they list there is blank-java which they describe as "A Java function with the events library, advanced logging configuration, and the AWS SDK for Java 2.x that calls the Lambda API to retrieve account settings"

If you look at that sample application's pom.xml you'll see com.amazonaws and software.amazon packages mixed together.

Similarly for the Lambda handler.

So either they haven't ported everything to SDK v2, or they still want you to use the interfaces from SDK v1 - and then more functional code (non interface code) can be used from SDK v2.

However I am trying to use the latest SDK as recommended here but this is completely different and the RequestHandler interface doesn't appear to exist anymore.

You're using wrong a dependency. This is an SDK for using AWS Services via its REST API, like:

• Putting an object to S3
• Listing EC2 instances
• Deleting an item from AWS DynamoDB
• Invoking a Lambda
• …

I.e. this is an SDK for working with various AWS services. It consists of many libraries, like aws-java-sdk-s3, aws-java-sdk-dynamodb. aws-java-sdk-lambda is one of them, but it is for interacting with Lambda API and not for authoring Lambdas.

The libraries you need for authoring Lambdas are:

• com.amazonaws:aws-lambda-java-core
• com.amazonaws:aws-lambda-java-events

As you see, those are different. First provides Handler interfaces you're looking for and second contains various events Lambda can accept as input: SNS events, CloudWatch timers and so on.

Where does the client side of your code runs at (the app that is using Java SDK)? What might be happening is you're hitting the TCP Keepalive timeout. There's no traffic being sent either way on your TCP connection When SDK waits for Lambda to reply. Network appliances that you might have along the way might be closing idle connection after some period of time. For example if your app runs in a VPC environment and using NAT Gateway or VPC Endpoints for outbound connections to Lambda, the idle connections will be closed after 350 seconds. In this case the behavior will be consistent with what you're observing - the Lambda side will continue to run, and the client side will eventually timeout. If above description fits your case, you can try remediating it by doing two steps - (1) reducing the OS level TCP Keepalive time (2) enabling TCP Keepalive in Java SDK. I'm going to add some details on both steps below. > NOTE: Those steps are using advanced techniques by changing the default behavior for OS-level TCP keepalive settings and App-level HTTP client configuration. Use below description as a reference only, and make sure you understand what you're doing if you decide to apply it to real environments. This is a good article explaining TCP keepalive. 1. By default it is common for a Linux environment to be configured with 7200 seconds (2 hours) of TCP Keepalive interval, which is obviously too high for your scenario. You can see the configuration by running ``` cat /proc/sys/net/ipv4/tcp_keepalive_time cat /proc/sys/net/ipv4/tcp_keepalive_intvl ``` You can update these settings by adding below properties to `/etc/sysctl.conf` and rebooting your system. You might want to use different values. In case you do have NAT Gateway or VPC Endpoint on your path make sure your keepalive is below 350 seconds. Other network appliances might have different timeouts. Below config means wait for 120 seconds before starting to send keepalive probes, and then send them with 30 second intervals. ``` net.ipv4.tcp_keepalive_time=120 net.ipv4.tcp_keepalive_intvl=30 ``` After reboot run the same `cat` commands to make sure new settings were applied. 2. Build a custom ApacheHttpClient, enable TCP Keepalive, and use it when building your Lambda client. See below for a reference. ``` ApacheHttpClient.Builder apacheHttpClientBuilder = ApacheHttpClient.builder(); apacheHttpClientBuilder.connectionMaxIdleTime(Duration.ofSeconds(900)); apacheHttpClientBuilder.connectionTimeToLive(Duration.ofSeconds(900)); apacheHttpClientBuilder.socketTimeout(Duration.ofSeconds(900)); apacheHttpClientBuilder.tcpKeepAlive(true); SdkHttpClient sdkHttpClient = apacheHttpClientBuilder.build(); RetryPolicy retryPolicy = RetryPolicy.builder().numRetries(0).build(); ClientOverrideConfiguration clientOverrideConfiguration = ClientOverrideConfiguration.builder() .apiCallAttemptTimeout(Duration.ofSeconds(900)) .apiCallTimeout(Duration.ofSeconds(900)) .retryPolicy(retryPolicy) .build(); LambdaClientBuilder lambdaClientBuilder = LambdaClient.builder(); lambdaClientBuilder.overrideConfiguration(clientOverrideConfiguration); lambdaClientBuilder.httpClient(sdkHttpClient); LambdaClient lambdaClient = lambdaClientBuilder.build(); InvokeRequest invokeRequest = InvokeRequest.builder().functionName(FUNCTION_NAME).build(); InvokeResponse invokeResponse = lambdaClient.invoke(invokeRequest); ``` ApacheHttpClient class is coming from https://mvnrepository.com/artifact/software.amazon.awssdk/apache-client