aws-sdk-go

aws-sdk-go is the original AWS SDK for the Go programming language, providing typed clients for effectively every AWS service — S3, DynamoDB, EC2, Lambda, and hundreds more — generated from AWS’s own API models under service/. It bundles session and credential management, request signing, retries, and pagination behind a consistent client pattern, plus utilities like s3manager for chunked, concurrent multipart uploads and downloads.

AWS marked the module end-of-support on July 31, 2025, and every package now carries a deprecation notice pointing to aws-sdk-go-v2. It still works and remains deeply embedded in existing Go codebases, but new projects should target v2, which brings modular per-service modules, native context support, and ongoing feature updates.

What You Get

• 383 service clients - typed Go packages under service/ for virtually every AWS API, from S3 and DynamoDB to niche services like AppFabric and ApplicationSignals, all generated from AWS’s API models.
• Session and credential chain - aws/session and aws/credentials resolve credentials from environment variables, shared config files, EC2/ECS roles, SSO, or STS-assumed roles without extra wiring.
• s3manager transfer utilities - concurrent, chunked multipart upload and download helpers in service/s3/s3manager for moving large objects efficiently.
• Request middleware pipeline - aws/request exposes a handler-list architecture for injecting custom logic into signing, retries, validation, and error unmarshaling.

Common Use Cases

• Uploading large files to S3 - applications use s3manager.Uploader to stream multi-gigabyte files to S3 with automatic multipart chunking and concurrency.
• Reading and writing DynamoDB items - backend services use the dynamodb client with dynamodbattribute marshaling to persist Go structs directly as items.
• Assuming cross-account IAM roles - services running in one AWS account use stscreds.AssumeRoleProvider to obtain temporary credentials for resources in another account.
• Maintaining legacy Go services on AWS - teams with existing codebases built on the v1 API keep using aws-sdk-go for stability while planning a migration to v2.

Under The Hood

Architecture Code-generated per-service clients live under service/<name>/ (383 packages), each pairing a client file with a generated api.go of operations and typed structs. The shared aws/ package supplies cross-cutting concerns: session.Session assembles a Config (region, credentials, endpoint) once, and each service client embeds a request-building Client. A single outbound call flows Session to NewClient to NewRequest to a Handlers pipeline (Validate, Build, Sign, Send, Unmarshal/UnmarshalError) defined in aws/request, with aws/corehandlers and aws/signer/v4 installed as default stages and a pluggable Retryer handling backoff. s3manager (service/s3/s3manager/upload.go, download.go) sits on top of the s3 client as a higher-level concurrent transfer layer. The result is a modular monolith: hundreds of independently generated leaf packages sharing one core request/session pipeline, so a change to the shared Handlers or Config path ripples across every one of the 383 service clients.

Tech Stack go.mod declares module github.com/aws/aws-sdk-go on Go 1.19 with a single external dependency, github.com/jmespath/go-jmespath, used for JMESPath-based response filtering in waiters. There’s no web framework since this is a client library; HTTP transport runs over net/http with a custom RoundTripper for TLS and CA-bundle customization. Build tooling is a Makefile plus buildspec.yml for AWS CodeBuild-based CI, and service clients plus their typed models are code-generated from JSON API definitions under models/apis/. No database access is involved — the SDK is purely an outbound API client vendored into other Go binaries.

Code Quality The test suite is extensive: dozens of *_test.go files sit alongside implementation files throughout aws/ and each service package, including Go-version-gated variants (request_1_5_test.go, request_1_7_test.go) that exercise behavior across supported compiler versions. Tests use the standard library testing package plus a homegrown awstesting helper package rather than a third-party assertion library. Error handling is explicit and typed via awserr.Error, which wraps every SDK and service error with a code, message, and original error, and generated service packages export named error constants callers can switch on instead of string-matching. Naming is consistent, idiomatic Go throughout. CI runs through AWS CodeBuild (buildspec.yml) rather than GitHub Actions, so lint/format enforcement isn’t visible directly from the repository.

API Design The defining design choice is wholesale code generation from AWS’s service API models: every one of the 383 service packages exposes an identical shape (constructor, PascalCase operation methods, typed Input/Output structs, and WithContext variants) generated mechanically, which is what let AWS keep pace with hundreds of services without hand-writing each client. The Handlers-pipeline extensibility point is a deliberately public seam most hand-rolled API clients don’t expose, letting callers inject custom signing, logging, or retry logic without forking the SDK. Measured against modern idioms — context-first APIs, generics-based option builders — the design now reads as dated, which is precisely why AWS built SDK v2; but for a single generator producing one consistent client shape and one shared request pipeline across an enormous multi-service surface, the pattern was a deliberate and effective engineering choice for its era.