AWS SDK for JavaScript v2

aws-sdk is the original JavaScript SDK for Amazon Web Services, providing a unified client interface to virtually every AWS API — S3, DynamoDB, EC2, SQS, SNS, Lambda, and hundreds more — generated from the same JSON API models AWS uses internally. It ships pluggable credential providers, automatic retry/backoff, request signing, and both promise- and callback-based calling conventions, and runs in Node.js, the browser, and React Native from a single codebase.

Officially designated AWS SDK for JavaScript v2, this package reached end-of-support on September 8, 2025 and receives no further updates; AWS now directs new projects to the modular aws-sdk-js-v3 SDK. It remains published on npm and continues to be depended on by a very large body of existing Node.js applications that have not yet completed the v2-to-v3 migration.

What You Get

• Full AWS API coverage - Generated clients for hundreds of AWS services (S3, DynamoDB, EC2, SQS, Lambda, and more) from AWS’s own JSON API models.
• Unified request lifecycle - Every service call flows through the same build/sign/send/retry state machine, so signing (SigV4), retries, and pagination behave consistently across services.
• Pluggable credential providers - Built-in support for environment variables, shared config files, EC2/ECS instance metadata, STS role assumption, and custom credential chains.
• Cross-environment builds - Ships separate entry points for Node.js, browser (via browserify), and React Native from the same source tree.
• Bundled TypeScript typings - Ships .d.ts definitions for every client and the core request/response types.

Common Use Cases

• Legacy Node.js backend calling S3/DynamoDB - Teams with existing aws-sdk v2 integrations that upload/download objects or read/write DynamoDB tables without having migrated to v3 yet.
• Browser apps using AWS Cognito credentials - Front-end code that authenticates via Cognito Identity and calls AWS services directly from the browser bundle.
• Older Lambda functions bundling their own SDK - Functions written before Node.js 18-era Lambda runtimes stopped preinstalling aws-sdk v2, so it has to be bundled explicitly.
• Migration audits - Codebases inventorying aws-sdk v2 call sites ahead of a v3 migration using AWS’s codemod tooling.

Under The Hood

Architecture The codebase is a monolith in packaging terms (roughly 300 generated services and ~774 client/typing files all in one npm package) but internally layered: per-service JSON models under apis/ are lazily registered through lib/api_loader.js and turned into client behavior at require-time, so lib/service.js’s abstract AWS.Service base class and every generated AWS.<ServiceName> constructor are almost entirely data-driven rather than hand-coded per service. Every API call, regardless of which service issued it, is executed by the same finite-state machine in lib/request.js (validate -> build -> afterBuild -> sign -> send -> retry -> afterRetry -> validateResponse -> extractData/extractError -> success/error -> complete), which centralizes signing, retry, and error propagation in one place. That centralization is also the architecture’s single point of failure: because every one of the ~300+ generated clients shares the same core request pipeline, a change to request.js or service.js has blast radius across the entire library rather than being scoped to one service.

Tech Stack The implementation is plain CommonJS JavaScript (ES5-oriented, using a prototype-based inherit() helper rather than ES6 classes), with a deliberately small runtime dependency set — buffer, events, ieee754, jmespath (for JMESPath query support), sax and xml2js (XML parsing), and uuid. Browser and React Native builds are produced via browserify with a custom transform plus webpack, and TypeScript 2.0.8 is used only to typecheck and ship the bundled .d.ts declaration files rather than as the implementation language. A Ruby toolchain (Rakefile, Gemfile) and leftover CoffeeScript in dist-tools/ reflect the project’s early-2010s origins. Testing spans Mocha and Chai for Node, Karma plus Jasmine for browser runs, and Cucumber/Gherkin feature files for higher-level integration scenarios.

Code Quality The test/ directory holds roughly a hundred .spec.js files exercising protocol marshalling, credential provider resolution, parameter validation, and request state-machine transitions, complemented by browser tests and Cucumber-driven integration features — an unusually broad test setup for a decade-old codebase. Error handling is centralized rather than ad hoc: AWS.util.error() decorates native Error objects and the request state machine explicitly funnels every failure through dedicated error/retry states instead of letting exceptions propagate unchecked. Style is enforced via a checked-in ESLint configuration, and CI runs through AWS CodeBuild (buildspec.yml) with Codecov coverage reporting. There is no source-level type safety, however — TypeScript is confined to the shipped type declarations, not the implementation — and the ES5-era conventions throughout now reflect a codebase that is frozen in place rather than actively maintained.

API Design Every AWS service exposes an identical calling convention — construct new AWS.<Service>(config), then call .operationName(params, callback) or chain .promise() — so the ergonomics learned on one client (say S3) transfer directly to all ~300+ others, backed by uniform parameter validation and consistent error shapes. Documentation is comprehensive and effectively auto-generated per operation from the underlying API models, and bundled TypeScript typings give IDE autocomplete for every operation without hand-authored type definitions. The cost of that consistency is boilerplate: juggling callback- and promise-based flows, manually wiring pagination and waiters, and pulling in one large, all-services-bundled package is heavier than the modular, tree-shakeable client-command pattern AWS SDK for JavaScript v3 replaced it with.