aws4fetch

aws4fetch is a minimal (6.4kb minified, 2.5kb gzipped) AWS API client for JavaScript environments that support the standard fetch and SubtleCrypto APIs — modern browsers and edge platforms like Cloudflare Workers where the full AWS SDK’s Node.js dependencies (streams, Buffer, crypto module) aren’t available. It exports AwsClient, a drop-in wrapper around fetch that signs every request with AWS Signature Version 4 before sending it, and AwsV4Signer, the lower-level signer for callers who want the signed method/url/headers/body without an opinionated fetch call.

Because it targets any AWS service reachable over its REST/JSON HTTP APIs rather than one specific service, it works for Lambda invocation, S3 object access, DynamoDB, and anything else with a documented AWS endpoint, with automatic retries using exponential backoff with full jitter built in by default.

What You Get

• AwsClient, a fetch-compatible wrapper (aws.fetch(url, init)) that transparently signs requests with AWS SigV4
• AwsV4Signer, a lower-level signer returning the signed method/url/headers/body for manual fetch() calls
• Automatic retries with exponential backoff and full jitter, configurable via retries/initRetryMs
• Support for query-string signing (signQuery) as an alternative to the Authorization header
• Works against any AWS REST/JSON HTTP endpoint (Lambda, S3, DynamoDB, IoT, etc.) since service/region are inferred from the URL at fetch time

Common Use Cases

• Calling AWS services (Lambda, S3, DynamoDB) directly from a Cloudflare Worker or other edge function without bundling the full AWS SDK
• Signing AWS API requests from a browser-based tool where Node.js crypto/stream polyfills aren’t practical
• Replacing API Gateway with a lightweight signed proxy to AWS services from an edge script
• Invoking AWS Lambda functions or accessing S3 objects from serverless functions with minimal bundle size overhead

Under The Hood

Architecture - The entire client lives in a single 441-line file, src/main.js, which exports the two public classes: AwsClient (a thin fetch-signing wrapper with retry logic) and AwsV4Signer (the core canonical-request builder and signature calculator implementing the AWS SigV4 algorithm — canonical request, string to sign, and derived signing key via HMAC-SHA256). Service and region are parsed from the target URL’s hostname at call time by default, avoiding any AWS-specific configuration beyond credentials. Tech Stack - Zero runtime dependencies; it relies entirely on Web-standard APIs (fetch, Headers, Request, URL, crypto.subtle) available in browsers, Cloudflare Workers, Deno, and modern Node.js, which is what keeps the bundle at roughly 6.4kb minified. The build is produced via Rollup (rollup.config.mjs) into CJS, ESM, and UMD bundles plus TypeScript declaration files, and an example/ directory demonstrates a Cloudflare Worker used as an API Gateway replacement. Code Quality - The test/ directory includes dedicated suites for signing parameters, AWS-specific behaviors, and per-service quirks (paramTests.js, awsTests.js, serviceTests.js), plus CommonJS/ESM interop smoke tests (node-commonjs.js, node-es.mjs) and an integration test — solid coverage for a security-sensitive signing implementation given the package’s small size. Development has slowed since 2024 (activity_status: inactive), but the surface area is narrow and the SigV4 algorithm itself doesn’t change, so quiescence here is less concerning than for a rapidly-evolving library. API Design - The API mirrors the standard fetch signature almost exactly (aws.fetch(url, init)), with AWS-specific overrides nested under an aws: {...} key in init, so existing fetch-based code needs minimal changes to adopt it; AwsV4Signer is offered separately for consumers who want to construct and send the Request themselves.