Amazonka keeps a Haskell AWS SDK in step with botocore

One package per service, so you only pay for what you call

Amazonka is an AWS SDK for Haskell, and its packaging is the first decision a user meets. Instead of one library with every service inside it, the repository splits the surface into a core library and one package per Amazon service.

The layout follows from that. lib/amazonka holds setup, authentication and send logic, and the documentation calls it the primary dependency. lib/amazonka-core sits underneath every service library. lib/service/amazonka-* contains one library per supported service, and you add a dependency on each service you actually use. lib/amazonka-test holds shared test functionality, examples holds basic usage samples, and configs holds the service configuration, templates and assets that feed the generator.

The consequence for a build is straightforward and worth stating plainly. A project that touches S3 and IAM depends on amazonka, amazonka-s3 and amazonka-iam, and nothing else. A project that touches everything depends on everything, and the documentation is blunt about the cost: building the entire project takes a very long time.

cabal build amazonka amazonka-s3

For a service that spends most of its deploys talking to two or three AWS endpoints, that selective dependency is the reason to pick this SDK over a monolith.

Service types come from botocore, not from a Haskell author

Amazonka states that parts of the code in the repository are auto-generated and kept up to date with Amazon's latest service APIs. The source of truth is botocore, the Python SDK's service definition repository, and the gen package contains the generator that synthesises Haskell data types, packages and configuration from it.

The mechanics are visible in the scripts directory. A script named generate runs the generator across every service listed in the config/services file.

./scripts/generate

Or you can target specific services when you only care about a few.

./scripts/generate ec2 s3 iam

There is a second README entry point that is worth knowing: scripts/generate is what refreshes the botocore service definitions the generator consumes, so the upstream definitions can be pulled and the Haskell types rebuilt in one loop.

This is the mechanism that keeps a large SDK current. A service that AWS adds new operations to is not hand ported, it is regenerated. The trade-off is that the Haskell type names, module layout and record shapes are decided by a generator rather than by a human with taste, so the ergonomics of the resulting API are only partly under the maintainer's control.

Nix and Cabal, and what that means before you touch the code

The contributor path is the heavy path, and the documentation is direct about that. Building the repository requires a set of development dependencies obtained through Nix in a reproducible, hermetic environment, and the setup assumes you will enable flakes.

sh <(curl -L https://nixos.org/nix/install) --daemon

There is a binary cache for the project's dependencies, which avoids building them yourself.

nix-env -iA cachix -f https://cachix.org/api/v1/install
cachix use amazonka

Flake support has to be turned on in the Nix configuration.

experimental-features = nix-command flakes

After that, entering the development shell installs and activates the build tools.

nix develop

The flake also exposes a development environment per GHC version, which matters because the supported compilers are pinned.

nix develop '.#ghc90'

A .envrc file is provided so that Direnv can enter the default shell automatically and put the scripts directory on your PATH, and you can extend that with an uncommitted .envrc.local. Contributors are expected to work inside the Nix shell; the documentation assumes those commands run from within it.

GHC 9.0 through 9.6 and the CI matrix that decides

Amazonka supports GHC versions 9.0, 9.4 and 9.6, tested on NixOS, Ubuntu and macOS. The documentation notes that other versions may also work, but only the listed ones are exercised by the continuous integration pipeline.

That is a narrower window than it first appears, because the GHC series move quickly and 9.0 is the oldest listed. A team on a newer compiler is on untested ground, and a team that still needs an older one is below the supported floor.

The version choice is also baked into the development shell names. The flake exposes a default environment labelled amazonka-ghc944 plus explicit attributes for ghc810, ghc90, ghc92, ghc94 and ghc96, and the documentation explains that the minor version in each name comes from what nixpkgs happens to publish, so the names increment automatically as the lock file updates. That is a small detail with a practical consequence: a script or CI job that hard codes ghc927 will break when nixpkgs moves on.

The flake.lock file pins the nixpkgs revision in use, which is what keeps the environment reproducible between the maintainer and a contributor.

Where a Haskell AWS SDK competes and where it does not

The obvious comparison is with generating a thin client from botocore yourself, or with using the AWS CLI and a process pipe from Haskell. The difference in approach is where the types live.

A generated client in another language gives you typed requests and responses as a by-product of a schema you already maintain. Amazonka makes that schema the centre of the project: the botocore definitions are the input, the Haskell data types are the output, and the whole repository is arranged around regenerating them. The cost is a repository with a generator, Nix shells, a flake, a per service package layout and a release script, which is far more machinery than a single hand written module.

The case for that machinery is type coverage across many services. A Haskell service that talks to S3, IAM and EC2 wants request and response types for each, with the shape of the response known at compile time. If you hand wrote those, you would be maintaining a port of AWS's own API descriptions, which is the work Amazonka has already automated.

The case against it is version drift. Because the SDK is regenerated rather than released often, the version on Hackage and the services it covers may lag the definitions upstream. The release changelog at lib/amazonka/CHANGELOG.md is the place to check that gap, and the releases listed here are 2.0.0 on 2023-07-28 and its release candidates, with the last push on 2026-09-30.

MPL 2.0 for the code, Apache 2.0 for the service descriptions

The licence is Mozilla Public License Version 2.0 for the Amazonka code. That is a file level copyleft licence: it is permissive for a company that only uses the library, and it asks you to publish modifications to the covered files if you distribute them.

The service descriptions are a separate matter. They are licensed under Apache 2.0, and source files derived from those descriptions carry an additional licensing clause in their file header. Since a large part of the repository is generated from those descriptions, the derived files are not covered by the MPL in the same way as hand written ones. The header clause is the place to read if you intend to modify generated code and redistribute it.

Both are permissive licences, so neither blocks commercial use. The point worth flagging is that generated and hand written code in the same repository do not share one licence, which matters if your organisation runs a licence scanner over dependencies.

The documentation for each library is published as Haddock on the project website, so you can read the generated API surface before deciding which service packages to depend on.

Editorial conclusion

Amazonka fits a Haskell codebase that wants AWS calls as typed functions rather than hand written requests, and that is willing to depend on one package per service and to track a generator driven API surface. It does not fit a team that wants a stable published API, since the last listed releases are 2.0.0 and its release candidates from 2023 while the last push was on 2026-09-30, and it does not fit a contributor who wants a quick cabal build without Nix. Before adopting it, check the supported GHC versions against your compiler, read lib/amazonka/CHANGELOG.md for the service coverage of your release, and decide whether to depend on the released package or a git dependency before the next botocore sync.

Frequently asked questions

Official sources

1. brendanhay/amazonka on GitHub
2. Issues
3. Project website
4. README
5. Releases