Why would a developer use AWS Lambda? In a word, simplicity. AWS Lambda—and other event-driven, “function-as-a-service” platforms such as Microsoft Azure Functions, Google Cloud Functions, and IBM OpenWhisk—simplify development by abstracting away everything in the stack below the code. Developers write functions that respond to certain events (a form submission, a webhook, a row added to a database, etc.), upload their code, and pay only when that code executes.

In “” I covered the nuts and bolts of how a function-as-a-service (FaaS) runtime works and how that enables a serverless software architecture. Here we’ll take a more hands-on approach by walking through the creation of a simple function in AWS Lambda and then discuss some common design patterns that make this technology so powerful.

AWS Lambda, the original FaaS runtime, was first announced at AWS re:Invent in 2014.  The most common example used to explain how the event-driven, compute-on-demand platform works remains this one, the resizing of an image uploaded to Amazon S3:


A picture gets uploaded to an S3 bucket, triggering an event that executes a Lambda function.  Prior to the event being triggered, the function sits in a file on disk; no CPU resources are used (or billed) until the work arrives. Once the trigger fires, the function is loaded into the Lambda runtime and passed information about the event. In this example, the function reads the image file from S3 into memory and creates thumbnails of varying sizes, which it then writes out to a second S3 bucket.

. But the easiest way to start is to use one of the blueprints provided by AWS. If we go to the AWS Lambda console and click on Create New Function, we get the following:

aws lambda 02IDG

We’ll be using Node.js to create a function that reacts to an S3 event, so we’ll choose Node.js 6.10 from the Select Runtime menu and enter S3 into the Filter dialog:

aws lambda 03IDG

Clicking the s3-get-object blueprint takes us to the Configure Triggers page:

highlighted four such patterns. Here I’ll introduce my two favorites because they represent low hanging fruit for any organization wanting to get started with serverless architectures.

First, it is easy to build web applications the use of S3 and CloudFront for static content and the use of API Gateway backed by Lambda and DynamoDB for dynamic needs:

aws lambda 20Amazon

That basic pattern can be locked down tightly with security at multiple levels:

aws lambda 21Amazon

The bulk of the content for a web application tends to be read-only for all users, and this model can be served cheaply from S3 and CloudWatch. Authorized data can take advantage of IAM hooks into API Gateway along with IAM roles for individual Lambda functions that interact with a DynamoDB.

My second favorite use case—one implemented by —is to set up automation hooks using Lambda. In Capital One’s implementation, CloudWatch log events trigger Lambda functions to run checks against compliance and policy rules specific to Capital One. When potential issues have been found, the function generates notifications through Amazon SNS, which can be configured to send SMS messages, emails, and a number of other mechanisms to alert the right people to policy violations that require their attention.

aws lambda 22Amazon

I like this automation pattern because it adds enormous value to an existing process without disturbing that process in any way. System compliance is automated without touching the systems being monitored. And like the previous pattern, it offers an easy way for an organization to get its feet wet with serverless.

Thinking outside the server

As we’ve seen, setting up a Lambda function, configuring an event, applying security policies, and testing the results is a snap—even without an IDE or command line tools. Microsoft, Google, and IBM offer similarly easy onboarding for their FaaS runtimes. Plus design patterns are emerging that will undoubtedly pave the way to even higher orders of tooling and reuse.

Serverless application architectures represent a very different mindset. The pieces of code are smaller, they execute only when triggered to reduce cost, and they are tied together through loosely coupled events instead of statically defined APIs. Serverless enables far more rapid development cycles than were possible previously, and with simple automation and web application design patterns to draw on, it is easy to get started with low risk.