Installing Only the Clients You Need

In boto3 you pip install boto3 once and every AWS service is available. The AWS SDK for JavaScript v3 works the opposite way: there is no single package that contains all the services.

Instead, each service is published as its own npm package named @aws-sdk/client-<service>. You install only the ones you use. This is the design decision that makes v3 friendly to browsers and Lambda, and it is worth understanding early.

Recipe

Install one client package per service, then import the client and the commands you need from it.

// Terminal:
//   npm install @aws-sdk/client-s3
//   npm install @aws-sdk/client-dynamodb
 
import { S3Client, PutObjectCommand } from "@aws-sdk/client-s3";
import { DynamoDBClient, PutItemCommand } from "@aws-sdk/client-dynamodb";
 
const s3 = new S3Client({ region: "us-east-1" });
const ddb = new DynamoDBClient({ region: "us-east-1" });

When to reach for this:

• You are starting any new v3 project and need to decide what to install.
• You care about bundle size in a browser app or cold-start time in Lambda.
• You want your node_modules and Docker image to carry only the services you actually call.
• You are migrating from the v2 aws-sdk monolith and want the modular equivalent.

Working Example

A realistic app touches a handful of services and a couple of helper libraries. Install each one explicitly.

// Terminal:
//   npm install @aws-sdk/client-s3 @aws-sdk/client-sqs @aws-sdk/client-dynamodb
//   npm install @aws-sdk/credential-providers @aws-sdk/lib-storage
 
import { S3Client } from "@aws-sdk/client-s3";
import { SQSClient } from "@aws-sdk/client-sqs";
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { fromNodeProviderChain } from "@aws-sdk/credential-providers";
import { Upload } from "@aws-sdk/lib-storage";
 
const credentials = fromNodeProviderChain();
const region = "us-east-1";
 
const s3 = new S3Client({ region, credentials });
const sqs = new SQSClient({ region, credentials });
const ddb = new DynamoDBClient({ region, credentials });
 
// Upload from @aws-sdk/lib-storage handles multipart automatically.
const upload = new Upload({ client: s3, params: { Bucket: "my-bucket", Key: "big.bin", Body: someStream } });
await upload.done();

What this demonstrates:

• Three services means three @aws-sdk/client-* packages, one import each.
• Cross-cutting helpers (credential-providers, lib-storage) are their own packages, not bundled into the clients.
• One shared credential provider can be passed into every client.
• You install exactly five packages and ship exactly those, nothing more.

Deep Dive

Why v3 Is Modular

• v2 shipped one aws-sdk package containing every service, often 40+ MB unpacked. Importing it pulled the whole surface into your bundle.
• v3 splits each service into @aws-sdk/client-<service>, so node_modules grows only with the services you install.
• Combined with the command pattern, a bundler can then remove even the operations within a client you never import - true tree-shaking.
• The net effect is smaller browser bundles, lighter Lambda deployment packages, and faster cold starts.

The Package Naming Convention

• Clients: @aws-sdk/client-s3, @aws-sdk/client-dynamodb, @aws-sdk/client-sqs, and so on - always lowercase and hyphenated.
• Credential helpers: @aws-sdk/credential-providers.
• S3 conveniences: @aws-sdk/lib-storage (multipart uploads) and @aws-sdk/s3-request-presigner (presigned URLs).
• DynamoDB ergonomics: @aws-sdk/lib-dynamodb (the Document client that hides attribute-value typing).

What Ships to Production

• Your dependency list is your API surface: someone reading package.json sees exactly which AWS services the app talks to.
• Tree-shaking is a build-time step, so a browser bundle for an app that only calls GetObject contains only that command's code.
• On the server, the runtime cost of an unused import is small, but install size and cold start still benefit from installing only what you use.

Contrast with boto3

boto3 is deliberately monolithic. pip install boto3 gives you every service through boto3.client("<name>"), selected by string at runtime. Python apps rarely ship to size-constrained runtimes, so there is little pressure to trim. v3 optimizes for the browser and Lambda, where that same monolith would be a liability - which is exactly why the packaging models diverge.

Gotchas

• Looking for a single aws-sdk v3 package - there is none; installing one client per service is the intended model. Fix: install @aws-sdk/client-<service> for each service you call.
• Accidentally installing v2 - npm install aws-sdk gives you the maintenance-mode v2 monolith, not v3. Fix: install the scoped @aws-sdk/* packages instead.
• Version drift across clients - mismatched @aws-sdk/client-* versions can pull duplicate copies of shared internals. Fix: keep all @aws-sdk/* packages on the same version and update them together.
• Forgetting helper packages are separate - presigning or multipart upload code will not be in the client package. Fix: install @aws-sdk/s3-request-presigner or @aws-sdk/lib-storage explicitly.
• Assuming tree-shaking works with a bad bundler config - CommonJS-only or non-ESM builds may not shake unused commands. Fix: use ESM imports and a bundler with tree-shaking enabled (esbuild, Rollup, webpack in production mode).
• Over-installing clients you never call - inflates install size and audit surface. Fix: remove client packages when you remove the code that used them.

Alternatives

FAQs

Related

• SDK v3's Command Pattern - the pattern that makes per-command tree-shaking possible.
• SDK v3 Fundamentals Basics - install a client and send your first command.
• SDK v3 in the Browser vs Node.js - where install and bundle size matter most.
• SDK v3 Fundamentals Best Practices - import hygiene and keeping versions aligned.

Stack versions: This page was written for the AWS SDK for JavaScript v3 on Node.js 18+ (and boto3 1.43.x / Python 3.10+ where contrasted).