aws-sdk-s3

aws-sdk-s3 is the official Rust client for Amazon S3, one of several hundred per-service crates published from the awslabs/aws-sdk-rust monorepo. Like every crate in that repository, it is generated from Smithy service models (via the smithy-rs code generator) rather than hand-written, giving it complete, always-current coverage of the S3 REST API’s operations, request/response types, and error variants.

The crate is built on Tokio for async execution and integrates with aws-config for credential resolution (environment variables, shared config/credentials files, IAM roles, ECS/EKS container credentials, and EC2 instance metadata), following the same client-construction pattern (aws_config::load_from_env() + Client::new(&config)) shared across every AWS Rust SDK crate. It was selected as the canonical primary package for this repository over the initially-suggested aws-sdk-bedrock because it has vastly higher adoption (over 71M monthly downloads vs. roughly 354K for aws-sdk-bedrock), reflecting S3’s status as the most widely used AWS service from Rust.

What You Get

• A typed async Client covering every S3 REST API operation (bucket/object CRUD, multipart uploads, presigned URLs, and more)
• Integration with aws-config for automatic credential resolution across environment variables, shared config files, IAM roles, and container/instance metadata
• Strongly typed request builders and response structs generated from AWS’s official Smithy service model, so the API surface tracks S3’s real capabilities exactly
• Consistent client-construction and error-handling patterns shared across all other aws-sdk-* crates in the same monorepo
• Tokio-based async execution with full support for streaming request/response bodies

Common Use Cases

• Uploading, downloading, and managing objects in S3 buckets from a Rust backend service
• Building data pipelines or CLIs that read/write large objects via S3 multipart upload/download
• Generating presigned URLs for temporary, credential-free client access to S3 objects
• Migrating an existing AWS-integrated Rust service from a community S3 client to the officially maintained, Smithy-generated SDK

Under The Hood

Architecture: Every crate in the monorepo, including sdk/s3, is machine-generated by the smithy-rs code generator (hosted in the separate smithy-lang/smithy-rs repository) from Smithy models under aws-models/; the generated sdk/s3/src contains the Client struct, per-operation fluent builders, typed input/output structs, and error enums, all reflecting the exact shape of the S3 API version 2006-03-01. Tech Stack: Rust 2021 edition (MSRV pinned per-release, e.g. 1.94.1), async via Tokio, credential/config handling delegated to the separately-versioned aws-config crate, and dependencies like arc-swap used internally for the generated client’s shared configuration state. Code Quality: Every generated file carries a DO NOT EDIT header pointing back to the code generator, meaning correctness and quality are governed upstream in smithy-rs and the Smithy models rather than through hand-review of this repository’s generated output; the monorepo itself runs an extensive tests/ suite and a public roadmap/CODEOWNERS process reflecting direct AWS ownership. API Design: The aws_config::load_from_env().await + Client::new(&config) construction pattern, and the fluent per-operation builder style (client.list_tables().limit(10).send().await), is identical across all ~300+ generated AWS Rust SDK crates, so developer experience learned on one AWS service (e.g. S3) transfers directly to any other (DynamoDB, Bedrock, Kinesis) with no additional learning curve beyond each service’s own operation set.