AWS Builder Center

Builder Center

Set Up AWS Lambda MicroVMs Through the AWS Console

Set Up AWS Lambda MicroVMs Through the AWS Console

Series: Financial Service (19 articles)

  1. 1
    AWS Lambda MicroVMs and the End of Repeated Application Cold Initialization
  2. 2
    Set Up AWS Lambda MicroVMs Through the AWS Console This article
  3. 3
    Lambda Managed Instances for an Urgent Multi-Party Trading Workbench

Martin

Dev @ Vertex Macro

Set Up AWS Lambda MicroVMs Through the AWS Console

This walkthrough creates an AWS Lambda MicroVM image, launches a MicroVM, connects to its dedicated HTTPS endpoint, tests suspend and resume, and terminates the environment. Lambda MicroVMs are designed for isolated, stateful execution environments that retain memory and disk state across interactions, with a maximum lifecycle of up to eight hours.
Console labels may change as the service evolves. If a lifecycle action is not exposed in your current console, use the AWS CloudShell commands displayed by the service documentation.

1. Select a supported AWS Region

Sign in to the AWS Management Console.
From the Region selector in the upper-right corner, choose a Region where Lambda MicroVMs are available. Keep the following resources in the same Region:
  • The Amazon S3 artifact bucket
  • CloudWatch Logs
  • The MicroVM image
  • Network connectors
  • The running MicroVM
  • Any VPC resources used by the MicroVM
Do not start by creating an ordinary Lambda function. Lambda MicroVMs use a separate image, networking, endpoint, and lifecycle model from conventional Lambda Functions.

2. Prepare a simple test application

Create a folder named lambda-microvm-demo.
Inside the folder, create app.js:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
const http = require("http");

let sessionState = {
counter: 0,
startedAt: new Date().toISOString()
};

const server = http.createServer((req, res) => {
if (req.url === "/increment") {
sessionState.counter += 1;
}

res.writeHead(200, {
"Content-Type": "application/json"
});

res.end(JSON.stringify({
status: "ok",
path: req.url,
state: sessionState
}));
});

server.listen(8080, () => {
console.log("Application listening on port 8080");
});
Create a file named Dockerfile in the same folder:
1
2
3
4
5
6
7
8
9
FROM node:24-alpine

WORKDIR /app

COPY app.js .

EXPOSE 8080

CMD ["node", "app.js"]
The application uses an in-memory counter so that you can prove the state remains available after suspending and resuming the MicroVM.

3. Create the ZIP artifact

The Dockerfile and application file must be located at the root of the ZIP archive.
The archive should look like this:
1
2
3
lambda-microvm-demo.zip
├── Dockerfile
└── app.js
On Linux, macOS, or AWS CloudShell:
1
2
cd lambda-microvm-demo
zip lambda-microvm-demo.zip Dockerfile app.js
Do not create this structure:
1
2
3
4
lambda-microvm-demo.zip
└── lambda-microvm-demo
├── Dockerfile
└── app.js
An extra directory level can prevent the image builder from finding the Dockerfile.

4. Create an Amazon S3 artifact bucket

Open the Amazon S3 console.
Choose Create bucket.
Use a globally unique name, for example:
1
lambda-microvm-artifacts-123456789012-us-east-1
Configure the bucket as follows:
  • Keep Block all public access enabled.
  • Enable default server-side encryption.
  • Enable bucket versioning if you need artifact traceability.
  • Add project, environment, owner, and cost-center tags.
  • Create the bucket in the same Region selected for Lambda MicroVMs.
Open the bucket and create a prefix such as:
1
microvm-images/trading-workbench/
Upload lambda-microvm-demo.zip to that prefix.

5. Create the MicroVM build role

Open the AWS Identity and Access Management console.
Go to Roles and choose Create role.
Select Custom trust policy and enter:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
Name the role:
1
lambda-microvm-build-role
After creating the role, open it and add an inline permissions policy:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ReadMicroVMArtifact",
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::YOUR-BUCKET-NAME/microvm-images/trading-workbench/*"
]
},
{
"Sid": "WriteBuildLogs",
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "arn:aws:logs:*:*:*"
}
]
}
Replace YOUR-BUCKET-NAME with the actual bucket name.
If the Dockerfile pulls software from a private Amazon Elastic Container Registry repository, add only the required ECR permissions, such as ecr:GetAuthorizationToken and ecr:BatchGetImage. The build role should not receive application runtime permissions or general administrative access.

6. Create a separate runtime execution role

Still in the IAM console, create another role using the same trust policy.
Name it:
1
lambda-microvm-runtime-role
For a basic test, give it permission to write runtime logs:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "WriteRuntimeLogs",
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "arn:aws:logs:*:*:*"
}
]
}
For a production financial-services environment, add only the access required by the application, for example:
  • Read access to an approved Amazon S3 portfolio prefix
  • Write access to a session-specific result prefix
  • Access to selected AWS Secrets Manager secrets
  • Access to named Systems Manager parameters
  • Permission to publish approved CloudWatch metrics
  • Access to specific internal APIs through a VPC connector
Do not reuse the build role as the runtime role. Separating the roles prevents image-building permissions from becoming runtime application permissions.

7. Open Lambda MicroVMs

Open the AWS Lambda console.
In the left navigation, locate MicroVMs.
Select MicroVM images and choose Create MicroVM image.
If the MicroVM menu is not visible:
  1. Confirm that you selected a supported Region.
  2. Confirm that your IAM identity can list and create Lambda MicroVM resources.
  3. Refresh the Lambda console.
  4. Check the official Lambda MicroVM documentation for current Regional availability.
  5. Try another supported Region approved by your organization.

8. Configure the MicroVM image

Enter an image name:
1
lambda-microvm-demo
Provide a description such as:
1
Stateful Node.js MicroVM demonstration
For the application artifact, select the S3 bucket and object:
1
s3://YOUR-BUCKET-NAME/microvm-images/trading-workbench/lambda-microvm-demo.zip
Select:
1
lambda-microvm-build-role
Choose the AWS-managed MicroVM base image presented by the console.
Configure baseline memory. For a simple Node.js test, begin with the default baseline unless the console or documentation requires another value.
Add tags such as:
1
2
3
4
5
Application=lambda-microvm-demo
Environment=development
Owner=cloud-platform
DataClassification=internal
CostCenter=technology

9. Configure build networking

Build networking controls what the image-building environment can reach.
If the test application has no private dependencies, select the most restrictive build egress option that still permits the Dockerfile to retrieve required public packages or base layers.
If dependencies reside inside a VPC:
  1. Create or select a VPC network connector.
  2. Select private subnets with appropriate routes.
  3. Attach restrictive security groups.
  4. Allow access only to required repositories or endpoints.
  5. Avoid unrestricted internet egress.
Build-time networking and runtime networking should be treated as separate trust boundaries.

10. Build the MicroVM image

Review the configuration and choose Create image or Build image.
The image should progress through states similar to:
1
2
3
PENDING
IN_PROGRESS
SUCCESSFUL
During the build, Lambda:
  1. Downloads the ZIP artifact from Amazon S3.
  2. Executes the Dockerfile.
  3. Starts the application.
  4. Waits for application initialization.
  5. Captures the initialized memory and disk state.
  6. Creates a reusable snapshot-backed MicroVM image.
If the build fails, open its details and follow the link to Amazon CloudWatch Logs. Check for:
  • Dockerfile not located at the ZIP root
  • Invalid FROM image
  • Application process exiting
  • Incorrect file names
  • Missing S3 permissions
  • Missing logging permissions
  • Blocked network access
  • Application not listening on the expected port

11. Launch a MicroVM

After the image reaches a successful state, open the image version.
Choose Run MicroVM.
Select the runtime execution role:
1
lambda-microvm-runtime-role
For ingress, choose the connector that permits access to application port 8080.
For egress, choose one of the following:
  • No egress, if the application does not call external services
  • Internet egress for a controlled development test
  • A VPC egress connector for private APIs and enterprise workloads
For production FSI workloads, prefer a VPC egress connector with inspected and allow-listed destinations.

12. Configure the idle and maximum-duration policies

For an initial test, configure:
1
2
3
4
Suspend after idle period: 15 minutes
Automatic resume: Enabled
Suspended duration: 30 minutes
Maximum session duration: 1 hour
The exact console field names may vary.
Although Lambda MicroVMs can preserve memory and disk state for up to eight hours, use a shorter maximum duration for the initial test. Increase the duration only after validating security, cleanup, cost, and application resume behavior.

13. Configure runtime logging

Enable CloudWatch logging.
Use a log group such as:
1
/aws/lambda-microvms/lambda-microvm-demo
Set an appropriate retention period.
Do not write the following into logs:
  • Authentication tokens
  • Passwords or API keys
  • Customer personal information
  • Complete portfolios
  • Order details
  • Proprietary model inputs
  • Secrets obtained through Secrets Manager
Choose Run MicroVM and wait until its state becomes RUNNING.

14. Create an authentication token

Open the running MicroVM’s details page.
Locate:
  • MicroVM identifier
  • Image version
  • Lifecycle state
  • Dedicated HTTPS endpoint
  • Start time
  • Maximum termination time
Choose Create authentication token.
Configure the token to permit only port 8080 and use a short expiration time, such as 15 minutes.
A token should be treated like a temporary credential. Do not put it in source code, Git repositories, screenshots, support tickets, persistent logs, or browser bookmarks.

15. Test the application

Use the console-provided connection example, CloudShell, or an approved local terminal.
The request pattern will resemble:
1
2
3
curl \
-H "X-aws-proxy-auth: YOUR_AUTH_TOKEN" \
"https://YOUR-MICROVM-ENDPOINT/"
The response should resemble:
1
2
3
4
5
6
7
8
{
"status": "ok",
"path": "/",
"state": {
"counter": 0,
"startedAt": "2026-09-24T10:00:00.000Z"
}
}
Call the increment endpoint:
1
2
3
curl \
-H "X-aws-proxy-auth: YOUR_AUTH_TOKEN" \
"https://YOUR-MICROVM-ENDPOINT/increment"
Call it several times and confirm that the counter increases.

16. Suspend and resume the MicroVM

From the MicroVM details page, choose Suspend.
Wait until its state becomes SUSPENDED.
Then choose Resume. If automatic resume is enabled, calling the HTTPS endpoint may initiate the resume operation.
Create a new authentication token if the previous token has expired, then call the application again:
1
2
3
curl \
-H "X-aws-proxy-auth: YOUR_NEW_AUTH_TOKEN" \
"https://YOUR-MICROVM-ENDPOINT/"
Confirm that:
  • The counter retains its previous value.
  • The startedAt value remains unchanged.
  • The MicroVM returns to running state.
  • The application does not repeat its complete initialization.
  • Memory and disk state remain available.

17. Validate resume safety

A production application must not assume the external world was suspended with the MicroVM.
After every resume, the application should:
  • Refresh temporary AWS credentials.
  • Revalidate the user’s current authorization.
  • Reconnect to databases and internal APIs.
  • Revalidate the current business date.
  • Confirm market-data timestamps.
  • Reload volatile reference data.
  • Check the approved model version.
  • Confirm that secrets have not been rotated.
  • Reject calculations until freshness checks succeed.
Preserving state should remove unnecessary initialization, but it must not preserve expired trust.

18. Terminate the MicroVM

After testing, return to the MicroVM details page and choose Terminate MicroVM.
Confirm that:
  • The lifecycle state becomes terminal.
  • The endpoint no longer responds.
  • Previously issued tokens no longer provide access.
  • Required results have been written to durable storage.
  • Temporary working state is removed.
  • CloudWatch logs remain available according to retention policy.
Suspending a MicroVM does not end its lifecycle. Terminate it when the business session is complete to release resources.

19. Recommended production controls

Before using Lambda MicroVMs for an enterprise or trading workload, implement:
  • Separate development, testing, and production AWS accounts
  • Explicit image-version pinning
  • Automated image vulnerability scanning
  • Dependency and software bill of materials validation
  • Least-privilege build and runtime roles
  • VPC-based controlled egress
  • Short-lived, port-restricted authentication tokens
  • CloudTrail API auditing
  • CloudWatch alarms for failed launch, suspension, resume, and termination
  • Automatic termination of abandoned sessions
  • Durable checkpoints outside the MicroVM
  • Resume-time authorization and freshness checks
  • Application, owner, environment, and cost-allocation tags
  • Service quota and concurrency monitoring
  • Disaster-recovery and image-rebuild procedures
The AWS console is appropriate for the first controlled implementation. After the workflow is validated, move image creation, version promotion, network configuration, session launch, and termination into infrastructure as code and an authorized control-plane service.

References

  • AWS Lambda Developer Guide, Create your first Lambda MicroVM: https://docs.aws.amazon.com/lambda/latest/dg/microvms-getting-started.html
  • AWS Lambda Developer Guide, AWS Lambda MicroVMs: https://docs.aws.amazon.com/lambda/latest/dg/lambda-microvms-guide.html
  • AWS Lambda MicroVMs product page: https://aws.amazon.com/lambda/lambda-microvms/

Series: Financial Service (19 articles)

  1. 1
    AWS Lambda MicroVMs and the End of Repeated Application Cold Initialization
  2. 2
    Set Up AWS Lambda MicroVMs Through the AWS Console This article
  3. 3
    Lambda Managed Instances for an Urgent Multi-Party Trading Workbench
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article