Using SDK v3 from Deno & Bun

The AWS SDK for JavaScript v3 targets Node.js, but it runs on the newer JavaScript runtimes too. Bun aims for Node compatibility and installs npm packages directly. Deno reaches npm through npm: specifiers. In both, the same @aws-sdk/client-* packages work.

The differences are not in the SDK API - they are in how each runtime resolves packages and, more importantly, how it grants access to the environment variables and files the credential chain needs. This page shows the working setup for each and the permission gotchas that trip people up.

Recipe

Deno imports via npm: and needs explicit permissions; Bun installs and imports like Node.

// --- Deno: import with an npm: specifier ---
import { S3Client, ListBucketsCommand } from "npm:@aws-sdk/client-s3";
 
const s3 = new S3Client({ region: "us-east-1" });
const res = await s3.send(new ListBucketsCommand({}));
console.log(res.Buckets?.map((b) => b.Name));
 
// Run: deno run --allow-env --allow-net --allow-read app.ts

When to reach for this:

• You are building on Bun or Deno and need to call AWS services.
• You want the same SDK code to run across Node and an alternative runtime.
• You are writing a serverless function on a platform whose runtime is Deno or Bun based.
• You are prototyping quickly with Bun's fast installs or Deno's built-in tooling.

Working Example

Bun is close to a drop-in for Node here: install the package and import it normally.

// --- Bun: install then import like Node ---
// Terminal: bun install @aws-sdk/client-s3 @aws-sdk/credential-providers
import { S3Client, PutObjectCommand } from "@aws-sdk/client-s3";
import { fromEnv } from "@aws-sdk/credential-providers";
 
const s3 = new S3Client({
  region: "us-east-1",
  credentials: fromEnv(),   // explicit source avoids surprises across runtimes
});
 
await s3.send(new PutObjectCommand({
  Bucket: "my-bucket",
  Key: "from-bun.txt",
  Body: "hello from Bun",
}));
 
// Run: bun run app.ts

What this demonstrates:

• Bun installs npm packages into node_modules, so imports look exactly like Node.
• Passing an explicit provider (fromEnv) sidesteps differences in how each runtime exposes the default chain.
• The command pattern and every client API behave the same as on Node.
• No special configuration is needed beyond having credentials available to the runtime.

Deep Dive

Deno Specifics

• Import with the npm: prefix: import { S3Client } from "npm:@aws-sdk/client-s3". Deno resolves and caches the npm package.
• Deno is secure by default, so you must grant permissions: --allow-net for the HTTPS calls, --allow-env so the credential chain can read AWS_* variables, and --allow-read if it reads ~/.aws config.
• You can pin the version in the specifier (npm:@aws-sdk/client-s3@3.x) or manage it in a deno.json imports map.
• Node built-ins the SDK uses are available through Deno's Node compatibility layer, but test anything filesystem or stream heavy.

Bun Specifics

• Bun targets Node compatibility, so bun install @aws-sdk/client-s3 and a normal import usually just work.
• Bun reads environment variables and files without a permission prompt, so the default credential chain behaves much like Node.
• Bun's speed helps install and cold-start times, which is attractive for serverless.
• As with Deno, keep an eye on any Node API the SDK depends on that Bun has not fully implemented yet.

Credentials Across Runtimes

• The credential chain needs to read env vars and possibly ~/.aws files. In Deno that means granting --allow-env and --allow-read; in Bun it is generally unrestricted.
• Passing an explicit provider such as fromEnv() or fromIni() makes the source unambiguous and avoids relying on runtime-specific defaults.
• On a cloud platform, prefer injected environment credentials or the platform's role integration over reading local files.
• If a call mysteriously reports missing credentials on Deno, a missing --allow-env is the usual cause.

Version Pinning and Parity

• Both runtimes evolve quickly, and their Node compatibility is very good but not total.
• Pin both the runtime version and the @aws-sdk/* version so a runtime upgrade does not silently change behavior.
• Run your integration tests on the actual target runtime; do not assume Node parity for stream-heavy or multipart operations.
• When something fails only on Deno or Bun, suspect a Node API gap in the runtime before suspecting the SDK.

There Is No boto3 Angle

boto3 is Python, so Deno and Bun are irrelevant to it. This is another v3-only concern, which is why the whole page is single-language TypeScript.

Gotchas

• Deno "PermissionDenied" on env - the credential chain cannot read AWS_* without permission. Fix: run with --allow-env (and --allow-read for shared config).
• Missing --allow-net - the HTTPS call is blocked. Fix: grant --allow-net, optionally scoped to the AWS endpoints.
• Assuming full Node parity - a rarely used Node API may be missing on either runtime. Fix: test the actual operations you use on the target runtime.
• Unpinned versions - a runtime or SDK auto-update changes behavior. Fix: pin both versions and upgrade deliberately.
• Reaching for IMDS locally - the default chain may probe instance metadata and stall off-cloud. Fix: pass fromEnv/fromIni explicitly during local development.
• Forgetting Deno's npm: prefix - a bare @aws-sdk/client-s3 import fails in Deno without an imports map. Fix: use the npm: specifier or configure deno.json.

Alternatives

FAQs

Related

• Installing Only the Clients You Need - the npm packages Deno and Bun resolve.
• Credential Providers: fromEnv, fromIni, fromNodeProviderChain - the providers to pass explicitly across runtimes.
• SDK v3 Fundamentals Basics - the client and command API that is identical everywhere.
• SDK v3 in the Browser vs Node.js - another non-Node target with its own rules.

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).