Spring Cloud AWS and the version matrix you have to check first

A relocation, not a rewrite

The repository description is the shortest summary available: the new home for Spring Cloud AWS. The project simplifies using AWS managed services in Spring and Spring Boot applications, and the documentation links, the module names and the awspring.io homepage all point at a project that has moved out of its previous location and settled into its own organisation.

The audience is a team that already decided to build a Spring service on AWS and now faces the second question, which is how the managed services get into the application. Without a layer like this, the choice is to write AWS SDK clients yourself, wire credentials, and reproduce the same connection management, retry behaviour and configuration surface in every service. With it, the intent is that a dependency plus a configuration key is enough.

The scale of the project is visible in the module list. There are close to twenty Maven modules at the root, one per service or concern, and they are not sample code but published artifacts that a consumer depends on individually.

One module per service, plus the plumbing modules

The root directory reads like a catalogue. The service modules include spring-cloud-aws-s3/, spring-cloud-aws-sqs/, spring-cloud-aws-sns/, spring-cloud-aws-ses/, spring-cloud-aws-dynamodb/, spring-cloud-aws-kinesis/ with a companion spring-cloud-aws-kinesis-stream-binder/, spring-cloud-aws-parameter-store/, spring-cloud-aws-secrets-manager/ and spring-cloud-aws-app-config/.

Around them sit the modules that make the service modules usable. spring-cloud-aws-autoconfigure/ holds the auto-configuration, spring-cloud-aws-core/ the shared abstractions, spring-cloud-aws-starters/ the curated dependency sets, and spring-cloud-aws-dependencies/ the bill of materials for pinning versions consistently across a set of services.

Then there is the part that shows how the project is built to be used in earnest rather than only demoed. spring-cloud-aws-samples/ contains example applications, spring-cloud-aws-docker-compose/ provides a compose based local environment, and there are two separate test modules, spring-cloud-aws-test/ and spring-cloud-aws-testcontainers/, which tells you the maintainers support both a hand-rolled harness and a Testcontainers based one. spring-cloud-aws-modulith/ is for the Spring Modulith approach to modular monoliths. This is a project aimed at a broad estate of services rather than one application.

The compatibility table is the real contract

Before anything else, check the table. The project publishes which Spring Cloud, Spring Boot, Spring Framework and AWS Java SDK versions each Spring Cloud AWS line supports, and the differences between lines are large enough to break a build.

The 2.x lines are marked as being in maintenance mode. 2.3.x pairs with Spring Cloud 2020.0.x, Spring Boot 2.4.x and 2.5.x, Spring Framework 5.3.x and AWS Java SDK 1.x. 2.4.x pairs with Spring Cloud 2021.0.x, Spring Boot 2.6.x and 2.7.x, and the same 5.3.x framework line and SDK 1.x. The 3.x lines move to Spring Framework 6.x and AWS Java SDK 2.x, and the current 4.x line sits on Spring Cloud 2025.1.x, Spring Boot 4.0.x, Spring Framework 7.0.x and AWS Java SDK 2.x.

Two notes in the table decide real projects. 3.0.0-M2 is the last version compatible with Spring Boot 2.7.x and Spring Cloud 3.1, and from 3.0.0-M3 onwards the project switched to Spring Boot 3.0. And 3.4.x is the last version compatible with Spring Boot 3.5.x and Spring Cloud 2025.0.x, which means an application on Boot 3.5 is pinned to the 3.4.x line and cannot move to 4.x without first moving to Spring Boot 4.0.x. The AWS Java SDK major version is a second migration axis, from 1.x to 2.x, and it arrives at the 3.0.x boundary.

The supported services table stops short of the newest release

The README carries a table of supported AWS integrations with one column per Spring Cloud AWS line: 2.x, 3.x, 4.0.x and 4.1.x. S3 and SNS are marked as supported across all of them, and the table extends over the other services the project ships modules for, one row per AWS service.

Notice what is missing. The newest tagged release is v4.2.0, published on 2026-09-29, and the reference documentation table above it also stops at 4.1.1, so there is no column and no documentation link for 4.2.0. The last push to the repository was on 2026-10-15, which is after that release, so the branch has moved on again.

The practical reading is that the README is maintained by hand and lags the tags. If you are deciding whether a service is supported in the exact version you intend to pin, the authoritative source is the release notes and the module list rather than this table, and you should check the reference documentation for your version directly. For a project whose releases land roughly monthly, a stale compatibility matrix is a normal condition and not a warning sign on its own, but it does mean the README is not something to paste into your own runbook without verifying it.

Building with mvnd and a spotless-enforced format

The build is Maven based, with mvnw and mvnw.cmd wrappers at the root and a.mvn/ directory, and the Makefile drives it through mvnd, the Maven daemon. The targets are short enough to read in one sitting:

mvnd spotless:apply

That is the format target, and it runs the Spotless plugin to apply the code style, which matches the eclipse-code-formatter.xml and license-header.txt files at the root. The build target runs the full verification with the formatter applied afterwards:

mvnd verify spotless:apply

Documentation is built through a profile rather than a default task, and the classic reference docs are produced with tests skipped:

mvnd verify -Pdocs-classic -DskipTests=true

A second target, docs-full, adds an aggregated javadoc build with the same profile and skip flag. The Makefile also has a clean target that runs mvnd clean. A Gitpod configuration and a.gitpod.yml at the root mean the repository can be opened in a hosted workspace, which is convenient for trying a change without a local JDK and Maven setup.

One sponsorship detail is worth knowing because it explains the local testing story: the README thanks LocalStack for providing PRO licences to the development team. The docker-compose and testcontainers modules are the natural way to exercise AWS-dependent code locally.

Old lines linger in maintenance mode

The documentation table still links reference and API docs for a long tail of releases, going back through 3.3.1, 3.2.1, 3.1.1, 3.0.4 and the 2.x series down to 2.3.5 and 2.4.4. That is a deliberate signal: teams on those versions are still supported for reference purposes even though the code lines themselves are in maintenance mode.

Maintenance mode here means bug fixes and security patches rather than new features, which fits how a compatibility-coupled library ages. Spring Cloud AWS cannot add a capability that the Spring Boot version in a line does not have, so the older lines change very little by design.

For an adopter, the practical consequence is that staying on an old line is a legitimate choice with a defined end, but it is a choice that comes with a growing gap. The 2.x lines are on Spring Framework 5.3.x and AWS Java SDK 1.x, and staying there means staying on an SDK major version that is no longer where new AWS services are added. The documentation staying online is a courtesy, not a sign that the line is a good place to be.

Apache-2.0, four releases in a season, and no archive notice

The licence is Apache 2.0, stored in LICENSE.txt with the licence header template in license-header.txt and enforced by the formatter during the build, so new files have to carry the notice. That is a permissive licence with an explicit patent grant, which is the usual choice for infrastructure libraries embedded in commercial services.

The repository is not archived. The last push was on 2026-10-15, and the release history shows v4.2.0 on 2026-09-29, v4.1.1 on 2026-08-28 and v4.1.0 on 2026-07-22. That is a monthly-ish cadence for a minor line, which is normal for a library whose release content is dictated by upstream Spring and AWS releases rather than by its own feature plans.

The project also ships a SECURITY.md and a CONTRIBUTING.md, and a CODEOWNERS-adjacent review culture is visible in the build requirements, since the formatter runs as part of verify and the build is the gate. Nothing here needs special handling for a team picking a version. The one thing worth doing is checking the release notes for the version you intend to upgrade to, because the compatibility table changes from release to release and a mismatch between your Spring Boot line and the Spring Cloud AWS line fails at build or startup rather than at compile time in every case.

Editorial conclusion

Adopt Spring Cloud AWS if your service already runs on Spring Boot and you want S3, SQS, SNS, DynamoDB, Secrets Manager and the rest wired in through auto-configuration instead of hand-written SDK clients. Do not adopt it if your application is on a Spring Boot version outside the matrix, since the 2.x and 3.x lines are in maintenance mode and the 4.x line requires Spring Boot 4.0.x with Spring Framework 7.0.x. Verify three things before you upgrade: your Spring Cloud release train against the compatibility table, which service integrations exist in the release you are pinning, and whether the README's supported services table has caught up with the version you install, because it currently stops at 4.1.x while v4.2.0 was published on 2026-09-29 and the last push was on 2026-10-15.

Frequently asked questions

Official sources

1. awspring/spring-cloud-aws on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases