# aws-sdk-go-v2: the modular AWS SDK for Go, module by module

> The v2 AWS SDK for Go splits what v1 shipped as one monolith into per-service Go modules built on smithy-go. Here is how it is structured, how to install it, and where it gets awkward.

**aws/aws-sdk-go-v2** — AWS SDK for the Go programming language. 

- Repository: https://github.com/aws/aws-sdk-go-v2
- Website: https://docs.aws.amazon.com/sdk-for-go/
- Stars: 3,659 · Forks: 820
- Language: Go
- License: Apache-2.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/aws-aws-sdk-go-v2

## What aws-sdk-go-v2 replaces, and who ends up using it

The README states plainly that aws-sdk-go-v2 is the v2 AWS SDK for the Go programming language. The problem it addresses is narrow but constant: Go programs need to sign and send requests to AWS service APIs, and doing that by hand means reimplementing SigV4 signing, retry behaviour, endpoint resolution, and credential discovery for every service. The SDK packages all of that behind generated service clients.

The intended audience is Go developers writing services, CLIs, and jobs that talk to AWS. The repository layout makes the scope visible: aws/, config/, credentials/, internal/, feature/, and service/ sit at the top level, alongside codegen/ and a Smithy codegen version file. The service/ directory is where per-service clients live, and it is the reason the module count is large rather than one.

It is not a general HTTP client and it is not a CLI. If you need to call AWS from a shell script, this is the wrong layer entirely. If you need to call AWS from Go, the alternative is the v1 SDK, discussed further down.

## How the module split and smithy-go shape the dependency graph

The root go.mod is short. It declares the module github.com/aws/aws-sdk-go-v2, requires github.com/aws/smithy-go v1.28.1, and sets go 1.24. That single require line is the architectural tell: the shared protocol, middleware, and serialization machinery lives in smithy-go, and the SDK is built on top of it.

Because services are separate modules under service/, importing DynamoDB does not pull in S3, SQS, or anything else you did not ask for. The README's own getting-started example reflects this by retrieving three distinct module paths rather than one: the core aws module, the config module, and the specific service module. That is the trade: a leaner build in exchange for more go get lines and a go.mod that grows one entry per AWS service your program calls.

The config layer is the second mechanism worth understanding. config.LoadDefaultConfig resolves credentials and settings from environment variables, the shared credentials file, and the shared configuration file, in the SDK's standard chain. Region is not inferred from those files in the README example; it is passed explicitly through config.WithRegion. The resulting aws.Config value is then handed to a service constructor such as dynamodb.NewFromConfig, which is the v2 pattern. There is no package-level session object to mutate, which is the change most v1 code notices first.

## Installing aws-sdk-go-v2 and listing DynamoDB tables

The README's getting-started walkthrough is the shortest path to a working program. It begins by creating a Go module for the example project. The README shows these commands with a leading $ prompt; the shell does not need it, and Go's minimum version for the v2 SDK is 1.24 per the README.

```bash
mkdir ~/helloaws
cd ~/helloaws
go mod init helloaws
```

Next, retrieve the SDK dependencies. Note that these are three separate module paths, not one.

```bash
go get github.com/aws/aws-sdk-go-v2/aws
go get github.com/aws/aws-sdk-go-v2/config
go get github.com/aws/aws-sdk-go-v2/service/dynamodb
```

The README then places this content in main.go. It loads default configuration for a region, constructs a DynamoDB client from that config, and calls ListTables with a limit of five.

```go
package main

import (
    "context"
    "fmt"
    "log"

    "github.com/aws/aws-sdk-go-v2/aws"
    "github.com/aws/aws-sdk-go-v2/config"
    "github.com/aws/aws-sdk-go-v2/service/dynamodb"
)

func main() {
    cfg, err := config.LoadDefaultConfig(context.TODO(), config.WithRegion("us-west-2"))
    if err != nil {
        log.Fatalf("unable to load SDK config, %v", err)
    }

    svc := dynamodb.NewFromConfig(cfg)

    resp, err := svc.ListTables(context.TODO(), &dynamodb.ListTablesInput{
        Limit: aws.Int32(5),
    })
    if err != nil {
        log.Fatalf("failed to list tables, %v", err)
    }

    fmt.Println("Tables:")
    for _, tableName := range resp.TableNames {
        fmt.Println(tableName)
    }
}
```

Running it produces the table names the SDK returns. The README shows the output as a Tables: header followed by tableOne and tableTwo, which is illustrative rather than a fixed result; your account determines the actual list. Two details in the code matter beyond the happy path. Every call takes a context, so cancellation is available without extra plumbing. And aws.Int32 is how optional numeric input fields are set, because the generated input structs use pointers to distinguish an absent value from a zero value.

## The Go 1.24 floor and other places aws-sdk-go-v2 pushes back

The README states that the v2 SDK requires a minimum version of Go 1.24. That is a hard floor, not a suggestion, and it is the first thing to check before adopting. The SDK's Go version support policy follows the upstream Go release policy with an additional six months of support for the most recently deprecated language version, and the README notes that AWS reserves the right to drop support for unsupported Go versions earlier to address critical security issues. Teams on older toolchains are simply not served by this release line.

The second constraint is dependency surface. Splitting services into modules keeps an individual build small, but the repository as a whole is large, and a program that touches many AWS services accumulates many module requirements. That interacts badly with strict vendoring workflows and with any policy that wants a short, auditable go.sum. There is nothing in the README that offers a bundled single-module option as v1 had.

The third is the failure mode that shows up in production rather than in a tutorial. The README example passes config.WithRegion("us-west-2") explicitly. In a real deployment the region and credentials come from the resolution chain, and a missing or misconfigured source produces a load-time or call-time error rather than a compile-time one. The README does not document rollback or fallback behaviour for credential resolution, so the chain's precedence is something to confirm against the shared configuration and credentials reference the README links, not to assume from the example.

Finally, the README is explicit that the GitHub issues tracker is for bug reports and feature requests, and that usage questions belong in GitHub Discussions or AWS Support. That is a support-model constraint: if you file a usage question as an issue, it is the wrong channel.

## aws-sdk-go-v2 against the v1 SDK, and what the migration actually costs

The real alternative is the v1 SDK for Go, and the README links a migration guide for moving between them. The difference is not cosmetic. v1 exposed a session package whose value you configured and then passed to service clients, and it shipped as a much smaller number of modules. v2 replaces the session with config.LoadDefaultConfig, which returns an aws.Config, and clients are built from that config with constructors like dynamodb.NewFromConfig. Region and other settings are supplied as functional options rather than by mutating a session.

The module layout is the second difference. v1's packaging meant importing one SDK pulled in a broad surface; v2's per-service modules mean you import exactly the services you use. For a small program the difference is mostly in go.mod length. For a large one it changes build times and the size of the dependency audit.

The migration cost is real and mostly mechanical but not trivial: every session construction becomes a config load, every client construction changes shape, and every call site gains a context argument. The README points to the migration guide rather than describing the steps itself, so the guide is the document to read before estimating the work. A note on the related-search data: people also search for an AWS SDK for Go v3. Nothing in the README or the release history mentions a v3 line, so treat that as a question rather than a roadmap.

## Release cadence, maintenance policy and the Apache-2.0 licence

The repository is not archived, and the last push was on 2026-09-23. Recent release tags are dated 2026-09-22, 2026-09-21, and 2026-09-18, which indicates a near-daily release cadence driven by service model updates rather than a hand-curated schedule. The practical consequence for upgrade cost is that pinning is the norm: a version bump can arrive any day, and the CHANGELOG.md at the repository root is where the release notes live.

Maintenance of major versions is governed outside the README. It points to the AWS SDKs and Tools Maintenance Policy and the AWS SDKs and Tools Version Support Matrix in the shared configuration and credentials reference guide. The README does not restate those timelines, so anyone planning a multi-year support commitment should read them directly rather than inferring from the release tags.

The licence is Apache-2.0, and the README states that all pull requests must be submitted under that licence. For consumers the relevant implication is the usual permissive one: you can use the SDK in commercial and closed-source software. Apache-2.0 also carries an express patent grant and requires that notices be preserved, which matters if you vendor the source. None of this is legal advice; check the LICENSE.txt and NOTICE.txt files at the repository root against your own policy.

## Conclusion

Adopt aws-sdk-go-v2 for new Go services that call AWS, and for v1 codebases that can absorb a migration. Do not adopt it if you are pinned below Go 1.24, or if your dependency policy cannot tolerate a module tree that grows with every AWS service you touch. Before committing, verify three things: that your toolchain meets the stated minimum, that your vendoring or private-proxy setup can resolve the per-service module paths, and that your credential chain in production matches what config.LoadDefaultConfig resolves locally. The migration guide at aws.github.io/aws-sdk-go-v2/docs/migrating/ is the place to start the v1 comparison.

## FAQ

### What is aws-sdk-go-v2?

It is the v2 AWS SDK for the Go programming language, built on top of github.com/aws/smithy-go, with per-service clients generated under the service/ directory. It handles request signing, retries, endpoint resolution and credential loading so that Go programs can call AWS service APIs directly.

### How do I install aws-sdk-go-v2?

Create a Go module and retrieve the specific SDK modules you need with go get, for example github.com/aws/aws-sdk-go-v2/aws, github.com/aws/aws-sdk-go-v2/config and github.com/aws/aws-sdk-go-v2/service/dynamodb. The README requires Go 1.24 or newer.

### Is the AWS SDK for Go v2 deprecated?

The repository is not archived, and the last push was on 2026-09-23, with releases tagged on 2026-09-22, 2026-09-21 and 2026-09-18. Support timelines for SDK major versions are set out in the AWS SDKs and Tools Maintenance Policy and Version Support Matrix that the README links to.

### What are the key differences between the AWS SDK for Go v1 and v2?

v2 replaces the v1 session package with config.LoadDefaultConfig, which returns an aws.Config that service clients are constructed from, and it ships services as separate Go modules rather than a single broad package. The README links a dedicated migration guide rather than describing the steps itself.

### How do I use aws-sdk-go-v2?

Load configuration with config.LoadDefaultConfig, build a service client from it with a constructor such as dynamodb.NewFromConfig, and call operations with a context and an input struct. The README's example lists DynamoDB tables with a limit of five.

## Sources

- [aws/aws-sdk-go-v2 on GitHub](https://github.com/aws/aws-sdk-go-v2)
- [License: Apache-2.0](https://github.com/aws/aws-sdk-go-v2/blob/main/LICENSE)
- [Project website](https://docs.aws.amazon.com/sdk-for-go/)
- [README](https://github.com/aws/aws-sdk-go-v2/blob/main/README.md)
- [Releases](https://github.com/aws/aws-sdk-go-v2/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/aws-aws-sdk-go-v2