aws-sdk-rust: the AWS SDK for Rust, crate by crate

What aws-sdk-rust actually replaces in a Rust service

Calling an AWS API from Rust by hand means SigV4 request signing, credential discovery across environment variables, config files, container and instance metadata, retry and timeout policy, and a per-service request and response shape. aws-sdk-rust packages all of that. The README states the SDK is code generated from Smithy models that represent each AWS service, and that the generating code lives in smithy-rs. The practical consequence is that the SDK surface tracks the service models rather than being hand-written per API.

The audience is narrow and specific. It is for teams writing Rust binaries or services that need to talk to AWS and want the same credential behaviour they get from the CLI or from other AWS SDKs. The repository layout makes the granularity explicit: the workspace Cargo.toml lists one member per service, from sdk/accessanalyzer through the runtime crates such as sdk/aws-config, sdk/aws-credential-types, sdk/aws-sigv4 and sdk/aws-smithy-runtime. You depend on the services you use, not on a monolith. If your workload is a Rust Lambda that reads a queue and writes to DynamoDB, this is the intended shape.

One crate per service and where the credentials come from

The architecture has three layers visible in the repository. Service crates under sdk/ hold the generated clients. Runtime crates hold the shared machinery: aws-config for configuration loading, aws-credential-types for credential types, aws-sigv4 for signing, and the aws-smithy-* crates for HTTP, JSON, query, event stream and runtime behaviour. The README notes that the runtime and handwritten code is copied into this repo as part of code generation from smithy-rs, so the runtime crates you depend on are snapshots produced by the build, not separately maintained forks.

Credential resolution is the part most people get wrong. The README lists the default credential provider chain order: environment variables AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY and AWS_REGION; the files at ~/.aws/config and ~/.aws/credentials (the README notes the location can vary per platform); web identity token credentials from the environment or container, including EKS; ECS container credentials for IAM roles for tasks; and finally the EC2 instance metadata service. That ordering means a stray AWS_ACCESS_KEY_ID in your shell silently wins over the role attached to the task. On ECS and Lambda that is the most common cause of a client authenticating as the wrong principal.

Installing aws-sdk-rust and listing DynamoDB tables

Prerequisites are Rust and Cargo. The README links to the official Rust installation instructions and states the SDK currently requires a minimum of Rust 1.94.1 and is not guaranteed to build on earlier compilers. It also states the SDK provides one crate per AWS service and that you must add Tokio as a dependency to execute asynchronous code.

Start a project and add the dependencies. The README gives this exact Cargo.toml block, using aws-config with the behavior-version-latest feature, the DynamoDB service crate, and Tokio:

[dependencies]
aws-config = { version= "1.12.0", features = ["behavior-version-latest"] }
aws-sdk-dynamodb = "1.127.0"
tokio = { version = "1", features = ["full"] }

Then make a request. The README's example loads configuration from the environment, builds a client, and calls list_tables with a limit of 10:

use aws_sdk_dynamodb::{Client, Error};

#[tokio::main]
async fn main() -> Result<(), Error> {
    let shared_config = aws_config::load_from_env().await;
    let client = Client::new(&shared_config);
    let req = client.list_tables().limit(10);
    let resp = req.send().await?;
    println!("Current DynamoDB tables: {:?}", resp.table_names);
    Ok(())
}

What you should see is a printed vector of table names for the region resolved by the credential chain. Note the two-step call shape: the builder returns a request, and .send().await executes it. That split is what makes per-call overrides possible, and it is also why error handling attaches to send() rather than to the builder. Before you ship, check crates.io for the current aws-config and aws-sdk-dynamodb versions instead of pinning the versions shown above.

The MSRV policy is the real upgrade constraint

The README is unusually direct about the toolchain: the SDK keeps the minimum compiler version two releases behind the latest stable where possible, and increases in the minimum required Rust version are called out in the release notes. The current floor is 1.94.1. For a team with a pinned toolchain in CI, that policy means a compiler bump can land on a Tuesday release and block your upgrade until you move the toolchain.

The release cadence compounds this. The recent releases listed are release-2026-09-22, release-2026-09-21 and release-2026-09-18, and the last push to the repository was on 2026-09-22. Daily or near-daily generated releases are normal for this project. Nothing forces you to take them, but the version numbers in the README will be stale within days, and the gap between the versions you pin and the versions on crates.io grows quietly. Treat the SDK as a dependency you schedule updates for, not one you set and forget.

The second constraint is coverage. Because every client is generated from a service model, a service or a new operation appears only after the model and the generator support it. The workspace list in Cargo.toml is long, but it is a finite list, and the README points at the public roadmap project rather than promising parity with every AWS API on day one. If your target service is not there, no amount of configuration will produce a client for it.

Testing without calling AWS, and what the mock support does not cover

The repository includes sdk/aws-smithy-mocks among the runtime crates, which is the piece aimed at exercising client code without hitting a live endpoint. The README itself does not document the mocking API, so the honest position is that mock support exists in the workspace but its usage is not described in the README. Anyone planning a test strategy should read the crate documentation directly rather than assume the API shape.

The same caution applies to two other areas. The README does not document rollback or downgrade behaviour for a bad generated release, so a team that pins aggressively should decide its own policy for reverting a version. And while the repository has a tests/ directory with entries such as tests/no-default-features, tests/telemetry, tests/webassembly-wstd and tests/webassembly-no-os, the README does not describe what those suites assert. Those directory names suggest the project tracks no-default-feature builds and WebAssembly targets, but that is inference from the layout, not a documented support commitment.

aws-sdk-rust compared with rusoto and with the CLI

The obvious alternative for Rust developers was rusoto, which took the opposite architectural route: a community-maintained set of crates rather than a generator fed by AWS service models. The difference shows up in coverage and in update lag. With a generated SDK, a new API operation arrives when the model and generator produce it; with a hand-maintained client, someone has to write the binding. That is the trade you are making when you pick aws-sdk-rust over a community client, and it is why the SDK's roadmap and release notes matter more than its API aesthetics.

A second alternative is not a library at all: shelling out to the AWS CLI or calling the APIs from a different language. That is a reasonable choice when a Rust service needs exactly one AWS call and you do not want the dependency tree. The cost is that you inherit process management, output parsing, and a second credential configuration path. The SDK earns its place when the number of AWS calls and the need for typed request and response structures grow past the point where parsing CLI output is pleasant.

Licence and the cost of generated code

The repository is licensed under Apache-2.0, and the README states this plainly. Apache-2.0 includes an express patent grant and permits commercial use, modification and redistribution provided you keep the licence and notice files; the repository ships both LICENSE and NOTICE, and the NOTICE file is the one people forget to carry into a redistributed binary. This is a description of the licence text, not legal advice, and if you redistribute the SDK inside a product you should have your own counsel review the NOTICE obligations.

The upgrade cost is more concrete than the licence. Every generated release pulls the runtime crates forward with it, so bumping aws-sdk-dynamodb can also move aws-smithy-runtime and aws-config. In a workspace with several service crates, those versions need to agree. The practical approach is to update the service crates and the runtime crates in one commit, run your test suite, and read the release notes for MSRV increases, which the README says are called out there. The CHANGELOG.md at the repository root is where those entries live.

Editorial conclusion

Adopt aws-sdk-rust if your service is already Rust and you can track Rust 1.94.1 or newer, because the credential chain and per-service crates remove the signing and retry code you would otherwise write. Do not adopt it if you are pinned to an older toolchain, if you need a service the generated crate list does not include, or if you only call one AWS API from a non-Rust service. Verify first that the specific sdk/<service> crate you need exists in Cargo.toml, then confirm the current aws-config and aws-sdk-<service> versions on crates.io rather than copying the versions in the README.

Frequently asked questions

Official sources

1. awslabs/aws-sdk-rust on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases