Add Lambda MicroVMs with S3 Files pattern#3206
Open
bfreiberg wants to merge 5 commits into
Open
Conversation
Mount an Amazon S3 bucket as a POSIX file system inside an AWS Lambda MicroVM (Firecracker-isolated, snapshot-resumable serverless compute) over NFS, reachable through a VPC egress network connector, with bidirectional S3 sync. CloudFormation (AWS SAM) provisions the data bucket, the S3 Files file system / mount target / access point, the VPC egress network connector, the IAM roles, the CloudWatch log group, and the MicroVM image (AWS::Lambda::MicrovmImage). A small src/run.sh helper performs the data-plane steps that have no CloudFormation resource: packaging the app artifact and launching the MicroVM (RunMicrovm). Verified end-to-end in us-west-2: deploy -> run -> bidirectional S3 Files sync.
marcojahn
previously requested changes
Jul 7, 2026
marcojahn
left a comment
marcojahn
left a comment
Contributor
There was a problem hiding this comment.
Hi @bfreiberg, thank you for your contribution. I made a few request for changes. Please review.
| * **Stack Name** – e.g. `lambda-microvm-s3files` | ||
| * **AWS Region** – `us-west-2` | ||
| * **CodeArtifactBucket** – the bucket name from step 3 | ||
| * **VpcId** / **SubnetId** – a VPC and subnet for the mount target and egress connector ENIs |
Contributor
There was a problem hiding this comment.
Please indicate more prominently that a VPC and Subnet needs either to be provided OR generated
Subnet requirements, private / public?
| * **CodeArtifactBucket** – the bucket name from step 3 | ||
| * **VpcId** / **SubnetId** – a VPC and subnet for the mount target and egress connector ENIs | ||
| * Accept the IAM-capabilities prompt (`CAPABILITY_IAM`) | ||
| 6. Note the stack outputs (`ImageArn`, `ExecutionRoleArn`, `EgressConnectorArn`, `FileSystemId`, `AccessPointId`, `MountTargetId`, `DataBucket`). The image build is asynchronous; wait until `ImageState` is `CREATED`. |
Contributor
There was a problem hiding this comment.
what for? never re-used later. Or just for FYI to show what has been created?
| @@ -0,0 +1,138 @@ | |||
| # Lambda MicroVMs with S3 Files | |||
Contributor
There was a problem hiding this comment.
Suggested change
| # Lambda MicroVMs with S3 Files | |
| # AWS Lambda MicroVMs with Amazon S3 Files |
| ## Requirements | ||
|
|
||
| * [Create an AWS account](https://portal.aws.amazon.com/gp/aws/developer/registration/index.html) if you do not already have one and log in. The IAM user that you use must have sufficient permissions to make necessary AWS service calls and manage AWS resources. | ||
| * [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html) installed and configured. Upgrade the CLI if you encounter command not found errors. |
Contributor
There was a problem hiding this comment.
It seems we have a hard minimum requirement on the CLI version
too old
❯ aws --version
aws-cli/2.32.34 Python/3.13.11 Darwin/25.5.0 exe/arm64
working
❯ aws --version
aws-cli/2.35.16 Python/3.14.5 Darwin/25.5.0 exe/arm64
Review feedback (PR aws-samples#3206): - README: title -> "AWS Lambda MicroVMs with Amazon S3 Files" - README: make the VPC/subnet requirement prominent (supply OR create one), document that any subnet works (public or private) and why - README: clarify stack outputs are informational; run.sh reads them by stack name - README: document the AWS CLI minimum (v2.35.0+; lambda-microvms/s3files subcommands are missing on older builds) - template: scope ConnectorOperatorRole ENI creation to the deployment's subnet + security group via resource ARNs. NOTE: the ec2:Vpc *condition key* does not work here (CreateNetworkConnector pre-validates the role without the VPC request context, so the connector fails to create); resource-ARN scoping is the validated equivalent. Reliability fixes found while validating the README end-to-end in us-west-2: - app.py: the /run hook reported mounted=true as soon as findmnt saw the mount, ~3s before the efs-proxy TLS tunnel could carry I/O, so a write issued right after `run` (e.g. `prove`) was silently lost. Add a bounded write/read/delete readiness probe and only report mounted once real I/O succeeds. Time-box the whole hook (~50s worst case) to stay under RunTimeoutInSeconds. - run.sh: `run` now waits on the /run lifecycle event's mounted flag instead of the first HTTP 200, so the documented run -> prove flow can't race the mount. - run.sh: pass the access-point root path as the run-payload prefix so the app reports correct s3:// locations (bucket + /microvm + file); prove() now polls for the exact object it wrote instead of any non-empty prefix. - template: raise Run/Resume hook timeouts 30s -> 60s for the blocking mount. - README/example-pattern: correct the cleanup sequence. The versioned data bucket blocks stack deletion; and because S3 Files keeps syncing (and flushes during teardown), empty the bucket AFTER the file system is gone: sam delete (fails on the bucket) -> empty the now-static bucket -> delete again. Use a guarded loop that also handles the already-empty case.
added lambda-microvm-s3files.json
Contributor
|
Hello @bfreiberg, thank you for your contribution. Your PR will be merged soon. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
AWS Lambda MicroVMs with Amazon S3 Files
Adds
lambda-microvm-s3files/— a pattern that mounts an Amazon S3 bucket as a POSIX file system inside an AWS Lambda MicroVM (Firecracker-isolated, snapshot-resumable serverless compute) over NFS, reachable through a VPC egress network connector, with changes synchronized to and from S3 in both directions.How it works
S3::Bucket(versioning on), theS3Files::FileSystem/MountTarget/AccessPoint, the NFS security group, theLambda::NetworkConnector(VPC egress), the IAM roles, the CloudWatch log group, and theLambda::MicrovmImage.src/run.shhelper performs the two data-plane steps that have no CloudFormation resource: packaging/uploading the app artifact (read by the image build) and launching the MicroVM viaRunMicrovm+ minting an auth token./runlifecycle hook (the VPC connector and execution-role credentials only exist at run time), and re-mounts on/resume.Contents
template.yaml— the SAM/CloudFormation templateexample-pattern.json— Serverless Land metadatasrc/—app.py(Flask app + lifecycle hooks),Dockerfile(AL2023 + amazon-efs-utils),run.shREADME.md— requirements, deployment, how-it-works, testing, cleanupTesting
Verified end-to-end in
us-west-2:sam deploy→run.sh run("mounted": true) →run.sh proveconfirms bidirectional sync (a file written through the mount appears in S3; a file written to S3 is read back through the mount).By submitting this pull request, I confirm that my contribution is made under the terms of the MIT-0 license.