AWS SDK for Go v2

aws-sdk-go-v2 is the base module of AWS’s official Go SDK, providing the shared Config, CredentialsProvider, Retryer, and middleware primitives that every generated AWS service client builds on. Rather than one monolithic package, the SDK ships as a monorepo of 400+ independently versioned service modules (S3, DynamoDB, EC2, Lambda, and hundreds more) that all compose this base module’s request signing, credential resolution, and retry logic through a shared smithy-go middleware pipeline.

Developers use it to authenticate against AWS (via environment variables, shared config files, IAM roles, SSO, or STS AssumeRole), configure region and retry behavior once via config.LoadDefaultConfig, and then construct any service client with a uniform NewFromConfig(cfg) pattern — giving Go applications a consistent, idiomatic way to call AWS APIs without hand-rolling HTTP signing or credential plumbing.

What You Get

• A unified aws.Config type carrying region, credentials, HTTP client, retry, and endpoint settings shared across all AWS service clients
• config.LoadDefaultConfig, which resolves credentials and settings from environment variables, shared config/credentials files, IMDS, and functional options in one call
• A pluggable credentials chain (credentials/stscreds, ssocreds, ec2rolecreds, endpointcreds, processcreds) covering static keys, IAM roles, SSO, and STS AssumeRole
• Built-in SigV4/SigV4A request signing and a configurable Retryer (standard and adaptive retry modes) wired into every service client automatically
• A smithy-go-based middleware pipeline (user-agent, recursion detection, request-ID tracking) that generated service clients extend rather than reimplement

Common Use Cases

• Bootstrapping a Go application’s AWS access once with config.LoadDefaultConfig, then sharing that Config across multiple service clients (S3, DynamoDB, SQS, etc.)
• Assuming cross-account or cross-role AWS access in server-side Go services via credentials/stscreds.NewAssumeRoleProvider
• Running Go workloads on EC2, ECS, or Lambda that need automatic IAM role credential resolution without hardcoded keys
• Building CLI tools or backend services that need consistent retry/backoff behavior across many AWS API calls

Under The Hood

Architecture — The base aws-sdk-go-v2 module provides the shared runtime that every generated service client builds on: the aws package (aws/config.go, aws/credentials.go, aws/retryer.go) defines the core Config, CredentialsProvider, and Retryer abstractions; aws/middleware wraps smithy-go’s middleware stack to inject user-agent, recursion-detection, and request-ID handling into every request; internal/auth and internal/v4a handle SigV4/SigV4A request signing; the config package (config/load_options.go, config/config.go) implements LoadDefaultConfig, resolving region/credentials/retry settings from environment variables, shared config/credentials files, IMDS, and functional options; and credentials (credentials/stscreds, ssocreds, ec2rolecreds, endpointcreds, processcreds) supplies the pluggable CredentialsProvider chain. Each of the 427 subdirectories under service/ is an independently versioned Go module generated from Smithy models (see codegen/) that composes these primitives — NewFromConfig(cfg) on a service client pulls Region/Credentials/HTTPClient/Retryer straight from the shared aws.Config and wires them into a smithy-go request/response middleware pipeline, so the base module’s job is purely to be the common substrate the generated service code depends on.

Tech Stack — The module declares only one direct dependency in its own go.mod — github.com/aws/smithy-go v1.27.3, AWS’s shared client-runtime library — and requires Go 1.24, tracking upstream Go’s release/support policy per the README. The wider repository is a monorepo where config/, credentials/, and each service/<name> directory ships its own go.mod/go.sum so consumers only pull in the AWS services they actually import, and internal/repotools plus codegen/ (backed by a Smithy/Java toolchain) drive automatic regeneration of all service clients and the CHANGELOG from AWS’s service models. There is no runtime framework dependency beyond the Go standard library’s net/http and smithy-go — the SDK deliberately keeps its core dependency graph minimal so it can be vendored into hundreds of downstream service modules without version conflicts.

Code Quality — This base module carries unit tests alongside nearly every source file (credentials_test.go, retryer_test.go, endpoints_test.go, config_test.go, credential_cache_test.go plus a dedicated credential_cache_bench_test.go for benchmarking) — 47 _test.go files under aws/ alone — and the repo layout separates public API (aws/, config/, credentials/) from internal implementation detail (internal/v4a, internal/auth, internal/rand, internal/sync) using Go’s internal/ visibility convention. Exported types favor explicit interfaces (CredentialsProvider, HTTPClient, Retryer, EndpointResolverV2) over concrete structs, errors are wrapped with context via fmt.Errorf and dedicated error types, and .golangci.toml plus CI workflows (go.yml, codegen.yml) enforce linting and codegen-drift checks on every PR — process rigor typical of a foundational, widely-vendored SDK.

API Design — Getting started is two go get calls plus one config.LoadDefaultConfig(ctx, …) call — the functional-options pattern (config.WithRegion, config.WithCredentialsProvider, etc.) keeps the common path to a working client under ten lines, as shown in both the README and doc.go. Every generated service client follows the identical svc := <service>.NewFromConfig(cfg) constructor and Input/Output struct-pair convention, so learning the base module’s Config/Credentials/Retryer vocabulary transfers unchanged across all 427 service clients. The main friction is surface size and historical accretion — Config carries current fields (EndpointResolverV2, BaseEndpoint) alongside explicitly Deprecated ones (EndpointResolver, EndpointResolverWithOptions) with in-doc migration guidance, so new users must read comments carefully to avoid deprecated paths; thorough godoc coverage, a migration guide, and a developer guide offset this learning curve.