If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/awslabs/aws-sdk-rust shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Single-maintainer risk — review before adopting

• Last commit today
• 5 active contributors
• Apache-2.0 licensed
• CI configured
• ⚠ Single-maintainer risk — top contributor 94% of recent commits
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live awslabs/aws-sdk-rust repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/awslabs/aws-sdk-rust.

What it runs against: a local clone of awslabs/aws-sdk-rust — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in awslabs/aws-sdk-rust | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of awslabs/aws-sdk-rust. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/awslabs/aws-sdk-rust.git
#   cd aws-sdk-rust
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of awslabs/aws-sdk-rust and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "awslabs/aws-sdk-rust(\\.git)?\\b" \\
  && ok "origin remote is awslabs/aws-sdk-rust" \\
  || miss "origin remote is not awslabs/aws-sdk-rust (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/awslabs/aws-sdk-rust"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

The AWS SDK for Rust is a code-generated, service-specific Rust library that provides idiomatic bindings to all AWS services via Smithy models. It generates one crate per AWS service (e.g., aws-sdk-dynamodb, aws-sdk-s3) with async/await support and integrates with the Tokio runtime to enable Rust developers to interact with AWS infrastructure without writing low-level HTTP boilerplate. Workspace monorepo (Cargo.toml resolver v2) with ~200 crates under sdk/: service crates (sdk/dynamodb, sdk/s3, etc.), shared runtime crates (aws-config, aws-credential-types, aws-runtime, aws-sigv4), and Smithy-specific crates (aws-smithy-json, aws-smithy-xml, aws-smithy-runtime-api). The .handwritten directory marks code not regenerated from Smithy. AWS service models live in aws-models/.json (Smithy JSON definitions).

Rust developers building cloud applications who need type-safe, async access to AWS services. Contributors are primarily AWS SDK maintainers and Rust community members extending service coverage or fixing AWS API compatibility issues.

Production-ready and actively maintained. The repo shows 1.6M+ lines of Rust code, comprehensive CI/CD workflows (audit.yaml, canary.yaml, release-checks.yaml), public roadmap at github.com/orgs/awslabs/projects/50, and MSRV stability at 1.91.1. Recent activity spans multiple service crates with regular updates.

Low immediate risk but requires careful dependency management. The monorepo includes 100+ service crates plus 20+ smithy runtime/helper crates (aws-smithy-* family), creating a large transitive dependency surface. Code is auto-generated from smithy-rs (not hand-written), so direct patches may be overwritten on regeneration. Breaking changes can ripple across all dependent services when Smithy models shift.

Active development across multiple vectors: service coverage expansion (canary.yaml tests new service additions), security audits (audit.yaml), release validation (release-checks.yaml), and regression detection (issue-regression-labeler.yml). The public roadmap suggests ongoing work on cross-cutting concerns (observability, compression, DNS resolution via aws-smithy-* crates) and service-specific improvements.

git clone https://github.com/awslabs/aws-sdk-rust.git
cd aws-sdk-rust
cargo build  # builds entire workspace
cargo test --workspace  # runs all tests

Daily commands: No single 'server' to run—this is a library SDK. For examples: cd sdk/dynamodb && cargo build --example ... (check each service crate for example/ directory). For tests: cargo test --workspace (respects excluded test crates in Cargo.toml: webassembly-*, telemetry, no-default-features).

• sdk/aws-config/src/lib.rs: Core credential chain implementation and default provider setup—essential for all SDK users to understand authentication flow.
• sdk/aws-smithy-runtime/src/lib.rs: Middleware pipeline, retry logic, and request lifecycle—fundamental to how all service requests are processed.
• sdk/aws-sigv4/src/lib.rs: AWS Signature Version 4 signing implementation—critical for request authentication and security.
• .github/workflows/ci.yaml: Main CI pipeline defining build, test, and validation strategy across the entire workspace.
• Cargo.toml: Workspace root configuration declaring 200+ member crates and resolver version—controls the entire monorepo structure.
• aws-models/: Source Smithy JSON model definitions for each AWS service—these drive code generation for all service crates.

1. New service features: add to sdk/[service]/src/lib.rs and sdk/[service]/Cargo.toml (though most changes are code-generated). 2) Shared runtime fixes: edit sdk/aws-smithy-*/src/ for protocol, async, or observability changes. 3) Credential/config logic: modify sdk/aws-config/src/. 4) CI/test improvements: edit .github/workflows/ files. Start with understanding the specific service crate's structure before attempting edits, as regeneration overwrites hand-written code.

1. Code generation ownership: Most code under sdk/[service]/src/generated/ is auto-generated from smithy-rs; hand-edits will be overwritten on next build. Only modify .handwritten files or shared runtime crates. 2) Feature flag dependencies: Many crates expose optional features (e.g., 'behavior-version-latest' in aws-config)—using the SDK without correct features can silently disable critical behavior. 3) Excluded test crates: Cargo.toml excludes webassembly-*, telemetry, and no-default-features test crates from normal workspace builds; run them explicitly. 4) Credential chain ordering: aws-config::load_from_env() checks env vars, then ~/.aws, then Web Identity, then ECS—if multiple are present, order matters. 5) MSRV 1.91.1: Some async patterns or edition features may not work on older Rust versions.

• Smithy (service modeling language) — The entire aws-sdk-rust is code-generated from Smithy models in aws-models/; understanding Smithy syntax and shapes is essential for contributing service improvements or debugging API mapping issues.
• AWS Signature Version 4 (SigV4) — Every SDK request is signed using SigV4 (aws-sigv4 crate); contributors must understand header signing, canonical request format, and credential scope to debug authentication failures.
• Middleware pipeline pattern — aws-smithy-runtime implements request/response middleware (retry, timeout, signing, logging) as a composable pipeline; understanding this pattern is key to extending SDK behavior without modifying service crates.
• AWS credential provider chain — aws-config implements the default credential provider chain (env → file → Web Identity → ECS → EC2 metadata); SDK users must understand the fallback order to diagnose authentication issues.
• Async/await with Tokio runtime — All AWS SDK operations are async via #[tokio::main]; understanding Tokio task spawning, cancellation, and runtime configuration is necessary for integrating the SDK into larger applications.
• Protocol serialization (JSON-RPC, XML, Query) — Different AWS services use different wire protocols (JSON, XML, Query); aws-smithy-json, aws-smithy-xml, and aws-smithy-query crates handle this—understanding which protocol a service uses helps debug serialization issues.
• Transitive dependency management in monorepos — The workspace includes 200+ crates with shared dependencies (hyper, tokio, serde); version conflicts and feature flag interactions across the monorepo require careful management to avoid breaking changes.

• smithy-lang/smithy-rs — Upstream code generator that produces all aws-sdk-rust service crates from Smithy models—essential for understanding code generation and submitting runtime improvements.
• awslabs/aws-cdk-rust — Rust bindings for AWS CDK; often used alongside aws-sdk-rust for infrastructure-as-code workflows in Rust projects.
• tokio-rs/tokio — Required async runtime dependency for all aws-sdk-rust operations; understanding Tokio is critical for using the SDK effectively.
• awsdocs/aws-doc-sdk-examples — Official AWS examples repository including Rust SDK examples (rustv1 folder)—primary reference for common service usage patterns and best practices.
• hyperium/hyper — HTTP client library underlying aws-sdk-rust; relevant for debugging transport-level issues or customizing HTTP behavior.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add integration tests for aws-smithy-runtime retry and timeout behavior

The SDK has comprehensive runtime modules (aws-smithy-runtime, aws-smithy-runtime-api) but there are no visible integration tests validating retry logic, exponential backoff, and timeout configurations across different AWS services. This is critical for reliability and would help catch regressions in runtime behavior.

• [ ] Create tests/runtime-behavior directory with integration test suite
• [ ] Add tests for retry policy configurations using mock services from sdk/aws-smithy-mocks
• [ ] Add tests for timeout behavior across different service clients
• [ ] Add tests for retry exhaustion and error propagation
• [ ] Document retry/timeout patterns in CONTRIBUTING.md

Add WebAssembly compatibility tests with proper CI workflow

The repo excludes 'tests/webassembly-wstd' and 'tests/webassembly-no-os' from the workspace, suggesting WASM support exists but testing is incomplete. The .github/workflows directory has no dedicated WASM test workflow, making it easy to regress WASM compatibility.

• [ ] Create .github/workflows/wasm-tests.yaml to test wasm32-unknown-unknown and wasm32-wasi targets
• [ ] Update tests/webassembly-wstd and tests/webassembly-no-os with integration test cases
• [ ] Add WASM-specific examples to demonstrate usage in browser/Node.js environments
• [ ] Document WASM setup and limitations in CONTRIBUTING.md with specific crate requirements

Add comprehensive test coverage for aws-smithy-observability and OpenTelemetry integration

The repo includes aws-smithy-observability and aws-smithy-observability-otel crates but there are no visible test workflows validating observability instrumentation. Given that observability is critical for production SDKs, this gap could hide bugs in tracing, metrics, and logging.

• [ ] Create tests/observability-integration directory with comprehensive test suite
• [ ] Add tests validating OTel span generation for service calls, retries, and errors using sdk/aws-smithy-observability-otel
• [ ] Add tests for metric collection and propagation across runtime components
• [ ] Add a .github/workflows/observability-tests.yaml CI workflow
• [ ] Create examples/observability-setup.rs demonstrating proper instrumentation configuration

• Add integration examples for each service crate (e.g., sdk/[service]/examples/[operation].rs) covering common use cases like DynamoDB table operations or S3 uploads—many crates are missing runnable demos.
• Expand Smithy model validation tests in the canary workflow (.github/workflows/canary.yaml)—add checks for newly released AWS services to catch model inconsistencies early.
• Create a 'Getting Started' contributor guide documenting the code-generation workflow from Smithy models to generated Rust code, explaining why files exist and which are safe to edit.

The AWS SDK for Rust demonstrates solid security practices with automated CI/CD workflows including security audits (audit.yaml), appropriate use of workspace configuration, and clear separation of auto-generated code. No critical vulnerabilities were identified in the static analysis. The main security considerations are inherent to the large scope (200+ services), dependency management of numerous crates, and reliance on external code generation tooling. The presence of established security processes (CODEOWNERS, code of conduct, security workflows) indicates good governance. No hardcoded secrets, SQL injection risks, or infrastructure misconfigurations were detected in the provided file structure.

• Low · Workspace Members Not Pinned to Specific Versions — Cargo.toml - workspace members configuration. The Cargo.toml workspace includes numerous interdependent members without explicit version pinning. This could potentially lead to unexpected behavior if internal dependencies are updated without coordinating all workspace members. Fix: Ensure workspace members use consistent version specifications and consider implementing a release coordination process for interdependent crates.
• Low · Large Number of Generated AWS Service Crates — aws-models/ directory and sdk/ workspace members. The repository contains auto-generated code for 200+ AWS services from Smithy models. While auto-generation reduces manual vulnerabilities, the large attack surface and number of dependencies increases overall maintenance burden. Fix: Maintain automated security audits (already present via .github/workflows/audit.yaml) and ensure all dependencies are regularly updated. Consider implementing additional SBOM (Software Bill of Materials) generation.
• Low · Auto-Generated Code with External Dependencies — Entire codebase (generated from smithy-lang/smithy-rs). The SDK is entirely code-generated from external Smithy models in a separate repository (smithy-lang/smithy-rs). This introduces supply chain risk if the Smithy code generation system is compromised. Fix: Verify integrity of generated code through checksums or signatures. Document the code generation process and maintain clear separation between generated and manually written code (.handwritten directory shows good practice).

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.