Performance and functionality improvements for AWS Lambda extensions

AWS Lambda extensions are a new way to integrate Lambda more easily with your favorite monitoring, observability, security, and governance tools.

With the general availability announcement, AWS is introducing performance and functionality improvements. The Lambda service now returns the response from the function as soon as the function code is complete without waiting for the included extensions to finish. This enables extensions to perform activities like sending telemetry to a preferred destination after the function’s response has been returned.

AWS welcomes extensions from new partners: Imperva, Instana, Sentry, Site24x7, and the AWS Distro for OpenTelemetry. For the list of available extensions and partners, see AWS Lambda Extensions Are Now Generally Available.

Extensions integrate deeply into the Lambda environment using the Lambda Runtime Extensions API. They control and participate in all phases of the Lambda lifecycle, function initialization, invocation, and shutdown. Extensions enable a wide range of use cases. For example, you can use extensions to send telemetry data about function invocations to observability tools. Extensions can pre-fetch configuration and secrets before running a function handler, or send function logs directly to any destination. You can follow the learning path video series which explores many aspects of using and building Lambda extensions. See AWS Lambda extensions: The deep dive.

Lambda extensions APIs

Performance and functionality improvements

Decoupling the invocation response

During preview, the function response returned after the function and all extensions completed. Now, the Lambda service returns the response from the function as soon as the function code is complete without waiting for the extensions to finish. This enables extensions to perform activities like sending telemetry data to a preferred destination after the function’s response is returned.

Extensions do not need to make any configuration changes to take advantage of this change. You can see this represented in the invoke phase diagram from the Extensions API documentation.

Lambda invoke phase response

New Logs API functionality

platform.runtimeDone message

Logging tools, running as Lambda extensions, can use the Lambda Logs API to receive log streams directly from within the Lambda execution environment. Lambda streams the logs to the extension, and the extension can then process, filter, and send the logs to any preferred destination.

The Lambda service now emits a new log message to let Logs API consumers know that the function handler has finished. Extensions that use the new schema for Logs API can use this to know when to send all the telemetry collected during that invocation.

The Lambda service generates a REPORT log line at the end of the invoke phase. This includes metrics such as the billed duration. Since these metrics apply to the entire invoke phase, which includes the runtime and all extensions, this line is generated after the invoke phase is completed. Extensions receive it upon the next event, either an invoke or shutdown.

Logs API buffering

Lambda can buffer logs and deliver them to the subscriber. You can configure the buffer behavior by specifying the optional timeoutMs, maxBytes, and maxItems values in the subscription request. As part of this release, we have reduced the minimum value of timeoutMs from 100 ms to 25 ms so that extensions can receive logs even sooner.

Logs API local listener address

Logging extensions start a local listener endpoint to receive the logs using either TCP or the recommended HTTP. For HTTP endpoints, we now recommend using the address http://sandbox.localdomain:${PORT}/${PATH}. The $PATH parameter is optional.

Building your own extensions

You can build and use your own extensions to integrate your organization’s tooling. To learn how to build you own extension, see Extensions API.

For instance, GoDaddy is a provider of internet services to small, independent ventures. GoDaddy went all-in on AWS in 2018 to innovate faster and meet global customer growth.

“As we migrate several critical applications to the cloud, our application teams choose a breadth of AWS’s compute services – including Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), and AWS Lambda for building applications,” said Grant Shively, a Principal Software Engineer on the Global Platform Development team at GoDaddy. “Extensions have enabled us to use Open Policy Agent on Lambda to build the capability to standardize authorization policies across the company and seamlessly handle our audit and governance needs. They let the Global Platform Development team decouple the common concerns of auditing, governing, and evolving authorization policy from the code which application teams write.”

“At GoDaddy, the Global Platform Development team is responsible for creating software platforms that support and augment other software systems across the company. Application teams at GoDaddy have embraced the serverless paradigm, and we need to ensure that their applications are integrated with our new authorization platform.  Leaders from multiple GoDaddy teams joined forces to design and create a platform, based on the Open Policy Agent, that allows us to centralize the management and governance of authorization policy, while decentralizing the evaluation and enforcement of said policy.

“Extensions enable GoDaddy teams to run our platform agents as a companion process within their functions, via simple configuration. On initialization, our agent fetches the latest policy bundles and watches for any updates in the background, spins up an HTTP server, and prepares to accept requests. When an application encounters a client attempting to access a protected resource, it makes an HTTP request to the policy agent asking if it is allowed by policy. The policy agent authenticates the client identity, evaluates the request, and returns its decision, along with any obligations required of the client. Audit logs of all decisions are shipped in real-time to a central data store, where we can monitor them for anomalies.

“By using Extensions and communicating with the platform agent over localhost, we’re able to provide millisecond responses to authorization requests. And co-locating policy agents with applications isn’t only critical for performance, it also increases the reliability of our platform by significantly limiting the blast radius of agent failures.”

Ridgeline is a privately funded fintech startup determined to modernize investment management software and is building their enterprise platform on Amazon Web Services (AWS).

“As a modern fintech startup, serverless is our preferred approach for building applications,” said Chris Petrunik, Director of Engineering at Ridgeline. “AWS Lambda Extensions have enabled us to leverage the performance and scale benefits of Lambda for synchronous requests, and seamlessly handle our audit and governance needs, by asynchronously persisting transaction data outside our function handler.”

Ridgeline strives to use technologies that enable us to innovate faster. When we first learned about AWS Lambda Extensions, we immediately saw the benefits for our users. They could speed up our API response times by offloading work normally done in the main path of our requests. Our extension is a companion to the main function and allows for parallel and post-processing during requests from our users. The work to persist transaction data now runs during and after the response from the Lambda function has been returned to the user, saving Ridgeline considerable time and improving the overall performance of our API. This allows us to add redundancy into our system at no cost to our API performance.

In addition to providing a simplified development experience, Ridgeline uses extensions to distribute and synchronize configuration information to the Lambda functions that power our requests. We use extensions to update this configuration metadata as the system parameters change and have the latest configuration available for the next request. It is incredibly powerful to know that an update can propagate to hundreds of functions without suffering any cold starts.

AWS Lambda console

Generally available extensions from AWS and AWS Lambda Ready Partners are now visible in the AWS Lambda console. Navigate to https://console.thinkwithwp.com/lambda/home#/extensions. You can select the links to find out more about how each extension works.

AWS Lambda Ready Partner extensions in the Lambda console

Conclusion

Lambda extensions enable you to extend the Lambda service to more easily integrate with your favorite tools for monitoring, observability, security, and governance.

With the general availability announcement, there are a number of performance and feature enhancements. The Lambda service now returns the response from the function as soon as the function code is complete, without waiting for the extensions to finish. The Logs API emits a new platform.runtimeDone message to let you know when a function has finished, along with some additional configuration options.

There are a number of open-source example projects and demos to help you get started building your own extension available in the GitHub repository. These include example AWS external extensions for a number of languages, wrapper scripts, and logging extensions.

AWS Lambda extensions are available in all AWS Regions where AWS Lambda is available. The performance improvements announced as part of GA are currently available in US East (N. Virginia), Europe (Ireland), and Europe (Milan) Regions.

For more serverless learning resources, visit https://serverlessland.com.