This is a pattern that attaches an EFS file system to your lambda function to give it expandable, persistent storage. Having this level of storage in a Lambda Function opens the door to many new possibilities (multiple functions can even use the same file system).
Some Useful References:
Author | Link |
---|---|
AWS Docs | Using Amazon EFS with Lambda |
AWS Docs | Configuring file system access for Lambda functions |
AWS Samples | EFS for Lambda - Example SAM applications |
James Beswick | Using Amazon EFS for AWS Lambda in your serverless applications |
Danilo Poccia | A Shared File System for Your Lambda Functions |
Yan Cui | Unlocking New Serverless Use Caes With EFS and Lambda |
This pattern covers the first half of Danilo Poccia's awesome blog post. After deployment you will have an API Gateway HTTP API where any url you hit gets directed to a Lambda Function that is integrated with EFS.
A VPC is bundled in this pattern because EFS requires it, this is using the default settings from CDK so if you want to put this in production you will have to review / refine this
A FileSystem is included in the above VPC with a removal policy of destroy. In a production system you probably would want to retain your storage on stack deletion.
POSIX permissions are also setup for this File System
A simple Python lambda function that interacts with the file system - storing, retrieving and deleting messages
This is configured with the Lambda Function as the default handler for any url you hit.
Our deployed Lambda Function is acting as a shared message broker. It allows you to send messages to it which it stores in EFS, then you can retrieve all messages to read them or delete all messages after you have finished reading.
The Lambda Function will behave differently based on the RESTful verb you use:
- GET - Retrieve messages
- POST - Send a message (whatever you send in the body is the message)
- DELETE - Deletes all stored messages
The URL for the HTTP API to use these commands will be printed in the CloudFormation stack output after you deploy
Note - After deployment you may need to wait 60-90 seconds before the implementation works as expected. There are a lot of network configurations happening so you need to wait on propagation
dotnet build src
compile this appcdk deploy
deploy this stack to your default AWS account/regioncdk diff
compare deployed stack with current statecdk synth
emits the synthesized CloudFormation template
- Create an Ubuntu AWS Cloud9 EC2 development environment
- Add the Microsoft repository
wget https://packages.microsoft.com/config/ubuntu/20.04/packages-microsoft-prod.deb -O packages-microsoft-prod.deb
sudo dpkg -i packages-microsoft-prod.deb
- Install the .NET Core SDK
sudo apt-get update; \ sudo apt-get install -y apt-transport-https && \ sudo apt-get update && \ sudo apt-get install -y dotnet-sdk-3.1
- Clone the CDK Patterns repo
git clone https://github.com/cdk-patterns/serverless.git
- Change directory
cd serverless/the-efs-lambda/csharp
- Build the project to see if .NET Core has been setup correctly (optional)
dotnet build src
- Deploy the stack
cdk deploy