Skip to main content
The AWS SDK for JavaScript v3 is a complete rewrite of v2, built around modularity and first-class TypeScript support. Instead of one monolithic package, every AWS service ships as its own npm package — your application only bundles the code it actually uses.

​
What is the SDK?

The SDK enables JavaScript and TypeScript applications to call Amazon Web Services APIs from Node.js, browsers, and React Native. V3 replaces the aws-sdk v2 package with a modular architecture: separate packages per service, a redesigned middleware stack, and native TypeScript types throughout. The two key differences from v2:
  • Modular packages — install @aws-sdk/client-s3 or @aws-sdk/client-dynamodb independently instead of the entire aws-sdk.
  • TypeScript-first — every client, command input, and command output is fully typed with no @types package needed.

Modular packages

One npm package per AWS service. Install only what your application needs.

TypeScript native

Full types for every client, command, and input/output shape. No @types package required.

Middleware stack

Intercept and modify requests and responses at any lifecycle step: initialize, serialize, build, finalize, or deserialize.

Async paginators

Use for await...of over paginated results without managing continuation tokens yourself.

Cross-platform

Works in Node.js, browsers, and React Native with platform-appropriate HTTP and crypto implementations.

Higher-level libraries

@aws-sdk/lib-dynamodb and @aws-sdk/lib-storage wrap lower-level clients for common patterns.

​
Repository structure

The SDK source is a monorepo with three top-level directories, each with a different purpose and npm naming convention.
Directorynpm prefixContentsMaintained by
/clients@aws-sdk/client-*Generated service clients, one per AWS service. Created from AWS Smithy models.AWS service teams + AWS SDK JS team
/packages@aws-sdk/*Manually written utility code: credential providers, middleware, serializers, and types.AWS SDK JS team
/lib@aws-sdk/lib-*Higher-level JavaScript libraries that wrap generated clients for common use cases.AWS SDK JS team

​
Package naming

  • @aws-sdk/client-s3, @aws-sdk/client-dynamodb, @aws-sdk/client-lambda — service clients from /clients
  • @aws-sdk/lib-dynamodb, @aws-sdk/lib-storage — higher-level libraries from /lib
  • @aws-sdk/credential-providers, @aws-sdk/middleware-retry — utilities from /packages
Always import from the top-level package, not a deep path. For example, use import { S3Client } from "@aws-sdk/client-s3" rather than importing from dist-cjs/ directly, since internal file structure may change.

​
Two usage styles

V3 supports two ways to call AWS APIs. Both are valid — choose based on your bundle size requirements. Import the client and each command separately. This allows tree shaking to remove unused commands from your bundle. 
import { S3Client, GetObjectCommand } from "@aws-sdk/client-s3";

const client = new S3Client({ region: "us-east-1" });
const response = await client.send(new GetObjectCommand({ Bucket: "my-bucket", Key: "my-key" }));

​
Aggregated (v2-compatible style)

Import the service class directly. All commands are available as methods, matching the v2 AWS.S3 style. This is convenient but imports all commands, increasing bundle size. 
import { S3 } from "@aws-sdk/client-s3";

const client = new S3({ region: "us-east-1" });
const response = await client.getObject({ Bucket: "my-bucket", Key: "my-key" });
If you use tree shaking (e.g., with webpack or esbuild), the aggregated style will produce a larger bundle because all commands on the client are imported regardless of which ones you call.

​
Cross-platform support

The SDK runs on Node.js, browsers, and React Native. Platform-specific implementations of HTTP, crypto, and streams are selected automatically at runtime.
  • Node.js — uses Node.js built-in https, crypto, and stream APIs.
  • Browsers — uses the Fetch API, Web Crypto API, and Web Streams.
  • React Native — requires three polyfills (see Installation for details).

​
Stability

Not all packages in the SDK have the same stability guarantee. The table below summarizes which are public and stable versus internal.
PackageFolderStability
@aws-sdk/client-* Commands/clientspublic / stable
@aws-sdk/client-* Clients/clientspublic / stable
@aws-sdk/lib-*/libpublic / stable
@aws-sdk/*-signer/packagespublic / stable
@aws-sdk/middleware-stack/packagespublic / stable
All other @aws-sdk/*/packagesinternal
“Internal” does not mean a package is constantly changing. It means it can change without a deprecation period. Changes are included in the release notes. Public interfaces can also change in exceptional cases, but with advance notice.

​
Node.js version requirements

The minimum required Node.js version depends on the SDK version you install.
SDK version rangeMinimum Node.js
v3.968.0 and higherNode.js >= 20
v3.723.0 – v3.967.xNode.js >= 18
v3.567.0 – v3.722.xNode.js >= 16
v3.201.0 – v3.566.xNode.js >= 14
v3.46.0 – v3.200.0Node.js >= 12
Earlier versionsNode.js >= 10
The Lambda runtime bundles a specific minor version of the SDK, not the latest. To avoid unexpected behavior during Lambda runtime updates, always include the SDK packages your function uses in your deployment package or a Lambda layer.

​
Release cadence

The SDK releases once per weekday. Each release increments the minor version — for example, 3.200.0 → 3.201.0. Because releases are frequent, keep all @aws-sdk/client-* packages pinned to the same version in your package.json to avoid subtle compatibility issues between mismatched client and utility packages.

​
Next steps

Quick start

Make your first AWS API call in under 5 minutes.

Installation

Install service clients, credential providers, and utilities.

Build docs developers (and LLMs) love

Get started for freeTalk to us