Hi! I’m Dhruv Sood, a product manager
on the AWS Lambda team,
and today, I’m excited to give you
an overview of Lambda Extensions.
Extensions are new way to easily integrate
your favorite operational tools for monitoring,
observability, security, and governance with Lambda.
You can use extensions from AWS,
AWS Partners, and open source projects.
And, as of this recording, there are
extensions available for all of these tools.
Head over to the link below to see the latest set
of extensions and what you can achieve with them.
Extensions help solve a common request from customers
to make it easier to integrate their
favorite operational tools with Lambda.
Previously, customers told us
that integrating some tools
required extra operational and configuration tasks.
In addition, tools such as log routers,
which are long-running processes,
could not easily run on Lambda.
With Lambda Extensions, you can plug
in the tools you want to use
directly into the Lambda environment
without complex configuration or installation.
You can use extensions for use-cases such as:
Capturing diagnostic information
before, during, and after function invocation
Automatically instrumenting your code
without needing code changes
Fetching configuration settings
or secrets before the function invocation
Sending telemetry to custom destinations directly
and asynchronously from your Lambda functions,
Detecting and alerting on function
activity through security agents
Getting started with extensions is easy.
You can deploy extensions as layers and use
environment variables to configure it.
Or, if you package and deploy your Lambda
functions as container images,
you can add the extension to your image.
To get specific instructions,
head over to the documentation provided
by your favorite tooling vendor.
Now, let’s take a look at how Lambda extensions work
and talk a little bit about Lambda’s environment.
Lambda provides a sandboxed environment
and this is where your function code runs.
This isolates your function from other functions
and provides the resources, such as memory,
which you specify in the function configuration.
The Lambda service initializes this environment
on-demand during the first invocation.
Or, in advance of the first invocation
if you use provisioned concurrency
which keeps functions initialized and-ready
to respond in double-digit milliseconds.
When you invoke a Lambda function, the Lambda service
routes the request to this environment.
After the function has processed the request
the Lambda service freezes this environment.
It thaws it later, if it needs to re-use it
for another invocation.
When a function has not been used for some time,
the Lambda service spins down this environment.
In this way, Lambda automatically
manages the lifecycle of compute resources.
Let’s zoom in a bit...
The main process within the Lambda environment
is the runtime
which runs your function code.
The runtime process uses the Runtime API
to communicate with the Lambda service.
It requests invocation events from the Lambda service
and then invokes the function handler.
After the function code is done,
it returns the response to the Runtime API
and asks for the next invocation event.
If there are no events ready to be processed,
the Lambda service freezes the environment.
Now, extensions are a new way for tools to more easily
integrate deeply into the Lambda environment.
They use the Extensions API to request
lifecycle events, process them,
and then tell the Lambda service when they are done.
Through this API, extensions get greater control
of the lifecycle of the environment
the Lambda service freezes it once the runtime
and all extensions are done.
Let’s take a closer look at how extensions can run
at all phases of the Lambda lifecycle
initialization, invocation, and shutdown.
First - extensions can run before the function
because the Lambda service starts extensions
before the runtime and the function.
Second, during the invoke phase, extensions can
run logic in parallel to the function and can also
choose to run after the function code is done.
Extensions can use this time for things
like sending out data collected during the invoke.
The Lambda service freezes the environment
when the runtime and all extensions are done,
and so, in this way,
extensions can influence the freeze and thaw behavior.
Finally, extensions can run during a shutdown phase
which occurs before the environment is spun down.
They can use this time for final clean-up tasks.
Note: because extensions run in the same environment
as function code, they share resources such as memory, CPU
and credentials with the runtime process.
Now, before we wrap up,
let’s talk a little bit about logs...
To help you troubleshoot failures in a function,
the Lambda service automatically captures logs generated
by your function, and streams them to Amazon CloudWatch.
This log stream contains the logs which are generated
from within your function code, and also those
that are generated by the Lambda service
as part of the invoke
Extensions for tools like log routers can now
use the new Logs API to subscribe to these log streams,
and the Lambda service will then stream
logs to the extension.
Previously, 3rd party tools would get logs via CloudWatch,
and now, they can also use the Logs API
to get them directly from within the Lambda environment.
So to wrap up, you have seen that Extensions are
a new way to integrate tools with Lambda.
Extensions can run in parallel the function and can
also continue to run after the function code is done.
They use the Extensions API to control and influence
the lifecycle of the Lambda environment.
In addition, The new Logs API gives extension authors
a simple interface to receive a stream of logs
These capabilities together, make it even easier for you
to use favorite tools with AWS Lambda.
For more information, take a look at the link below.
Thank you.