AWS SDK for Java 2.0: what the Maven BOM buys you, and what it costs

Who aws-sdk-java-v2 is actually for

This is the official AWS SDK for Java, version 2. The README describes it as a rewrite of 1.0 with new features, and the two it names first are a pluggable HTTP implementation and first class support for non-blocking IO in async clients. That framing tells you who the project is aimed at. If you are writing a JVM service that talks to S3, DynamoDB, EC2 or any other AWS service, and you want the client maintained by AWS rather than a third party wrapper, this is the default choice. The minimum requirement stated in the README is Java 1.8 or newer, and the maintenance section says full support is maintained on the LTS releases Java 8, Java 11, Java 17 and Java 21.

The interesting audience is narrower than that. Version 1.0 already worked. What 2.0 changes is the IO model and the HTTP layer, which matters when you are running high concurrency workloads where thread-per-request blocking does not scale, or when you have an opinion about which HTTP client your stack should use. If your application makes a handful of AWS calls per request and you are happy with blocking IO, the case for moving is much weaker, and the README itself points at a migration changelog rather than claiming a drop-in upgrade.

There is a constraint worth stating plainly. The README notes that individual features in newer Java releases may not be supported because the SDK must stay compatible with Java 8. That is a deliberate floor, not an oversight, and it means you should not expect the SDK to adopt newer language or runtime facilities quickly.

How the modules, BOM and HTTP layer fit together

The repository layout shows the shape of the project. There is a core directory, an http-client-spi directory, an http-clients directory, a services directory, a codegen directory with its own Maven plugin, and a bom directory. That is the architecture in miniature: service clients are generated from models by the codegen tooling, they sit on top of core, and the actual network transport is selected from http-clients behind the interface defined in http-client-spi.

That SPI is the mechanism behind the README's claim that you can plug in your own HTTP implementation. Rather than hard-coding a transport, the SDK defines the contract and ships implementations. The practical consequence is that the HTTP client is a dependency decision you make, not one the SDK makes for you, and swapping it does not require changing your service call sites.

The second axis is sync versus async. The README says async clients get first class non-blocking IO support. So for a given service you have a blocking client and a non-blocking one, and the choice is per client rather than per application. You can use the blocking S3 client in one part of a codebase and the async one elsewhere, which is useful when only some call paths are latency sensitive.

Version alignment is handled by the BOM. The README explains that importing the BOM lets individual modules omit their version, and notes that currently all modules share the same version but that this may not always be the case. That last clause is the real argument for the BOM: it is insurance against a future where service modules version independently, and it removes the chore of bumping a version string in a dozen dependency blocks.

Installing aws-sdk-java-v2 from Maven Central

The README states that the recommended way to consume the SDK is from Maven Central, and that you can get started using Maven or any build system that supports Maven Central as an artifact source. There are no install steps beyond adding dependencies; nothing is downloaded and run separately.

Start by importing the BOM in your dependency management block. This pins the version for every AWS module you later declare. The README shows exactly this, with version 2.55.4:

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>software.amazon.awssdk</groupId>
      <artifactId>bom</artifactId>
      <version>2.55.4</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

With the BOM in place, declare only the services you use and leave the version out. The README gives ec2, s3 and dynamodb as the example set:

<dependencies>
  <dependency>
    <groupId>software.amazon.awssdk</groupId>
    <artifactId>s3</artifactId>
  </dependency>
</dependencies>

If you would rather not use a BOM, the README also shows the individual form, where each dependency carries its own version. That is the pattern to use if your build cannot import a BOM, but you then own the version alignment yourself.

There is also a whole-SDK artifact, aws-sdk-java, which the README says includes all services. The same paragraph recommends importing only the modules you need, and that is the right default: pulling every service into a build to use one of them is a cost you pay at compile and packaging time for no benefit.

Gradle users are not shown a snippet in the README, but the same coordinates in the software.amazon.awssdk group apply, and the BOM can be consumed as a platform dependency in the usual way. The README does not give a Gradle example, so treat the exact syntax as something to confirm against your Gradle version rather than copying from here.

The SDK needs an AWS account and credentials before any call will succeed. The README points at the Sign Up for AWS section of the developer guide for creating an account and retrieving credentials, and at the setup section for further usage information. It does not document a credential chain in the README itself, so the developer guide is where that detail lives.

Building the SDK from source and where the samples are

Most teams should not build this from source. It is worth knowing how, though, because the commands reveal the module structure. On Linux the README gives three forms: a full build, a quick build that skips tests, checkstyles and findbugs, and a single-module build.

./mvnw clean install
./mvnw clean install -P quick
./mvnw clean install -pl :s3 -P quick --am

On Windows the equivalent is ./mvnw.cmd clean install. The -pl :s3 flag targets the S3 module by artifact name, and --am builds the modules it depends on. If you have ever wondered whether the service clients are independent artifacts, that command answers it: they are separate Maven modules and can be built in isolation.

For sample code, the README points at two places rather than embedding examples. The first is the aws-doc-sdk-examples repository. The second is the integration tests inside this repository, located in the it directory under each service module, with the S3 integration tests called out as an example. That second pointer is more useful than it sounds. Integration tests exercise real service calls, so they show how clients are constructed and configured in a way that unit tests do not. They are also the closest thing to a working example that ships with the code.

The README does not include a hello-world snippet for any service. If you are looking for a first call to copy, the developer guide linked from the README and the examples repository are where the project directs you.

The Java 8 floor and the version treadmill

Two limitations deserve attention before you adopt this.

The first is the Java 8 compatibility floor. The README states it twice: the minimum requirement is Java 1.8+, and newer releases may contain features that are not supported because the SDK must remain compatible with Java 8. The practical effect is that the SDK cannot use language or library facilities introduced after Java 8 in its own implementation, even when running on Java 21. That is a reasonable trade for a library that wants to serve the widest possible install base, and it is also a ceiling. If your codebase has moved past Java 8 idioms, the SDK will feel dated in places, and that is a deliberate choice on AWS's part rather than something that will be fixed in a patch release.

The second is release cadence. The recent releases listed for this repository are 2.55.4, 2.55.3 and 2.55.2, published on consecutive days in September 2026. That is a very fast patch cadence. The BOM exists partly to make this manageable: you bump one version property and every module moves with it. Teams that pin each service module individually instead are signing up to track several version numbers that are currently identical but, per the README, may not stay that way.

Neither of these is a defect. They are the conditions of using a widely deployed, backward-compatible SDK. If you want a client that moves quickly with the JVM platform, this is not that client.

aws-sdk-java-v2 against version 1.0

The obvious alternative is the AWS SDK for Java 1.0. It is not a different vendor or a wrapper; it is the previous major version of the same SDK, and the README treats 2.0 as a rewrite of it. The difference in approach is concentrated in the two features the README highlights: a pluggable HTTP implementation and non-blocking IO in async clients.

In 1.0 terms, the HTTP transport was not something you swapped through a published SPI in the same way, and the async story was thinner. If you are on 1.0 and your workload is blocking and modest, the migration is a real cost with a modest payoff, and you should say so out loud rather than migrating because 2.0 exists. If you are on 1.0 and fighting thread exhaustion under load, or you want to standardize on a particular HTTP client across your stack, the 2.0 design is aimed squarely at you.

The repository supports that migration rather than leaving it to you. There is a docs/LaunchChangelog.md file linked from the README as the 1.11 to 2.0 changelog, and a v2-migration directory at the top level. Those are the places to start, and the changelog is the honest answer to how much of your 1.0 code will need to change.

One caveat: the SDK is Java only. If part of your stack is not on the JVM, this project does not help that part, and you will be running two AWS client stories side by side.

Licence, support and what you are agreeing to

The repository is licensed under Apache-2.0, with LICENSE.txt and NOTICE.txt at the top level. Apache-2.0 is a permissive licence that permits commercial and closed-source use, and it includes a patent grant. The NOTICE file is there because the licence expects attribution to be preserved where the project ships one; how that applies to your distribution is a question for your own legal review, not something this article can settle.

Support policy is documented separately rather than in the README. The README points at two documents in the AWS SDKs and Tools Reference Guide: the maintenance policy and the version support matrix. Those are the authoritative sources for how long a given major version receives updates and which dependencies are supported. If your adoption decision depends on a support horizon, read those documents rather than inferring anything from release cadence.

For contributions and bug reports, the README is explicit that submitting issues is the preferred channel to interact with the team, and it points at the issues page for feature requests and upvotes. There is also a CONTRIBUTING.md and a CODE_OF_CONDUCT.md in the repository. If you are adopting this as a dependency rather than contributing to it, none of that changes your obligations, but it does tell you where a fix would have to come from if you hit a bug.

Editorial conclusion

Adopt aws-sdk-java-v2 if you are on Java 8 or newer and want a supported AWS client with both blocking and non-blocking paths; the BOM keeps module versions aligned and the per-service artifacts keep your dependency graph small. Do not adopt it if you need a client for a language other than Java, or if you are still on SDK 1.0 and have not budgeted for the migration that docs/LaunchChangelog.md and the v2-migration directory describe. Before you commit, verify three things: that your build resolves software.amazon.awssdk:bom at 2.55.4, that your HTTP client choice is the one you actually want, and that the service module you need exists under services/ rather than only in the bundled artifact.

Frequently asked questions

Official sources

1. aws/aws-sdk-java-v2 on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases