Quasa
Use QUASA App
Join the pioneer of Web3 crypto freelancing today!
Open
Practical Guides

Your First Lambda MicroVM: Package, Snapshot and Launch an Isolated Job

|Author: QUASA Editorial Team|4 min read| 4
Your First Lambda MicroVM: Package, Snapshot and Launch an Isolated Job

To deploy your first AWS Lambda MicroVM, package an application and Dockerfile in a zip archive, upload it to Amazon S3, create a snapshot-backed MicroVM image, then launch one isolated runtime from that image. Wait for the runtime to reach RUNNING, create an authentication token and call its dedicated HTTPS endpoint.

The sequence below uses AWS’s Node.js example on port 8080. Choose one AWS Region, replace the bucket, account and Region placeholders, and keep the returned image ARN, MicroVM ID, endpoint and token distinct; each belongs to a different step.

1. Check that a MicroVM fits the job

Use a Lambda MicroVM when a user, session or job needs its own operating-system environment, especially for user-generated or AI-generated code, interactive development, security scanning or multi-tenant CI/CD. The AWS Lambda MicroVM overview describes VM-level isolation, full operating-system capabilities, snapshot-based startup and independently controlled ingress and egress.

A conventional Lambda function remains the simpler fit for a short, stateless event handler. A MicroVM image is a reusable template, while every call to run-microvm creates a separate environment for one tenant, session or job.

2. Prepare S3, IAM and the CLI

An S3 application artifact and a least-privilege IAM build role provide the inputs required for Lambda MicroVM image creation.

Create an S3 bucket for the source archive and an IAM build role such as MicrovmBuildRole. The role is assumed during image creation: it reads the artifact and writes build logs, but it is not the runtime execution role for the launched workload.

The official first-MicroVM tutorial specifies a trust policy granting sts:AssumeRole and sts:TagSession to lambda.amazonaws.com. Its permissions example grants s3:GetObject on arn:aws:s3:::YOUR_BUCKET/* and logs:CreateLogGroup, logs:CreateLogStream and logs:PutLogEvents on CloudWatch Logs resources. If the Dockerfile pulls from a private Amazon ECR repository, add ecr:GetAuthorizationToken and ecr:BatchGetImage.

Keep the CLI operator’s permissions separate from the build role. Before creating resources, run aws lambda-microvms help; if that command group is unavailable, update the AWS CLI rather than substituting ordinary Lambda function commands.

3. Package the service and create the image

Lambda builds the packaged service, initializes it on port 8080 and captures a reusable Firecracker snapshot.

Place app.js and Dockerfile at the archive root. The application should use Node’s HTTP module to listen on port 8080 and return JSON such as {"status":"ok","path":"/"}. Use the tutorial’s Dockerfile sequence: FROM node:24-alpine, WORKDIR /app, COPY app.js ., EXPOSE 8080 and CMD ["node", "app.js"].

  1. Package both root-level files with zip app.zip app.js Dockerfile.
  2. Upload the artifact with aws s3 cp app.zip s3://YOUR_BUCKET/app.zip.
  3. Start the build with aws lambda-microvms create-microvm-image --name my-first-microvm-image --code-artifact uri=s3://YOUR_BUCKET/app.zip --base-image-arn arn:aws:lambda:REGION:aws:microvm-image:al2023-1 --build-role-arn arn:aws:iam::ACCOUNT_ID:role/MicrovmBuildRole.
  4. Poll with aws lambda-microvms get-microvm-image --image-identifier my-first-microvm-image.

Image creation is asynchronous. Do not launch while its state is CREATING; proceed only at CREATED. For CREATE_FAILED, inspect the CloudWatch log group /aws/lambda/microvms/my-first-microvm-image.

During a successful build, Lambda executes the Dockerfile, starts the configured process and captures its initialized disk and memory state in a Firecracker snapshot. Anything generated before that boundary—including identifiers, secrets or live connections—can be inherited by every runtime created from the same image version. Generate per-job values in the /aws/lambda-microvms/runtime/v1/run hook and refresh credentials or connections in the corresponding /resume hook.

4. Launch and verify one isolated runtime

A running Lambda MicroVM returns its expected JSON response through an authenticated dedicated HTTPS endpoint.

Copy the returned imageArn into IMAGE_ARN, then launch the tutorial configuration with aws lambda-microvms run-microvm --image-identifier IMAGE_ARN --ingress-network-connectors "arn:aws:lambda:REGION:aws:network-connector:aws-network-connector:ALL_INGRESS" --egress-network-connectors "arn:aws:lambda:REGION:aws:network-connector:aws-network-connector:INTERNET_EGRESS" --idle-policy '{"autoResumeEnabled":true,"maxIdleDurationSeconds":900,"suspendedDurationSeconds":300}'.

Those managed connectors permit inbound HTTPS traffic and outbound internet access for this first test. They are not a default production policy: use NO_INGRESS when no inbound connection is required, omit unnecessary egress, or choose a VPC egress connector for private resources.

Save the returned microvmId and endpoint. Poll aws lambda-microvms get-microvm --microvm-identifier MICROVM_ID until the state is RUNNING, then create a port-scoped token with aws lambda-microvms create-microvm-auth-token --microvm-identifier MICROVM_ID --expiration-in-minutes 30 --allowed-ports '[{"port":8080}]'.

According to the AWS runtime documentation, each MicroVM has its own HTTPS endpoint, every request requires a JWE token, and inbound traffic routes to port 8080 by default. Verify the service with curl https://ENDPOINT/ -H "X-aws-proxy-auth: TOKEN"; the expected result is {"status":"ok","path":"/"}.

5. Observe suspension and clean up

The sample idle policy suspends the MicroVM after 900 seconds without endpoint traffic, allows automatic resumption when traffic returns and terminates it after 300 seconds in the suspended state. The first request after suspension may take longer while Lambda restores the checkpoint and completes the resume hook.

Terminate the test explicitly with aws lambda-microvms terminate-microvm --microvm-identifier MICROVM_ID, then use get-microvm until the state is TERMINATED. Running MicroVMs incur compute charges; suspended MicroVMs incur snapshot-storage charges but no compute charges; terminated MicroVMs incur no MicroVM charges.

Finally, delete s3://YOUR_BUCKET/app.zip if it is no longer needed, remove the test image and review its CloudWatch log group. Terminating the MicroVM releases that runtime, but it does not delete the source artifact, reusable image or logs.

Also read:

Share:

Subscribe to our newsletter

Get the latest Web3, AI, and crypto news delivered straight to your inbox.

0