Tim Wagner, AWS Lambda

AWS Lambda Now Generally Available

AWS Lambda has exited preview and is now ready for production workloads!

Increased Default Limits

AWS Lambda is designed to scale to the size of your workload, whether that’s one request a month or 10,000 a second. As a safety precaution each account has two limits: a default concurrent execution limit (previously 50, now 100 simultaneous executions) and a 1,000 request per second limit. We are happy to lift both limits – just request an increase from AWS customer service and we’ll get it turned around promptly for you. These limits provide you with a mechanism to control costs and also help us manage capacity per region — they are not in any way a fundamental restriction on Lambda’s ability to scale or to the work you can now do with Lambda!

API and Programming Model Improvements

Many developers tried AWS Lambda during its preview period and provided feedback that was essential to improving our programming model at all levels. We incorporated many of these suggestions into the current version of the service and client APIs, including

• Synchronous (request/response) calls that return results. One of the top requested features during the preview period was the ability to call Lambda functions and have them return results. We’ve added this feature and also made it easy in the Java, Android, and iOS clients to send objects (“POJOs”, in the Java case) and have them turn into JSON objects inside the Lambda function.
• Multiple functions per stream. Both Kinesis and DynamoDB streams can now be attached to multiple Lambda functions. Note that the per-shard read capacity still applies, so all the functions retrieving data share the read limit. You can also direct any number of event sources to a given AWS Lambda function (this has been true from the beginning).
• New context methods. In addition to context.done we’ve added context.succeed(result) and context.fail(Error). These functions are more natural than using context.done in some settings and can make your code more readable. If you pass an Error object to context.fail it will automatically extract and return the type, message, and stack trace. For request/response-style functions, context.succeed will return the result you give it to the Lambda function caller.
• Device and end user identity. The context variable now also contains information about the end user if the client calling the Lambda function used Amazon Cognito to authenticate that user. (This also works for unauthenticated access using Cognito.) If the AWS Mobile SDK was used to make the Lambda function invocation, then context also contains information about the app and device hardware that the client is using. Both of these make it easier to create mobile backends that personalize their behavior based on the end user’s identity and/or hardware. (More on this feature in a future article!)
• Resource policies. AWS Lambda now allows you grant cross-account access and to specify access to a Lambda function based on resources, such as events sent from a specific Amazon S3 bucket or SNS topic. At the same time, we removed the need to use invocation roles, making authorization easier and more powerful while keeping your Lambda functions safe and secure.
• New throttle metric. Developers told us they needed more visibility when they were reaching their concurrent request limit, so we added a fourth built-in metric to show when invocations are rejected because this limit has been reached. Developers can see this on the AWS Lambda console or by using the Amazon CloudWatch console or APIs.
• Finding relevant logs. Developers told us during the preview that finding the right log streams within the log group could be a challenge. So in conjunction with the Amazon CloudWatch Logs team we did several things: log streams can now be sorted by last entry time, making it easy to find the most recent log entries even when there are multiple streams. We also added the creation date to the name of the log stream for easier filtering and started providing the name of the log stream to the Lambda function (inside the context variable).

New Event Sources

When we launched AWS Lambda at re:Invent we included support for three event sources: Amazon S3 bucket notifications, Amazon Kinesis stream records, and the preview release of Amazon DynamoDB update streams. With the GA release we also added support for two more:

• Amazon Simple Notification Service (SNS). SNS was the most-requested additional source of events for AWS Lambda, and we’re excited to announce that you can now hook up a Lambda function to an SNS topic and have it invoked automatically for each message sent. This makes it easy to take any service that already uses SNS and easily turn it into a mechanism to run arbitrary commands through Lambda! You can also combine SNS’s ability to call Lambda and Lambda’s ability to call SNS to create targeted messaging frameworks, templated messages, A/B tests, and lots of other intelligent messaging scenarios that would previously have required you to provision and manage infrastructure.
• Amazon Cognito. In addition to the end user identity mentioned earlier, there is a second integration between Cognito and AWS Lambda: If you use Cognito sync to keep user data (such as game state or user preferences) synchronized across the user’s devices, you can now also automatically trigger Lambda whenever that data changes. This allows you to audit, log, or override the data and have that decision automatically propagate across all the user’s devices, making it easy to keep those devices synchronized with backend services in the cloud and vice versa.

We hope you enjoy the new and improved AWS Lambda service. For more information on the new features and GA release, see AWS Lambda: What’s New. Happy coding!