learn-aws-lambda: a 2015 to 2021 Lambda tutorial that tells you it is out of date

The README leads with its own obsolescence

This is unusual enough to start with. The disclaimer says the notes were written from 2015 to 2021 to extensively capture knowledge of using Lambda to build simple functions such as sending email or transforming an image, and then says plainly that while the notes can still serve as a reference, they are no longer current with the latest Lambda UI. It adds that most code examples will still work because they are reasonably simple, and that the authors have not had time to update the notes.

The project also says they still have several functions running smoothly on Lambda with zero maintenance required beyond updating the Node.js version, for internal apps and client apps, and points at two of them: the aws-ses-lambda repository and the github-scraper lambda. The framing is honest in a way most tutorial repositories are not: this is a snapshot of working knowledge, and the author is telling you which parts have aged and which have not.

What that means for you as a reader is that the console navigation steps, the IAM setup wording and the configuration screenshots are the parts to distrust, while the code, the request and response shapes and the trigger mechanics are the parts most likely to still teach you something.

The repository also carries a second, more current point. It notes that AWS released a feature allowing a Lambda function to be called directly via a URL without the complexity of API Gateway, which significantly simplifies invoking functions from other non Lambda apps. That observation is the most operationally useful thing in the README, and it is also the reason the project would not be worth writing today without it.

Why the project says not to build your whole backend on Lambda

The disclaimer contains a recommendation and a warning, and the warning is the part that should shape your decision. The project does not recommend building an entire complex serverless backend using Lambda, because the request and response time is quite slow compared to a Phoenix application, and because it is more tedious to test and deploy all the moving parts.

It recommends the opposite use case instead. If you are looking for a way to offload some processing to Lambda from an existing non Lambda app or backend, the project points you at the direct URL invocation feature. For simpler asynchronous functions it says Lambda is great, and it links the generous one million requests free tier.

This is a scoping statement, and it is worth taking at face value because it narrows what the tutorial should be used for. The tutorial is organised around individual functions: send an email, transform an image, react to a database stream, react to a notification. That is the shape of the examples in the repository, with directories such as api-gateway-dynamoDB-example, serverless-starter, upload-deploy-example and zip-example, each isolating one path through the platform.

The comparison the project draws is with a Phoenix application, and the point is about latency rather than capability. A function that cold starts, is invoked, does a small amount of work and exits is a fine fit for the platform. A request and response service where the caller waits for the answer is a different problem, and the tutorial does not claim otherwise.

Ephemeral storage, and the datastore costs hiding behind it

The conceptual section of the tutorial is the part that has aged best, because the constraint is a property of the platform rather than of the console.

The first feature listed is ephemeral storage. There is no access to a filesystem or memory persistence, such as an on instance Redis, so you cannot store data or the result of an operation locally. The second feature is how that limitation is resolved: low latency access to AWS S3 and other AWS datastores, naming ElastiCache as an in memory cache, DynamoDB as a NoSQL SSD based database, and RDS as a relational database.

Then comes the catch, and it is the sentence that has the most practical value in the whole tutorial. Requests to all AWS data stores are not free. Per run costs on Lambda are tiny, but if you GET and PUT something to S3 on each execution cycle, you can rack up the bill. That is a cost modelling warning rather than a technical one, and it is the kind of thing that only becomes obvious after you have deployed something and looked at the bill.

The same shape of argument runs through the rest of the concept section. The project frames Lambda as a disruption of AWS's own EC2 business, since EC2 is sold in fixed increments with application monitoring and scaling to manage, while Lambda is a simpler way to build micro services. It also notes that Lambda disrupts other platform as a service providers such as Heroku, Google App Engine, Azure and Modulus, where you buy a specific amount of compute power and RAM and get a scaling delay and a fixed instance increment. The mechanics of autoscaling to zero versus scaling in instances is the real difference, and it is why the async use case fits so much better.

One directory per integration path, which is the real content

The repository structure is where the teaching material actually lives, and the top level listing makes the curriculum visible. There is api-gateway-dynamoDB-example, dist, examples, gulpfile.js, lambda-testing, serverless-starter, upload-deploy-example and zip-example, plus package.json, package-lock.json, a CONTRIBUTING.md and a .github directory.

Read the directory names against the table of contents and the structure explains itself. zip-example and dist relate to the two ways of getting code to Lambda, inline in the console or as a zip folder. api-gateway-dynamoDB-example is the API Gateway path in front of a database. serverless-starter is a starting point. lambda-testing is the testing story. upload-deploy-example is the script that uploads a function to S3 and then deploys it. gulpfile.js is the Gulp based deployment path.

The examples directory holds the code. It contains GetNotes.js, SaveNotes.js, notes.html, add.ts and add.test.ts, a lambda_invoke subdirectory and its own README. Two of those files are named after the two halves of a DynamoDB read and write, which tells you the shape of the example application: notes, read and saved.

The table of contents in the README lists the same paths as lessons, including the inline function, the zip folder, the API Gateway version, the callback parameter with node v4.3, triggering from a DynamoDB event, triggering from the Simple Notification System, triggering on email arrival through Simple Email Service, continuous integration using Codeship, testing functions, uploading to S3 and deploying to Lambda with a bash script, deploying with Gulp, and versioning and aliasing. Each of those has a directory or file behind it, which is what makes this a tutorial you can read offline as well as one you can read in the browser.

The test script and the deployment tooling in package.json

The package.json is small and tells you what the project actually expects to be run.

{
  "name": "learn-aws-lambda",
  "version": "1.0.4",
  "scripts": {
    "upload": "./lambda-upload-create.sh",
    "test": "nyc --reporter=lcov tap ./examples/add.test.ts",
    "coverage": "nyc --report html tap ./examples/add.test.ts && open coverage/index.html"
  }
}

The test script runs the tap test runner under nyc for coverage, against a single file, examples/add.test.ts. The coverage script produces an HTML report and opens it. The upload script points at a shell script named lambda-upload-create.sh, which is the artefact behind the uploading to S3 and deploying lesson in the table of contents.

The dev dependencies explain the test harness. aws-lambda-mock-context and aws-lambda-pify are there so a function can be invoked with a mock event and context in a test rather than in AWS, and tap and nyc are the runner and the coverage tool. That is the whole testing story, and it is a sensible one: you test the handler logic locally, then you test the wiring in the console.

The deployment tooling is the other half. The project points at its own micro Lambda deployment tool, aws-lambda-deploy, and describes it as still working flawlessly ten plus years later, attributing that to its simplicity and ultra low dependency count. The gulpfile.js and gulp-zip, gulp-install and run-sequence dependencies cover the older Gulp path.

The declared version is 1.0.4 and the description is a how to guide for AWS Lambda, DynamoDB, SNS and API Gateway, with the author line crediting Nelson Correia, Jack Carlisle and Nikki Ravi, the same three names the disclaimer credits for the original notes.

Licence ambiguity, and the platform links the tutorial points at

Two things are worth checking before you reuse anything here.

The first is the licence. The package.json declares GPL-2.0, and the top level listing of the repository shows .github, .gitignore, CONTRIBUTING.md, README.md, the example directories, gulpfile.js, package.json, package-lock.json and serverless-starter, with no LICENSE file among them. The project metadata in the repository listing also records the licence as unknown. A declared GPL-2.0 in a package manifest with no licence text in the tree is a gap you should close before copying code out of the examples, and it applies with full force to the GPL copyleft obligations if you do reuse a file, as opposed to reading the prose.

The second is the external dependencies the tutorial leans on. It links the AWS Lambda introduction, the getting started guide and the pricing page, and it links the project wiki for the Lambda deployment tool. It also references the dwyl technology stack for the Phoenix comparison. Those links are where current information lives, and they are also where the tutorial's age shows: everything the tutorial teaches is behind a link, and the links move forward while the notes do not.

The examples themselves carry the same character. The lambda_invoke directory and the tests using aws-lambda-mock-context are how the project demonstrates calling a function directly, which is the same mechanism the README highlights as the new AWS feature. In other words the directory layout quietly documents the modern recommendation, while the prose is still describing the API Gateway route as the main event.

Editorial conclusion

learn-aws-lambda fits a developer who wants the shape of a Lambda application before touching the console, who wants runnable example folders for DynamoDB access, API Gateway routing, SNS triggers and SES email handling, or who needs a working pattern for uploading a function to S3 and deploying it. It does not fit a team that needs current AWS guidance, since the notes are explicitly written against the 2015 to 2021 console and the README says they are no longer current with the latest Lambda UI, and it does not fit a project that needs a supported service rather than a set of examples. Check three things before you rely on it. Check the age of what you are reading, because the project says the code examples will still work as they are reasonably simple, but the interface steps will not match what you see. Check the deployment tooling, because the bundled gulpfile.js and the separate aws-lambda-deploy project are what the project points to for shipping a function, and the notes have not been updated alongside them. And check the licence, because the package.json declares GPL-2.0 while no licence file appears at the top level of the repository. The last push was on 2026-10-05 and the package version is 1.0.4.

Frequently asked questions

Official sources

1. dwyl/learn-aws-lambda on GitHub
2. Issues
3. README