How to Write for AWS in Kotlin Without Pain and Java Legacy

Developers who wrote for AWS in Kotlin probably remember Java SDK v2. Working with it in Kotlin projects is possible, but you constantly have to wrap CompletableFuture in coroutines, put up with long Java-builder syntax, and drag extra dependencies into the build. The AWS team solves this with an official project aws-sdk-kotlin — a client written from scratch specifically for Kotlin.

What changes with the native Kotlin SDK

The main advantage of the library is native coroutine support and Kotlin Flow. No callback spaghetti or async wrappers. Calls to S3, DynamoDB, or Lambda are written exactly like any other async code in Kotlin.

The second important point is the architectural foundation for multiplatform. The library targets Kotlin Multiplatform and works out of the box on multiple target platforms:

• JVM for classic backends on Ktor or Spring
• Android for mobile applications
• GraalVM Native Image for fast startup of compiled binaries

Code generation via Smithy and targeted build

AWS has hundreds of services. If you compile and package clients for each of them into a single library, the size of the final artifact becomes ridiculously large. The SDK authors solved this through code generation based on the declarative Smithy language.

The repository doesn't contain pre-generated code for every AWS service. Code is created during project build. If you build the SDK yourself from source, you can specify only the services actually needed in your application.

Configuration filtering happens in the local.properties file:

# Генерируем клиент только для AWS Lambda
aws.services=+lambda

If you need to remove certain services from the build, use a minus sign:

# Исключаем AWS Location и DynamoDB
aws.services=-location,-dynamodb

Code generation is triggered through Gradle:

./gradlew --no-daemon :codegen:sdk:bootstrap

After that, the generated module is built with the standard task:

./gradlew :services:lambda:build

This approach saves time during local development and testing of individual SDK modules.

Documentation build via Dokka

For documenting code, the developers use Dokka — the standard JetBrains tool that works with the KDoc format.

To generate API reference locally, the repository provides a command:

./gradlew --no-daemon --no-parallel dokkaHtmlMultiModule

Finished HTML documentation goes into the build/dokka/htmlMultiModule directory. To open it in a browser, you need any simple HTTP server, for example the one built into IntelliJ IDEA or launched via Python:

python3 -m http.server --directory build/dokka/htmlMultiModule

Is it worth switching to Kotlin SDK

The repository has around 500 stars on GitHub. The number is relatively small because the project was in active development status for a long time, and many teams habitually use Java SDK v2. Nevertheless, the library is already production-ready and officially supported by Amazon.

The library comes in handy in four scenarios:

• You're building an Android app that needs direct access to AWS services without dragging in heavy Java dependencies.
• You're writing Serverless functions in Kotlin for AWS Lambda with GraalVM Native Image compilation, where cold start speed is critical.
• Your backend is entirely built on coroutines and Ktor, and you want to keep a consistent async code style.
• You're making a multiplatform module that combines logic for mobile and server.

If you already have a large legacy project on Spring Boot with the old Java SDK, there's no point in urgently rewriting it. But for new services and applications in Kotlin, this SDK looks like the logical choice.