CDK app that deploys a Lambda internal extension to modify the standard behaviour of AWS Lambda.
- AWS:
- Must have authenticated with Default Credentials in your local environment.
- Must have completed the CDK bootstrapping process for the AWS environment where you intend to deploy the app.
- Node.js + npm:
- Must be installed in your system.
- Poetry:
- Must be installed in your system.
- Docker:
- Must be installed in your system and running at deployment.
npx projen installnpx projen deploynpx projen destroy
A Lambda layer containing our internal extension gets created and attached to a Lambda function. This Lambda function is configured to call the wrapper script inside the Lambda layer as soon as it starts, which in turn calls a forked awslambdaric (Lambda Runtime API) that was modified so that it reads a parameter from SSM Parameter Store during the Lambda bootstrap process. If the current datetime falls inside the maintenance window defined by the parameter, the Lambda function handler doesn't get executed; instead, the Lambda invocation event gets stored in DynamoDB so that it can be triggered manually at a later time. Outside the defined maintenance window, the Lambda function keeps working normally.
The way AWS Lambda works under the hood is by using Firecracker, a virtual machine monitor (VMM) that is able to spawn a fleet of microVMs as Lambda invocation events come in. When a new microVM gets created, all the parameters you set in your AWS Lambda are read and used to apply the wanted configuration to the microVM environment. In addition, your Lambda function and any Lambda layer you attached to it get copied into specific directories of the microVM. With this knowledge, you can modify the behaviour of AWS Lambda by configuring it to use a custom version of the Lambda Runtime API instead of the official one provided by AWS inside the microVM.