Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
AWS (Amazon Web Services) APIs client implementation for node.js

Fetching latest commit…

Cannot retrieve the latest commit at this time

Failed to load latest commit information.


Amazon Web Services node.js module. Originally a fork of aws-lib.


Either manually clone this repository into your node_modules directory, then run npm install on the aws2js top directory, or the recommended method:

npm install aws2js

npm is the only direct dependency of this library. It is used programmatically to install the dependencies.

By default, the module installs as dependencies the libxml-to-js and the mime-magic libraries. Under Windows, it installs by default with xml2js and mime-magic.

Basically, under Windows the default installation is the equivalent of:

npm install aws2js --xml2js true

If you want to install the library without binary dependencies, you can issue this npm command:

npm install aws2js --xml2js true --mime true

This installs the library with xml2js and mime as dependencies. Please notice that the mime library detects the MIME type by doing a file extension lookup, while mime-magic does it the proper way by wrapping the functionality of libmagic. You have been warned.

The '--xml2js true' and '--mime true' are boolean flags, therefore you may use them in any combination, if applicable.

Project and Design goals

  • HTTPS-only APIs communication (exceptions allowed for HTTP-only APIs)
  • Proper error reporting
  • Simple to write clients for a specific AWS service (abstracts most of the low level plumbing)
  • Simple to use AWS API calls
  • Higher level clients for specific work flows
  • Proper documentation



For the moment, this project is largely a one man show. Bear with me if things don't move as fast as they should. There are a handful of aws2js contributors as well. The community makes things to be better for everyone.

If you'd like to contribute your line of code (or more), please send a pull request against the future branch. This makes things to be easier on my side. Feature branches are also acceptable. Even commits in your master branch are acceptable. I don't rely on GitHub's merge functionality as I always pull from remotes and manually issue the merge command.

I ask you to patch against the future branch since that's the place where all the development happens, therefore it should be the least conflicts when merging your code. I use the master only for integrating the releases. The master branch always contains the latest stable release.

Something went wrong with that request. Please try again.